ダニエルの冒険

I got tired of Irrlicht pretty quickly, with my frustration mainly coming from the poor pipeline support. Today I moved over to Ogre3D and things started moving really quickly!

Here’s what my pipeline looks like now:

• Everything is modelled in 3ds Max 2008.
• Havok Content Tools 3ds Max plugin is used to create rigid bodies, constraints and all that other physics goodness.
• Use OgreMax to generate a .scene (XML file describing the scene nodes), and corresponding .mesh and .material files (actual entities and associated materials).
• Use Havok Content Tools exporter to generate a .hkx file, containing the physics data for the whole scene.

What I’ve tested exporting:

• Meshes (boxes and a CSG-hollowed 6-sided cyclinder)
• Materials (only created by setting diffuse colour in 3ds Max, no textures)
• Lights (directional, white)
• Rigid bodies (static box, static mesh with MOPP, dynamic boxes)
• Constraints (limited hinge with high torque)

And here’s what happens at runtime:

• Load up the .scene with the DotSceneInterface Ogre addon when the application starts.
• Load up the .hkx with the Havok SDK once the Ogre scene is done.
• Iterate through all Havok rigid bodies, find associated Ogre entities, and set up a vector of associations.

Before every frame, I run through the vector and update the positions and orientations of all Ogre entities according to their associated Havok rigid bodies. I’m probably going to use Havok’s userdata on rigid bodies to keep pointers to the Ogre objects, or maybe use a hashmap if I think the userdata might be useful in some other context later (I don’t think I have redundancy with the userdata… I’ll need to see whether or not OgreMax really exports it). Once I have immediate random access to rigid bodies’ corresponding graphical entities, I can only update active (moving or possibly moving) entities which will save a lot of work when things start getting bigger.

Development is really made easy by Havok’s excellent pipeline and testing integration. The 3ds Max exporter allows you preview your seen in a 3D window, with all the physics you designed working properly. If you use a lot of custom actions it won’t be perfect, but not having to load your own graphics engine to see how it works really speeds things up and lets you catch problems in the design much earlier.

As far as testing goes, the Visual Debugger hooks in to your application through a TCP/IP port when it runs and shows you the physics in its own graphics engine. A mouse-picking ‘viewer’ means that you can interact directly with objects in your game (and of course, your game’s graphics will reflect the interaction).

Here‘s a clip of a test involving all exported elements listed above: