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