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

[zoot]

This is the info I get upon loading it in gdb:

Core was generated by `./pyrogenesis'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fbcc626ffa0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so

[zoot]

Here is a backtrace:

(gdb) bt
#0  0x00007fbcc626ffa0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so
#1  0x00007fbcc62715b0 in ?? ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so
#2  0x00007fbcc6271a09 in _mesa_store_teximage3d ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so
#3  0x00007fbcc6622012 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x00007fbcc6622554 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x00007fbcc625fd6b in ?? ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so
#6  0x00007fbcc6260364 in _mesa_TexImage2D ()
   from /usr/lib/x86_64-linux-gnu/dri/libdricore.so
#7  0x00000000006138e2 in CLOSTexture::ConstructTexture (this=0x421d850, 
    unit=0) at ../../../source/graphics/LOSTexture.cpp:198
#8  0x000000000061506c in CLOSTexture::RecomputeTexture (this=0x421d850, 
    unit=0) at ../../../source/graphics/LOSTexture.cpp:262
#9  0x00000000006157ba in CLOSTexture::InterpolateLOS (this=0x421d850)
    at ../../../source/graphics/LOSTexture.cpp:105
#10 0x000000000068bc03 in CRenderer::RenderSubmissions (this=0x2505c90)
    at ../../../source/renderer/Renderer.cpp:1365
#11 0x000000000068ca6f in CRenderer::RenderScene (this=0x2505c90, scene=...)
    at ../../../source/renderer/Renderer.cpp:1675
#12 0x000000000058eb41 in Render ()
---Type <return> to continue, or q <return> to quit---
    at ../../../source/ps/GameSetup/GameSetup.cpp:228
#13 0x000000000041db93 in Frame () at ../../../source/main.cpp:413
#14 RunGameOrAtlas (argc=<optimized out>, argv=<optimized out>)
    at ../../../source/main.cpp:529
#15 0x0000000000413677 in main (argc=1, argv=0x7fff8e0bbb88)
    at ../../../source/main.cpp:572

[myconid]

Hmm, it's LOS-related then. When creating the textures, it looks like...

And you say this only happens when smoothlos is false?

[zoot]

It happens regardless of smoothlos being true or false.

[zoot]

It happens regardless of smoothlos being true or false.

Sorry, you're right. It only happens when it is false.

[zoot]

I still happens when preferglsl, smoothlos and fancywater are set to false.

I've tried to narrow the commit range a bit:

It does not crash on 9f80921728f89c15673b89575cd92a1fa0338470.

It does not crash on 8d0e60543966812eb86525eb5c8fe907bc77cce5.

It does crash on 3b56fb334a08f89d7c878e46b4ea1ee8e5c0e90e.

So presumably it is something in the 'biwater' implementation.

Scratch the above then. It also crashes on 8d0e60543966812eb86525eb5c8fe907bc77cce5 when smoothlos is false.

[myconid]

Sorry, you're right. It only happens when it is false.

How is this even possible...

If smoothlos is disabled, the InterpolateLOS method shouldn't ever reach the point where it calls RecomputeTexture, yet there it is in your stacktrace. GAH.

[myconid]

zoot, could you please try to recreate the problem in the "smoothlos" branch instead of "merged"? (needs update_workspaces and recompile)

[zoot]

Okay. Currently recompiling from scratch (clean workspaces).

[zoot]

Okay, I've done 'git checkout -f myconid/smoothlos', update_workspaces and recompile. The issue persists.

(Edit: Obviously, I also set smoothlos to false somewhere in between there.)

Edited July 8, 2012 by zoot

[k776]

When I compiled the 'merged' branch fresh (no local modifications, applied merged branch on top of 0 A.D. git master, no default.cfg changes), the game segfaults when map loading reaches 100%, but before it switches to the ingame UI. It seems to work occasionally. So far, I've crashed it 5 times and it's worked 1 time.

Hope these help:

http://pastie.org/4222576 <- Apples default crash log output

http://pastie.org/4222607 <- Result of gdb's "thread apply all bt full"

[myconid]

Looks like you're both having the same issue (with the LOS).

Ok, I'm off to bed and I'll look at that again tomorrow.

ARGH. Figured it out. I'm such an idiot sometimes.

Edited July 8, 2012 by myconid

[myconid]

Alright, tell me it's fixed.

[k776]

Yup, it's working. With smoothlos enabled, the game didn't crash.

Two bugs so far, both to do with developer overlay (Alt+D):

* When you enable and then disable reveal map, the SoD isn't slightly transparent (you can see the terrain when normally you should just see black).

* The "Pathfinder Overlay" option turned on looks a lot worse. Red lines, flickering.

Also, using "Reveal Map" the fade in/out is really nice, but very slow (jumpy/stagey). Is it CPU or GPU? Can it be made smoother?

[myconid]

* When you enable and then disable reveal map, the SoD isn't slightly transparent (you can see the terrain when normally you should just see black).

* The "Pathfinder Overlay" option turned on looks a lot worse. Red lines, flickering.

Shouldn't be hard to fix. Tomorrow!

Also, using "Reveal Map" the fade in/out is really nice, but very slow (jumpy/stagey). Is it CPU or GPU? Can it be made smoother?

All the work is done on the GPU, so it depends on your hardware. Keep in mind that when you reveal the map, everything gets drawn, so it's normal that it becomes slower. Try using it on a smaller map (or on a more powerful GPU ).

[k776]

@myconid: We want to commit the multiple textures and multiple UV patches. Are the ones on Trac ok, else can you rebuild the patches with just the requires changes? Then we can commit them into SVN, I'll do a Git sync, and you can pull in 0ad/0ad which should clean up compare pages so further code reviewing. Anyway, provide the patches if the ones on Trac are different, and we can go from there...

[historic_bruno]

Thanks for making that updated, merged branch! I tested it on the following system: system_info.txt

I like most of the effects and they seem to work as expected. I think the AO/normal/parallax/specular mapping will make the most impact and since it's also the longest tested and doesn't seem to have many problems, how long do you think it will be before it's ready to commit? Personally given how active development is in this thread (fixing bugs, adding new features, etc.), I feel it can be added to SVN fairly soon. It would be stupid to risk losing the momentum. The smooth LOS is also really nice

Good job adding the heightmap import to Atlas, do you happen to have an image for testing it? Or what are the guidelines for it? I think if we add this, we also need some kind of global erode/smooth function, to tweak the overall result Or maybe we can show the selected heightmap image in a dialog and let the user preview, possibly modify it.

Here's what I noticed that seemed buggy. With unchanged default.cfg (non-GLSL path):

• Might be a known problem: the terrain doesn't seem to be blending at all. I can see all the square tile boundaries between textures, and when I change zoom the boundary tiles shift somewhat. This might just be an oversight or unfinished work, but I want to mention it anyway
  
• Related: the grass material doesn't look good, I can't see the grass blades but it looks like the normal default grass terrain with black speckles all over. Should the two textures differ for grass material vs. standard texture, and can they be selected individually for different render paths?
  

Now enabling preferglsl, gentangents, and smoothlos:

• Terrain overlays are no longer visible on default terrain because of the grass blades. This effects some debug overlays, but more importantly the Atlas terrain brushes.
  
• There are apparently some z-ordering problems even on other terrains, as you can see in this screenshot, showing an Atlas brush:
  
  

The only effect I saw and wasn't sold on was the grass material. I guess there's some LOD stuff going on, because I'm noticing a kind of band at a distance from the camera, at certain angles it's more noticeable and while moving the camera it's very ugly. It gets very blurry and distorted in front of the band, also the terrain appears darker in the distance. It's difficult to show what I mean in a screenshot, you really need to see it in motion. Could the LOD algorithm be tweaked?

Even without the LOD issues it currently looks worse than hand placed alpha textured grass Would a more detailed/higher res grass texture help? What's the advantage of this new grass, possibility of animation?

[zoot]

The only effect I saw and wasn't sold on was the grass material. I guess there's some LOD stuff going on, because I'm noticing a kind of band at a distance from the camera, at certain angles it's more noticeable and while moving the camera it's very ugly. It gets very blurry and distorted in front of the band, also the terrain appears darker in the distance. It's difficult to show what I mean in a screenshot, you really need to see it in motion. Could the LOD algorithm be tweaked?

Even without the LOD issues it currently looks worse than hand placed alpha textured grass Would a more detailed/higher res grass texture help? What's the advantage of this new grass, possibility of animation?

Could you post a screenshot? Does it look anything like this:

[wraitii]

Here's what I noticed that seemed buggy. With unchanged default.cfg (non-GLSL path):

• Might be a known problem: the terrain doesn't seem to be blending at all. I can see all the square tile boundaries between textures, and when I change zoom the boundary tiles shift somewhat. This might just be an oversight or unfinished work, but I want to mention it anyway
  
• Related: the grass material doesn't look good, I can't see the grass blades but it looks like the normal default grass terrain with black speckles all over. Should the two textures differ for grass material vs. standard texture, and can they be selected individually for different render paths?
  

Your first point is probably an ARB problem, because if GLSL is not preferred, it should use those shaders. Some things may have changed in terrain_common or terrain_base that make the ARB one crash. I'm going to try fixing that today.

Your second point looks to me like the same issue: it's not yet implemented for ARB. Again, as the guy who decided he wanted to port stuff to ARB, I'll try that today.

Is no-one else but me getting a wrong result with the AO? It doesn't seem to recognize the second layer of UV.

BTW, hav you reached a decision about my water shader? It think it's an improvement, but it requires re-working most maps to take into account the new settings...

Edited July 9, 2012 by wraitii

[zoot]

I have a problem on the 'biwater' branch. When I enable shadows, the whole minimap is revealed:

If I move the camera into the SoD (outside the view of any shadow rendering, perhaps?), the minimap returns to normal.

Also, shadows on water do not seem to be affected by waves on the water surface. Don't know if that is fixable.

[myconid]

k776, there have been a few bugfixes, so I'll generate new patches.

Good job adding the heightmap import to Atlas, do you happen to have an image for testing it? Or what are the guidelines for it? I think if we add this, we also need some kind of global erode/smooth function, to tweak the overall result Or maybe we can show the selected heightmap image in a dialog and let the user preview, possibly modify it.

To test, any heightmap image should do, just pick any one off Google. The image must be in RGB/A mode, as the engine can't load greyscale/indexed images (not my fault). Assuming 0-255 colour values. The image is currently truncated to a fixed size, but that should be easy to fix by resizing the map. The heightmap comes out looking flipped, though that is also easy to fix.

A dialog to choose options would be nice, but these days I don't have much patience for GUI programming. OTOH, an erosion method would be awesome and I'd like to try it eventually.

• Might be a known problem: the terrain doesn't seem to be blending at all. I can see all the square tile boundaries between textures, and when I change zoom the boundary tiles shift somewhat. This might just be an oversight or unfinished work, but I want to mention it anyway
  

Already fixed but not committed. Done.

• Related: the grass material doesn't look good, I can't see the grass blades but it looks like the normal default grass terrain with black speckles all over. Should the two textures differ for grass material vs. standard texture, and can they be selected individually for different render paths?
  

Grass is not implemented in the ARB shaders. The grass texture is actually identical to the default texture, but also contains an alpha channel -- the alpha should be ignored, sounds like it isn't.

• Terrain overlays are no longer visible on default terrain because of the grass blades. This effects some debug overlays, but more importantly the Atlas terrain brushes.
  

I'm aware of this. Not sure if there's anything that can be done about it. The terrain adds new geometry that is higher than the terrain itself, and there's no way of telling the overlay renderers about that.

• There are apparently some z-ordering problems even on other terrains, as you can see in this screenshot, showing an Atlas brush:
  

I'm also aware of this. Not sure if it's my fault or a pre-existing issue with GLSL mode. Will look into it eventually.

The only effect I saw and wasn't sold on was the grass material. I guess there's some LOD stuff going on, because I'm noticing a kind of band at a distance from the camera, at certain angles it's more noticeable and while moving the camera it's very ugly. It gets very blurry and distorted in front of the band, also the terrain appears darker in the distance. It's difficult to show what I mean in a screenshot, you really need to see it in motion. Could the LOD algorithm be tweaked?

Even without the LOD issues it currently looks worse than hand placed alpha textured grass Would a more detailed/higher res grass texture help? What's the advantage of this new grass, possibility of animation?

I think I know what you mean about the thing in the distance. That's due to how the grass algorithm works (no LOD). We may be able to tweak the algorithm to hide the artifacts by doing something wraitii suggested, and I think my grass texture isn't exactly of the finest artistic quality. The advantage of this grass? It looks like grass! Plus, it can be animated with a wind effect, so it could look nice.

The real disadvantage? We're adding new geometry, though we aren't sorting the geometry and the wrong blending around the edges is really tricky to hide.

But anyway, the grass effect is meant to be just a test. It's an xml file and something like 5 lines in the shaders, without changes in the engine, so let's just ignore it for now.

Thanks for testing.

[wraitii]

Allright, so I've once again lost at Anno 1404's "build the cathedral" mission, so I'm off to try converting the shaders to ARB again.

Edit: Still about the grass: you may want to try experimenting with lowering the alpha as the layers go up, or "thinning" the grass. could reduce some of the artifacts.

I'm getting your last update (figured that upstream stuff).

Edited July 9, 2012 by wraitii

[zoot]

BTW, hav you reached a decision about my water shader? It think it's an improvement, but it requires re-working most maps to take into account the new settings...

Have you created a ticket(s) for this? I guess it is quite seperate from all the other stuff. I personally hope the ARB water shader will be made default for non-GLSL rendering as the current CPU-based one looks quite hideous in comparison.

[myconid]

I have a problem on the 'biwater' branch. When I enable shadows, the whole minimap is revealed:

If I move the camera into the SoD (outside the view of any shadow rendering, perhaps?), the minimap returns to normal.

Haven't been able to reproduce. Be more specific. Which map? GLSL or ARB?

Also, shadows on water do not seem to be affected by waves on the water surface. Don't know if that is fixable.

Yeah, it's not a problem.

[myconid]

Have you created a ticket(s) for this? I guess it is quite seperate from all the other stuff. I personally hope the ARB water shader will be made default for non-GLSL rendering as the current CPU-based one looks quite hideous in comparison.

I haven't given it much thought yet, but I could incorporate all the GLSL-related aspects of wraitii's code in my repo and then we could prepare a separate patch for all the ARB stuff. Seems easier to review.