The following is a minimal scene to reproduce this. It requires a 
perfect storm of using a micronormal, blurring, and a high amount of 
dispersion samples to cause POV-Ray to run away with allocating memory.

------ BEGIN POV CODE -------
#declare n1 = normal
{
     crackle .5
     scale 0.001
     accuracy 0.0001
}

#declare n2 = normal
{
     bumps 0
}

camera
{
     location <0, 0.2, -1>
     look_at <0.4, 0.3, 1>

     focal_point <0.4, 0.3-.0, 1>
     blur_samples 25
     confidence .9
     variance 0
     aperture .05
}

light_source
{
     <-10, 10,-5>, rgb 1.5
     area_light x*2,y*2,7,7 orient adaptive 2
}

sphere{ <0, 0, 0>, 0.5 pigment {color rgbf <0.85,1,.95,1>}

     interior
     {
         ior 1.5
         fade_color rgb <0.0, 0.5, 0.0>
         fade_power 2
         fade_distance 10.5
         dispersion 1.1
         dispersion_samples 100
     }

     normal {

         checker normal{n2} normal{n1}
         scale 0.1
         warp { spherical }

     }

     translate z*1
}
------- END POV CODE ------

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:
> The following is a minimal scene to reproduce this. It requires a 
> perfect storm of using a micronormal, blurring, and a high amount of 
> dispersion samples to cause POV-Ray to run away with allocating memory.

Runs OK in 3.6, I think this might actually be a bug.


-- 
~Mike

Post a reply to this message

Mike Raiford schrieb:
> The following is a minimal scene to reproduce this. It requires a 
> perfect storm of using a micronormal, blurring, and a high amount of 
> dispersion samples to cause POV-Ray to run away with allocating memory.

The memory consumption is alarming even without the dispersion, rising 
as high as 1.6 GB for a 800x600 render on 8 threads.

The reason appears to be a humongous amount of crackle cache data: The 
crackle pattern is only semi-procedural, requiring random values to be 
computed and cached for subsequent queries, with a fixed amount of data 
per unit-cube in crackle pattern coordinate space. Using crackle for 
micronormals is therefore a bad idea: Scaled smaller than the density of 
actual ray-object-intersections computed, it will eventually lead to a 
separate crackle cache entry being created for each and every 
intersection. Memory consumption will then grow with every additional 
ray being traced, which is fatal with e.g. focal blur or dispersion that 
create a huge amount of rays per pixel.

With bumps instead of crackle, memory requirements stay virtually at 
idle level. Given that you can't make out the crackle structure at such 
a scale anyway, that's the way to go. If you need a different 
distribution of "slope probabilities" than the standard bumps pattern 
(e.g. to simulate a basically polished surface with comparatively sparse 
microsopic scratches), you may want to try bumps with a slope_map.

Post a reply to this message

clipka wrote:
> Mike Raiford schrieb:
>> The following is a minimal scene to reproduce this. It requires a 
>> perfect storm of using a micronormal, blurring, and a high amount of 
>> dispersion samples to cause POV-Ray to run away with allocating memory.
> 
> The memory consumption is alarming even without the dispersion, rising 
> as high as 1.6 GB for a 800x600 render on 8 threads.

Oh, wow. I thought it was the dispersion + micronormal.

> The reason appears to be a humongous amount of crackle cache data: The 
> crackle pattern is only semi-procedural, requiring random values to be 
> computed and cached for subsequent queries, with a fixed amount of data 
> per unit-cube in crackle pattern coordinate space. Using crackle for 
> micronormals is therefore a bad idea: Scaled smaller than the density of 
> actual ray-object-intersections computed, it will eventually lead to a 
> separate crackle cache entry being created for each and every 
> intersection. Memory consumption will then grow with every additional 
> ray being traced, which is fatal with e.g. focal blur or dispersion that 
> create a huge amount of rays per pixel.

Makes sense...

> With bumps instead of crackle, memory requirements stay virtually at 
> idle level. Given that you can't make out the crackle structure at such 
> a scale anyway, that's the way to go. If you need a different 
> distribution of "slope probabilities" than the standard bumps pattern 
> (e.g. to simulate a basically polished surface with comparatively sparse 
> microsopic scratches), you may want to try bumps with a slope_map.

Thanks for that. Honestly, I don't know why I was using crackle in this 
scene in the first place.

(I've been going through old test scenes, doodles and such with 3.7 to 
see how they render, etc...)



-- 
~Mike

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4a9fe4fe$1@news.povray.org...
> The reason appears to be a humongous amount of crackle cache data: The 
> crackle pattern is only semi-procedural, requiring random values to be 
> computed and cached for subsequent queries, with a fixed amount of data 
> per unit-cube in crackle pattern coordinate space. Using crackle for 
> micronormals is therefore a bad idea: Scaled smaller than the density of 
> actual ray-object-intersections computed, it will eventually lead to a 
> separate crackle cache entry being created for each and every 
> intersection. Memory consumption will then grow with every additional ray 
> being traced, which is fatal with e.g. focal blur or dispersion that 
> create a huge amount of rays per pixel.
>

Ah! It is good to be reminded of this. The crackle issue has come up earlier 
already, but I confess that I almost forgot about it and so am often using 
crackle in a micro normal. Thanks Christoph.

Thomas

Post a reply to this message