To get to a box versus box test in axis-aligned space, first need to go through line versus box (cuboid) collision test.
Parameters:
1. Need an origin point XYZ.
2. Need an end point (XYZ) using ...
2. ... line slope XYZ.
3. Need bounding box mins  (X LEFT, Y TOP, Z NEAR)
4. Need bounding box macs (X RIGHT, Y BOTTOM, Z FAR)
A bounding box is define by 6 planes, each plane with a slope.  In axis-aligned space (no angles for cuboid) ...
1. Front face.  X left, Y top through X right, Y bottom.  Z Near.  Check to make sure LINE origin Z <= ZNEAR <= Line end Z (if not, cannot have hit.  Collision = False).  Calculate LINE at Z Near.  Call result Point_At_Plane.  If X Left <= Point_At_Plane (X) =< X Right and Y Bottom <= Point_At_Plane (Y) <= Y Bottom.  We have collision.  Collision point is Point_At_Plane (X) and Point_At_Plane (Y).
2. Blah
3. Blah
4. Blah
5. Blah again?  Yes
6. Guess what?  Answer is blah.  Surprised?  No.
In fact, any cuboid can be pulled into axis-aligned space as long as you do the same calc on the line slope.
[I guess after writing this code, the next step is plane versus cube.  Quake has entities move in turn, so there is no need for a cube versus cube test for motion.  It is plane versus plane.  But a plane moving is a cuboid in a way with a Z depth of the motion length.  And not really a plane.  Looks like  might have some of this already worked out.  I still want to work through the calks myself step by step, but I don't want to step up to the eventual matrix maths without being able to code the simpler axis-aligned stuff myself.]
Maybe only 16 steps away from being able to write the Worldcraft "carve" tool function.  Sigh ..
			