a tilebased terrain manager

kneeride · Post by **kneeride** » Sun Jun 25, 2006 4:03 am

is this project still in action?

just wondering whether this editor will suite my needs:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=21761

thanks.

polyveg · Post by **polyveg** » Mon Jun 26, 2006 9:16 pm

@sichuan:
there is no actual source package of the tile-engine (the old one is in the daimonin-cvs).
but there are a few projects which are using it and make some extension to it.

@kneeride:

is this project still in action?

yes and no.
yes, there is still action.
no, there is no new common source.

@all:
you have to choose your contact person...
code-black is using levels. its not time critical on setting up the level.
daimonin is using a streamed map "window".
(i havent looked very close to ultima iris yet)

polyveg · Post by **polyveg** » Sat Sep 02, 2006 4:06 pm

I have divided each tile into 8x8 subtiles for the movement, which is looking much better.
the tile-picking is working perfect (A* still needs some fine tuning).
I think it will be in the daimonin cvs within 1-2 weeks.
Its part of the tileengine, so i have no problem to release it under lgpl also...

if anybody has the time to update the tileengine code please drop a line

i am sure filopher and SiENcE have also some lines of code for the lgpl version.

Post by **jacmoe** » Sat Sep 02, 2006 6:55 pm

Good news! That means that the tileengine is still alive!

I was just about to ping this topic, but you beat me to it!

MaxWave · Post by **MaxWave** » Mon Sep 11, 2006 4:42 pm

This project is continue supporting? I download this - http://www.code-black.org/Programmversi ... Engine.rar

It does not work - this code does not correspond to modern Ogre. After fixing some code I get error in compiler VC8:

Code: Select all

Unhandled exception at 0x00f16aa5 in tilemanager_debug.exe: 0xC0000005: Access violation reading location 0x0000000c.

MaxWave · Post by **MaxWave** » Thu Sep 14, 2006 3:20 pm

auuuu, anybody here?

michtoen · Post by **michtoen** » Thu Sep 14, 2006 5:11 pm

A working version of the engine is part of our 3d client:

http://daimonin.cvs.sourceforge.net/dai ... /client3d/

MaxWave · Post by **MaxWave** » Tue Sep 19, 2006 8:14 pm

2michtoen
Please, give me adress to archive, I want to download from Reget (FTP not work on it) or my browser.

polyveg · Post by **polyveg** » Wed Sep 20, 2006 6:07 pm

assuming you are running win, you should take a look at: http://www.devdaily.com/wincvs/HowToUseWinCVS/

Filopher · Post by **Filopher** » Sat Oct 14, 2006 7:45 pm

polyveg wrote:i am sure filopher and SiENcE have also some lines of code for the lgpl version.

I did not code for quite a while now. I have to submit my diploma thesis in two weeks. But I guess things will get better then.

I've got the problem that I've rewritten the whole tilemanager code completely from scratch to support a different height system, more details and pixel shader support. I don't know if there is anything that I could add to the lgpl version but I'll look at it.

Here is "my" current version:

edit: By the way, It's very funny that this thread already has got more than 20.000 views.

kneeride · Post by **kneeride** » Wed Oct 18, 2006 4:53 pm

20,000 views? holy smokes!!!

i think the ogre community has an interest in terrain editors

Filopher · Post by **Filopher** » Wed Nov 08, 2006 2:41 pm

Ok, I'll use the next weeks and months to design a new tilemanager version. The first and second version were some kind of trial versions to get used to 3d programming and ogre ( I'm still only a mathematician and not a coder

) but did lack a lot of flexibility and features I'll need in the end. Here some thoughts about the next version:

custom map sizes (that's obvious - but the previous versions didn't support it directly)
possibility to visualize "maps with holes" (meaning: if you don't know what's out there it won't be rendered)
support of height maps for every tile instead of the whole map (still both is possible and will be mixed - so you can have a different height setting for each tile but still have mountains or hills on a single tile)
flexible tile based render quality settings - each tile can use a different number of tris (so a flat tile only needs a 3x3 vertices grid and a mountain could use a 7x7 vertices grid)
flexible creation of new tile visualisations (loose-coupled)
A more detailed coastline depending on seperate heightmaps
better feedback (for example the possibility to get the mapheight at a specific 2D point)

I'm open for more suggestions.

steven · Post by **steven** » Wed Nov 08, 2006 3:46 pm

One suggestion:

Support for hexagon maps
Hexagonal grid overview

Some links:
http://cyberboard.brainiac.com/screensh.html
http://www.hyw.com/Books/WargamesHandbook/1-2-test.htm

Bye

Filopher · Post by **Filopher** » Wed Nov 08, 2006 5:37 pm

A hexagonal map is kind of tricky because it would require a complete new approach in the kind of texturing I use. However, since the new tiles will draw themselves and are loosely coupled I think it should work with a little adaption. I'll think about it, thanks.

kneeride · Post by **kneeride** » Thu Nov 09, 2006 5:52 am

i thought a hex tile map would be a complete rewrite?

filopher, how about the ability to place meshes on the surface? for example buildings and trees...

Filopher · Post by **Filopher** » Thu Nov 09, 2006 9:04 am

kneeride wrote:i thought a hex tile map would be a complete rewrite?

Yes, it would have been if someone had wanted this feature in a previous version. When I designed the first versions I did not think about hex maps because I didn't need them and I didn't want to overload my first 3d codings. I rather wanted to stay simple.

In the new version I want to separate the tile map from the tiles themselves. A hex map is still just another 2d visualization of the same x/y array. Of course it works very different internally and needs another way of texturing adjacent tiles (a hex tile obviously has 6 neighbours and a quad tile 4 or 8 - if you count diagonal neighbours too) but speaking in terms of global rendering it's just another 2d grid of objects.

So, to be precise I want to design a renderer that organizes objects that use a uniform (x,y) or even (x,y,z) coordinate system to place themselves in the scene. It will pack these objects in batches (chunks) depending on their position and provide a way of tile picking and other things. How each tile will be rendered is completely up to the tile itself. Basically speaking to change the quad map to a hex map you would just provide another tile rendering class. This could also be a way to simulate a 2d or 3d galaxy environment for space strategy games. The "tiles" don't need to be visually connected or use the same material (although it would be much faster).

kneeride wrote: filopher, how about the ability to place meshes on the surface? for example buildings and trees...

Yes, that's very important. I would want to add static placement of objects to the tile manager. However, I would not want to add things like movement of objects between tiles because this really depends on the way you organize your tiles.

kneeride · Post by **kneeride** » Fri Nov 10, 2006 4:14 am

Filopher wrote:Yes, that's very important. I would want to add static placement of objects to the tile manager. However, I would not want to add things like movement of objects between tiles because this really depends on the way you organize your tiles.

Yes, i'm only talking about static objects. ie building a scene with terrain, houses/buildings, trees/shrubs...

I guess you need to be careful because it may end up being a scene manager. ie once you start with scene management then you might get hooked on lighting etc...and may lose focus on the terrain functionality

Another feature?: Texture spatting

Filopher · Post by **Filopher** » Fri Nov 10, 2006 2:11 pm

kneeride wrote:I guess you need to be careful because it may end up being a scene manager. ie once you start with scene management then you might get hooked on lighting etc...and may lose focus on the terrain functionality

That's really something I want to avoid.

kneeride wrote:Another feature?: Texture spatting

In my design this would be a feature of the tile rendering class. I'm going to code the tile manager and a quad tile rendering class I need (that doesn't use texture splatting). I will most probably implement a basic hex tile rendering class too - just to show how it works.

But everything else would be up to the people who need such stuff and those rendering classes could be shared here.

Filopher · Post by **Filopher** » Thu Nov 16, 2006 12:55 pm

Ok, some work on the details.

I want the tilemanager to be most flexible. I myself don't know what kind of information a person might want to store in their tiles to determine their visualization.

So I thought about sending a user defined std::vector<int> to every tile when it is created by the tile manager. Thus you can send and store as many ints in the tile as you want. The first int could set the height level, the second int could determine the terrain, etc ...

To optimize space allocation I could send a std::vector<char> for booleans too, since a std::vector<bool> may not be a good idea (see here: http://www.informit.com/guides/content. ... um=98&rl=1).

Any objections?

edit: At the moment I forgot why I did use a vector and not an array pointer, anyway.

stodge · Post by **stodge** » Mon Feb 05, 2007 3:09 am

What's the state of this tile manager? I built the demo with the current stable release of OGRE and it works flawlessly.

mako · Post by **mako** » Fri Apr 27, 2007 2:33 pm

Great project.

the official release is in
http://www.code-black.org/Programmversi ... Engine.rar

or in daimonin?

is this Eihort compatible?

mako · Post by **mako** » Mon May 14, 2007 1:19 pm

hello?

polyveg · Post by **polyveg** » Fri May 18, 2007 11:10 am

there is no official release.

you can have a look into the svn for the currently state of the daimonin version.
but better wait some days until i have upgraded client3d to the new server version.

caesar2k · Post by **caesar2k** » Wed Jul 11, 2007 9:58 pm

how many days?

Trosan · Post by **Trosan** » Mon Aug 27, 2007 8:31 pm

First of all: Thank you very much! Your tile-based terrain system is GREAT, I am using it for my project and are very very happy as it exactly fulfills my needs.

To get a better approach to it and since there were lots of features I didn't need (such as path finding, objects on tiles, walls, statics, those texture filters, water tiles etc. - some of which I'll eventually need but which looked too teethed to the tile-manager and which didn't help me while trying to get an understanding of it), I started from scratch, using some modified TBT code where it fitted (please note, I was using the latest daimonin CVS version for this only - those files were released under the LGPL).
This is what I've already implemented and what is new (afaik):

stricter separation of classes (e.g. the texture loader is now completely independent from the rest of the tile-manager)
construction of heightmap from a std::vector<float> (instead of png only)
support for different map sizes
support for different texture sizes
support for different TBTs in the same scene
support for texture directions (north, east, south, west)
creation of texture atlas from a std::vector<Ogre::Image*> including all images

(some features such as paging also remain)

If anyone is in the same situation as I was and could need the code, I would release it after another cleanup. (In the end I'll have to release it anyway as it's LGPL, but since the game I'm doing will probably take more than one more year, I'd not need to do it in the next time)

This is what will be implemented next:

support for selecting tiles
support for changing height, dir, texture

If you need splatting support, that could be done quite easily (by setting the x texture coordinate of every tile to tile x/mapwidth and the y texture coordinate of every tile to tile y/mapheight - then managing the terrain material on your own [you don't need to use the TileTextureManager class]).

But on the other hand, this might be a too minimalistic approach for many, lacking lots of features they need (talking about "my" version). I only needed it as I was not really creating a tile-based game, but needed a one-texture-per-tile terrain - for that purpose it suffices perfectly!