Any good physics libraries that can handle dynamic scenes?

Started by
8 comments, last by GroZZleR 20 years ago
Are there any good physics libraries that can handle dynamic scenes? I''ve checked out Tokamak, and it looked extremely promising until I realized that it can''t handle dynamic scenes. It can''t seem to add or remove physics objects from the scene or alter the envrionment in which the simulation runs, at anything but initialisation. That seems useless to me, because how do you simulate things like gibs, bullets, tree-branches, whatever else you want to add at run-time? If I have a streaming envrionment, its not going to work with Tokamak because the environment can''t change. So does anyone know of any physics libraries with rag-doll physics and rigid bodies that can handle dynamic scene changes or can provide some guidance as far as Tokamak is concerned? Thanks a lot.
Advertisement
http://opende.sourceforge.net/

Haven''t used it personally, but it looks good. I''ll be writing my own physics engine for my game engine (learning project).
+1 for ODE, and yes you can add and delete objects as you go.
[teamonkey] [blog] [tinyminions]
You probably misunderstood Tokamak (which is quite easy, considering that the documentation is awful). In the initialization, you only need to specify how much memory Tokamak allocates for different things, you can create those things later in the simulation.
I guess the real problem comes with terrain. Certain parts of the terrain (say something with a building on it) will have more vertices than others (say something without a building on it). This terrain is being streamed in seamlessly, so theres nothing I can really do to reuse the terrain thats set up at run-time can I?

The only thing I could think of would be to build an amazing amount of static rigid bodies and define the terrain with a lot of triangles, but that seems like absolute overkill / a lot of swapping work with every patch that gets streamed in.

I imagine I''d face the same difficulties with ODE.

Any ideas?
++ ODE,

It rocks, you can update whatever you want at any point in th simulation, it''s fast/stable, and there is a built in terrain collider which sounds like what you are looking for.
quote:Original post by GroZZleR
I guess the real problem comes with terrain. Certain parts of the terrain (say something with a building on it) will have more vertices than others (say something without a building on it). This terrain is being streamed in seamlessly, so theres nothing I can really do to reuse the terrain thats set up at run-time can I?

The only thing I could think of would be to build an amazing amount of static rigid bodies and define the terrain with a lot of triangles, but that seems like absolute overkill / a lot of swapping work with every patch that gets streamed in.

I imagine I'd face the same difficulties with ODE.

Any ideas?


I'm not sure what you mean. Tokamak has a terrain triangle callback function that asks for triangles from the area it's currently processing. You supply it with pointers to a vertex array, an index array and a triangle index array (this is what you'll generally fill per-query). You might want to check it out to see if it does what you need.

[edited by - Painless on March 24, 2004 8:24:06 PM]
I think you are confusing rendering with physics.

Presumably, you are only streaming in the visible areas of your world. However, the physics simulation exists throughout your entire world, beyond what you can see.

As Painless says, there is an excellent facility in Tokamak that allows you to specify a terrain collision callback. Perhaps you could use this with some lower lod terrain data that is kept resident at all times.
Its not entirely loaded though.

Think like a Flight Sim or Dungeon Siege, or even Shadowbane if you've played it.

I load patches of terrain in on the fly, so I'd need a way to manipulate the terrain information that Tokamak has, but it seems I can only do this at startup. I'll look into the callback functionality, but I'm not sure if it'll provide the solution.

[edited by - GroZZleR on March 25, 2004 10:34:56 AM]
why could u only do it at init?
could u just call neSimulator::SetTerrainMesh with the new data at any time?

This topic is closed to new replies.

Advertisement