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

[zoot]

Okay, here's what we can do for efficient culling: we divide each game map into regions and store the static models in a 2d array of hashmaps, where each array element corresponds to a separate region. Every time the reflections need to change, we use the 9 regions around the model to re-render its cubemap. Sounds workable to me..!

Cool! As an alternative, would it be infeasible to maintain a list of "stuff to draw" in non-real-time? So if a unit walked inside the "view" of the reflective surface, it would be added to the list. When it walks out the view, it would be removed. Then when the reflective surface comes into the view of the camera, the renderer would just draw everything on the list.

[myconid]

Cool! As an alternative, would it be infeasible to maintain a list of "stuff to draw" in non-real-time? So if a unit walked inside the "view" of the reflective surface, it would be added to the list. When it walks out the view, it would be removed. Then when the reflective surface comes into the view of the camera, the renderer would just draw everything on the list.

I think that's equivalent to my solution, but uses more memory.

Btw, I don't think we can do this with units that "walk into view" as for that we'd have to re-render all (or most) cubemaps every frame. I'm suggesting we render only when static objects like trees, buildings and terrain change, so we only rarely need to re-render the cubes.

(or maybe I misunderstood your suggestion)

Edited July 19, 2012 by myconid

[zoot]

Maybe it doesn't work this way, but I see two different "modes": cubemaps for drawing static objects and "something else" for drawing dynamic objects. My suggestion then would be to reduce the real-time workload of the "something else" part by continually keeping track of units in view of the reflector.

Edited July 19, 2012 by zoot

[myconid]

Maybe it doesn't work this way, but I see two different "modes": cubemaps for drawing static objects and "something else" for drawing dynamic objects. My suggestion then would be to reduce the real-time workload of the "something else" part by continually keeping track of units in view of the reflector.

Okay, we could do something like this:

There are two cubemaps per reflective object. One contains all the static objects and is rarely updated, while a second cubemap contains all the dynamic objects and is updated every frame. The alpha channels of the two cubemaps contain depth information.

When rendering the reflective object, we pass in both cubemaps. We sample the same locations from both cubes and decide which one to use based on depth.

Don't know if the alpha channel of a texture has good enough precision for depth testing, but this seems like a very interesting experiment. 32f textrures, maybe? This is starting to sound way too wasteful.

Edited July 19, 2012 by myconid

[zoot]

This is starting to sound way too wasteful.

Ah well It did sound very nice, though.

[Gen.Kenobi]

If we can already reflect buildings and static objects, I think it'll be enough, since we really won't get many "models" with water nor people standing next to them... But again, would be nice to have all possible ways (dynamic too - how intensive would it be? Maybe it could be easily turned on or off if the player wanted or his hardware didn't support), if possible For modders and maybe for things like waterfalls, ect.

Yeah. I am no programmer, so please forgive my "out-of-range" suggestions

[myconid]

Right now it doesn't reflect buildings, just the sky. I guess in my first attempt I'll make it so everything is reflected (including dynamic objects) and updated every frame. This is actually easiest from a dev point of view, uses very little memory but a lot of processing power, and will give us an idea about how feasible this is.

But anyway, as interesting as this is I don't plan to tackle it right away. Just FYI, my priorities list atm looks somewhat like this:

• Finish off the new materials system for the terrain renderer.
  
• Extend this materials system to terrain decals.
  
• Wrap up the custom terrain alphamaps loader.
  
• Finish the postprocessing manager: add correct LOS rendering, expose effects parameters in config.
  
• Add passing cloud shadows on terrain.
  
• Add basic terrain erosion in Atlas.
  
• Support for animated textures (parametric, like translation for a waterfall).
  
• Support for animated textures (from files, like the water normalmaps).
  
• Experiment with GPU raytracing of AO.
  
• Experiment with cloud rendering, particle effects.
  
• Experiment with reflection cubemaps rendering for reflections.
  
• Experiment with more realistic water effects (waves, ship trails etc).
  
• Experiment with LOS obstructions and multiple pathfinder obstructions.
  
• Et cetera, ad infinitum.
  

Edited July 23, 2012 by myconid

[Pureon]

Rock on!

[zoot]

I need to check what's been changed (if anything) in the multi-texture and multi-UV stuff and submit new patches Then those need to be reviewed. Then the rest as patches. Then that needs to be reviewed. Do forever.

Can you be bribed to put this on your list?

Edit: Oh, I guess you already did.

Edited July 20, 2012 by zoot

[Wijitmaker]

• Et cetera, ad infinitum.
  

Sounds like a great list. Could you throw on a post processing affect for altering hue/saturation, gamma affects?

[myconid]

Sounds like a great list. Could you throw on a post processing affect for altering hue/saturation, gamma affects?

Sure.

[Wijitmaker]

Ok, try this for a specular and light map.

[myconid]

Ok, try this for a specular and light map.

http://imgur.com/a/XUvu0

[Wijitmaker]

Cool thanks. I think the light map will work, but I need to make some tweaks to the diffuse texture. It is hard to tell the specular from a static photo, do you think it looks OK in motion? I'm not happy with the roof textures. The texture was created from a photograph that was not taken perpendicularity from the roof, so all the tiles look funny. I guess it will work for showcasing the capabilities, but it doesn't look quite right to the eye. The pediment and those statues in the arches sorely need some more help too. I have an idea for that, but it will require some more work.

[myconid]

It is hard to tell the specular from a static photo, do you think it looks OK in motion?

I think they're quite nice, though I'd say both the specular and the normal maps look a bit too flawless. If you look at the second pic (where I rotated the camera to face the sun), the reflected light looks way too even.

For example, where there are scratches and imperfections in the stone walls or the marble floors (in the diffuse texture), light could behave slightly differently to look more realistic. e.g. In this pic, there are some self-shadows, which would affect the surface normals/specularity.

Edited July 21, 2012 by myconid

[Wijitmaker]

I think they're quite nice, though I'd say both the specular and the normal maps look a bit too flawless. If you look at the second pic (where I rotated the camera to face the sun), the reflected light looks way too even.

For example, where there are scratches and imperfections in the stone walls or the marble floors (in the diffuse texture), light could behave slightly differently to look more realistic. e.g. In this pic, there are some self-shadows, which would affect the surface normals/specularity.

Ok, thanks I'll work on refining it a bit more.

[k776]

myconid, your two patches (multi texture and multi coord) have been applied to SVN and the git clone has been updated.

When you get a chance, please merge your branches with git://github.com/0ad/0ad.git which will make the 'git diff' much cleaner to look at.

[zoot]

myconid, your two patches (multi texture and multi coord) have been applied to SVN and the git clone has been updated.

Good stuff. Can #1429 be put back on review?

[myconid]

myconid, your two patches (multi texture and multi coord) have been applied to SVN and the git clone has been updated.

When you get a chance, please merge your branches with git://github.com/0ad/0ad.git which will make the 'git diff' much cleaner to look at.

Ok. I'll also have to separate the code from the game data in the commits, because they've become somewhat mixed together.

Btw, would it be possible for people to review the code straight from the git repo? It's very cumbersome to have to generate patches, get feedback, generate the patches again, get other feedback...

[k776]

Good stuff. Can #1429 be put back on review?

Not quite. I think myconid's Git work is far ahead of those older patches.

Btw, would it be possible for people to review the code straight from the git repo? It's very cumbersome to have to generate patches, get feedback, generate the patches again, get other feedback...

In theory, yes. It'll be much easier for developers to code review using Github's branch compare functionality.

[zoot]

Not quite. I think myconid's Git work is far ahead of those older patches.

From a purely 'economical' point of view, I'd have to advocate against postponing this ticket until next alpha for the specific reason that it will give artists (and everyone around them) three months less to develop normal/parallax/etc maps in. Nearly all of myconid's other changes (and wraitii's too) can wait, because they don't have implications for other contributors, but if this branch does not make it into the upcoming alpha, artists who want to work on normal maps specifically (and there is a lot of good work that can be done) will effectively have to sit on their hands for the next three months.

That said, I do of course understand if reviewers just don't have the time.

*steps off the soap-box*

[k776]

Well, for started, myconid's latest patch on Trac is most likely outdated. He's done a lot of changes lately.

I agree, it would be nice to have his work merged in, and it was the driving force behind getting two of the support patches committed.

@myconid It would help the developers reviewing if you could provide a hierarchy of your branches. i.e. which is the base, which ones can be merged in next, which ones are in progress etc. From what I can see, it sort of looks like this at the moment (please correct/fill in):

• modelmapping
  
  • windtrees
    
    • smoothlos
      
      • postproc
        

      [*]terrainmapping

      • terrainalpha2
        

[historic_bruno]

From a purely 'economical' point of view, I'd have to advocate against postponing this ticket until next alpha for the specific reason that it will give artists (and everyone around them) three months less to develop normal/parallax/etc maps in. Nearly all of myconid's other changes (and wraitii's too) can wait, because they don't have implications for other contributors, but if this branch does not make it into the upcoming alpha, artists who want to work on normal maps specifically (and there is a lot of good work that can be done) will effectively have to sit on their hands for the next three months.

That said, I do of course understand if reviewers just don't have the time.

*steps off the soap-box*

Artists shouldn't be using releases for development anyway, so it's no problem if they start working on completely new stuff in the middle of a release cycle, after all that's part of development While it might be nice to attract new contributors with fancy features like AO/normalmapping/etc, IMO it doesn't particularly matter if that happens in A11, A12 or later. And also, no one says they can't start working on AO and normal maps now and wait to see how they look in-game. I think we've shown the concept is possible and probable.

As far as the difficulty of creating an SVN patch from Git, since we have to commit to SVN, someone has to go through that pain...

[wraitii]

Myconid, would it be easier for me to work from a clean SVN (ie Kieran's master branch) or from your merged branch?

[myconid]

@myconid It would help the developers reviewing if you could provide a hierarchy of your branches. i.e. which is the base, which ones can be merged in next, which ones are in progress etc. From what I can see, it sort of looks like this at the moment (please correct/fill in):

Yes, the patch on trac is completely out of date. I'm not too fussed about which Alpha these changes are included in, as long as someone can upload some Windows binaries for people to work with!

As for hierarchy, most things are actually independent of each other! I have occasionally merged some branches together for integration testing, but most changes are separate and the relevant commits shouldn't be hard to pick out. There are four different things that can be reviewed more or less simultaneously. IIRC, these are:

1. modelmapping (merge of modelmapping + effectsdistance2),
   
2. terrainmapping (merge of terrainmapping + terrainalpha2),
   
3. smoothlos, and
   
4. importheightmap.
   

Tell me the order in which you want these prepared and I'll put the relevant commits in new branches for you to sink your teeth in.

In the meantime, I updated from upstream yesterday and started merging with the modelmapping branch (not pushed yet), and I'm dealing with a strange regression bug in the commit to support older ATI cards like fabio's (the kind of bug where putting four values in some vector causes the tree shadows to disappear, which seems more like a driver bug). If this can't be resolved quickly, I'll just reset modelmapping to before that commit and people with old hardware will have to stick with ARB.. Sorry, guys, you really need to upgrade already.