tile-based terrain

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?

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.

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.

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.

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.

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.

Wow thanks 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

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

Regards

Andy

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

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() )
Regards
Andy

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.

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) =-

TileTerrain.zip

Nice work!

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.

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

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?

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

Hi

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?

greets
silentpolygon

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.

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) =-

TileTerrain.zip
Hello
Any chance to get the kit uploaded somewhere else? This link isnt working.
Cheers

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

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

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

AAAAAAARGH!!!!!

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!!!!

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

Hi,

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
silentpolygon

No problem,

just change the line


MATERIAL_NAME = "LandTest";

to

MATERIAL_NAME = "Ogre/Skin";

or any other material you already have installed

Somewhat on this tip

http://docs.python.org/dev/library/multiprocessing.html#multiprocessing-programming


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... )

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

http://pyprocessing.berlios.de/

Python2.6 just includes it as standard.

Wow,

missed that one!

thanks saluk

What does that mean for Python Ogre?

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 ) its still quite a challenge.