Decals darker

[Enjay]

I'm going to raise an issue for this on the bug tracker, but I'm going to link to this thread because it's easier for me to post pictures here and to order my thoughts.

[edit] Done: https://mantis.zdoom.org/view.php?id=607 [/edit]

Sometime between version 2.2.0 and 2.3.2 something happened to decals to make them darker if they use a sprite as part of their decal. The plasma scorch shows it reasonably well:


2.2.0


The only grey bit is the parts of the underlying scorch that can be seen poking out from behind the fading blue sprite.

2.3.2 (and later, right up to the 3.0 pre versions)


There is an obvious dark grey edge to the decal around the edge of the blue sprite graphic


In my Burghead mod, it's even more obvious because I used sprites with quite large but very faint borders.

2.2.0




2.3.2+




Once the sprite part of the decal fades, the bit left behind looks fine.

[Graf Zahl]

This looks like their render style changed from additive to translucent.

[Enjay]

If anyone else has been following this and trying to replicate the problem, I have found out that it only happens when Ambient Occlusion is active.

[dpJudas]

Here's a screenshot of what's going wrong:



The sprite normals are being written into the normal gbuffer - the plasma shots and the vial shouldn't be visible on this screenshot. It probably shouldn't write normal data for transparent stuff, just like it doesn't write depth data.

Edit: Hmm, weird. That can't explain it as the SSAO pass runs BEFORE the sprites are drawn. The plot thickens..

[Graf Zahl]

Decals are not sprites. They are drawn as the last pass of solid geometry, so they either shouldn't write normals or get one from the underlying line.

[Nash]

dpJudas - off topic but how do you make the scene show those funky bright colours? :D Been meaning to ask since that model normal thread... :V

[dpJudas]

Decals are not sprites. They are drawn as the last pass of solid geometry, so they either shouldn't write normals or get one from the underlying line.

If they are drawn last, then that's actually good news. Makes it easier to make them stop outputting depth and normal data.

dpJudas - off topic but how do you make the scene show those funky bright colours? Been meaning to ask since that model normal thread... :V

At the moment I cheat. In main.fp I change the last part of the shader to look like this:

Code: Select all

	FragColor = frag;
#ifdef GBUFFER_PASS
	FragFog = vec4(AmbientOcclusionColor(), 1.0);
	FragNormal = vec4(vEyeNormal.xyz * 0.5 + 0.5, 1.0);
	FragColor = FragNormal; // <---- this line creates the funky colors
#endif

About the funky colors, those are the normal vectors stored as RGB. The red channel is X, green Y, blue Z and then offset so that 0 means -1, 128 means 0, and 255 means 1. My faked version only gives me a rough version of the true data I want. For example, you can see the SSAO applying its shadowing on top of the normals, which it wouldn't be in the normal gbuffer I'm trying to debug.

What I really need is to improve the debugging part of the GL renderer so I can pick any given point in the rendering process and copy that particular buffer to be shown. In this particular case I'm interested in knowing how the depth and normal buffers look like exactly between the opaque and translucent passes, because that's the data that the SSAO pass is working with.

[Nash]

Ahh okay. I thought it was a Cvar. It most definitely won't mean anything to me since I don't know anything about graphics programming, so nevermind. :D Still looks cool though! I guess you are talking about "filtering" a particular pass of a scene, as seen in those blogs that break down the rendering in GTA 5/Doom 4 etc.

[dpJudas]

Yes, exactly. Seeing how things look like half-way through helps a lot when trying to debug a shader. Like if you set gl_ssao_debug to 2 then you can see the true output of the SSAO shader. Then after blurring that you get what gl_ssao_debug 1 shows and so forth. I tried adding support for identifying the various passes to RenderDoc, but unfortunately the way GZDoom renders things is too heavy for that debugger. RenderDoc being the tool they used to generate all those screenshots in the blogs you're talking about.