POV-Ray

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.

Tasklist

FS#267 - Bug in "sor" Primitive Leads to Random Black Artefacts in Radiosity Scenes

Attached to Project: POV-Ray
Opened by Benedikt Adelmann (badelmann) - Tuesday, 22 January 2013, 10:42 GMT
Last edited by Christoph Lipka (clipka) - Saturday, 06 April 2013, 15:15 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version 3.70 RC6
Due in Version 3.70 RC7
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Recently, I have been rendering an animation with POV-Ray 3.7 RC 6 using radiosity, photons and backside illumination. Many frames contained artefacts like in the attached image file. Trying to eliminate those artefacts I observed the following:

  • Rendering the same frame several times did not reproduce the artefacts or reproduced them differently. I.e., when I rendered a second (third, fourth, ...) time with +SF100 +EF100, the black space in the image was somewhere else or in some cases disappeared.
  • With radiosity turned off, no such artefacts have happened since, even in the scenes where they happened with radiosity turned on.
  • Turning off photons with radiosity still turned on did not remove the artefacts.
  • Rendering with one thread on one CPU core instead of two threads on two cores did not change anything except the rendering time.
  • Changing the radiosity settings I have not tried thoroughly, but at least raising or lowering count or error_bound does not seem to have any effect on this.

While POV-Ray was rendering, no other memory-intensive or CPU-intensive programs were running and POV-Ray itself did not report any error (just the usual warnings that some of the used features could change in future versions etc.). Render priotity was set to “high”.

This task depends upon

Closed by  Christoph Lipka (clipka)
Saturday, 06 April 2013, 15:15 GMT
Reason for closing:  Fixed
Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 11:55 GMT

can you provide a scene (preferrably trimmed down to the minimum) that demonstrates this error, so that I can try to track down the issue?

Comment by Benedikt Adelmann (badelmann) - Tuesday, 22 January 2013, 13:03 GMT

Here you are.

I have removed animation code (usages of the clock variable) and the ships' sails' image maps. (As the attached image shows, I still get an artefact.)

Comment by Jim Holsenback (jholsenback) - Tuesday, 22 January 2013, 15:53 GMT

Does this happen with every render ... how repeatable is it? I ran (2 dozen times) your min scene and never got the black artifacts even once. Exception of the black cannons and the back side of the sail in the middle of the ring of ships. I /did/ however get just /once/ strange results between the ships at 5 and 6 o'clock position, however the artifacts were /white/ not black

Things I noticed with scene code:

radiosity count is /really/ low ... you have 5, well below the default of 35
photons global settings spacing you have spacing 0.01 the in the photons block with the water (plane) you have target 10000 IIRC I've seen that cause speckled results.

@clipka: could this have been address with the recent changes you posted as that's what I'm running ie: RC6+

Comment by Benedikt Adelmann (badelmann) - Tuesday, 22 January 2013, 16:49 GMT

I cannot precisely state how repeatable those artefacts are. In some of the animation scenes, I observed them nearly every other frame and re-rendering individual frames produced artefacts again (usually not the same, but similar), in other scenes hardly any artefacts occured or artefacts were not produced when re-rendering a frame. (I just took scene 15 as a sample.)

However, all scenes, regardless whether artefacts occured or not, use similar (low) radiosity counts (below 10) and similar photons spacing. Admittedly the photons options can cause the scene to look speckled, but turning off photons did not remove the artefacts, i.e. I also observed them in scenes rendered with photons being deactivated.

Yet I have tried raising radiosity count, not in all scenes, but in those which showed artefacts. I thought that would solve the problem, but it did not. It just slowed down the render. The artefacts did not vanish.

Since you seem to be unable to reproduce the effect (or just get white instead of black artefacts), do you think it is a problem related to my hardware or operating system, respectively?

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 17:39 GMT

I did manage to reproduce the artifacts you are reporting; I haven't found out what they actually are though. Somehow radiosity seems to gather "negative" or "illegal" light from somewhere.

@Jim: Did you test on a Windows or Unix machine? If we're seeing "illegal" light, then a Unix machine might give different results.

Comment by Jim Holsenback (jholsenback) - Tuesday, 22 January 2013, 17:59 GMT

The /one/ time I did see the anomaly it was shaped like in the original posters example ... I tested on my linux machine:

Built-in features:

I/O restrictions:          enabled
X Window display:          enabled (using SDL)
Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -

Compilation settings:

Build architecture:  i686-pc-linux-gnu
Built/Optimized for: i686-pc-linux-gnu (using -march=native)
Compiler vendor:     gnu
Compiler version:    g++ 4.6
Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -malign-double -march=native -pthread

so maybe I /was/ seeing the problem, but it manifested itself differently as you noted ... SDL library??? BTW: when the problem happened it was in BOTH the preview window AND the final output image.

Shout when you have something for me to test.

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 18:24 GMT

No, the SDL library has nothing to do with it. We're apparently looking at some color computation that gives "Not-A-Number" as a result (division by zero or some such maybe). When converting such a number into a byte value, IIRC the Linux and Windows C++ runtime libraries show different behaviour: Windows apparently sets all bits to 0, while Linux sets them all to 1 instead.

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 19:44 GMT

After dramatically trimming down the scene I was able to nail down the artifacts to the "Radius" object in the scene; apparently we have a bug in the sor code.

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 22 January 2013, 19:59 GMT

For discussion sack:

#local Radius =
sor {
  9,
  <0.01,-0.1>, <0.01,0>, <0.02,0.05>, <0.005,0.1>,
  <0.01,0.15>, <0.005,0.2>, <0.02,0.25>, <0,0.3>, <0, 0.35>
  sturm
}

N-A-N might be due to -ffast-math (IIRC, that removes checks and computes anyway), without it I would expect a kind of exception/crash.

Comment by Jim Holsenback (jholsenback) - Tuesday, 22 January 2013, 20:09 GMT

Had a look at Coverity results and I see two issues mentioned regarding sor:

CID:967356
CID:967353

Does that help any?

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 22 January 2013, 20:10 GMT

It seems it's due to small radius.

Illustration with the original Radius (on left): texturing is bogus; With a scaled radius, it's better until the the top of the object is reached.

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 22 January 2013, 20:17 GMT

967353 might be: when X²+Z² =< DEPTH_TOLERANCE, N remains unset on curve.
(circa line 604 of sor.cpp)

967356 is about superellipsoid, no cigar.

(My bet is on CID:967353, usual amount: N-A-N on Sor::Normal... )

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 22 January 2013, 20:36 GMT

Without correcting CID:967353, replacing >DEPTH_TOLERANCE with >0 seems to be ok in sor.cpp. It produces a far better texturing of the sor in sor.pov;
The test >0 seems fine with the underlying maths in the "then" sections, does anyone see a reason to need DEPTH_TOLERANCE ?

I do not know how to handle the case X²+Z² == 0 (which N would you use ? with a bit of luck, it never happens, especially due to numerical precision and antialiasing, if any ?)

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 20:40 GMT

CID:967353 is a hot candidate; I'll try what happens when I fix it.

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 20:56 GMT

In the case of X²+Z² == 0 we'll get a normal facing +Y or -Y, depending on what direction the local slope happens to be biased towards.

A zero slopele can only occur at a single point in space, or with a truly pathological construction.

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 21:05 GMT

Yup, CID:967353 was the bad guy. Dropping the test altogether solves the issue.

Comment by Christoph Lipka (clipka) - Tuesday, 22 January 2013, 21:11 GMT

fixed with change #5746

Comment by Benedikt Adelmann (badelmann) - Thursday, 04 April 2013, 21:11 GMT

Test report:

I have rendered the scenes again which had shown artefacts. I have not observed them anymore. However, in two scenes I discovered one image each only the lower half of which seemed to be written to disc correctly, but that is probably another problem (or I have done something wrong).

In some other scenes I am not sure whether there really were no artefacts. There were none as obvious as in the image I originally posted, but in some parts of the image colours quite differed between individual frames, occasionally getting black like the artefacts. That, however, is probably just due to radiosity count (which I have raised to 36 indeed).

Comment by Christoph Lipka (clipka) - Saturday, 06 April 2013, 05:49 GMT

That Frame585.bmp is weird indeed - especially so since the bitmaps are written to disc starting at the top; in case of a crippled image I'd suspect the last part to be missing, not the first one.

I'd suggest to try rendering the image again. If the problem perists, please open a new bug report (unless of course you find that someone else already reported a similar issue).

As for colours differing between individual frames and most particularly "getting black like the artefacts", can you attach an example to assess whether it might be related?

Comment by Benedikt Adelmann (badelmann) - Saturday, 06 April 2013, 10:35 GMT

I had already rendered frame 585 again (and the similar image in the other scene) and then they looked fine, but the fact that something like that did occur at all puzzled me.

The first four frames from scene 7 (attached) show the flickering of colours between frames (that effect can be observed throughout the entire scene). The ship is from the same include file I have already posted, the holes in it have been made by intersecting it with an isosurface:

#local zfunc = function { pattern { granite } }

isosurface {
  function { zfunc(x,y,z)-0.4 }
  contained_by { box { <-2,-1,-3>,<3,4,3> } }
}

(If necessary, I could again trim down the scene code file.)

I'm afraid at the moment I cannot provide a frame showing colours in the flickering places get entirely black since I have not recovered them so far - maybe I just thought they were black while leafing through the frames although on closer inspection one can see they are just very dark. So I have probably just observed artefacts of too random radiosity sampling. If I spot a frame that clearly shows black artefacts I'll hand it in later.

Comment by Christoph Lipka (clipka) - Saturday, 06 April 2013, 15:15 GMT

Yes, that looks like perfectly normal radiosity randomness to me. And as the sail(?) does not flicker at all, I presume it is black by design.

I'd like to call this issue closed for now; should you happen to come across a clearly black artifact, please request this entry to be re-opened.

Loading...