Some Issues

Post Reply
User avatar
cippyboy
Posts: 36
Joined: Fri Aug 25, 2006 1:00 am
Location: Bucharest
Contact:

Some Issues

Post by cippyboy »

I discovered a couple of issues with Bullet and I've just upgraded to 2.54 and their still there.

First thing, I have some objects, which are mostly planes, or several unconnected planes (imagine a cube and you have to give it 2 materials so you have to slice it so you can render it, I'm practically giving Bullet 2 objects that way, making up the whole cube), and the funny thing is that I shoot spheres at them and sometimes they pass through, sometimes they don't.
And the higher the frame rate (and thus a smaller time step) the lower the chances of passing through, and usually if I send a sphere in a certain direction to that object, it passes through (or not) even if I send 3 spheres in that direction, in the same way, so it's not a random thing.

It would be possible that at one frame it's on one side of the plane and at the next frame it's on the other side, does Bullet solve these kind of problems ?

The other issue is a bit weird. After I compile the sources (through a static lib) on Release, and I run my program by going "Debug->Start Debugging" in MSVC2005, it works well, but if I go "Debug->Start Without Debugging" (or similarly double-click on the executable in windows) the newly created dynamic objects sometimes just don't work, and they just stop, I mean their created but they won't work, and the ones that are working, they continue to work no matter what else happens.

In some post I read, it was indicated that btTriangleMesh be used instead of btTriangleIndexVertexArray, does that mean that btTriangleIndexVertexArray isn't processed well or has certain issues ?
Another weird thing, I push a sphere way up, and I can feel the acceleration, but when falling down I don't feel any acceleration, it's like the gravity is just a constant force, is that normal ?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Some Issues

Post by Erwin Coumans »

cippyboy wrote:I discovered a couple of issues with Bullet and I've just upgraded to 2.54 and their still there.

First thing, I have some objects, which are mostly planes, or several unconnected planes (imagine a cube and you have to give it 2 materials so you have to slice it so you can render it, I'm practically giving Bullet 2 objects that way, making up the whole cube), and the funny thing is that I shoot spheres at them and sometimes they pass through, sometimes they don't.
And the higher the frame rate (and thus a smaller time step) the lower the chances of passing through, and usually if I send a sphere in a certain direction to that object, it passes through (or not) even if I send 3 spheres in that direction, in the same way, so it's not a random thing.

It would be possible that at one frame it's on one side of the plane and at the next frame it's on the other side, does Bullet solve these kind of problems ?
This effect is called tunneling, or temporal aliasing. Bullet has continuous collision detection for this, but this is currently not available. Later this year, a btContinuousDynamicsWorld will solve those issues.

The other issue is a bit weird. After I compile the sources (through a static lib) on Release, and I run my program by going "Debug->Start Debugging" in MSVC2005, it works well, but if I go "Debug->Start Without Debugging" (or similarly double-click on the executable in windows) the newly created dynamic objects sometimes just don't work, and they just stop, I mean their created but they won't work, and the ones that are working, they continue to work no matter what else happens.
The default projectfiles of Bullet should work on all platforms. Did you make your own projectfiles? Recompile all etc?
In some post I read, it was indicated that btTriangleMesh be used instead of btTriangleIndexVertexArray, does that mean that btTriangleIndexVertexArray isn't processed well or has certain issues ?
The btTriangleIndexVertexArray works fine, but is very prone to user errors (wrong vertex or index striding etc). So first try to get the btTriangleMesh as input to btBvhTriangleMeshShape.
Another weird thing, I push a sphere way up, and I can feel the acceleration, but when falling down I don't feel any acceleration, it's like the gravity is just a constant force, is that normal ?
Gravity is a constant force, causing a constant acceleration, this is normal.

Thanks,
Erwin
User avatar
cippyboy
Posts: 36
Joined: Fri Aug 25, 2006 1:00 am
Location: Bucharest
Contact:

Post by cippyboy »

This effect is called tunneling, or temporal aliasing
Is there any easy way to manually insert that for now ? Would it be safe to limit speed this way ?

Code: Select all

btRigidBody *body=GetMyCollisionObject();
btVector3 Speed=body->getLinearVelocity();

if (Length(Speed)>MaxSpeed)
{
    Normalize(Speed);
    Speed*=MaxSpeed;
    body->setLinearVelocity(Speed);
    //Should I also limit the AngularVelocity in this manner ?
}
The default projectfiles of Bullet should work on all platforms. Did you make your own projectfiles? Recompile all etc?
No I didn't, I just use the static libs built from the .sln provided, although it has that Post-Build Step that is erroneous.
The btTriangleIndexVertexArray works fine, but is very prone to user errors (wrong vertex or index striding etc).
I have no striding (because I use GL arrays), so I'm sending the data like I send it to GL; if they were any errors I should be able to see them visually... right ?
Gravity is a constant force, causing a constant acceleration, this is normal.
What I meant to say was that I feel a constant force, but no acceleration, as if there's only Position+=Force per frame, and something like Force+=Gravity should happen, that I think it may be missing. Could it be from the fact that I increased the gravity to something like 50g ? I did that because I kept feeling that the objects were moving in slow-motion.
jackskelyton
Posts: 32
Joined: Mon Nov 05, 2007 3:52 pm

Re: Some Issues

Post by jackskelyton »

We are having a similar bug with gravity and slow motion. With gravity set to -10 or other comparable value, and normal-sized stock collision shapes like a 2m-radius sphere, the objects fall so slowly it's as if they're not moving at all. To even see it move, we have to set gravity to 50 or higher. Our timestep is set to (dt in seconds, 1, 1./180.0).
AlexSilverman
Posts: 141
Joined: Mon Jul 02, 2007 5:12 pm

Re: Some Issues

Post by AlexSilverman »

Hello,

First, a note on terminology. A constant force (such as gravity in Bullet) is one that is applied to an object every timestep, resulting in a steadily accelerating object. So saying that gravity is a constant force but there is no acceleration is a bit misleading. Perhaps it's more accurate to say that you see a constant speed, or an instantaneous force being applied.

Next, are either jackskelyton of cippyboy able to reproduce the gravity effects they see in their applications in any of the Bullet demos? I'm seeing something somewhat similar in my application, but my schedule is such that I can't take time out to set up an empty testbed to properly get to the bottom of it. The one condition on my observed effect is that I only see the slow falling objects after a force straight up (ie: 0 in the X and Z) is applied. If I apply any force at all in either dimension, the object behaves normally. Regardless, I had attributed this (in the short term anyway) to the fact that my project is not on a PC and there was something at play that I wasn't aware of, but I'm still interested in seeing one of your problems reproduced in a demo to see if it's the same, in addition to that being the first step to resolving it.

- Alex
Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Re: Some Issues

Post by Dirk Gregorius »

I would disable the linear damping just to check if this is the reason for this. Personally I don't use any linear damping because it can slow down falling objects. Also a standard gravity looks often too slow. So we usually use a gravity of 30 and still objects often appear to fall to slow (of course this is very bad for the solver if you step at 30 - 60 Hz - so maybe try 15 as gravity). This effect of slow falling objects happens especially when you drop very large objects. Just check a scene of objects with a radius of maybe 2 and then try the same scene with a radius of 100. So this is might be the reason that the major physic engine vendors recommend using SI Units and proper sizes.
jackskelyton
Posts: 32
Joined: Mon Nov 05, 2007 3:52 pm

Re: Some Issues

Post by jackskelyton »

I tried that, and it makes very little difference. We initialize with these values:

Damping (0, 0)
SleepingThreshold(0.1, 0.1)
CcdCalculationThreshold(0.01)
Mass = 1
CollisionShape = sphere(2.0)
stepSimulation(TicksSinceLastFrame * 0.001, 6)
All other RigidBody values are default (not specified in btRigidBody ctor)

still falls very slowly.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Some Issues

Post by Erwin Coumans »

I haven't read through the whole tread, but can you reproduce this problem in a Bullet 2.64 Demo?

Can you try if commenting out EXPERIMENTAL_JITTER_REMOVAL and FORCE_VELOCITY_DAMPING around line 121 and 212 of Bullet/src/BulletDynamics/Dynamics/btRigidBody.cpp makes a difference?

Hope this helps,
Erwin
jackskelyton
Posts: 32
Joined: Mon Nov 05, 2007 3:52 pm

Re: Some Issues

Post by jackskelyton »

I'm not sure what you mean by "reproduce this problem in a Bullet 2.64 demo." Commenting out those lines appears to have no effect. The only time I have seen a change since I started tinkering with the settings is to change the time slice in stepSimulation.

I should note that I am also getting the "constant velocity" problem mentioned above. The gravity moves objects downward at a steady rate--they never appear to accelerate.
AlexSilverman
Posts: 141
Joined: Mon Jul 02, 2007 5:12 pm

Re: Some Issues

Post by AlexSilverman »

As far as reproduction in a Bullet Demo, I'd suggest creating a very simple scene (preferably one that contains nothing besides the physics objects necessary to exhibit the abnormal behavior) to showcase the problem in your application first, to verify that the problems you're seeing are present in a small scenario. If you still see the problem, I'd then create that same scene in a Bullet Demo (the CcdPhysicsDemo project is probably a good choice). If you don't see the problematic behavior in that setup, all that is left is to see where your code and the Bullet Demo code differ (initialization, object properties, global forces, etc...) and change the Bullet Demo to match your own application. Hopefully the problem will emerge at some point in this process, and give some clue as to what's causing it.

Hope that helps.

- Alex
dreamtheater39
Posts: 13
Joined: Sat Nov 10, 2007 8:39 pm

Re: Some Issues

Post by dreamtheater39 »

I think this should be an easy fix and might help -

Make sure your world is a discrete dynamics one -

Code: Select all

m_dynamicsWorld = new btDiscreteDynamicsWorld(m_dispatcher,m_overlappingPairCache,m_solver,m_collisionConfiguration);
And when you're stepping your sim, use the second parameter to specify the max number of sub steps it can take to internally process -

Code: Select all

if (m_dynamicsWorld)
		m_dynamicsWorld->stepSimulation(fElapsedTime, MAX_NUM_SUB_STEPS);
This would be time slicing internally. Remember, this doesnt work for simple dynamics world though...

I hope i'm making sense :D
San
jackskelyton
Posts: 32
Joined: Mon Nov 05, 2007 3:52 pm

Re: Some Issues

Post by jackskelyton »

Actually, it was our own control method that was mucking things up. My team's 0 for 3 on the Bullet forums, creating problems with our own mistakes :) It turned out we were setting the Y velocity to 0 at every iteration of the game loop. No wonder it moved so slowly.

Thanks to all for the help. As it turns out, using the internal timestep of 1/60 is the smoothest.
Post Reply