Ron Parker wrote:
/.../ 
> I agree that there's a problem.  Perhaps the proper solution is to
> make it easier to compare vector quantities, so that something like
> "#if (mynormal=0)" will work.  Then, the code to compare the normal
> vector would be almost the same as the code to compare a boolean,
> without having to add yet another parameter to an already big list.
> 
> Right now, inexplicably, the expression "mynormal=0" returns a
> vector with true wherever the corresponding component of
> mynormal is zero and false wherever it's not.

Uh... You lost me there. Surely #if (mynormal=0) returns an error? What do you
mean by "mynormal=0 returns a vector with true"? Could you explain?
Otherwise this one is a minor problem; I don't know whether trace() will be
mostly used in cases of quaranteed intersection or not.

/.../
> time) over testing the result yourself, because the built-in trace 
> functions don't have any limits on depth.  That is, it'd still have 
> to find all the intersections and check the distance to the closest 
> one, just like you're doing now in POV code.  Of course, some
> objects could have more optimal tests, but that would make for
> some pretty big changes.

You could optionally limit the trace function with a bounding sphere (or have
the user specify a bounding object?): when this is hit, trace() would return 0.

Margus

Post a reply to this message