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.

Tasklist

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

Attached to Project: POV-Ray
Opened by Michael Raiford (mraiford) - Thursday, 03 September 2009, 15:14 GMT
Last edited by Chris Cason (chrisc) - Tuesday, 04 September 2012, 20:47 GMT
Task Type Possible Bug
Category Backend → Texture/Material/Finish
Status Closed
Assigned To Chris Cason (chrisc)
Operating System Windows XP
Severity Medium
Priority Normal
Reported Version 3.70 beta 34
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

(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
} 
This task depends upon

Closed by  Chris Cason (chrisc)
Tuesday, 04 September 2012, 20:47 GMT
Reason for closing:  Fixed
Comment by Christoph Lipka (clipka) - Wednesday, 09 September 2009, 09:59 GMT
  • Field changed: Summary (Dispersion in some situations can cause runaway memory allocation → Crackle pattern in some situations can cause runaway memory allocation)
  • Field changed: Status (Unconfirmed → New)
  • Field changed: Category (Texture/Material/Finish → Documentation)
  • Field changed: Severity (High → Medium)

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.

Comment by Chris Cason (chrisc) - 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.

Comment by Grimbert Jérôme (Le_Forgeron) - 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.

Comment by Thorsten Fröhlich (thorsten) - 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?

Comment by Christoph Lipka (clipka) - 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).

Comment by Christoph Lipka (clipka) - 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.
Comment by Jim Holsenback (jholsenback) - Thursday, 25 August 2011, 19:11 GMT

Loading...