Real-Time Physics Simulation Forum

It's possible that the static objects have reached a sleeping state , you can try disabling sleeping on them in your PhysicsComponent as below. The default debug draw class also shades objects by activation state which may help show up errors. if(mass == 0.0f) { body_->setActivationState(DISABLE_DEA...

Out of interest, which version of JBullet are you using? If you're building from the github one (https://github.com/bubblecloud/jbullet) I can probably submit a patch to enabled the setLinear/Angular Factor code in case it's helpful in the future

Looks like the standard JBullet predates the linearFactor calls, shouldn't be a big deal to add them in though...

May be a dumb question, but are you using a debug or release build of bullet for you testing?

Memories a bit flakey on this but : You set-up a single btGhostPairCallback (only once) to allow the broad-phase to pass on the results of it's collision tests to the ghost objects directly. The ghost objects are a bit different in that they remember the colliding pairs (rather than just having the ...

Yes that's one option, or you could extend btDiscreteDynamicsWorld and update with a 'cleanup' method, though if you do that you'd have to be very careful with any objects that had been created before that point as they would no longer be valid

Hmm, tricky to see from that. But I couldn't see anything obviously wrong.
Would you expect the sphere to intersect the floor based on it's size and the offset from the player you're generating it at? How far away from the wall do you have to be before it stops generating 'false' collisions?

What the demos do is to keep a list(s) of all the shapes,bodies, constraints etc that you create and just go through and tidy those up at the end.
you'd have to do that (or similar ) in your own code

Not directly, though it would be easy enough to add such a method to btDiscreteDynamicsWorld, or to expose it's constraints list if you wanted to :

btDiscreteDynamicsWorld.h

btAlignedObjectArray<btTypedConstraint*> m_constraints;

btVector3.h
SIMD_FORCE_INLINE btVector3& operator*=(const btScalar& s)
{
...
}

so should just be able to multiply it as you've written your example:

btVector3 val(1.0f,1.0f.1.0f);
val *= 2.2f;

Probably best thing to use is ghost collision objects as you don't really want them to effect the physics of the world. If you look at the ghost demo you'll see an example, including how you might use a collision callback or similar. You can use the callback to trigger situations in your game . e.g....

Seems reasonable, are the errors consistent, i.e. do you always see the same pattern of incorrect height values or does it vary? does changing the resolution of your heightmap alter things at all?

You can step in with JBullet, just depending on which version you're using you may have to update your ide to run the instrumentation on the stackalloc created objects

And finally I stop being dim and remember that Java doesn't support ref types like c# , ho hum.
Anyone the attached jar and source jar has a working HeightfieldShape and a version of the TerrainDemo you can use as a reference. Or you could stick with your triangle mesh shape

well I'm stumped at the moment I'm afraid. Height map works 'inconsistently' unless all all the height values are the same, i.e. it's flat. Mesh renders correctly in debug draw and normals for surfaces seem correct just most of the time things fall through the world anyway. Changing collision shape ...