#1 2017-02-04 01:13:18

rransom.8774
Member

Fluctuations in Radiance Hints implementation

When ‘Global Illumination’ is set to ‘high’, there are sometimes noticeable bright spots in places where they don't belong (e.g. under the stairwells behind the bases in ‘reflection’).  With rhrect set to 1, dark spots also occur.  These spots are produced randomly whenever rhtaps is set to 20 or 32, but not when rhtaps=12.  I have narrowed them down to random fluctuations in the the Radiance Hints 3D textures; starting Tesseract with the options -lreflection -x'rhcache 0; rhforce 1; debugrh 24' will make them quite visible as bright flashes in the main view and oscillating patterns in the debug view.  (I don't know which slice(s) I should be looking at with debugrh; slice 24 isn't flat gray and has some fluctuation.)  The reflective shadow map does not fluctuate frame-to-frame.

I realize that Radiance Hints is a stochastic algorithm, but (a) averaging in more samples should make the algorithm's output less variable, not more, and (b) the randomization inputs specified by the Radiance Hints paper (i.e. the locations sampled in the RSM texture) are fixed and compiled into the shader in Tesseract's implementation, and cannot explain the variation I'm seeing.

To try to narrow this down further, I've tried the following:

* I patched the rsmworld fragment shader to write red pixels into the color buffer; with that change in place, rhtaps 20 only shows fluctuations in the red channel of the output, and rhtaps 32 shows both red and white fluctuations.

* With the RSM color buffer still forced to red, I then changed the map's sunlight color to (0 1 255).  This eliminated the red fluctuations with both rhtaps 20 and rhtaps 32, but did not affect the white fluctuations with rhtaps 32.


(Desktop system:
Renderer: Gallium 0.4 on AMD BONAIRE (DRM 2.43.0, LLVM 3.8.0) (X.Org)
Driver: 4.1 (Core Profile) Mesa 11.2.0
GLSL: 4.10

Laptop system:
Renderer: Gallium 0.4 on AMD CARRIZO (DRM 3.1.0, LLVM 3.8.0) (X.Org)
Driver: 4.1 (Core Profile) Mesa 11.2.0
GLSL: 4.10
)

Offline

#2 2017-02-11 11:15:29

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

Removing the following line from gi.cfg eliminates the worst of the fluctuations (the bright white ones), and fixes the bright spots in physically absurd places:

sha += step(rhaothreshold, dir.z) * vec4(normalize(vec3(dir.xy, min(dot(dir.xy, dir.xy) * rhaoatten - rhaoheight, 0.0))), 1.0);

From the variable names, it should be the ‘additional ambient occlusion term’ mentioned in renderer.txt, but it adds too much light overall by default (deferredlightshader uses the RH alpha component as “light += rhlight.a * skylightcolor;”), and the step function makes it too unstable if the sample points change slightly.  (I assume the RH sample points do change every time RH values are recomputed.)

There's still some flickering with ‘rhcache 0; rhforce 1’ in effect, but it stays within a plausible range, and the results are visually acceptable when RH caching is enabled for normal use.

Offline

#3 2017-02-12 00:40:59

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

I fixed it.  The RH shader was picking up RSM samples from outside the world; they had all-zero color values, so they didn't contribute to the color channels, but their depth values put their z coordinates far enough below the RH sample point  to contribute to sha.  See https://gitgud.io/rransom/tesseract/com … 5aaf31c09a for the patch; it uses the (previously unused and cleared to zero every frame) A channel of rsmnormaltex to mark which pixels in the RSM are valid.

I don't know what the “gnormal *= blend;” line was for, so I left it in place, but only modifying the RGB channels.  Is that line correct?

Offline

#4 2017-02-12 01:06:07

eihrul
Administrator

Re: Fluctuations in Radiance Hints implementation

Given that the link you've posted is a 404, it is not very helpful.

Offline

#5 2017-02-12 01:17:11

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

eihrul wrote:

Given that the link you've posted is a 404, it is not very helpful.

That's odd.  I've uploaded the patch to http://sprunge.us/ieNG now.

Offline

#6 2017-02-12 01:38:48

eihrul
Administrator

Re: Fluctuations in Radiance Hints implementation

I am not sure this patch overall makes sense in its current form. What this feature is implementing is how much atmospheric light reaches the cell in the 3d texture. So what we're concerned with in each tap is detecting if the geometry in the place in the RSM we're sampling is actually blocking the ray. Trivially, at the edge of the world/sky, nothing is blocking the ray travel, so it should not block anything. In Tesseract, the edge of the map represents falling off into the void, like your map was an island floating in the sky. So treating the edge of the world like a hard wall is a different sort of behavior that is not congruent with the default.

The behavior you are proposing thus is probably useful as a variable, but I don't think it could be a default.

Offline

#7 2017-02-12 09:26:44

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

eihrul wrote:

I am not sure this patch overall makes sense in its current form. What this feature is implementing is how much atmospheric light reaches the cell in the 3d texture. So what we're concerned with in each tap is detecting if the geometry in the place in the RSM we're sampling is actually blocking the ray. Trivially, at the edge of the world/sky, nothing is blocking the ray travel, so it should not block anything. In Tesseract, the edge of the map represents falling off into the void, like your map was an island floating in the sky. So treating the edge of the world like a hard wall is a different sort of behavior that is not congruent with the default.

Good point.

I tried removing the “if(rsmnormvalue.a == 0.0) return;” line and instead projecting out-of-world RSM samples onto a plane below the scene, but that brought the flickering back.  It turns out that only the color contributions from out-of-world RSM samples were causing the variation; see http://sprunge.us/JDDP for a second patch (to be applied on top of my first one) that fixes the issue without removing the skylight effect at the edge of the world.

(I don't know why this second patch is enough to fix the RH variation, but it does work.)

Offline

#8 2017-02-13 13:16:48

eihrul
Administrator

Re: Fluctuations in Radiance Hints implementation

Out of world samples have 0 color, so should not be causing probs here.

Offline

#9 2017-02-14 16:39:50

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

eihrul wrote:

Out of world samples have 0 color, so should not be causing probs here.

I know.  I've tried to figure out why this second patch worked, and as far as I can tell it shouldn't have any effect.  But it does: with the upstream sources, or with “if(rsmnormvalue.a == 0.0) return;” commented out in my patched copy, I get bright spots where they don't belong, and flickering with rhcache=0 and rhforce=1; with these patches applied, the random bright spots are gone and there's no flickering even with RH caching off.

Offline

#10 2017-03-06 06:01:09

rransom.8774
Member

Re: Fluctuations in Radiance Hints implementation

I've tried Tesseract straight from SVN on two other configurations, an Intel laptop running Ubuntu 16.04 and the same AMD laptop as before running Windows 10, and this bug doesn't show up there.  It's an AMD Linux driver bug.

(Renderer: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)  (Intel Open Source Technology Center)
Driver: 4.3 (Core Profile) Mesa 12.0.6
GLSL: 4.30

and

Renderer: AMD Radeon(TM) R5 Graphics (ATI Technologies Inc.)
Driver: 4.0.13421 Core Profile Context 16.101.1311.1001
GLSL: 4.40
)

Offline

#11 2017-03-07 16:14:43

eihrul
Administrator

Re: Fluctuations in Radiance Hints implementation

Probably worth reporting upstream to the Mesa developers?

Offline

Board footer