Post-processing effects test (SSAO/HDR/Bloom)

[Yves]

Well done myconid, I've tested again with the fixed renderpath and can't spot any issues now!

[k776]

@myconid: We seem to have wound up with dozens of materials doing nearly the same thing, minus one feature. e.g. basic_trans_ao_parallax_spec.xml does the same as basic_trans_ao_spec.xml, just without the Parallax.

How hard would it be to make a system like this instead? The conditionals are right in the file. The conditional_define tag is combined with <define /> to make it look nicer too.

(this is just my thoughts, you'll want to check with others first before implementing it if the idea is possible)

Edit: Tweaked based on feedback. Removing the quality level stuff in favour of different options in default.cfg instead. Doing so should make it easier to test things too (e.g. disable specular but have AO enabled)

Edit 2: Further tweaking. Actors define what effects they should use.

e.g. on the roman civ center:

<effects enable="normal specular ao parallax"/>

would pass EFFECT_NORMAL, EFFECT_AO, etc as true constants. (you can find better naming I'm sure).

Then the material would become:

<?xml version="1.0" encoding="utf-8"?>
<material>
  <alpha_blending/>
  <shader effect="model_transparent"/>
  <define name="USE_TRANSPARENT" value="1"/>
  <define name="USE_ALPHATEST" value="1" if="CFG_FORCE_ALPHATEST"/>

  <define name="USE_NORMAL_MAP" value="1" if="CFG_USE_NORMAL_MAP & EFFECT_NORMAL"/>
  <define name="USE_SPECULAR_MAP" value="1" if="CFG_USE_SPECULAR_MAP & EFFECT_SPECULAR"/>
  <define name="USE_AO" value="1" if="CFG_USE_AO & EFFECT_AO"/>

  <conditional if="CFG_USE_PARALLAX_MAP & EFFECT_PARALLAX">
	<define name="USE_PARALLAX_MAP" value="1" type="draw_range" conf="PARALLAX_DIST"/>
	<define name="USE_HQ_PARALLAX" value="1" type="draw_range" conf="PARALLAX_HQ_DIST"/>
	<define name="USE_VHQ_PARALLAX" value="1" type="draw_range" conf="PARALLAX_VHQ_DIST"/>
  </conditional>

  <uniform name="effectSettings" value="1.0 50.0 0.0075 0.85"/>
</material>

[zoot]

Then the material would become:

Some of those lines look conspicously tautological ("if use specular, then use specular".)

IMO the CFG stuff should not be written into the materials. If the user has disabled AO, then AO should be disabled across the board on all materials. If anything, it could go into the lower-level effects XML.

[myconid]

Yes, I'm sure we could do something of the sort...

[historic_bruno]

Personally I don't see much value to that change, it just rips out a lot of the purpose of materials and shoves it into actors instead. The whole point of materials is they contain settings common to several actors, what's the advantage of breaking that relationship?

The one thing I'd like to see is the ability to tweak effectsSettings on a per-actor basis - it's not reasonable to expect a single set of values will look good for every actor, nor that a new material should be created for every possible combination (even if they only differ in e.g. specular value). Whereas having a separate material for each used subset of effects is reasonable, as long as they are clearly labelled and the artists can make sense of it. It doesn't seem worth spending a lot of time on this though, it doesn't matter much if we have a few extra materials made specially for helmets, spears, and whatnot.

[myconid]

Personally I don't see much value to that change, it just rips out a lot of the purpose of materials and shoves it into actors instead. The whole point of materials is they contain settings common to several actors, what's the advantage of breaking that relationship?

The one thing I'd like to see is the ability to tweak effectsSettings on a per-actor basis - it's not reasonable to expect a single set of values will look good for every actor, nor that a new material should be created for every possible combination (even if they only differ in e.g. specular value). Whereas having a separate material for each used subset of effects is reasonable, as long as they are clearly labelled and the artists can make sense of it. It doesn't seem worth spending a lot of time on this though, it doesn't matter much if we have a few extra materials made specially for helmets, spears, and whatnot.

That's more like my way of thinking about this.

For the moment, I'll just point out that materials can be put into directories. For instance, model and terrain materials should go into different subdirectories of the materials directory. We should also start working on a standard about what effects constitute high/medium/low graphics, and have separate folders for each type.

[fabio]

If the GLSL mode is considered the third renderer mode why don't add a third option (= glsl) to the renderpath option, rather than having a dedicated one (preferglsl = true)?

[Deiz]

My favourite texture issue is back: 1, 2.

[myconid]

My favourite texture issue is back: 1, 2.

Ok, commented out an optimisation that may have been the cause...

[Deiz]

No, that seems to drastically worsen the issue, but in a different manner - certain portions of meshes turn completely white when zoomed out, and completely black when zoomed in.

Is this perhaps related to a particular material? It presently impacts most of the props on various Iberian structures, e.g. drying racks and wood piles on houses, containers in the market - but not the basic Iberian stone texture itself, nor the market canopy, etc.

[ac892006]

Will intel hd 3000 graphics be sufficient to run all the post-processing effects ?

[myconid]

No, that seems to drastically worsen the issue, but in a different manner - certain portions of meshes turn completely white when zoomed out, and completely black when zoomed in.

I think the two might be related, and we're now a step closer to the root cause.

Is this perhaps related to a particular material? It presently impacts most of the props on various Iberian structures, e.g. drying racks and wood piles on houses, containers in the market - but not the basic Iberian stone texture itself, nor the market canopy, etc.

That's my thought. There are a number of textures that are used in the GLSL shaders, but are bound to nothing in the ARB shaders. Maybe binding them to a dummy name would fix this...

[myconid]

Will intel hd 3000 graphics be sufficient to run all the post-processing effects ?

I think so.

[myconid]

Deiz, give it another try please. Also, does any of this affect GLSL mode?

Oh, what's your hardware, btw?

[Deiz]

I have a Nvidia 9600 GT and run the proprietary driver, 302.17 presently.

The issue presents itself in the exact same way in both ARB and GLSL modes. For what it's worth, the Iberian Sandbox triggers the issue immediately and 100% of the time, for me.

[myconid]

I have a Nvidia 9600 GT and run the proprietary driver, 302.17 presently.

The issue presents itself in the exact same way in both ARB and GLSL modes. For what it's worth, the Iberian Sandbox triggers the issue immediately and 100% of the time, for me.

Iberian Sandbox works perfectly fine here. Please rebuild now that I've disabled some more stuff and let me know what happens (you want commit 12630).

[Deiz]

No dice with r12630. In both ARB and GLSL modes, the incorrect textures change with the zoom level.

There are some differences in behaviour between the two modes, though. With GLSL, the texture mappings generally change rapidly with zoom, but notably the textures are often mapped correctly at the default camera h eight. In ARB mode, I usually only have two mappings no matter how extreme the zoom level, yet both are wrong - one is either white or black and the other is usually gold.

[myconid]

There are some differences in behaviour between the two modes, though. With GLSL, the texture mappings generally change rapidly with zoom, but notably the textures are often mapped correctly at the default camera h eight. In ARB mode, I usually only have two mappings no matter how extreme the zoom level, yet both are wrong - one is either white or black and the other is usually gold.

The LOD should be disabled in that revision (are you sure you recompiled?), and with it, parallax should be disabled as well. My theory is that the texture mappings (or the textures themselves) change as the shader is changed with distance due to the LOD system (I don't think this has to do with mipmaps). For some obscure reason, the parameters of the shader are being passed incorrectly, hence the visual artifacts.

In GLSL mode, the parallax fades itself out to make the LOD transition less noticeable, thus "the texture mappings generally change rapidly with zoom". The fading doesn't happen in ARB because the shaders don't know and don't care about the LOD, but the shader is still replaced with an identical copy at a certain distance so you get a sudden transition.

I can't see a reason why the shader parameters wouldn't be passed correctly. The code in ShaderProgram.cpp is fairly basic, and by disabling the optimisations the parameters are being rebound explicitly for every new model that is drawn.

[historic_bruno]

You're not referring to a problem with the various overloaded Uniform() methods are you? (some compilers spit out warnings for those, related to hiding an overloaded virtual function, which is indeed an obscure problem but I couldn't think of how it would cause a problem for us in practice)

[myconid]

You're not referring to a problem with the various overloaded Uniform() methods are you? (some compilers spit out warnings for those, related to hiding an overloaded virtual function, which is indeed an obscure problem but I couldn't think of how it would cause a problem for us in practice)

I doubt that's it, unless his compiler is so horribly buggy that it's calling the wrong methods.

[Deiz]

I definitely did rebuild - I saw source/renderer/ModelRenderer.cpp go by in make's output and then linking proceeded without issue.

Anyhow, I have a bit of "WTF" that might provide some insight, confirmed on both r12630 and current r12636: Shadow filtering makes a difference. In both ARB and GLSL mode, toggling shadow filtering without moving the camera whatsoever will result in a complete change in the texture mapping - it's clearly not just a shade change, as I've seen a rough sandstone texture be replaced by crisp grey and black lines.

[myconid]

Ah, that is useful to know!

While shadows are not affected directly by distance, the shadowmap is scaled depending on the number/placement of models on the screen. As you zoom out, the scale of the shadowmap is changed to accommodate more models, so it may give the impression that the problem is related to distance. The shadowmap scale thing is only used with shadow filtering, so the facts fit.

So it's the shadows that are interfering with the texture mapping. That's... entirely illogical.

I wonder if it's silently failing because of a hardware limitation (very unlikely - your hardware is too new, and this happens when everything is turned off). More likely, it could be a driver bug - me and wraitii had to chase one down on his Nvidia card a while back.

Out of curiosity, what happens when you completely disable shadows in the config?

[Deiz]

In r12636, with shadows = false and shadowpcf = false, textures in ARB mode vary a lot with camera distance, GLSL textures are mostly gold or black stripes.

Here's your second helping of "WTF": This just happened in GLSL mode. Note how the structure textures are all fine... but most of the HUD has disappeared.

[Mythos_Ruler]

Deiz, do you have a clean local checkout?

[myconid]

In r12636, with shadows = false and shadowpcf = false, textures in ARB mode vary a lot with camera distance, GLSL textures are mostly gold or black stripes.

Here's your second helping of "WTF": This just happened in GLSL mode. Note how the structure textures are all fine... but most of the HUD has disappeared.

I don't know, man. You're reporting so many different problems and they all seem so random and unrelated...