POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Attached to Project: POV-Ray
Opened by Michael Raiford - 2009-09-03
Last edited by Chris Cason - 2012-09-04

FS#56 - Crackle pattern in some situations can cause runaway memory allocation

(This happens as of beta 34)

The following scene will cause POV-Ray to allocate memory until all available memory is used, resulting in an Out of Memory error message:

#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
} 
Closed by  Chris Cason
Tuesday, 04 September 2012, 20:47 GMT
Reason for closing:  Fixed
Admin
Christoph Lipka commented on Wednesday, 09 September 2009, 09:59 GMT

Original title of this entry was “Dispersion in some situations can cause runaway memory allocation”, and category “Backend...Texture/Material/Finish”.

The underlying problem here, however, is not in the dispersion, but in the crackle pattern being scaled particularly small, and at the same time the number of rays shot being particularly high (due to focal blur and dispersion), which leads to a horrendous amount of crackle cache data being gathered.

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. 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, including secondary rays due to e.g. dispersion.

This is probably more a documentation issue: Users should be warned about the consequences associated with scaling the crackle pattern too small.

Admin
Chris Cason commented on Wednesday, 01 December 2010, 15:39 GMT

I've checked in some changes which will mitigate this issue (change #5129).

After the cache reaches a certain size (currently 30mb per thread - this needs to be configurable but isn't yet), new entries for that particular block will be discarded after they are calculated. Starting a new block will allow the caching to resume working again. While discarding the data is of course inefficient, it's still preferable to chewing up 100% of the available physical RAM and then hitting the swapfile.

This still needs to be documented though. We might also want to add code to trigger a warning if the limit is hit during a render.

Grimbert Jérôme commented on Wednesday, 09 February 2011, 19:16 GMT

renderering with 3.7RC3+ (-H160 -W160 -A) took:
* 308 seconds with 1 thread (307.610 CPU-seconds total)
* 87 seconds with 10 threads (387.545 CPU-seconds total)

memory is kept low, picture is full black.

Thorsten Fröhlich commented on Tuesday, 23 August 2011, 06:38 GMT

memory is kept low, picture is full black.

I assume this is the expected behavior and this can be closed?

Admin
Christoph Lipka commented on Thursday, 25 August 2011, 18:53 GMT

Confirmed. We don't see anything because the only object in the scene has no opaque component (filter 1).

Admin
Christoph Lipka commented on Thursday, 25 August 2011, 18:54 GMT

This hasn't been done yet though:

This still needs to be documented though. We might also want to add code to trigger a warning if the limit is hit during a render.
Jim Holsenback commented on Thursday, 25 August 2011, 19:11 GMT

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing