Hey, so the main point of this thread is just getting some feedback and thoughts about a tool to help with a student game I'm involved in.

So, briefly, we're working on a dungeon-crawler (ish) using Ogre. The environment will be created using a tile-set modelled inside of 3ds Max.

Now instead of putting all this together inside of Max and hitting export, or the programmers trying to re-create it via code, it was suggested that we could build a little tool via MAXScript to help create the level.

So this tool would alter all the settings inside of Max to make it suitable for tile placement; would have some kind of tile-set manager; would be able to generate a single collision mesh based on the tiles used; and, most importantly, would export the data (tile placement and rotation) in text format - so the programmers can then build a loader that automatically places the geometry in the correct placement and uses instances based on what meshes are being re-used.

So there are a few other things, like using lights in Max and then spitting out usable light data for the programmers.

I know a lot of this stuff is exported with the FBX format, but Ogre doesn't support FBX and... well, I dunno. This was just a suggestion and none of us really have much idea about this type of pipeline tools. So I thought it would be useful to ask some pros for opinions before running in blind thinking it's a fantastic idea.

Cheers!

I´m doing it with XML which is what the dotscene format uses, which can be loaded into ogre directly.
I did my own xml format though.
Lights and stuff can be handled like any other format you just have to define a value in xml which gets read as a light in max.
For the collision mesh it would be probably easier to generate it inside ogre i think there was a library which could do that.

Ah! An Ogre user, this is pretty handy. I will be sure to pass on this information to the of the team as everyone is new to it.

The XML route is really interesting. Essentially it looks like most of what I'm trying to create has been done before, which is useful because I was worried I was making a pointless tool. The other stuff that surrounds it in Max (fancy UI stuff) can be justified for other designers who aren't that friendly with the more technical stuff.

After searching Google a bit I found the DotScene document in their Cookbook. It's a treasure trove of useful stuff. Should have really looked around there a bit before, but most of the language was alien.

Thanks a bunch SpeCter!

If you or your team has questions i´ll gladly help.I have to admit that i´m writing a simple editor myself, because i didn´t want to manage everything in max.For example max handles quaternions different (Y and Z are switched or something if i´m not mistaken).
If you do it inside of Ogre you get your XYZW values you can put into an xml file easily.
I used my own format and not dotscene because it had many things i didn´t need and some things i wanted(custom properties) which it didn´t do.
And since XML is an easy to format to read and write it´s not hard to actually do your own parser for it.
I used QT+Ogre and qtxml for writing the xml files and rapidxml to read them inside of ogre.

Ah cheers for the help man. It's interesting to see what you're using for doing this sort of thing. I'll probably keep bumping this thread with progress/problems that I'm having with this. Might be better than creating a bunch of threads of individual things. Cheers again dude.

No problem and got some time to look for the collision thing i talked about:
http://code.google.com/p/recastnavigation/

It creates what you need(i guess?) and can be used with detour(pathfinding lib)
Might be worth to take a look at ;)

Ok, so... this has changed slightly. We're no longer using Ogre and we're now using Irrlicht...

So! After searching a little bit around Irrlicht it appear that some of that great useful stuff that Ogre uses doesn't exist for Irrlicht.

So thinking back to my original post, a lot of this stuff may now apply for the Irrlicht engine? Kinda back to square one. Don't know why we're not using Ogre...

Meh.... you should get your mates to use Ogre it´s superior in almost every way, except that it only accepts .mesh files.
What i said for Ogre should be no problem with Irrlicht, because you would only need to change the actuall loading part of it,but i´m very interessted why you guys changed from Ogre to Irrlicht.

Yeah after looking at some of the feature lists and some of the pipeline stuff, I'm also questioning why our programmers have decided to use Irrlicht. Especially when some of the stuff they're making right now, like path finding, is an open library within Ogre...

It´s not exactly part of ogre, but you can use almost everything in conjunction with ogre and it´s easy to understand.My quick guess would be that ogre is just a rendering engine and Irrlicht has some of the other things like networking,sound and stuff build in(as far as i remember).