FreeGameDev

The tiles are now separated, centered, named and ready for export (very tedious work). However, the claimed walls still don't fit to the dirt walls and I probably need a set of connector pieces that have to be placed between them to get rid of the gaps. It's getting more and more complicated. I'm going to add the tileset to the SVN repository tomorrow.

Cool, looking forward to see it in action

Cleaning up the files and fixing some mistakes in the meshes took more time than expected, so I'm uploading the files now. I don't want to replace the old tiles yet, because the placing system needs to be changed first, so I'll put everything into the new OD_Tilesets source folder. The scale is 2.5*2.5.

I need a break now.

You deserved it, GOOD WORK

svenskmand {l Wrote}:The textures I talk about should just be parallel to the floor of the tiles and only be visible from the top. They should be position just a little bit above the tile, and this ordering will also define the precedence for the terrains. But you still only need to do 12 (I was wrong with 16 before) different transitions for each tile type, i.e. 4 edges and 4 corners, that points outwards and 4 corners that points inwards, you do not need 4 edges that point inwards/outwards as you can just use the other edges. So then you need to to 12*n transitions in total for n different types of terrain.

Then using texture splatting will give even more variation, which is always nice

Warcraft3 used this splatting method (pre-defined alphas for blending transitions. click). It leads to one of two scenarios: A) Terrain is dull because every tile uses the same transition, or B) puts a huge workload on the artists to hand-paint each transition scenario for each texture. Either way it always cuts down on the end-user customize-ability, because the transitions are predefined. It also prevents your terrain textures from having alpha channel (one unrelated to the transitions).

It is much easier and more versatile to setup a layered splatting system that uses weights to blend transitions. This can be done in a number of ways (shoving the weights in a texture, then retrieving them using texture-lookups in the shaders, using the alpha channel of the vertex color-buffer, etc). Each has its benefits and it all depends on what you want for your terrain. One disadvantage to doing it in the vertex color buffer is lighting can be more expensive using multi-pass (slower for lighting, faster for more complicated splats). The texture-lookup method is slower when using complicated splats (and limited in the texture count), but can be much faster for the lighting. Vertex-color-buffer is different in its interpolation methods (its exp instead of linear), which can cause problems with even transitions.

There are a slew of other methods, but this gets the point across. Ideally you would need a deferred rendering/multi-pass hybrid with (what I would recommend) vertex-color-buffer splatting. Its the best method IMHO. The implementation shown in this demo would work great with splatting.

Please keep in mind that the game is inherently tile based as the player digs and builds on tiles, hence the transitions should not be made too "nice/artistic" as the player should still be able to see where the tiles are. I am not sure exactly how you imagine the transitions should look. Do you have examples of what you imagine them to be? With that in mind I think my suggestion should suffice. Also the mappers should only choose which terrain type a tile should have and then the game should do the actual transitions. You suggestion with texture splatting with weights sounds like the mapper will hand-paint the terrain with each texture type, i.e. like you can do in UT2004 and probably also UT3, this is the same system they use in SC2 also (see 4:50).

svenskmand {l Wrote}:Please keep in mind that the game is inherently tile based as the player digs and builds on tiles, hence the transitions should not be made too "nice/artistic" as the player should still be able to see where the tiles are.

You can still make it nice and accentuate the tile types.

svenskmand {l Wrote}:I am not sure exactly how you imagine the transitions should look. Do you have examples of what you imagine them to be?

The one I described is used for Sc2, but by the way Sc2 does things don't think the system can't be tweaked to fit OD's needs. Here is a quick screenshot from the project I am working on: http://img59.imageshack.us/img59/2464/mapeditor.jpg

svenskmand {l Wrote}:Also the mappers should only choose which terrain type a tile should have and then the game should do the actual transitions.

Its called procedural generation, and is very doable in the method I described. In fact, it is also far more versatile than the predefined-transition method--scales and biases can be added to the texture weights, which can add control and variation to the transitions while still keeping them procedurally generated.

Heh your one of the guys from Galatic Vice! So which of the guys are you? Is it Jon or Bob or someine else?

svenskmand {l Wrote}:Heh your one of the guys from Galatic Vice! So which of the guys are you? Is it Jon or Bob or someine else?

I am Jon . Back to the subject--how are you currently implementing your terrain, and what features must it support?

Currently the terrain is made using individual tile meshes put next to each other.
(By the way, I am working on changing the game to use the Ogre RT shaders, and after that we can start adding the extra shaders for team colours and other things. Though I have hit some issues, so I might have to go ask for some help over at the Ogre forums.)

oln {l Wrote}:Currently the terrain is made using individual tile meshes put next to each other.

And are the textures independent? aka does the engine mix/match the tile meshes and textures?

Yep, independent textures.
The engine does some testing for walls that are being picked down, and switches meshes according to how much they are dug out. (Not sure if it uses direction or not.)
Other than that it's just cube meshes put next to each other.

oln {l Wrote}:Yep, independent textures.

Then weight-splatting should work fine.

oln {l Wrote}:The engine does some testing for walls that are being picked down, and switches meshes according to how much they are dug out. (Not sure if it uses direction or not.)
Other than that it's just cube meshes put next to each other.

How do you standardize your mesh transitions? (adjacent tiles must sync up, and yet you must have interchangeable meshes, correct?)