In the Android version, the simple collision between two geometry objects is detected from a large distance and the desktop version in the normal way - in case of contact. Someone will suggest some? Thanks
are you sure its the same code? please check .setMargin() method first for collision mesh/control.
Code is exactly the same. But … perhaps the difference is the fact that android is using repo of jme taken from jayfellas git… Maybe he could drop some light on issue ?
Can you clarify where I come into this…? I’m not sure what you mean.
What does debug show for collision shapes? Maybe the scale is off?
I/System.out:
Collision distance : 5.69007 m… assuming the world dimensions reflects real
Visually, do the collisionshapes match the object size?
bulletAppState.setDebugEnabled(true);
https://wiki.jmonkeyengine.org/jme3/advanced/physics.html#changing-the-scale-of-a-physicscontrol
The other thing to look for is if the models origin is offset then the collision shape will be also.
I see no reason why at the desktop is OK but on mobile not. However… I noticed the rotation of model cause the problem. With no rotation works well.
Rotation as below
crateAmmoNode.rotate(0f, PI * tpf / 20, 0f);
I’m curious what you mean by “simple collision between two geometry objects” …
Are you using a physics library? If so, which version, with what collision objects/controls/shapes?
If you’re using com.jme3.collision.Collidable (no physics), then try updating the model bounds and clearing the collision data.
Well… collision is with no physics -and is between two spatial models. The first one is not added to physic space - the second one is (betterChracterControl). updating is in every loop . result.clear(); makes no difference… checking of collision as below
result = new CollisionResults();
BoundingVolume bv = crateLifeNode.getWorldBound();
characterNode.collideWith(bv, result);`
BetterCharacterControl is a PhysicsControl—there’s no point in having one unless you’re going to add it to a PhysicsSpace and use physics.
Bullet physics collision objects have no effect on com.jme3.collision collidables and vice versa.
Collidables are optimized for picking (for instance, selecting scene objects using a mouse). Using them to detect collisions between scene objects is tricky. Before invoking collideWith(), you need to make sure the bounds are up-to-date (Geometry.updateModelBound()) and any stale BIH collision data is cleared (Mesh.clearCollisionData()). If you’ve done all that and are still seeing unexpected behavior, perhaps you should create a self-contained test case to show us.
Also, as being used, one should only expect bounding volume to bounding volume collisions. And bounding volumes can sometimes be a bit unpredictable.
That being said, I can’t explain why it would be different on android versus desktop except if the versions of JME are different. Over the years, there have been a handful of bounding box related collision fixes in point releases.
1 Like