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 Nikita Kipriyanov - 2011-10-03
Last edited by William F Pokorny - 2017-01-22

FS#222 - incorrect render of CSG merge with radiosity

The problem arises when I am trying to trace a radiosity scene without conventional lighting that has a GSG merge object. There are a coincident surfaces, but these surfaces are first merged, then the texture applied. The texture is a simple solig color non-transfluent pigment, default normal, default finish etc..

Problem consists when adding antialiasing, changing resolution, changing camera view-point etc.; when I replace merge with union, the problem disappeared.

The scene was checked on two different machines with different versions of POV-Ray:

  1. Gentoo Linux, kernel 2.6.39-r3, i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel, 2G RAM (this is Dell PowerEdge 2650 server with 2 dual-core Intel Xeon MP processors); Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (i686-pc-linux-gnu-g++ 4.5.3 @ i686-pc-linux-gnu)
  2. Gentoo Linux, kernel 2.6.37-r4, x86_64 AMD Athlon™ X2 Dual Core Processor BE-2350, 2G RAM (non-branded machine); Persistence of Vision™ Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++ 4.4.4 @ x86_64-pc-linux-gnu)

(scene has been adapted slightly to be rendered with 3.6, the adaptation was to change “emission” with “ambient” and replace gamma “srgb” with “2.2”)

Both machines generate similar images.

The attachment is an archive containing sources of minimal scenes with these problems, and sample pictures I generated from them on my machines.

Christoph Lipka commented on Monday, 03 October 2011, 21:52 GMT

The root cause of this is totally unrelated to radiosity. The underlying problem is that POV-Ray fails to properly "see" the coincident surfaces of the merge. This is due to the way intersection testing with a merge object is currently implemented, which makes it even more susceptible to coincident surface issues: Intersections with one member object that lie inside any other member object are ignored in order to suppress inner surfaces; when two members A and B have coincident surfaces, due to rounding an intersection with A may be considered inside B and vice versa.

While this is indeed a kind of bug, it won't be fixed in 3.70 release proper, as it would require more changes to the intersection testing code than would be prudent in the Release Candidate phase. We hope to find a general solution to the whole class of coincident surface problems in some future version though.

William F Pokorny commented on Sunday, 22 January 2017, 14:58 GMT

Now tracked on github as issue #209.


Available keyboard shortcuts


Task Details

Task Editing