The exporter problems are mostly behind me. In the end, Derek Nedelman turned out to be quite responsive to problem files/scenes mailed his way, and made OgreMax work pretty well. I still have two outstanding complaints, but I can work around them:
- Materials ought to have a common default copy base. Allow me to specify that all material definitions add ": SomeBaseName" in the exported script, and I'm happy. Now, I have to remember to re-edit materials each time they're exported.
- Mesh data ought to be rotated so that the identity mesh orientation requires an identity node orientation. As it is, I have some animated/skinned meshes that come out lying down when I bring them into Ogre. In the OgreMax XML scene file, those entities have a non-identity orientation for the node that contains them. This is a major pain when trying to create mix-and-match meshes; that additional orientation needs to be carried along as metadata somehow.
All that art path stuff has taken a lot of time that I'd rather spend writing game code, but oh, well. Networking still works fine, and I added undo/redo of creating entities to my editor to make up for it. I still need a "delete entity" command, though, and better camera controls.
I'm still working on the overall goal of "player entity can walk around world after logging in," which currently means using real world collisions. I've been using the built-in OGRE ray-casts until now to constrain the camera and object placement, but that doesn't work if you want to be able to walk into houses but not through windows, etc. It also doesn't work if I don't want to run graphics on a hypothetical stand-alone server, as OGRE is needed to load the geometry for mesh colliders and heightmaps.
Thus, I imported ODE as a dependent library, and wrote a quick wrapper around its collision parts, to add as a component to entities that need collision. It also has a separate "collision world" abstraction that contains all the collision entities -- I tie them into the game code through the aforementioned component. In the level script, for a template or object, you add a "collision" component to the object, and magically the object will collide.
Because I don't want to load OGRE at runtime on servers, this allows me to save out the entire collision world as a separate piece of data. In the editor, where there are graphics, the mesh data is extracted, and compacted into collidable form (for use by ODE). When saving a level file (say, level.lua), it also writes out the corresponding collision file (level.lua.coll) in a simple format. When loading a level, the collision world is loaded from this file as well. Only when the editor is present will this file be updated for writing, else all entities simply find their collision entities in the inflated collision world. The main draw-back is that there's two files to keep in sync, but the editor does it for you most of the time.
Alright, so I'm currently testing the code that takes an Ogre::StaticGeometry and generates a large collision mesh out of it. Once that's done, I might take a detour and allow loading of OgreMax .scene files as large entities in the scene editor (not hard, and would improve the art path). Then it's on to players that can actually move through the level! I probably won't use the ODE solver for physical movement, because I want to use a simpler model of movement on the server. Mainly because all previous projects I've done have had real physics, and I want to know what it's like not to have it :-)
