Exporting from Max through Collada to Bullet

[magicchicken]

Before I get started I should apologize for the large amount of questions I'm asking, and thank you for taking the time to just read over it. Any help in any area is greatly appreciated. I'm new to using Bullet as well as Collada. In the past I've rolled my own physics engine from Ian Millington's Physics Architecture book, as well as a year of using PhysX for the student game project "Froggle". This year we chose Bullet for commercial licensing reasons.

For the project I'm working on now, I'd like to export environmental collision data from 3DS Max. I'm wondering what the process is like for games/projects using a similar resource setup. We already have an exporter (ColladaMax) to get visual data out to Collada, and we're looking at using NVidia/Ageia's exporter for physics data. The questions before getting started are:

• Do we use two different exporters, or would the PhysX exporter also export visual data?
• How hard is it to manage the association between visual data and physics data?
• I'm sure I don't always want the physical and graphical representations to match up, so how does this process work in Max itself? If we have artists creating the environments, would they need to also model a similar physical mesh? Does the PhysX exporter know if when you're giving an object a sphere collision shape versus a convex mesh that just happens to be a sphere?

From what I understand, collada is meant to be an intermediate format, so that's exactly how we've been approaching it for our game so far:

• The first part of the process is building the environments in Max and then exporting them entirely to collada.
• Then, in the editor that runs in our game engine we're processing the .dae file to create and save mesh data in custom binary format.
• The binary data gets loaded by the game at run-time. This way we don't ship any Collada files with our final build.

I want to follow a similar direction for physics data - meaning I only want to processing Collada files in our editor and use some faster/custom format at game's run-time. I less concerned with material configuration (mass, friction, etc) as I am with just building associated collision data. With PhysX this was pretty easy to do with collision data, since there was the Cooking system that would process and export data to a NxStream, which I could then load it again later with the same interface. I'm not finding a similar setup in Bullet, but I could be missing it since the documentation isn't as easy for me to parse through.

Also, I'm having some other difficulties understanding a few elements of the Bullet sample for Collada:

• setCameraInfo() has nothing to do with physics or collada? It seems like it's notifying the system of the coordinate system used in the exported data, just tailored to fit the demo application's structure.
• We already have FCollada in our project, so if I wanted to use that then does that keep me from using the ColladaConverter library that comes with v2.73? Is Collada DOM and the Bullet ColladaConverter heavily integrated?
• The ColladaConverter also knows about the dynamicsWorld, so I'm led to believe that it's parsing the .DAE to add bodies and collision shapes to the world directly. Since this is what I'm trying to avoid, I think hard-rolling my own Collada converting system is inevitable.

I know Collada and physics isn't super-well supported still, and I'm trying to save some work by not having to add features to our own editor. Am I trying to swim against the current, or does this direction make sense? Are there other ways to serialize Bullet rigid body configuration and collision data?

[magicchicken]

I see this thread from over a year ago: http://www.bulletphysics.com/Bullet/php ... =12&t=1364

aboeing's suggestion to use John Ratcliff's loader to only load and modify the physics data to re-export my own engine's format seems logical. I can handle two Collada processing chains in my engine since they'll be sharing some TinyXML, FCollada code. But I'm still confused as how to manage both the graphical and physical data in Max and then again once processed.

In Max, building physical representations of environments that are less complex (less vertices) than the graphical representations, and editing/exporting/importing both. What if I export a single slightly complex graphical mesh (a room with highly detailed, non flat walls), and want to export several really simple physical objects to represent it's collision (lots of btBoxShapes for example).

Do I really need two different exporters (ColladaMax and PhysX)?

Would it hurt to export those into separate .DAE files if I manage their association some other way?

And what's a good suggestion for building my own engine's physics format? PhysX has a serialization system in place already with NxStream. If I have to do this by scratch in Bullet then maybe using the Collada files at run time is easier and I skip the conversion step in my editor.

[magicchicken]

Haha, lots more searching of the internet helps clarify things a bit. I found a post from erwin at the bottom of this thread: https://collada.org/public_forum/viewtopic.php?p=4218

Is there actually a bullet binary serialization component still being worked on?