Page 1 of 1

representing map

Posted: Fri May 25, 2012 5:20 am
by mike1
Hi everyone,

I'm trying to create a game using Irrlicht as my graphics engine and Bullet as my physics engine.
Assuming I have a map represented in a 3d file format (such as .obj, .3ds), it's fairly easy to load it and draw it using Irrlicht. However, I can't find a way to do it in Bullet.

I found that there's a .bullet file format that could be loaded - is it the only supported format? is there any conversion tool between public formats and .bullet format? I guess it will be easy to create such a tool, but I'm not sure about how optimized the result would be.

This leads me to my next question - is it considered good practice to represent the 'world' (or map) using a single btRigidBody (which is static)?

Thanks!

Re: representing map

Posted: Fri May 25, 2012 7:39 am
by MaxDZ8
mike1 wrote:
  1. I found that there's a .bullet file format that could be loaded - is it the only supported format?
  2. is there any conversion tool between public formats and .bullet format?
  3. I guess it will be easy to create such a tool, but I'm not sure about how optimized the result would be.
  4. is it considered good practice to represent the 'world' (or map) using a single btRigidBody?
  1. It is the only format supported by Bullet. I strongly suggest to just encapsulate it in your own engine format as an opaque blob, the complexity is fairly high.
  2. I don't know any.
  3. You're wrong. Producing an efficient physics representation would have to consider polygonal reduction, proximity and reachability (product and even context specific), not to mention it needs to implicitize the mesh, a non-trivial operation by itself. Of course we can always cut corners and pour everything in a trimesh which takes us to the next answer...
  4. No. It's typically an assembly of rigid bodies. See it for yourself for Unreal Tournament (which is using PhysX but the concept is the same, scroll to the pictures at the end).
Having blender as my DCC tool of choice (because I have no choice) I'd say the physics workflow is rather rough. I experimented quite a bit with building the collision geometry automatically with minor success, but in general, I see no other reliable way to let the artist build it manually.

Re: representing map

Posted: Fri May 25, 2012 6:41 pm
by mike1
thanks for the reply!

that's what i assumed. thanks for confirming.

my world is basically an arena with walls around it and some walls inside it - much like a maze. it could quite easily be divided to several 'wall' objects i guess. the problem is syncing this with the graphics engine, but i guess there's not a lot of choice here

thanks!

Re: representing map

Posted: Sat May 26, 2012 7:59 pm
by Erwin Coumans
Several modelers can directly export .bullet files, such as Blender, Maya, Cinema 4D etc.

In the Bullet sdk there are various ways of importing files, such as
.bullet, see Bullet/Demos/SerializeDemo
.obj, see Bullet/Demos/ConvexDecompositionDemo
.bsp (Quake/Doom), see Bullet/Demos/BspDemo

Once you have the mesh data in memory, it should be easy to create a Bullet collision shape from it.

There are also various examples how to integrate Irrlicht with Bullet. Check-out the branch of IrrKit:
http://code.google.com/p/gamekit/source ... s%2FIrrKit
(note that the trunk uses Ogre, but that branch uses Irrlicht)

In other words, no need to re-invent any wheel there.

Re: representing map

Posted: Tue May 29, 2012 2:01 pm
by MaxDZ8
Erwin Coumans wrote:Several modelers can directly export .bullet files, such as Blender, Maya, Cinema 4D etc.
...
In other words, no need to re-invent any wheel there.
I'm sorry but it is my understanding that while Blender can produce a .bullet serialization, conversion is manual. The Game engine must be explicitly instructed in selecting bounds for each primitive.

When it comes to conversion, importing using the obj filter is a step in the correct direction, but as far as I understand the code it would require quite some care in fitting a workflow. I'm pretty sure this utility is not intended for serious use but for demonstration purposes only.