Making better looking environments

[Psychedelic_hands]

To be frank, Glest has terrible looking environments. I spent a long time working on a tileset for a new project of mine, but ultimately realised that it was futile trying to get what I wanted.
The downfall of glest's environments I think is because the tile system is so obvious, one way to change this is with tucho's idea:

(click to show/hide)

Hi, I'd like to make a sugestion, I talked about it with Martiño a lot of years ago when we was working on 1.0 version but we never implemented it because there was other priorities in that moment.

As I see the awesome improvements that you are making on Megaglest engine I'd like to tell you my idea just in case you like it and you can implement it on Megaglest.

The thing is to make bigger textures for tilesets (512 for example ) and just one for each different kind of texture, instead a lot of 64x64 small tiles, but keeping the current pixel aspect ratio and the size of cells to make the blending between the different thextures (by this way all the old maps will keep working with the new system).

With this system, making new tilesets would be much easier than with the current system, and the visual look will be much better because the tiling will be much less evident than with the small 64x64 tiles.

If whe think that the ground is one of things that take up a considerable space on the screen when you play a Glest game, we will achieve a considerable improvement in the global visual Glest quality.

I'm not a programmer and I don't know how difficult can be to implement this system, but I guess that won't be too complicated, and the result will really worth.

I attach a picture just in case I don't explain it too clearly (my English sucks )

Tell me what you think about this idea.


Edit by Ultifd- Making is the correct grammar

If you didn't understand that, heres my interpretaton:
Instead of rending each tile individually with a different texture, it instead renders larger textures in the coordinates of the specific tile where needed.
This would rid Glest of those ugly seams and repeative tiles everywhere. Something which would make GAE look so much more purty!

Another thing which has been suggested before, bump maps on ground textures. Normal maps are already implemented in GAE so I'm not sure easy it would be to implement. But I beleive it would be far more worthwhile than putting bump maps on units, I could cite many examples of how nice this would be; but I'm sure you all know already.

Can a ticket please be made for these two features? I'm not a coder but they sound relatively straight forward. 

[John.d.h]

Another thing which has been suggested before, bump maps on ground textures. Normal maps are already implemented in GAE so I'm not sure easy it would be to implement. But I beleive it would be far more worthwhile than putting bump maps on units, I could cite many examples of how nice this would be; but I'm sure you all know already.

Yes.  This.  Terrain with depth looks amazing compared to the flat, painted-on stuff we have.

[Philip]

Instead of rending each tile individually with a different texture, it instead renders larger textures in the coordinates of the specific tile where needed.
This would rid Glest of those ugly seams and repeative tiles everywhere. Something which would make GAE look so much more purty!

If I understand correctly, that's pretty much what 0 A.D. does: its terrain textures are typically 512x512, and they're stretched to cover about 8x8 tiles (and also rotated by 45 degrees to give more of a traditional isometric look, since the default camera angle is aligned with the terrain grid). (The renderer then just looks for all tiles that share some particular texture, picks the appropriate alpha-blending shape for tiles adjacent to the ones with that texture, sticks everything into a VBO with the base texture using one set of texcoords (allowing arbitrary scaling and rotation just by transforming those texcoords) and the blend texture selected from an atlas with another set of texcoords, then repeat for every base texture in the map, and render by drawing each layer on top of the previous ones. I think that may be quite different to how Glest's current terrain renderer works, though I don't know much about that. I think 0 A.D.'s a nice approach since it's reasonably efficient and it allows high-res base textures and high-res blend textures without needing to maintain world-sized splat textures.)

[Psychedelic_hands]

Instead of rending each tile individually with a different texture, it instead renders larger textures in the coordinates of the specific tile where needed.
This would rid Glest of those ugly seams and repeative tiles everywhere. Something which would make GAE look so much more purty!

If I understand correctly, that's pretty much what 0 A.D. does: its terrain textures are typically 512x512, and they're stretched to cover about 8x8 tiles (and also rotated by 45 degrees to give more of a traditional isometric look, since the default camera angle is aligned with the terrain grid). (The renderer then just looks for all tiles that share some particular texture, picks the appropriate alpha-blending shape for tiles adjacent to the ones with that texture, sticks everything into a VBO with the base texture using one set of texcoords (allowing arbitrary scaling and rotation just by transforming those texcoords) and the blend texture selected from an atlas with another set of texcoords, then repeat for every base texture in the map, and render by drawing each layer on top of the previous ones. I think that may be quite different to how Glest's current terrain renderer works, though I don't know much about that. I think 0 A.D.'s a nice approach since it's reasonably efficient and it allows high-res base textures and high-res blend textures without needing to maintain world-sized splat textures.)

Thanks for that post! Much more descriptive than I could ever be!
I am not a coder, but I would love to know more. Care to share any more insight into how you got the 0 A.D engine to looks so dang smexy? And maybe ways we could apply that to our own, adequately-looking engine?

[silnarm]

The downfall of glest's environments I think is because the tile system is so obvious, one way to change this is with tucho's idea:

If Glest had only 4 'surface types' rather than 5, then I reckon I would have done this shortly after tucho suggested it. Even then I was concerned with the extra memory it would eat, but I was thinking inside a box... see reply to Philip below.

Can a ticket please be made for these two features? I'm not a coder but they sound relatively straight forward. 

You'll get your tickets (although I think there is already one for a new terrain render/splat system), but beware the "I'm not a programmer, but this seems simple" comments. Nothing is a simple as it sounds, a good idea is worth little compared to a good implementation, and the former does not guarantee the later.

Another thing which has been suggested before, bump maps on ground textures. Normal maps are already implemented in GAE so I'm not sure easy it would be to implement. But I beleive it would be far more worthwhile than putting bump maps on units, I could cite many examples of how nice this would be; but I'm sure you all know already.

Yes.  This.  Terrain with depth looks amazing compared to the flat, painted-on stuff we have.

I'm happy to get it rigged up and let people experiment, but considering the terrain will generally fill the entire field of view, the performance hit which be much more noticeable.

The renderer then just looks for all tiles that share some particular texture, picks the appropriate alpha-blending shape for tiles adjacent to the ones with that texture, sticks everything into a VBO with the base texture using one set of texcoords (allowing arbitrary scaling and rotation just by transforming those texcoords) and the blend texture selected from an atlas with another set of texcoords, then repeat for every base texture in the map, and render by drawing each layer on top of the previous ones.

Multi-pass... of course! I feel a little foolish now, I was blindly seeking a one pass solution and the amount of extra UV coords I would need to make that work was a major issue, and it also would have required the 'tile type' as a vertex attribute and then numerous conditionals in the shader (not a good thing).

Building the texture up in multiple passes removes both these problems, and indeed the need to implement it using a shader.

Many thanks Philip!

[Omega]

If Glest had only 4 'surface types' rather than 5, then I reckon I would have done this shortly after tucho suggested it. Even then I was concerned with the extra memory it would eat, but I was thinking inside a box... see reply to Philip below.

We don't even really use the 5th at all. I would be fine with seeing it gone gone gone (and replacing any instances of it with surface 3 - road, on maps).

I'm happy to get it rigged up and let people experiment, but considering the terrain will generally fill the entire field of view, the performance hit which be much more noticeable.

Even if it's just an option for the higher end computers (perhaps defaulting off if the impact ends up being too much), it would still be a nice idea.

[John.d.h]

Speaking of better looking environments, here was something I read that seems related to our old transparency problem, and may (wild hunch) be a better way to do it: http://blog.wolfire.com/2009/02/rendering-plants-with-smooth-edges/

[Philip]

Care to share any more insight into how you got the 0 A.D engine to looks so dang smexy? And maybe ways we could apply that to our own, adequately-looking engine?

0 A.D. doesn't really do much at all - it's all plain diffuse lighting with a single static light source (plus standard depth-texture shadows); only a single texture per mesh, no specular, no normal maps, no ambient occlusion, etc. Partly that's intentional, since it's technically easier for artists if they don't have to worry about more features and they can focus more on the art itself, though mostly it's just because we haven't got around to implementing anything fancy. The graphics code tries to be flexible in the non-fancy things it does do (e.g. terrain does this scaling stuff to minimise visible tiling, and it also gives the map designer full control over the blending order of tiles (e.g. road tiles can be blended either on top of grass or underneath grass, simply by left-click vs right-click in the editor); and units can be built from many randomised components (typically a single body mesh with a choice of a few textures, and a choice of a few heads, and some shields, and different weapons or tools depending on the unit's current activity) to give them some individuality; etc). I think the resulting look must be mostly thanks to the artists rather than to coders

Multi-pass... of course! I feel a little foolish now, I was blindly seeking a one pass solution and the amount of extra UV coords I would need to make that work was a major issue, and it also would have required the 'tile type' as a vertex attribute and then numerous conditionals in the shader (not a good thing).

Building the texture up in multiple passes removes both these problems, and indeed the need to implement it using a shader.

Yeah, multi-pass definitely makes this much easier (and works with plain old non-shader multitexturing). I think the main danger is fill rate - in theory, a tile in 0 A.D. could have one base texture plus 8 blend textures (from adjacent tiles) drawn on top of each other, which would be relatively painful. But in practice, most tiles just have the base texture and no blending, and most of the rest just have a base texture plus a single blend, so there's not a lot of overdraw and it's not a problem. The tricky part in 0 A.D. (which the Age of Empires games don't bother with) is that blend priorities are per-tile, not per-texture, so it can be necessary to draw one texture as multiple layers depending on the tile layout, and then it has to try hard to minimise texture binds and draw calls and dynamic memory allocations (which all make significant performance improvements). (Most of the code is here and here, for reference.)

[will]

Fascinating!  Any LOD in models or terrain?

[Philip]

There's no LOD on anything. Doesn't seem particularly important in an RTS game where the difference between minimum and maximum viewing distance is only a factor of maybe 2 or 3, compared to first-person games where you can see to the horizon, so we've been able to avoid that complexity so far, which is nice

[wciow]

I noticed that 0ad has a very restrictive camera view similar to most commericial rts games. However since Glest is highly moddable the camera can be set to give the user any view between zooming in on a single unit or viewing the whole map. The spring engine does a similar thing but is more optimised to use LOD models and sprites at long distance and also has far fewer objects on the terrain.

From what I've read on this forum the rendering in Glest has been improved a bit since 3.2.2 but is still criminally wasteful, since both fork teams lack coders with 3d graphics experience. Silnarm recently discovered and solved the problem that all models for Glest were being massively over-rendered, in some cases by 50%!

[ultifd]

I noticed that 0ad has a very restrictive camera view similar to most commericial rts games.

I don't want to be off topic, but that's probably 0 A.D.'s biggest problem, IMO. If that was improved on, 0 A.D. would be a lot better.

[Psychedelic_hands]

Can a ticket please be made for these two features? I'm not a coder but they sound relatively straight forward.  

You'll get your tickets (although I think there is already one for a new terrain render/splat system), but beware the "I'm not a programmer, but this seems simple" comments. Nothing is a simple as it sounds, a good idea is worth little compared to a good implementation, and the former does not guarantee the later.

Yes   Sorry Silnarm. Excuse my ignorant nubness.
I have honestly no idea of what I'm talking about most of the time, so best just ignor me  .

[Philip]

I noticed that 0ad has a very restrictive camera view similar to most commericial rts games. However since Glest is highly moddable the camera can be set to give the user any view between zooming in on a single unit or viewing the whole map. The spring engine does a similar thing but is more optimised to use LOD models and sprites at long distance and also has far fewer objects on the terrain.

I think several people have complained the camera is too restrictive, so I've changed it to allow zooming out somewhat further - hopefully that'll help a bit . Zooming out to view the whole map isn't something we've designed for, though, and I expect it wouldn't be trivial to get good performance there - a decent GPU can probably handle the number of polygons with no problem (one large map is only about 300K terrain tris and 1M model tris, with no LOD) but we don't do enough batching (especially for trees) so the CPU cost is too high. Although, if we did some very simple LOD, and stopped rendering little decorative objects (grasses, rocks, etc) at large distances, and maybe cheated with trees somehow (replace them with sprites or something), perhaps it wouldn't be too bad... Does Glest have any LOD-related experience that might be helpful?

[Omega]

Zooming out to view the whole map isn't something we've designed for, though, and I expect it wouldn't be trivial to get good performance there - a decent GPU can probably handle the number of polygons with no problem (one large map is only about 300K terrain tris and 1M model tris, with no LOD) but we don't do enough batching (especially for trees) so the CPU cost is too high.

Yeah, even here, where we can zoom out all the way, it gets extremely laggy when zooming far out. I suppose a better GPU could handle it better, but my laptop doesn't like zooming out to see the entire map, dropping the frame rate to about 1-3 on a 128x128 map (on a 64x64, it is actually playable to a slight degree). Overly, though, it's not made for zooming out to such levels though. I would only do that to take images of maps, such as for the Glest Wiki's Map List.

Although, if we did some very simple LOD, and stopped rendering little decorative objects (grasses, rocks, etc) at large distances, and maybe cheated with trees somehow (replace them with sprites or something), perhaps it wouldn't be too bad...

Not sure how well it would look with cheating with the trees, but removing the decorative objects would probably work well for both engines.

Does Glest have any LOD-related experience that might be helpful?

Well, there's standard mipmapping, but I'm not sure how it works or how well.

[wciow]

Glest currently doesn't do LOD at all.

I've just tested trying to render a whole 64x64 map and got a frame rate of 36 FPS. My PC is 2 years old and was mid-range when i brought it so nowhere near what a new gaming pc could handle today. The FPS might drop quite a bit once a game really gets going with dozens of extra units and particles being rendered. However if someone was to tighten up Glests rendering properly then whole map views would certainly be possible.