On 4/30/20 12:21 PM, Cousin Ricky wrote:
...
> 
>> I've never gotten to where evaluate is part of my isosurface flow... 
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've 
>> also not stuck with using it. Am I'm missing bigger possible gains?
> 
> In my experience it helps with POV-Ray 3.6, but slows things down with 
> POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask 
> the group about this anomaly, but I never got a round tuit (POVers 
> charge a premium for those!), and I cannot find my records of the timing 
> statistics.  I don't normally use it, but I believe Thomas de Groot uses 
> it a great deal.

Hmm, That stinks of a thread safety issue. Let me take a quick look at 
the code.

On a quick read I agree with comments left long ago from the core 
developers - evaluate is not thread safe... ;-)

Also sort of looks like the on the fly evaluate adjustments are sticky 
for the isosurface. Meaning they are not done on a ray by ray basis 
which itself is questionable except with really well behaved functions 
(no sharp edges / local high gradients).

All doesn't mean things won't kinda sorta work if you set the right 
limiting parameters. Isosurfaces are like that...

Will take a deeper look before 'boom,' but think this feature just made 
my povr nuke it list. There is considerable overhead for it even when 
not using it.

If someone wants to test how much performance we get in v37, v38 by 
using it, running with one thread best for accuracy. Unsure what to 
trust results wise. A box with sharpish edges - it might adjust the 
internal gradient downward to where the image at the sharp edges changes 
(sharper bits get missed). Who knows, maybe this would make for a 
smoother image on average, certainly would render faster.

If folks do turn up performance numbers, I am still interested.

Bill P.

Post a reply to this message