>> Aahhh... use an *array* of functions... I wasn't sure if you could 
>> actually do that... yes, that saves writing an include file and 
>> reading it back... great!
> 
> 
> Yes that's one possible solution. But you can also make a
> recursive macro that assembles the function directly without
> using an include file. (Like the ones in my NURBS code.)
> 
> I guess that functions built the latter way will be faster,
> because calling other functions within a function takes time.

Yeah, but the whole point is that passing a value to another function 
allows me to reuse a number multiple times without recalculating it...

>>>> Thanks for that!
>>>
>>> Just glad to help.
>>
>> Maybe you should do it for a living. ;-)
> 
> Hehe - I have been working as a math and electronics teacher
> for the last half year. Now I'm looking for a new job.

Hmm... fair enough!

>> Out of interest... is there a document anywhere that explains the 
>> messy details of how POV-Ray's isosurface drawing system actually 
>> works? (Other than the source code of course. :-P)
> 
> Christoph Hormann has written a little about this:
> 
> http://www-public.tu-bs.de:8080/~y0013390/fast_iso/patch.html
> 
> On that page you'll also find a link to a news posting where
> Ryoichi Suzuki gives a brief explanation of the algorithm he
> used.
> 
> Apart from this I haven't seen anything.
> - But reading a little about numerical analysis won't hurt :)
> (Especially about root finding methods.)

Right... so... essentially, POV-Ray starts with the segment of the ray 
that's inside the isosurface's container, and then does a straight 
binary chop looking for intervals where the sign changes (or where the 
sign could potentially change, given the specified max_gradient). Is 
that about right?

So POV-Ray doesn't use (and hence isn't bothered about), e.g., "flat" 
areas in the function? (And presumably it won't be too upset about 
single points where the function reaches infinity or isn't defined.)

I take it POV-Ray also doesn't save any of the points it's sampled and 
reuse them in any way to speed up subsequent ray intersection tests?

(I presume max_gradient = 17 means that for every POV-unit you travel, 
the function's value changes up or down by a maximum of 17? Yes? In that 
case, I would imagine if the function evaluates to 1,287 at one 
particular point, you can safely say that there are no intersections 
within about 75 POV-units of that point. This would seem to be useful 
information to reuse...)

(...but then... how to recall that information in an efficient way?... I 
suppose you could generate a low-resolution voxel grid and mark all 
areas which definitely DON'T contain part of the surface... but it looks 
like that's exactly what Christoph's patch does!)

Thanks.
Andrew @ home.

Post a reply to this message