How to improve the way of making tilesets

[tucho]

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.

Code: [Select]

[img]http://img38.imageshack.us/img38/3848/newtilesetsystem.jpg[/img]Edit by Ultifd- Making is the correct grammar

[Psychedelic_hands]

Hey tucho!  

Currently Mega-glest and Glest Advanced Engine are planing to be merged into just one engine. So no new features are planed for either after thier next release which will be the end of March. There are talks of the new engine being called Glest 4.

So this won't make it into Mega-glest, but it could probably make it to Glest 4!

[ElimiNator]

This is a very good idea, I have seen it in commercial games and it looks way better.

[Omega]

I'm not entirely sure I understand it, but if it improves graphics without causing incompatibilities, I'm game.

[wciow]

I'm not entirely sure I understand it, but if it improves graphics without causing incompatibilities, I'm game.

I don't know the code but I assume that instead of rendering a different tile in each 64x64 square the engine will simply use the coordinate data of each square to know which part of the larger texture to render in each square. Adjacent squares from different textures will still be blended as normal. Seems like a great idea, Thanks Tucho 

[-Archmage-]

Nice Tucho!
I would guess that would improve performance a bit too, because of 1 texture to render instead of 64 different ones. Might not make much of a difference performance wise but that'll be way nicer looking!

[softcoder]

Tucho, titi had mentioned something like this a while ago to me, we will take a close look at this and see what can be done. Thanks for the suggestion and please keep them coming

[titi]

Hi tucho, I had a similar idea when I once experimented with jmonkey (jglest) because I am much much more skilled in java programming.
Whats currently stopping me from implementing my idea are my missing skills with OpenGL.
I think what we need for this are shaders using alpha blending ( At least I think this is the way to go ).....

what I did in java:
As you described I tiled the existing tiles up to 2048x2048 respecting their given probability. This was the base texture what was used for this texture layer ( and was tileable too). You were also able to use bigger textures which were either upscaled the same way if smaller than 2048x2048 or used like they are if bigger than 2048x2048. By this you got big texture tiles which were used for one layer of the surface. All these layers now have to be rendered one over another on the surface of the terrain. This is done with alpha blending. I used simple alpha maps which only had one pixel per (glest)cell so that the borders were very blurry. This blurry effect was looking very much the same as the blending which is made in software in current glests. ( The alpha map I generated had exactly the size of the map because I had one pixel per cell )

What I learned now is that you can have a rgb color bitmap instead of a black white alpha map were each color stands for one layer.
So if red value is set in one pixel it stands for the blending of that layer. If the red value is 0 there, no texture is painted. if its 255 its fully painted.

Currently we use 6 layers to paint a glest terrain, so it is maybe possible to render them in only two passes. If we use this we would greatly improve the terrain rendering and make it much more easy to create good looking terrain textures, without loosing the backwards compatibility to older tilesets.
On a side effect I think we need much less memory to hold all the textures for each cell on the map, because we now only need to hold one "base texture" for each layer ( which is repeated automaticaly when rendered on the terrain ).  

[will]

There's a limit to how many textures you can have 'active' at any one time and that will be what defines the number of passes.

With modern 'shaders' and such there is no problem having arbitrary number of layers, or even using bits to turn off or on each layer.

[titi]

Here is what i did in java:

The AlphaCalculator
http://pastebin.com/ktBDYUCa

TextureMerger:
http://pastebin.com/VyMz5Lgt

TerrainLoader:
http://pastebin.com/m97vcX9D

(hopefully) full source:
http://www.titusgames.de/jglest_src_2011_3_22.tgz

[will]

Here is what i did in java:

awesome!  I love to look at code.

Perhaps looking at screenshots is more informative though.  Do we have a good idea of any 'before' and 'after' comparisons for this technique?

[tucho]

I agree, screenshots would be cool for people that is not a coder

I guess this is no aplicable to the normal Glest, is there anybody with OGL knowledges who want to implement it on Glest, GAE or Megaglest?

I really think that this would improve a lot the Glest general look.

Cheers

[Omega]

I agree, screenshots would be cool for people that is not a coder

I guess this is no aplicable to the normal Glest, is there anybody with OGL knowledges who want to implement it on Glest, GAE or Megaglest?

I really think that this would improve a lot the Glest general look.

Cheers

The original Glest isn't really developed, as most developers are split between GAE and MegaGlest. However, the two forks are planning a merger, and would really like to christen this merged Glest as "Glest 4", as it expands on everything the original Glest had.