I have actually had a little bit of time to look at this code in more detail and
shift it over to my camera view frustum scene --- whereupon it doesn't see the
SURFACE unless the plane is included, and then that's the only thing it sees...

But I do agree, after back-tracking through the code, that dir_xy, which is used
in the trace () call has a high probability of being the culprit.

Having said that, the whole manner in which this macro works with vaxis_rotate
is a bit hard to follow, and it may be easier to start from first principles.


I think that if you look at the screen.inc code, you'll see that all you're
doing is using normalized coordinates in screen space.
If you just extend that vector, you "reach out" into the scene past z=1.
(assuming a default camera)
This ought to be a matter of the same simple trig, with no hard-to-follow (and
verify by hand) rotating vectors around axes.
So more than half the work is already done.
{Just erase all the stuff about object dimensions and offsets, etc. since we're
only working with a single point.}

I propose a new format for the scene - have three independent code blocks,
chosen with a switch/case/break/end block.

0.  The current Norbert Kern / Kenneth Walker code
1.  a method which is a simple extension of screen.inc object placement
2.  a method which uses a matrix

In this way they can be wrapped in a loop and executed sequentially in the same
scene run, to compare the results of the different methods of calculation.

I'm suggesting this because working it out by method 1 ought to help unravel
what's going on with method 0, and method 2 will just be points for style   :)

I have to do a bunch of IRL stuff today - but hopefully I will be able to return
to this in the near future and have some code snippets of my own to offer.

Post a reply to this message