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

[myconid]

Can haz grass?

(Here is a page about the technique. I realize it's not super simple!)

I know people don't like it when I say this, but it's not really that complex... I think it may be inefficient because we'd have to render the terrain 10+ times, once for each "layer", though I suppose there's no harm in having the option available.

Btw, this reveals a lack of multipass shader support in the terrain renderer. In theory, the materials system and model renderer can do something like this, but the terrain renderer will need to see some changes first.

Anyway, I'm having a really busy week right now, so I'll look at this over the weekend!

[wraitii]

If you're interested in working with 0 A.D. after the whole renderer updates have been cleared up, this might be relevant to your interests.

[Wijitmaker]

Well done, mate. In your view, which effects are missing before the engine's capablities are on par with AoE3?

I forgot about this but I thought you guys might find this interesting. I had some copies of an old game developer's conference that was held in 2005 with the AOE3 lead and senior programmer. They were talking about the new graphical engine features prior to the release of the game. You can see the slides in my attachment. There is more commentary here:

http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fgamepro.tistory.com%2Farchive%2F20060329%3Fpage%3D1

If you had a membership and access to http://www.gdconf.com/ you could probably see the whole bit there.

There are some details shared there about AOE3 cliffs that might be applicable to the terrain displacement discussion going on here: http://www.wildfiregames.com/forum/index.php?showtopic=16197

About the grass... how would that work, you won't want to have grass everywhere? Would you have to have a grass masking map for terrains that would get the grass? Could you color the grass to match the pixels of the terrain, and perhaps use RGB pixel values to define height variation (greener = taller)? These are the questions that popped in my head when I saw that video.

aoe3gdc2005.zip

[zoot]

I forgot about this but I thought you guys might find this interesting. I had some copies of an old game developer's conference that was held in 2005 with the AOE3 lead and senior programmer. They were talking about the new graphical engine features prior to the release of the game. You can see the slides in my attachment. There is more commentary here:

Thanks, I was considering buying that talk a while ago. The slides will give me the gist of it.

About the grass... how would that work, you won't want to have grass everywhere? Would you have to have a grass masking map for terrains that would get the grass? Could you color the grass to match the pixels of the terrain, and perhaps use RGB pixel values to define height variation (greener = taller)? These are the questions that popped in my head when I saw that video.

Subject to implementation, it could just be another material. The technique basically just extrudes a flat texture into 3D space, so its coloring would reflect the texture used:

Probably the cleanest way to control height would be with myconid's new terrain XML, so the "tall oatgrass" terrain type would have one height and the "buffalograss" type would have another etc. I assume the length of the invidual 'blades' can be varied relative to the base height by varying their alpha (high alpha -> short blade, low alpha -> long blade).

Edited June 26, 2012 by zoot

[Gen.Kenobi]

I really believe that grass should be something that we could look into, but not only as simple grass, but maybe also as some farm-fields or anything like that, supposing that we can have this material on actors, not only in terrains

Think about the possibilities of grass, ambushes, guerrilla, it could add a lot in terms of gameplay. Or just visually, if that's the case.

[iap]

Guys, all of your effort is amazing, I really appreciate it!

However, it seems that these additions are good only for close-up scenes.

While I like to get near the feild to see all the detailes, most of the gameplay is from far away.

[wraitii]

However, it seems that these additions are good only for close-up scenes.

While I like to get near the feild to see all the detailes, most of the gameplay is from far away.

All the texture mapping and the lighting effects are hard to discern from far away, but certainly improve the graphical feel of the game. Same with moving trees. This kind of improvement is not necessarily flashy (bar HDR - this is a funny joke -), but it makes a game go from "good looking" to "great looking", even at long distances

[myconid]

I forgot about this but I thought you guys might find this interesting. I had some copies of an old game developer's conference that was held in 2005 with the AOE3 lead and senior programmer. They were talking about the new graphical engine features prior to the release of the game.

The procedural rivers look interesting.

About the grass... how would that work, you won't want to have grass everywhere? Would you have to have a grass masking map for terrains that would get the grass? Could you color the grass to match the pixels of the terrain, and perhaps use RGB pixel values to define height variation (greener = taller)? These are the questions that popped in my head when I saw that video.

zoot is correct, it can be just another material.

However, it seems that these additions are good only for close-up scenes.

While I like to get near the feild to see all the detailes, most of the gameplay is from far away.

There are also screen-space effects on the way (look nearer the beginning of the thread).

[iap]

Thanks for reassuring.

[myconid]

Had some time today, so I threw this together to test performance... it certainly looks interesting, but it's just too slow.

[zoot]

Wow!

[Wijitmaker]

Aye that is impressive. It would be most impressive it moved with the trees Would performance be helped if it was thinned or the quantity of it lessened? Or perhaps if instead of applying directly to terrain, it could be applied to an object that could be placed on the terrain by a map designer.

[zoot]

I guess it comes down to a combination of:

• Massive amounts of overdraw
  
• Sorting problems due to alpha blending
  
• General inefficiency of the algorithm
  

?

[myconid]

Aye that is impressive. It would be most impressive it moved with the trees Would performance be helped if it was thinned or the quantity of it lessened? Or perhaps if instead of applying directly to terrain, it could be applied to an object that could be placed on the terrain by a map designer.

The longer the grass, the slower it needs to be to look decent (12 iterations per vertex in the above).

I'm using the multipass shader system for rendering, which definitely contributes to the slowness, though I'm certain the algorithm is already quite slow due to how it works.

We could make this material a special case in the renderer, though I'm not a fan of that idea.

[zoot]

It seems a main constituent part of the effect is the way that the angle at which each blade of grass is rendered depends on the viewing angle:

I can't help wondering if the effect could be simulated with a much simpler radial blur type of filter.

[myconid]

It seems a main constituent part of the effect is the way that the angle at which each blade of grass is rendered depends on the viewing angle:

I can't help wondering if the effect could be simulated with a much simpler radial blur type of filter.

Hmm, I doubt it... I think that won't look perspective-correct unless you can find a way to draw each blade of grass back-to-front.

Btw, it may not be as slow as I thought initially. Still pretty slow, though.

Edited June 27, 2012 by myconid

[myconid]

Here's a question for the programmers:

The actor in actors/campaigns/structures/hellenes/settlement_houses.xml is having some issues with the tangent generation. I get this error when loading the model (which comes out looking wrong):

ERROR: Failed to create VBOs (64*47479)

The error is not caused by any real hardware or software limit. There's a hardcoded 2MB buffer limit in renderer/VertexBuffer.h:

// Absolute maximum (bytewise) size of each GL vertex buffer object.
// Make it large enough for the maximum feasible mesh size (64K vertexes,
// 32 bytes per vertex in ShaderModelRenderer).
// TODO: measure what influence this has on performance
#define MAX_VB_SIZE_BYTES  (2*1024*1024)

This assumes 32 bytes per vertex max, but obviously by adding tangents, extra UVs etc that gets pushed over (and there's also padding to power of 2 sizes). What's the point of this hardcoded limit, other than not putting everything in one buffer? ... Can I change it to 4*1024*1024 (i.e. 64 bytes per vertex)?

Edited June 28, 2012 by myconid

[Pureon]

The actor in actors/campaigns/structures/hellenes/settlement_houses.xml is having some issues with the tangent generation. I get this error when loading the model (which comes out looking wrong):

It's one of the town/city models we created to illustrate what campaign maps could look like. You're receiving the error because the model was created by merging many other building models together into one DAE file - creating an excessively detailed model. When/if we create campaign maps, the models will be a lot less detailed.

One of the programmers will be able to explain why high-poly models cause that error.

[iap]

Wow!

Wow!

[myconid]

It's one of the town/city models we created to illustrate what campaign maps could look like. You're receiving the error because the model was created by merging many other building models together into one DAE file - creating an excessively detailed model. When/if we create campaign maps, the models will be a lot less detailed.

One of the programmers will be able to explain why high-poly models cause that error.

Thanks, I realise now that my question contained the answer: there's no real technical reason for choosing that size, I just need to "make it large enough for the maximum feasible mesh size" like the comment says, which is now 4MB. Problem sorted.

[Mythos_Ruler]

Had some time today, so I threw this together to test performance... it certainly looks interesting, but it's just too slow.

This looks bloody awesome btw. Would it be possible to assign different materials to different terrain textures to get different densities of grass and shrubbery?

[zoot]

This looks bloody awesome btw. Would it be possible to assign different materials to different terrain textures to get different densities of grass and shrubbery?

I'll take a stab at this: In short, yes. You can vary the density by varying the density of the input texture.

Btw, it may not be as slow as I thought initially. Still pretty slow, though.

I was wondering if you have done any LoD optimizations? If not, I'd venture the guess that it spends loads of time rendering layers in the scene's background that can't be seen anyway. (btw, any chance you could push to Github? )

[myconid]

I was wondering if you have done any LoD optimizations? If not, I'd venture the guess that it spends loads of time rendering layers in the scene's background that can't be seen anyway. (btw, any chance you could push to Github? )

No Lod.

Have fun running it on your netbook.

The grass material is attached to art/terrains/grass/grass1_spring.xml, which is the "default" grass. Look at shaders/effects/terrain_grass.xml for the evil multipass commands that make it so slow.

Edited June 30, 2012 by myconid

[zoot]

Thanks!

Have fun running it on your netbook.

Only makes it more incumbent upon me to come up with an optimization

[zoot]

The grass material is attached to art/terrains/grass/grass1_spring.xml, which is the "default" grass. Look at shaders/effects/terrain_grass.xml for the evil multipass commands that make it so slow.

The file shaders/effects/terrain_grass.xml seem to be missing from the commit, as well as terrain_triplanar.xml. The file art/terrains/grass/grass1_spring.xml references the terrain_base.xml material.