clipka wrote:
> If you want to keep the "Ray" class lightweight, fine - but then define a
> separate kind of "companion" data object for this type of information (it could
> then also contain all those flag currently in "Ray"). Misusing the "Trace"
> object as a container for this information is a bad idea - and not passing it
> as a parameter, but instead relying that a certain function be only called by a
> certain "Trace" object, is a *very* bad one.

I disagree. Trace is the algorithm, and as such it controls recursion. A ray 
does neither, and all you end up with is an uncontrollable recursion 
counter. As the recursion limit is a property of trace, there is no way a 
ray could enforce the limit. So what do you gain by adding the recursion 
level to a ray? - Nothing. What feature gets lost? - The ability to control 
the recursion limit. -- And that you do not want!!!

The real issue is different, and I can understand you confusion: The 
lighting code has a problem with division of work, in 3.7 it is just 
slightly better than in previous versions of POV-Ray. Once there is (4.0) a 
clear separation of the tracing and the lighting computations (and those of 
textures), it will be very clear that there are two algorithms (lighting and 
tracing). At that point the question why the recursion limit is a property 
of trace will become clear. Essentially you have to see radiosity as a 
variant of the lighting algorithm that makes use of the tracing algorithm 
like all other lighting algorithms use the tracing algorithm. Basically, 
what you have is this (ignoring texturing):

intersection = trace(ray);
color = lighting(intersection);


	Thorsten

Post a reply to this message