POV-Ray

Until the bug is fixed, it can be worked around by applying a (slightly) reflective finish to the blob as a whole.

Not only related to blob, seems to apply also to merge (whereas union give a differente result)

for instance the attached scene report a max recursion of 11/30 (rendered at 800x600).
Remplacing merge with union: 16/30
no CSG: 16/30
No visible difference in both picture, so must be related to the "missing" increase of max level.

Tested with beta 34, from source, on linux amd64

   sphere.pov (1.3 KiB)

I was unable to reproduce a stalled hall of mirrors render using only a merge.

In Le Forgeron's scene the messaged Max Level is normal,
reported rays do not exceed the set limit,
the rays reached the ADC_bailout before max_trace_level.

The stalling bug is likely limited to reflective blobs.

I can get the OP scene to render fine with a 1 line change:

--- a/source/backend/render/trace.cpp   Thu Sep 17 18:46:25 2009 +0200
+++ b/source/backend/render/trace.cpp   Sun Sep 20 12:06:18 2009 +0200
@@ -192,7 +192,7 @@
                bestisect.Object->incrementsTraceLevel ||
                ray.IsRadiosityRay();
 
-       if(traceLevelIncremented)
+       //if(traceLevelIncremented)
        {
                // Set highest level traced.
                ticket.traceLevel++;

With that change, sphere.pov (my scene) renders with merge/union/nothing always at 11/30
(previously, merge would have got 11, union & nothing 16!)
Seems more consistent, as there is no refraction in the scene, merge would not be different from union/nothing, from the point of view of seen surface and computation.

Now the real trick would be to understand the setting of the boolean traceLevelIncremented
Why is it needed ?
Is there a trick about bestisect.Object→incrementsTraceLevel ?

I think the extra traces in sphere.pov are from leakage at the CSG seams,
that probably is a different bug from the blobs stalling. Maybe you should
open a new bug report for it.

It looks to me like traceLevelIncremented is just a flag that the level
is higher than the last reported highest trace level before messaging it
across threads, though I'm not sure why that wasn't done from inside
incrementsTraceLevel.

incrementsTraceLevel, as used in the boolean computation, is not a function.
It is only an access to a field. (or a set of parentheses are missing).

Nevertheless, I still cannot understand why, in the tracing function, it is needed to AVOID incrementing a new ray depth.

In fact, I do not see the usefulness of that test at all.
If it is a radiosity, it must be incremented
If it is a reflecting/refracting ray, it must be incremented

In which case would it not be incremented ? (assuming the access to incrementsTraceLevel is true for all objects)

always the same question: why is there such a test here (in trace.cpp, circa line 192) ?

The test is there because the TraceRay() function is not only used for reflected rays, but in any and all of the following situations:

• shooting a secondary ray for reflection
• shooting a secondary ray for refraction
• shooting a secondary ray for radiosity sampling
• continue tracing a ray that has been transmitted though a non-refracting surface

The latter may include, for instance, triangles or other non-solid shapes with an alpha texture mapped to them, as frequently used to simulate tree foliage or the like. Normally you wouldn't want the trace level to be incremented in those cases, as it neither causes exponential increase in the number of rays, nor can it lead to circular ray paths.

(As a matter of fact radiosity sampling has its own bounce-level handling by now, and therefore the trace level shouldn't be affected by whether it's a radiosity ray or not. At the moment it looks like radiosity sampling rays passing through tree foliage would suffer from "trace level fatigue"; I guess I need to check & fix that.)

I think the true proper way to handle the issue would be to base the trace level increment decision not on whether an object may potentially reflect or refract, but whether reflection or refraction actually occurred. This would eliminate the need to painstakingly examine which object might have any reflecting/refracting components (which obviously poses a potential risk of missing something).

Implemented a fix in change #4897.

Apparently, mesh objects with a per-triangle or per-vertex texture also suffered from the same issue; the fix corrects that problem as well (see thread news://news.povray.org:119/4b1e9696$1@news.povray.org)