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.


FS#53 - Blob trace level

Attached to Project: POV-Ray
Opened by Tim Attwood (TimA) - Wednesday, 02 September 2009, 04:32 GMT
Last edited by Christoph Lipka (clipka) - Friday, 26 March 2010, 16:46 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Closed
Assigned To Christoph Lipka (clipka)
Operating System All
Severity Medium
Priority Normal
Reported Version 3.70 beta 32
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


It appears that reflective bounces from blobs are
not incrementing the trace level, causing self-
reflecting hall of mirror portions to stall renders.

This task depends upon

Closed by  Christoph Lipka (clipka)
Friday, 26 March 2010, 16:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  No feedback from beta testers for months, so probably "no news is good news"
Comment by Christoph Lipka (clipka) - Wednesday, 09 September 2009, 10:09 GMT
  • Field changed: Task Type (Possible Bug → Definite Bug)
  • Field changed: Status (Unconfirmed → New)

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

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 17 September 2009, 17:43 GMT

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

Comment by Tim Attwood (TimA) - Saturday, 19 September 2009, 03:25 GMT

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.

Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 20 September 2009, 10:14 GMT

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 ||
-       if(traceLevelIncremented)
+       //if(traceLevelIncremented)
                // Set highest level traced.

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 ?

Comment by Tim Attwood (TimA) - Monday, 21 September 2009, 00:41 GMT

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

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 21 September 2009, 14:43 GMT

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) ?

Comment by Christoph Lipka (clipka) - Thursday, 29 October 2009, 14:52 GMT

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).

Comment by Christoph Lipka (clipka) - Saturday, 07 November 2009, 17:23 GMT
  • Field changed: Status (New → Requires testing)
  • Field changed: Percent Complete (0% → 100%)
  • Task assigned to Christoph Lipka (clipka)

Implemented a fix in change #4897.

Comment by Christoph Lipka (clipka) - Thursday, 11 February 2010, 15:27 GMT

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)