CcdPhysicsDemo question
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
CcdPhysicsDemo question
Hi. I've downloaded the 2.62 library and I'm going through the demos to try and understand where to start. I would like to use the library where possible to compute collisions between a collection of tetrahedrons but I would like the ability to come in at each timestep (before the collision check) and add in my own forces (self gravity, and a few others) and check on a few things. Is the CcdPhysicsDemo code still the recommended starting point or can anyone recommend another I should look at? I guess I'm just having a hard time finding out where I can insert my own computations in there without causing a problem
Thanks for any help
Thanks for any help
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: CcdPhysicsDemo question
Can you use the more recent Bullet 2.64 version?bittwiddler wrote:Hi. I've downloaded the 2.62 library and I'm going through the demos to try and understand where to start.
If you want to customize the physics simulation loop, you probably need to derive your own class from btDiscreteDynamicsWorld, and override the 'internalSingleStepSimulation'. See Bullet/src/BulletDynamics/Dynamics/btDiscreteDynamicsWorld (cpp/h).I would like to use the library where possible to compute collisions between a collection of tetrahedrons but I would like the ability to come in at each timestep (before the collision check) and add in my own forces (self gravity, and a few others) and check on a few things. Is the CcdPhysicsDemo code still the recommended starting point or can anyone recommend another I should look at? I guess I'm just having a hard time finding out where I can insert my own computations in there without causing a problem
Hope this helps,
Erwin
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
Just downloaded the latest one.
I'll check out btDiscreteDynamicsWorld in just a few minutes. Does it sound like what I would like to do will work in the bullet framework? I don't want to delve too much in the library if it's going to be a dead end. In that case I'll just use the collision detections in my own program
I'll check out btDiscreteDynamicsWorld in just a few minutes. Does it sound like what I would like to do will work in the bullet framework? I don't want to delve too much in the library if it's going to be a dead end. In that case I'll just use the collision detections in my own program
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: CcdPhysicsDemo question
Can you discuss a bit what do you exactly want to achieve?
It would probably be best to use BulletDynamics, it will greatly simplify the use of the collision detection.
It should be straightforward to insert your code into the following code (just derive the class btDiscreteDynamicsWorld),
without getting into deep internals.
Hope this helps,
Erwin
It would probably be best to use BulletDynamics, it will greatly simplify the use of the collision detection.
It should be straightforward to insert your code into the following code (just derive the class btDiscreteDynamicsWorld),
without getting into deep internals.
Code: Select all
void btDiscreteDynamicsWorld::internalSingleStepSimulation(btScalar timeStep)
{
startProfiling(timeStep);
///update aabbs information
updateAabbs();
///apply gravity, predict motion
predictUnconstraintMotion(timeStep);
btDispatcherInfo& dispatchInfo = getDispatchInfo();
dispatchInfo.m_timeStep = timeStep;
dispatchInfo.m_stepCount = 0;
dispatchInfo.m_debugDraw = getDebugDrawer();
///perform collision detection
performDiscreteCollisionDetection();
calculateSimulationIslands();
getSolverInfo().m_timeStep = timeStep;
///solve contact and other joint constraints
solveConstraints(getSolverInfo());
///CallbackTriggers();
///integrate transforms
integrateTransforms(timeStep);
///update vehicle simulation
updateVehicles(timeStep);
updateActivationState( timeStep );
}
Erwin
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
Sure. Some of this may exist already but I'm not sure what all is in the library. I'm working on collisions of aggregate tetrahedrons where I have to account for self gravity, friction, and electrostatic forces to hold the larger bodies together. Essentially think of something like asteroid collisions with each asteroid composed of a series of various-sized tetrahedrons. Working with the library appeals to me since your collision detection code is far better than mine and the ties into the visualization tools are very usefulErwin Coumans wrote:Can you discuss a bit what do you exactly want to achieve?
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: CcdPhysicsDemo question
Ah, interesting.
Bullet allows to only use the collision detection, there is no dependency on the BulletDynamics, and its design is modular. However, it might be easier to start with this internalStepSimulation, and later decide to only use the collision detection.
Note that some values/parameters inside the Bullet SDK are tuned to work best with object sizes ranging 0.2 (20 centimeter) to 100 meter, if your units and gravity are meters. Especially extreme object size and/or mass rations can give problems/inaccuracies. So colliding an object of 0.20 meter against a 1 000 000 meter asteroid will likely cause issues. So if you don't get good results, you might want use other units (kilometer etc), so that the range sticks within 0.2 units and 100 (this is a rough estimate).
Thanks,
Erwin
Bullet allows to only use the collision detection, there is no dependency on the BulletDynamics, and its design is modular. However, it might be easier to start with this internalStepSimulation, and later decide to only use the collision detection.
Note that some values/parameters inside the Bullet SDK are tuned to work best with object sizes ranging 0.2 (20 centimeter) to 100 meter, if your units and gravity are meters. Especially extreme object size and/or mass rations can give problems/inaccuracies. So colliding an object of 0.20 meter against a 1 000 000 meter asteroid will likely cause issues. So if you don't get good results, you might want use other units (kilometer etc), so that the range sticks within 0.2 units and 100 (this is a rough estimate).
Thanks,
Erwin
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
Thanks - I'll keep an eye on that. At the moment it's not a big deal as I can keep them within the same order of magnitude in size.
If you have a second I've got a couple other questions regarding the physics that I was going to check on:
Is angular momentum conserved in the collisions? I was going to keep an eye on both momentums anyway but it's useful to know any limitations up front
Are all collisions 100% elastic and is it possible to vary this on an object by object basis?
Off the top of your head do you know of any limitations on the speeds of the collisions and their detections? While I have a lot of variations I may need to have some things moving at around 5000 m/s
Thanks for all the help
If you have a second I've got a couple other questions regarding the physics that I was going to check on:
Is angular momentum conserved in the collisions? I was going to keep an eye on both momentums anyway but it's useful to know any limitations up front
Are all collisions 100% elastic and is it possible to vary this on an object by object basis?
Off the top of your head do you know of any limitations on the speeds of the collisions and their detections? While I have a lot of variations I may need to have some things moving at around 5000 m/s
Thanks for all the help
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: CcdPhysicsDemo question
Most angular momentum is conserved, but there are several approximations, damping and even added momentum due to penetration depth correction. In short, it is an approximation that might be reasonable for games, but not for other applications. All of this can be improved however.bittwiddler wrote:Thanks - I'll keep an eye on that. At the moment it's not a big deal as I can keep them within the same order of magnitude in size.
If you have a second I've got a couple other questions regarding the physics that I was going to check on:
Is angular momentum conserved in the collisions? I was going to keep an eye on both momentums anyway but it's useful to know any limitations up front
The restitution can be tweaked per object (rigidbody->setRestitution()), and you can also override the 'combiner' function that calculates the resulting restitution and friction values. See CustomMaterialCombinerCallback usage in Demos/ConcaveDemo/ConcavePhysicsDemo.cpp for an example.Are all collisions 100% elastic and is it possible to vary this on an object by object basis?
You can also implement your own contact and friction solving function, but this is much more advanced/internal. See 'USER_DEFINED_FRICTION_MODEL' inside CcdPhysicsDemo.
By default, Bullet uses discrete collision detection, the physics mainloop using continuous collision detection is work in progress (btContinuousDynamicsWorld, derived from btDiscreteDynamicsWorld).Off the top of your head do you know of any limitations on the speeds of the collisions and their detections? While I have a lot of variations I may need to have some things moving at around 5000 m/s
However, you can do a continuous collision detection query yourself, passing in the start and end transform for both objects. It will give the time of impact fraction, between 0 (starts in collision) and >= 1 (no collision during the interval) Some support of this is provided in btCollisionWorld (and hence also in the derived class btDiscreteDynamicsWorld). You can do pair-wise time of impact manually, see the demos ContinuousConvexCollision (assuming constant linear and angular motion from 'start' to 'end' transforms), or pure linear motion (GjkConvexCastDemo).
Hope this helps,
Erwin
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
Yep, all that helps and gives me a bunch of things to experiment with. I'll work on it some this afternoon and see if I have any problems. At least in the first phases of my program the limitations shouldn't be a problem. Once I get more familiar with everything maybe I'll be able to offer some alternative slower but more accurate momentum and collision methods.
Thanks for all the help
Thanks for all the help
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
I used this as an example to start from and I'm progressing along. I do have a few questions about different things, though
Compound shapes are containers of other shapes used to combine them together into one large object. My understanding from what I have read is that the center of mass of the compound shape is the exact physical center and is not a function of the component density. Is that still correct? Is there a behavior where there are transitory compound shapes that exist so I can join the objects together and move them about but then they break apart when the constraints (self gravity, shear force) that join them are overcome?
What defines the colors of the shapes right now? I looked in the demos and the collision shapes but didn't see what was setting them. Eventually I may tie in with something like Ogre so this may be a moot issue
Is btTetraHedronShape a wire frame only? It would work great for one of my objects if it were solid but it seems to be drawn as just the wires
Finally, I've got a question about something I noticed in CcdPhysicsDemo when I was fiddling with it. In initPhysics I went in and changed line 338 so the shapes were btSphereShape(CUBE_HALF_EXTENTS) and not btCylinderShape. Leaving everything else as it was then they all collapse in a straight line on the Y (?) axis. If I then go in and change the define in initPhysics so I use a ground plane and not a big box to sit everything on then the balls collapse and spread out all over the ground as you would physically expect. Why does the box behave differently from the plane?
Compound shapes are containers of other shapes used to combine them together into one large object. My understanding from what I have read is that the center of mass of the compound shape is the exact physical center and is not a function of the component density. Is that still correct? Is there a behavior where there are transitory compound shapes that exist so I can join the objects together and move them about but then they break apart when the constraints (self gravity, shear force) that join them are overcome?
What defines the colors of the shapes right now? I looked in the demos and the collision shapes but didn't see what was setting them. Eventually I may tie in with something like Ogre so this may be a moot issue
Is btTetraHedronShape a wire frame only? It would work great for one of my objects if it were solid but it seems to be drawn as just the wires
Finally, I've got a question about something I noticed in CcdPhysicsDemo when I was fiddling with it. In initPhysics I went in and changed line 338 so the shapes were btSphereShape(CUBE_HALF_EXTENTS) and not btCylinderShape. Leaving everything else as it was then they all collapse in a straight line on the Y (?) axis. If I then go in and change the define in initPhysics so I use a ground plane and not a big box to sit everything on then the balls collapse and spread out all over the ground as you would physically expect. Why does the box behave differently from the plane?
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: CcdPhysicsDemo question
The rigid body local transform equals the center of mass. This means you have to build the collision shapes to match the center of mass. For most basic shapes there is no additional work needed. Right now, calculating a more accurate inertia tensor, or shifting the collision shapes to match the center of mass is up to the user. So it is possible, but requires manual work. This might be automatic in the future.bittwiddler wrote: My understanding from what I have read is that the center of mass of the compound shape is the exact physical center and is not a function of the component density.
The rendering of collision shapes happens in Bullet/Demos/OpenGL. Color reflects activation state (sleeping, active etc).What defines the colors of the shapes right now?
It is solid, ignore the debug rendering.Is btTetraHedronShape a wire frame only? It would work great for one of my objects if it were solid but it seems to be drawn as just the wires
Hope this helps,
Erwin
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
So it is the center of mass and not the physical center of space that dictates how the collisions behave? I can work with that and tweak the inertial tensor if needed. I was mostly concerned that if I put heavy objects on one side of the physical center and light ones on the other that it wouldn't behave realistically. I hadn't finished my test to check that condition, thoughThe rigid body local transform equals the center of mass. This means you have to build the collision shapes to match the center of mass. For most basic shapes there is no additional work needed. Right now, calculating a more accurate inertia tensor, or shifting the collision shapes to match the center of mass is up to the user. So it is possible, but requires manual work.
Is there a reason I cannot break apart a compound shape into it's subsequent components to simulate a collision?
I did seem to remember hearing that somewhere but couldn't find it written down anywhereThe rendering of collision shapes happens in Bullet/Demos/OpenGL. Color reflects activation state (sleeping, active etc).
Ah, thanks. I thought the experiments I tried showed that it was solid but wanted to make sureIt is solid, ignore the debug rendering.
Thanks for the help
-
- Posts: 8
- Joined: Tue Nov 06, 2007 10:14 pm
Re: CcdPhysicsDemo question
Any thoughts on the last question about the difference between the plane and the box? I would have thought both should behave the same