Jump to content

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


Recommended Posts

Can haz grass? :D

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

Link to post
Share on other sites
  • 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

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

Link to post
Share on other sites

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:

small.jpg

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 by zoot
Link to post
Share on other sites

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

Link to post
Share on other sites

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.

  • Like 1
Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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:

BBkPrl.png

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

Link to post
Share on other sites

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:

BBkPrl.png

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 by myconid
Link to post
Share on other sites

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 by myconid
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

2bXhg.jpg

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?

Link to post
Share on other sites

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? =])

Link to post
Share on other sites

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 by myconid
Link to post
Share on other sites

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.

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