[ODE] ODE-GIMPACT performance and advices
Pierre Terdiman
pierre.terdiman at novodex.com
Mon Oct 30 04:02:35 MST 2006
> It's probably best to leave the gameplay
> discussion for another forum, and focus on the tech.
Yes, please.
> Static structures are
> still useful, but more and more parts of game physics environments will
> become dynamic: Destruction is one of the next steps, next to
Naturalmotion
> style balancing ragdolls (powered ragdolls constraints).
I would love to see more practical destruction algorithms. What did people
use so far?
We had some FEM-based fracture in an old Novodex version, so I'm not unaware
of the (practical) issues it gives bith to. The actual fracture is really
just the tip of the iceberg, and not the most problematic part if you ask
me.
I'm really interested in this, I would love to use this in my own small
game. However here are the actual problems I need to solve:
1) Compute the fracture in some way, i.e. how the old mesh gets modified,
and how many new meshes are created. It is not enough to compute -where- the
fracture happens, you must also "close" your now open meshes, and possibly
fill them with some new procedural geometry. For example if you use CSG
here, new faces appear revealing the inside of the wall.
2) Update physics information:
- compute inertia tensors for new dynamic pieces.
- compute new AABB-tree (or equivalent) for new dynamic pieces. Update
AABB-tree for fractured part.
- update broadphase structure
- what collision model do I use for fractured pieces? They have an arbitrary
size and an arbitrary shape. Mesh-mesh would be ideal, but it is usually
slow and unreliable. If using convexes, you need to dynamically compute new
convex hulls for all those new meshes. Also, if your collisions only work
with a margin, you need to make sure 1) doesn't create pieces violating
this.
- update collision model for fractured mesh. If you fracture a convex or a
box, it may become a concave mesh.
3) Update rendering information:
- create new graphical meshes for broken pieces (vertex/index buffers)
- fill the vertex buffer: compute UVs & tangent-space vectors for new
geometry
- assign some generic texture for new geometry (say inside of wall).
- if the renderer has its own culling database, insert new meshes there, and
update or remove the old one. Update portal / occlusion data if necessary.
PVS seems out of question.
- precomputed shadow solutions seems all out as well.
4) Update sound database. It was not possible to hear that sound on the
other side of the wall. Now that there's a hold in it, you can actually hear
something. I asked on GDA a while back how to do that (computing the proper
volume of a sound), they all replied to re-use the PVS data for this. Since
PVS are out for us, I don't have a solution here.
5) Update path-finding database. Update navigation meshes (argh!). I am
using PathEngine at the moment, which uses precomputed structures to do its
job (quite well). I don't have a solution here.
6) Update all other AI-relevant information that might be precomputed. For
example that wall is not a good hidding place anymore. However the newly
created debris might be.
7) Did I forget something?
....and that's not even taking into account the gameplay issues.
- Pierre
More information about the ODE
mailing list