Christoph Hormann <chr### [at] gmxde> wrote in
news:3D4E948F.6A8571BB@gmx.de 
>> Only disadvantage is it's speed in some cases.
>> I have idea for a opimization, that in some cases can prove _realy_
>> fast. 

> A few thoughts about that:
> It's out of question that the isosurface intersection test is
> something that could be improved. 

so I'll be hepay to help in improving it :) 

> There are various possible
> approaches to achieve speed improvements, for example based on
> precalculations and caching of function values.  

> What's most important
> for such an improvement IMO is that it should not be too specialized
> for a particular type of function. 

it's useful for all functions
 
> And you should probably be careful when promising an enormeous speed
> improvement.

I'm preparing some tests right now :)

> Concerning your suggestion, you should probably try out 'evaluate' and
> play with the parameters, dividing a larger isosurface into smaller
> ones is a useful trick, but the borders are often a problem,
> especially if you also use different accuracy values.

yes, that's wy I want that future to be coded into POV, and using union 
{...} of iso's is just for testing purpose, because it doesn't take into 
account artefacts on borders of bounding boxes


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message