tile-based terrain


07-02-2008 21:54:19

I have found a pre-release version of a tile-based scene manager for ogre though its written c++. The code is at at http://www.forgottenworld.de/TBT/TBT2_pre.zip Some sceenshots are also avaible from a game thats using their scene manager. I looked at the source code, most of it is understandable but some parts are not clear, where tiles are created manually. a Is there anyone else who has a bigger knowledge of c++ and/or interested in a tile-based terrain?


08-02-2008 08:58:22

Sooo. You want to port it?
I think there would be a few people that would use it, but you could also have a look at the current solutions, ETM for example.


08-02-2008 14:15:45

Sure i want to port it, i am afraid that i cant. My knowledge of c++ is about zero. I think i tried every alternative, ETM too. I ve been playing with it for a month or so and it turned out that i needed a map with so high resolution that the frame rates were awful and the loading time was unacceptable.

Anyway i wonder if there are people who are also interested. I will try to port it by myself, though any help would be appreciated.


08-02-2008 14:21:01

actually it looks pretty simple, I've had a go at a few of these types of things before, I might try and do it this weekend.

TBH, this would work a lot better as a wrapped module, as the vertex generation will suffer from a speed loss in python. For that it would probably be better to wait until a final version of this is released.

Still, as I said its certainly not a massive amount of code to convert, and from a quick glance I can't see anything which presents too much of a headache.


08-02-2008 16:04:06

Yeah it should be possible. But I have some reasonable C++ knowledge. It might a bit hard for you.
But I´m sure Andy would wrap a final release of it if you ask him to.


08-02-2008 19:52:14

Well yes, he does seem to wrap everything i've tried to convert so far :)

Had a look at it today and i'm sure i can convert it into python, I've just been going over the mesh generation by copying c++ examples a few times in the last few weeks, and i know what the various datatypes are. Its quite small so I'm definitely going to give it a try in the next few days, it would be a good thing to 'optimize' in python as well if anyone has any ideas.


09-02-2008 02:12:54

Wow thanks :D it would be great if you could give it a try. I looked through it again and the worst parts for me are surely in the tile_Chunk.cpp

BTW the 'predecessor' version of TBT developed by www.code-black.org had rather good fps on my machine, much better than the other scene managers


09-02-2008 03:24:05

Promise not to look at it :)

However, once you have it converted it would be interesting to look at the performance and determine if there is a 'common' set of helper utilities that could be created (in C++ as part of the base Ogre wrapper) to overcome things like vertex processing etc




09-02-2008 10:44:05

lol :)

well, theres one bit so far you could help me with if you like, andy ...

self.mSceneManager.setOption( "Size", reinterpret_cast<void*> (&this->getBounds()) )

I checked and sceneManager.setOption is hand-wrapped to accept a ctypes.addressOf, and getBounds() from the tileManager class returns an axisAlignedBox - how would I marry up the two of those?

A lot of the rest of basic code conversion is done now, just got to iron out any mistakes I've made on the way. I'm going to go through it and see if i can work out where the bottlenecks are from a python point-of-view, if i can think of anything that would be a good helper I'll post


09-02-2008 23:34:33

This was fixed in the 1.1.a snapshot (and so is broken in the 1.1 release, fixed in the 1.2 binary when I get it out)...

You can simply do (using the snapshot release):
self.mSceneManager.setOption( "Size", self.getBounds() )The setOption handles axisAligned boxes, vectors, matrixies, quats, ints and booleans..

To retrieve the options you have to tell Python-Ogre what return type you want:
ret,size = sceneManager.getOption ( 'Size', ogre.AxisAlignedBox() )


11-02-2008 10:00:26

ah, thats great! much simpler than I had feared.

The only other bit thats perhaps giving me a little grief is the texture atlas creation, other than that its nearly there.


11-02-2008 20:48:40

Ok!, its partially done.

I say partially because the mesh generation is a bit shot, but the tile loading works. I think the mesh problem is to do with shared vertex data, and if someone fancies having a look that would be great.

-= download here (47kb) =-



11-02-2008 20:51:52

Nice work! :D


11-02-2008 21:12:46

Whoa that was quick!

Well, as you'll see, no faces show up, although you can see the vertices by pressing 'R' a couple of times and looking around a bit. They are definitely being loaded by the tileManager, but not generated properly.

EDIT: on closer inspection, if you move upwards a bit, there are 'strips' of tiles, which you can see the LOD effect working on, but it seems most of the geometry is missing - nearly there though ;)

The problem is i dont have any usage example, I think i've figured out how to set it up, but I'm unsure how to properly initialize the tileData instances.

actually, doing this was a great introduction to manual resource loaders, they are really powerful it seems.


11-02-2008 22:03:25

Hey i have just tried it out. Good job, it was real fast. Thanks a lot !!!


12-02-2008 20:39:02

Nope, I can't seem to work out why only 1 line of faces per tile appears. I'm thinking of re-writing the mesh generation bit as a manualObject ( a: because I understand them better than vertex buffers and b: sinbad actually says theres no real reason to use meshes over manual objects these days ).

I can see it going a bit wrong because the meshes use shared vertex data, does anyone have any better solutions?


17-02-2008 21:07:02

Slight update -:

I'm sure the problem lies with the tileData objects. Much of the mesh triangulation depends on 'dir' property of the tiledata objecta, but I dont really understand what this is supposed to represent. This is the bit of code thats causing the problem i think:

start = 4 - self.mTileManager.getDirAt( x, y )
end = 4 - self.mTileManager.getDirAt( x, y ) + 2

getDirAt returns the dir value from the list of arbitrarily created tileData objects, but since i dont know what this value means, I dont know what it should be!

again, if anyone thinks they know, please dont be shy and post :)


29-04-2008 21:51:48


Is there any progress on this.'m very interested in a tilebased Terrain Manager, as this is by now only existing for the C++ Version of Ogre3D.

@Developers: Are there plans to get a tilesystem into Python-Ogre?



30-04-2008 00:07:51

No progress at the moment sadly, have been too busy with other stuff. I still cannot work out how this particular implementation works, but a tile-based terrain system is not very complex, I think you could easily write your own from scratch. I would if I had time to do so at the moment. You probably want to by sub-classing ogre.MovableObject and then writing your own implementation, perhaps with a quadtree. Again, I really don't think this is too hard to do.


30-04-2008 15:30:12

Ok!, its partially done.

I say partially because the mesh generation is a bit shot, but the tile loading works. I think the mesh problem is to do with shared vertex data, and if someone fancies having a look that would be great.

-= download here (47kb) =-


Any chance to get the kit uploaded somewhere else? This link isnt working.


30-04-2008 20:09:13

That would be great. It would be a good starting point.


01-05-2008 08:46:21

Sure, here it is:

Be warned its a complete mess! lots of commented C++ where I wasn't sure what i was doing, but it does work up to the point i mentioned above ( tiles are rendered as 'strips' rather than full tiles, although LOD does seem to be working ).

http://pasteall.org/684/python - Demo_Tile_Terrain.py
http://pasteall.org/685/python - tile_Config.py
http://pasteall.org/686/python - tile_interface.py
http://pasteall.org/687/python - tile_Manager.py
http://pasteall.org/688/python - tile_Texture_Manager.py
http://pasteall.org/689/python - tileChunk.py

would love to hear if someone can fix it


02-05-2008 11:30:23

Ok little note having just tested it on another system, firstly though, apologies for the multiple code links, will try to upload a proper zip somewhere soon..

You'll need a recent python-ogre build for this to work properly ( ie: 1.2 ), the sceneManager.setOption thing is broke in 1.1


02-05-2008 11:45:26


Ok, I put my hands up, I have been a complete and total FOOL.

It works now, and it was all because of an indentation error in tileChunk.py.

At the end of the createVertexBuffers function 'return vertices' is indented one place too far, it just needs de-denting one line, and everything works!!!!


03-05-2008 12:59:28

Ok, I got the example working too with PythonOgre1.2 (will not work with 1.1). Great work so far! I am still digging. :)


22-08-2008 20:53:23


After a time to get more into Python itself I'm getting back to Python-ogre. I tried the demo and it says, that it cannot find the Materialscript which is written down in the tile_config.py.

Can you please share it?

Thanks and greetings


26-08-2008 12:14:24

No problem,

just change the line



MATERIAL_NAME = "Ogre/Skin";

or any other material you already have installed


02-09-2008 10:52:47

Somewhat on this tip


Looks like the new version of Python 2.6 will support true multi-threading using actual multiple cores. Perfect for making very neat terrain engines very easily methinks! However we'll have to wait for a build of python-ogre that works with it

I might even try to compile python-ogre with 2.6 myself ( not much chance of success i think... :( )


03-09-2008 20:12:49

No need to move to python2.6 to use the pyprocessing module:


Python2.6 just includes it as standard.


08-09-2008 09:42:58


missed that one!

thanks saluk


08-09-2008 16:03:16

What does that mean for Python Ogre?


08-09-2008 22:23:37

Well, its true multithreading for python ( python's default 'threading' module is not true multi-threading, as it still only uses a single cpu core, it just emulates concurrent processing ).

Its only really relevant to Windows, as linux python has os.fork() which does essentially the same thing, but this module is a bit 'cleaner' for want of a better word.

This allows you to take advantage of that dual / quad core machine you've got sitting on your desktop. You could use the second core for your AI routines, or terrain generation etc. while the main thread handles the rendering. There's a big long discussion on the main forum and wiki about how best to use this extra power, however the main gist is that you shouldn't try to split up ogre's rendering process, as this is really already done for you on the GPU, but instead use it to split up your game mechanics so that you can have multiple processes running at the same time.

Writing threaded applications is NOT easy though, believe me I have done several before and even in Python ( which i think is the easiest language in the world :wink: ) its still quite a challenge.