Integration of physics and graphics with collada

[KenB]

Hi,
Collada is a nice format since it can describe an entire scene with physics and graphics.

Collada is also an evil format since it can describe an entire scene with physics and graphics....

The problem is of course that it is hard to support Collada in a physics library that is graphics agnostic. And it is also hard to use a collada reader in a graphics engine for setting up the physics scene. For example, the OSG Collada plug-in isn't so well adapted for handing over the physics database to a physics engine, so one might need a separate Collada reader for the physics, but then this also must hand over the graphics to OSG. At the end of the day we have too many Collada readers.

I'm interested in opinions on how to actually do this integration in software.

[Erwin Coumans]

Hi,
Collada is a nice format since it can describe an entire scene with physics and graphics.

Collada is also an evil format since it can describe an entire scene with physics and graphics....

Can you explain? You can use COLLADA DOM or FCollada to read your data and pass the data into an application. Several tools exist that use those tools, and they feature both COLLADA graphics and physics support. Also tools exist that only deal with physics.

The application can build a mapping between graphics nodes and rigidbodies, and synchronize them at run-time.

The problem is of course that it is hard to support Collada in a physics library that is graphics agnostic.

Why?
For example, Bullet supports COLLADA, and it is graphics agnostics (it ignores it).

And it is also hard to use a collada reader in a graphics engine for setting up the physics scene.

Why?

For example, the OSG Collada plug-in isn't so well adapted for handing over the physics database to a physics engine, so one might need a separate Collada reader for the physics, but then this also must hand over the graphics to OSG.
I'm interested in opinions on how to actually do this integration in software.

I'm not familiar with OSG, but this sounds like a limitation or integration issue of OSG.

Please check existing integrations in Bullet, and COLLADA RT. COLLADA RT is an open source viewer for COLLADA files, and it supports both graphics and physics.

There exist more integrations with physics and/or graphics, and a few new applications are under development.

Thanks,
Erwin

[aboeing]

Collada is also an evil format since it can describe an entire scene with physics and graphics....

Agreed.

so one might need a separate Collada reader for the physics, but then this also must hand over the graphics to OSG.

Why 'must' this hand over the graphics? I don't see an issue with a seperate physics collada loader and a seperate graphics collada loader. 'glueing' the parts together shouldn't be a major drama.. leave it up to the app. developer?

At the end of the day we have too many Collada readers.
I'm interested in opinions on how to actually do this integration in software.

I don't think 2 is too many, and choice is arguably a good thing.

I'd recommend John Ratcliff's loader:
http://codesuppository.blogspot.com/200 ... physx.html

Its light weight (uses only tinyxml), physics only, loads collada outputs physx xml. Just modify it to output to your engine-specific-format, and your done!

[KenB]

There are obviously three ways of doing things,

1. Load collada graphics using loader 1.
Load collada physics using loader 2.
Bridge between the datasets.

2. Load collada graphics and using loader 1 and have send the physics
to the physics engine.

3. Load collada physics using loader 2, and have it send the graphics
to the graphics engine.

For efficiency we would like to avoid having two separate parsing passes of the same Collada file.
For maintenance reasons we would like to avoid having two separate collada loaders in the same simulation engine distribution.
Personally, I'd prefer to have the physics and the graphics in separate files - but still using the same collada specification.

The fact that Bullet is graphics agnostic doesn't mean it is graphics efficient - since one indeed will need a collada graphics loader that can deal with all the bells and whistles that actually can be done with collada. As you say, it just ignores the graphics. Assume we use a graphics engine that supports shaders, animation, and all other things in Collada - then I wouldn't want to reimplement that in a reader tied to the physics engine.

Anyway, we will take a decision about this and get it done, so I'll post an update once we have learnt how to do it (or not to do it..).