Jump to content

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


Recommended Posts

  • Replies 1,3k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hey everyone, I've been coding some very rough GLSL post-processing tests just to see what they'd look like in 0ad, and thought I might share some results. The following images are in pairs, with the

Much appreciated. I'd like it if people tried the code and gave me some feedback, if possible. No need for anything fancy, just compile, run Oasis 10 and let me know if anything looks wrong, and how

Just wanted to say the rock mountain screenshot above looks fantastic

Posted Images

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.

Link to post
Share on other sites

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 :P awesome work!

Edited by Thanduel
Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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? :scratch_one-s_head:

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"...

Link to post
Share on other sites

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).

Link to post
Share on other sites

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 :P 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 :P (Or does SVN do something to them that makes them seem as if they're modified when they're not?)

Link to post
Share on other sites

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. :D

Link to post
Share on other sites

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. :D

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 :(

Link to post
Share on other sites

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...

Link to post
Share on other sites

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).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...