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

[Deiz]

It could well be that Nvidia botched the 302.17 release (dates to mid-June). I'll upgrade my packages later today and see whether these issues remain reproducible.

[Arthur_D]

Maybe the video memory has gone bad, and the card may not have much longer to live? Just a thought.

[Zeta1127]

Well, that wouldn't be the first time nVidia has botched drivers before, they already botched a recent set of drivers, one of 200s, to point the drivers wouldn't work with Stronghold Kingdoms.

[Deiz]

It could well be that Nvidia botched the 302.17 release (dates to mid-June). I'll upgrade my packages later today and see whether these issues remain reproducible.

Well, so much for that - now running 304.43 and still able to reproduce the issues. Now that we're frozen for release, I suppose time will tell whether others are also experiencing the texture mapping issue.

[Thanduel]

Decided to test, I'm running latest svn on kubuntu 12.04, the latest stable nvidia 304 series driver off the xswat ppa with a gtx 460. The issue described above does not appear on my machine using GLSL and associated settings with quality at 10 in Iberian sandbox.

The only bug here is that I now spend too much time distracted staring at pretty graphics and not enough time conquering my enemies awesome work!

Edited September 6, 2012 by Thanduel

[Zaggy1024]

The only bug here is that I now spend too much time distracted staring at pretty graphics and not enough time conquering my enemies awesome work!

Which things do you think the effects look best on?

[myconid]

Well, so much for that - now running 304.43 and still able to reproduce the issues. Now that we're frozen for release, I suppose time will tell whether others are also experiencing the texture mapping issue.

Thanduel and HalcyonXII are two other Linux users with Nvidia cards that don't have this issue. Maybe there's something specific to your 9-series card, or maybe something specific to your system...

For now, there are two things left to try:

1. "ldd ./pyrogenesis" and post the result here. This will tell us whether the game is linking to the correct driver. I guess Nouveau/mesa drivers could be interfering, if they're present.
   
2. Check in Nvidia's control panel thingy that vsync, antialiasing and other bells and whistles are turned off, in case they are causing problems.
   

[Deiz]

My nvidia-settings options are (to my knowledge) vanilla, and it doesn't seem that any settings fiddling changes things for the better. Some options do have visual affects, though - e.g. forcing 16x AF and FXAA simultaneously seems to make the texture mappings cycle more rapidly with zoom.

My binary is definitely linked against current libraries:

	libnvidia-tls.so.304.43 => /usr/lib/libnvidia-tls.so.304.43 (0x00007f4842bd4000)
	libnvidia-glcore.so.304.43 => /usr/lib/libnvidia-glcore.so.304.43 (0x00007f48407eb000)

I just noticed something very interesting: art/actors/props/structures/iberians/market_01.xml is what contains the various crates and barrels of wares that populate the market. It only has one texture, "baseTex". Simply duplicating the normTex and specTex from another actor seems sufficient to make the issue disappear (tested with a few different props).

However, undoing that change and blowing away the art cache (~/.cache/0ad/art) seems insufficient to bring back the buggy behaviour, though other buggy props do persist after wiping the cache out. Is there some redundant caching I'm unaware of?

[myconid]

Not to my knowledge...

[historic_bruno]

That's sounding more and more like a hardware problem. Do you play other similar 3D OpenGL games (with similar amounts of testing)? You might check the graphics card and mobo for swelling/leaky capacitors. My old computer has bad caps on the mobo and the graphics were never stable after a few years, I got some of the strangest problems, but they sound vaguely similar to what you're having, mostly texture corruption. This would only manifest with more strenuous real-world 3D OpenGL apps, no amount of simple tests would cause it.

[Deiz]

I'm strongly doubting this is a hardware issue, as it wasn't present in alpha 10, I've never seen anything similar in other games, and it's heavily influenced by the actor XML, plus it occurs in both GLSL and ARB mode.

One more data point: Perhaps it's AO-related? At the very least it seems tied to the new materials and/or textures. The Iberian house (art/actors/structures/iberians/house.xml) uses this material: <material>player_trans_ao_parallax_spec.xml</material>. When I clear my art cache, in both GLSL and ARB modes, the wood pile in one of the variants is covered by a stretched stone texture. Removing that material line and clearing the cache, though, and the issue disappears. I've confirmed that this behaviour is 100% reproducible on my end.

[myconid]

Okay, so: Why is the parent object's material affecting the props? Why is it happening even though all fancy materials are turned off? And why is it happening just to you?

Since you have quality=0 in the config, player_trans_ao_parallax_spec redirects to player_trans, which doesn't have AO. Since the material doesn't have AO, the second UV stream is completely disabled. When you are using ARB, this doesn't even matter.

As a test, set both the parent and prop's material to "player_trans.xml"...

[Deiz]

I've discovered what the problem is. It turns out that most of what I've been attempting has been irrelevant: It's not a renderer bug, it's a loading bug. I was about to give up when I decided to strace 0ad while it loads with no cache, to see where it's actually sourcing files from.

The reason nobody else seems to be able to reproduce this? It requires both the internal/ and public/ trees within binaries/data/mods, and it requires the former to have newer mtimes than the latter.

The only real content of note in internal/art/actors are the Iberian props. They use the old texture element format, like so:

<texture>props/iber_prop_shields.dds</texture>

Meanwhile, the public/ version of that same file uses the newer format:

<textures><texture file="props/iber_prop_shields.dds" name="baseTex"/></textures>

Apparently, the "internal" mod is being loaded and when files exist in both public/ and internal/, the one with the newer mtime is preferred. If I touch every file in internal/art, all of the Iberian props are screwed up. If I touch every file in public/art, everything is fine.

This has been quite the bug odyssey. I, for one, blame Mythos Ruler (he's the one who created the internal/ props, back in 2009).

[zoot]

Error messages are your friend, but only if you remember to implement them.

[feneur]

Ah, and they're marked as modified when you check them out, which is why people who doesn't first checkout the public files and only later the internal doesn't see the issue The same files really shouldn't exist in both places in this case though, so I'd say that's the biggest issue in this specific case. A pity that the files are marked as changed when they're merely downloaded though (Or does SVN do something to them that makes them seem as if they're modified when they're not?)

[myconid]

Great work, Deiz. I'm relieved this has been resolved. I don't have the internal mod (nor do I know where to get it), so that never even crossed my mind. There was a script for updating actors, if you want to use it.

Error messages are your friend, but only if you remember to implement them.

XML validation would have been the answer here, which is possible to do, but a PITA to keep updated when the format keeps changing! If you recall, I wanted to deprecate but keep the <texture> tag because I was worried it would get to this, but historic_bruno wanted it removed. Doesn't matter though -- renderer stuff is finally clear for launch.

[historic_bruno]

XML validation would have been the answer here, which is possible to do, but a PITA to keep updated when the format keeps changing! If you recall, I wanted to deprecate but keep the <texture> tag because I was worried it would get to this, but historic_bruno wanted it removed. Doesn't matter though -- renderer stuff is finally clear for launch.

I still don't think the best solution would be assuming that if <texture> is found it's an old actor and if <textures> is found it's a new one - people could easily get the two confused by copy-pasting XML from different sources. We have a few possible solutions for preventing similar issues starting with A12: 1.) add the handling of old format actors back in, 2.) bump the actor version number from 1 to 2 (probably not bad from an organization standpoint) and either refuse to load version 1 or fall back to handling <texture>, and/or 3.) verify a model has valid textures defined for it before loading and rendering it. Really I can't believe there was no error, a model was apparently using garbage data for its texture

[myconid]

I still don't think the best solution would be assuming that if <texture> is found it's an old actor and if <textures> is found it's a new one - people could easily get the two confused by copy-pasting XML from different sources. We have a few possible solutions for preventing similar issues starting with A12: 1.) add the handling of old format actors back in, 2.) bump the actor version number from 1 to 2 (probably not bad from an organization standpoint) and either refuse to load version 1 or fall back to handling <texture>, and/or 3.) verify a model has valid textures defined for it before loading and rendering it. Really I can't believe there was no error, a model was apparently using garbage data for its texture

Right, I'll make it give a warning when it tries to load the old format - it should do that at least.

The real issue is that the engine wasn't written to know when any shader inputs are unbound, and annoyingly enough, OpenGL doesn't offer any functionality to check that. A possible solution would be to keep our own parameter lists somewhere. The xml files in the arb/glsl directories are good candidates for that. Maybe something for Alpha 12...

[myconid]

I still don't think the best solution would be assuming that if <texture> is found it's an old actor and if <textures> is found it's a new one - people could easily get the two confused by copy-pasting XML from different sources.

Btw, what I had in mind was much simpler than that. We could make this format

<texture>filename</texture>

syntactic sugar for

<textures>
	<texture name="baseTex" file="filename"/>
</textures>

Since there are no other changes to the xml format, there isn't an "old" format, really (unless you're trying to run new xml files on an old build, but that's not a problem).

[k776]

No alternative formats! Stick with <textures><texture> and throw an error when unmatching data is found, and keep it simple.

if actor->textures.size() == 0
  throw "internal/art/actors/iber_spearman_e.xml contains invalid texture data"
end

[myconid]

Done.

[zoot]

It works perfectly here, though, and since other specular mapped models work fine for you (yes?), it's not at all clear what the problem is...

I get the shimmering on the Athenian Civic Center too:

[Mythos_Ruler]

I wish we could produce that shimmering on demand for the metal mines.

[myconid]

What if you replace this

specular.rgb = sunColor * specCol * pow(max(0.0, dot(normalize(normal), v_half)), specPow);

with this

specular.rgb = sunColor * specCol * pow(max(0.0, dot(normalize(normal), normalize(v_half))), specPow);

in model_common.fs

[myconid]

I wish we could produce that shimmering on demand for the metal mines.

Producing it is easy. It's not producing it that is the problem.