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 Tim Attwood - 2009-09-02
Last edited by Christoph Lipka - 2010-03-26

FS#53 - Blob trace level

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

Closed by  Christoph Lipka
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"

Christoph Lipka commented on Wednesday, 09 September 2009, 10:09 GMT

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

Grimbert Jérôme commented on 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

Tim Attwood commented on 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.

Grimbert Jérôme commented on 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 ?

Tim Attwood commented on 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

Grimbert Jérôme commented on 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) ?

Christoph Lipka commented on 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).

Christoph Lipka commented on Saturday, 07 November 2009, 17:23 GMT

Implemented a fix in change #4897.

Christoph Lipka commented on 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)


Available keyboard shortcuts


Task Details

Task Editing