Crash with example scene glass-of-water when increasing max_depth and max_mirror_depth about openmoonray HOT 9 CLOSED

Increasing the depth to higher counts will put more pressure on the C++ stack, which holds information about the order handlers will get executed in, how many elements in each queue are left to process and so on. There is a stack overflow protection mechanism which kicks in at some point for safety where queued material evaluations are saved off to the side for deferred processing without increasing the handler stack depth any further (it seems this is where the bug is). One thing you could try is to grep the codebase for the line:

#define MAX_EXCL_ACCUM_STACK_SIZE 1024

and set it to a sufficiently high value (e.g. 4096) such that you don't see the deferEntriesForLaterProcessing errors any longer. As long as the stack doesn't overflow, your scene should render in vector mode.

From a performance point of view, since this scene contains a lot of specular bounces/transmissions, one thing to try would be to set the bsdf_sampler_strategy attribute to "one-sample" or "one-lobe", and the bsdf_samples attribute to 1. These attributes are mentioned here.

from openmoonray.

A caution: changing the bsdf_sampler_strategy switches to different integrator code that is a bit experimental, so you may see look differences when changing this mode from the default.

from openmoonray.

The messages up to Warning (lib.render): Multiple calls to Material::deferEntriesForLaterProcessing encountered, no more will be reported this frame. is shown very fast, and then the progress kept 0% , but DEBUG (lib.render): Block size too small to satisfy allocation in arena allocator, 34656256 wanted (64 byte aligned), 33554432 block size. is shown much much later, just before SIGSEGV.

from openmoonray.

Thanks for the report. You may be able to work around this issue by using the scalar integrator.

I believe the command line option is -exec_mode scalar, but I am not in front of a computer.

from openmoonray.

@kjeffery Thanks for the reply! Indeed, it doesn't crash in scalar mode:

moonray -in scene.rdla -in scene.rdlb -out /tmp/glass-of-water.exr -res 8.0 -debug -exec_mode scalar

However, the execution times seems to be exponential with respect to max_depth? Here is the total time for depth 8~12:

Then I continued experiments with max_adaptive_samples = 64 and the result is:

As a comparison, when rendered with pbrt v4 CPU mode, it takes 65 seconds with full resolution and spp=64. Here is the start of the pbrt file (converted to v4)

Integrator "bdpt"
    "integer maxdepth" [ 33 ]
Transform [ 0.999993 -0.0000592354 0.00373545 -0 7.27596e-12 0.999874 0.0158556 -0 0.00373592 0.0158555 -0.999867 -0 -0.0065528 -3.10084 25.6268 1  ]
Sampler "independent"
    "integer pixelsamples" [ 64 ]
PixelFilter "triangle"
    "float xradius" [ 1 ]
    "float yradius" [ 1 ]
Film "rgb"
    "string filename" [ "glass-of-water.png" ]
    "integer yresolution" [ 720 ]
    "integer xresolution" [ 1280 ]
Camera "perspective"
    "float fov" [ 20.114292 ]

If I changed it to 1/8 resolution (i.e. 160x90), it only takes 1 second.

I understand that the comparison doesn't make much sense and I noticed that with max_adaptive_samples = 64, the image is much cleaner than pbrt's spp=64, but I pbrt doesn't seem to have such a high growth of runtime when increasing maxdepth.

Is this the expected behavior? What should I do if I really need to set high maxdepth? In this case, I don't care about "correctness", just want it to look good and avoid very dark areas.

from openmoonray.

Thank you! bsdf_sampler_strategy is exactly what I'm looking for! Now that scalar mode can render even max_depth=64 with a small amount of time (without changing bsdf_samples to 1).
My final sceneVariables is:

SceneVariables {
    ["image_width"] = 1280,
    ["image_height"] = 720,
    ["lights_visible_in_camera"] = true,
    ["output_file"] = "",
    ["max_depth"] = 32,
    ["max_diffuse_depth"] = 2,
    ["max_glossy_depth"] = 8,
    ["max_mirror_depth"] = 32,
    ["max_adaptive_samples"] = 1024,
    ["min_adaptive_samples"] = 16,
    ["sampling_mode"] = 2,
    ["target_adaptive_error"] = 10,
    ["bsdf_sampler_strategy"] = "one-sample",
}

With this config, vectorized mode no long crashes even with depth=64 (and I didn't bother rebuilt it with MAX_EXCL_ACCUM_STACK_SIZE increased), but the result is darker (scalar mode's result matches pbrt's), so I guess there's still some bug. Anyway, I'm happy with this scene now. Thanks you both :)

from openmoonray.

Thanks @jmahovsky-dwa ! Actually I was wondering whether it's possible to switch bsdf_sampler_strategy based on current depth (e.g. only when the current depth is high, use "one-sample" strategy), by hacking some code, but forgot to ask. Based on your reply, it looks difficult or impossible :(

Most of our scenes don't have such problem but we can't know in advance, so I prefer some kind of "adaptive" behavior which uses the default integrator most of the time.

from openmoonray.

Yeah, the sampler strategy is currently an all-or-nothing thing. Yes, it does make sense to use fewer samples at greater depths but the integrator doesn't currently support that.

from openmoonray.

Understood. Thanks for the clarification!

from openmoonray.