Hey,
in our project we’re using ODE for physics and collisions. Now I was wondering if there are any known ways to setup, export and import ODE collision solids.
[size=150]1. idea:[/size]
Egg files are capable of collision solids for Panda’s collision system, so I thought it might be possible to extend the egg interpreter to load the objects as ODE solids instead of Panda collision solids.
Pros:
No new exporters or file formats needed.
Solids can be attached to joints in the modelling package. Cons:
ODE supports more solids than Panda and therefor the egg interpreter would need to be extended not only for creating ODE bodies but also to interpret new scalars for boxes, tubes and (maybe) more.
Probably hard to code. Especially as we can only extend Panda with Python (Rewriting Panda’s C/C++ core would make our game dependent on a custom Panda build and that’s not an option).
[size=150]2. idea:[/size]
Write a standalone editor in panda where you can fill your models with solids.
Pros:
Independent of modelling package as it needs only egg files
Support for all collision solids
Could also be used with Panda’s collision detection system
Allows a high grade of customization cons:
Huge amount of work to code such thing
There are no standard file types or syntax specifications for collision solids
Exported files would require an interpreter, if we use anything else than python code directly
[size=150]3. idea:[/size]
Using Blender for setting up the collision geometry in conjunction with tags or special object/v.-group names and exporting with a selfwritten exporter. Something like chicken, but specialized on collision geometry. How this would look like: example Pros:
Less to code than in idea 2.
Support for all available collision solids (with restrictions. see below) Cons:
There are no standard file types or syntax specifications for collision solids
Exported files would require an interpreter, if we use anything else than python code directly
Many rules for the modeller to follow. E.g. naming conventions or modelling in object mode only (in edit mode transforms are not saved). Some solids like the capsule would require additional rules.
As an alternative to reading only names and transforms we could go the panda approach and try to create solids after analyzing the vertices -i think this is how panda creates its collision solids from tagged geometry in eggs- but i’m not sure how well that works nor where to search for that code.
Ideas, suggestions, experience reports and tips very appreciated!
I have run into this annoying problem myself. I am a bit of a newcomer to panda3d but I was working up to using ODE with a small game. After doing some of my own research I came up with a bit of a ‘hack’ solution similar to your idea #3.
[size=167]My idea/hack:[/size]
Use dummy objects and tags/metadata in blender to place and describe collision geometry. After exporting to egg files, a python script will interpret the data and build the ODE geoms. Pros:
Highly Flexible
Other than the importer, no customized panda coded needed. Cons:
You cannot actually see the collision geometry (this is why this is a hack solution )
I may not understand the problem thoroughly but I wasn’t thinking that naming conventions or much in the way of constraints would be necessary (I figure that the modeler will have their own set of conventions to follow). So I was taking a very barebones type of approach.
I don’t know much in the way of Blender scripting but this is what I was going to begin reading into next. If you make any progress, I would love to know. Maybe I could be of some use as well.
Hi, I am spending thoughts on a related topic (Bullet integration). So here are a few additional cons to your idea:
Cons:
Not everybody loading an .egg wants to use ODE. Some want to use Panda3D’s internal collision system, some want PhysX, and other might want Bullet. So there has to be some way to determine WHAT collision object to create from an .egg tag.
All importers have to be modified, not only .egg, but also .dae and so on. And all importers should support all physics engines. Lot’s of work and hard to maintain.
Because of the expected effort to keep this functional I suggest another approach: Make ODE use Panda3D’s CollisionSolids. Not the Panda3D collision algorithms, just use the collision solids as structs to store the information about the collision geoemtry, and add methods to OdeBody to create/update OdeGeoms from all CollisionSolids found beneath a particular Node which is representing the OdeBody.
That’s a wonderful idea Ennox. It would be great to use the existing mechanisms for importing collision geometry. Still, I don’t see anyway to access the geometry through the python interface (and as I am new this doesn’t mean there isn’t one). If there is no way to access the collisionSolids directly, as nemesis said, modifying panda isn’t really an option. Still, if possible I would love this solution. Looking at this again, I see that this was the idea #1 Nemesis had.
Actually looking at the interfaces, there may be enough information to create ode geoms by just pulling information such as radius and position from existing collisionSolids. Not the most efficient method but feasible. I’ll probably try this. Ty Ennox
One thing about my ideas is that I am not looking for a generalized solution. I only want something that will work for Ode. Also the panda collision system already has code to import collision geometry. So why would I want to write more code for that?
Edit: Bullet has an impressive list of projects that have used it for sure. I’ll take a look at it.
