Real-Time Physics Simulation Forum

Ok,

You're going to need to put a breakpoint at the point you do new btDiscreteDynamicsWorld and see if thats hit, and that the object looks 'correct' after the construction. I'd also put one in void PhysicManager::shutdown() to make sure that the objects aren't being deleted unexpectedly.

Is it not working?

From what I remember you have to set the world gravity before you add objects to it otherwise they won't get the new value and you'll have to go through and adjust them by hand.

Where abouts do you call start(Ogre::SceneManager* sceneMgr) to create the world physics objects?

If it won't even step into the addRigidBody function without crashing then it does suggest that somehow the mWorld object is corrupt at that point... can you look at it under locals and see if some of it's members (gravity, m_nonStaticRigidBodies, etc) look like they have 'sensible' values. You coul...

Yeah, I can see why that isn't incredibly clear :) Just looking at the code for addRigidBody it doesn't seem as if there are many points where you could get an exception raised. What might be a useful start though is if you skip using your MyMotionState object (just pass NULL for now) and seeing if ...

Nothing obviously wrong that I can see.
Do you have the stack trace for the crash?

Bullet doesn't (can't) simulate backwards in time (don't think any physics engines can as there are a multitude of possible states). I think most games do what you suggest and store off a chunk of previous inputs so they can be replayed forwards from that point.

Yep would definitely be interesting to see your new profile data. I doubt you'll get much benefit from quad tree , if your zombies are/were 2.2 m and moving at 10m/s then you're probably only testing 4-8 triangles per entity anyway which shouldnt be excessive, am surprised that with only 20 entities...

applyGravity doesn't have any timestep component to it, all it does is update the total force so it has a standard 9.8m/s value , it's only when integrateTransforms is called during the rest of the simulation that the timestep comes into play . I believe thats why it's setup outside the number of st...

no, it's not that bad.... it will take your start and end movement points and calculate the set of possible overlapping triangles, not the whole heightfield shape. it just that if you're doing diagonal movements then that box is larger then it would be otherwise. If your zombies are only moving slow...

I had a patch for btHeightFieldTerrainShape that built an optional finer grained quadtree on top to help with situations like that. (submitted as issue : http://code.google.com/p/bullet/issues/detail?id=620&colspec=Modified%20ID%20Type%20Stars%20Status%20Owner%20Summary ) . I've also seen people...

I'm pretty sure that none of the shapes or mesh objects do a deep copy of the data so you'll probably want to allocate them on the heap and keep a reference to them then because otherwise the pointers to them will be trashed as soon as your function exits... the Demos/ConcaveDemo/ConcavePhysicsDemo....

I tend to get similar results with heightfield terrain shape in my c# version of bullet. Looking at that profile data it looks as though most of the calls are in GJKPairDetector::getClosestPoints and btConvexShape::getLocalSupportingVertex, which kind of makes sense as all the terrain shape is doing...

Have you got your exact example code, as it's a bit hard to tell from that which objects are in and out of scope (e.g. your index and vertices arrays look like they're declared locally...)

I agree it is a bit confusing, as you say the code defines things as short int so that would give you the 16 bits. I think the main confusion is the difference between the m_collisionFlags on btCollisionObject (CF_*) and the group and mask values that exist in the broadphase proxy. From what I can r...