[Solved] Finding out how deep spatial a is in spatial b

[pspeed]

@jayfella

I was thinking if I altered the scale. So a 10% reduction in size would result in a volume reduction % of x

yeah, I think it goes:
90% scale
= 81% area (0.9 * 0.9)
= 72.9% volume (0.9 * 0.9 * 0.9)

[zissis]

@sgold

Ghost objects can use any collision shape, not just AABB. I’m very sure of this for native Bullet and reasonably sure for jBullet.

I was originally going to use ghostcontrols and immediately saw that it uses AABB for collision detection as soon as I rotated the part and it told me that the parts where overlapping when they where not. That was yesterday, so I rewrote things to use rigid bodies instead.

So I can confirm that as on 3.2.2 stable and yesterday, Ghost controls use AABB for overlap detection. Try it yourself by rotating one object by 45 degrees and watching what happens.

EDIT: After wasting time with ghost control I went to our wiki and realized it was documented as such in the Physics pitfalls section too

[zissis]

@sgold

Yes, you can add 2 rigid-body controls to a single Spatial . To access them, you’d need to keep references (since Spatial.getControl() will only find one of them). And of course, if both RBCs were in dynamic mode, they’d interfere with each other, so I recommend that at least one of the controls be setKinematic(true) .

For the editor I use setKinematic(true) with a mass of one because all I need to do is check if the parts are touching overlapping or not touching. I started with ghost controls but regardless of the collision shape ghost controls returned values like they where using AABB so I moved to ridged bodies instead.

[sgold]

@zissis

I was originally going to use ghostcontrols and immediately saw that it uses AABB for collision detection as soon as I rotated the part and it told me that the parts where overlapping when they where not. That was yesterday, so I rewrote things to use rigid bodies instead.

So I can confirm that as on 3.2.2 stable and yesterday, Ghost controls use AABB for overlap detection. Try it yourself by rotating one object by 45 degrees and watching what happens.

I’ll look into this.

[zissis]

@sgold

I’ll look into this.

I did a quick search and seems like other found this out the hard way years ago as well.

[zissis]

@sgold I looked into it further. Seems like ghost controls use your collision shape for Physics collision listeners but an AABB shape for all the overlapping detection.

EDIT: NOPE after further testing it ALWAYS uses an AABB

[sgold]

I’m seeing unexpected behavior from PhysicsGhostObject, both with jme3-jbullet and jme3-bullet. In some cases, the 2 libraries behave quite differently. I’m still looking for patterns.

[pspeed]

When you move/rotate the ghost object, how are you moving them?

Edit: and when?

[zissis]

set local transform and rotation through the use of my gimble

[mitm]

Probably out of my league but why not redesign and use a panel to display the uncompleted object, then have side slots with the options available. They click the option, you apply it to the object and either gray out the selection or remove it from the options panel if they accept the changes.

[pspeed]

@zissis

set local transform and rotation through the use of my gimble

…but to move physics objects you must set the position/rotation of the physics object. Moving the spatial won’t do anything, I thought.

[pspeed]

@mitm

Probably out of my league but why not redesign and use a panel to display the uncompleted object, then have side slots with the options available.

Quite sure he wants more flexibility than that. Allows for more creativity.

[zissis]

@pspeed

…but to move physics objects you must set the position/rotation of the physics object. Moving the spatial won’t do anything, I thought.

If it’s a ghost control the physics object is bound to the spatial. When I use ridged body control I set it to kinetic and it’s mass to 1.

[sgold]

I think you were correct that getOverlappingObjects() reports (broadphase) AABB overlaps, while PhysicsSpace collision listeners report only the more precise (narrowphase) collisions.

With the 3.2.2 jme3-bullet library, I’m seeing good agreement (in the precise collisions reported by collision listeners) between PhysicsRigidBody and PhysicsGhostObject. If you’re seeing AABB overlaps reported as collisions by the PhysicsSpace then we’re seeing different things. I’d like to understand why.

Collision detection in Bullet can be quite tricky. I was surprised how long it took to write a good test for it. Would you mind running this test on your system?

Banana/TestDetectCollision.java at d93d2164d965b6fd3ada2e7a93df192d1ea4d914 · stephengold/Banana · GitHub

In the process of writing this test, I learned a bit more about Bullet.

For instance, broadphase and narrowphase apparently use different collision margins; you can set the narrowphase margin for each CollisionShape instance, but the broadphase margin seems to be hardcoded to about 0.05 or 0.06 physics-space units. That’s why GhostControl reports overlap between a pair of 2x2x2 cubes placed on the X axis with their centers 2.09 PSU apart.

[sgold]

@sgold

When Bullet detects a collision, it calculates the depth of penetration. Unfortunately, this information doesn’t seem to be accessible through the current jme3-bullet API.

After reading some code, I suspect the PhysicsCollisionEvent.getDistance1() method is intended to return the depth of penetration. (getDistance1() accesses the m_distance1 field, which is initialized from the constructor’s distance parameter, for which a variable named depth is passed in 2 places…)

I haven’t tried this yet, so I don’t know how/if it works in practice. If you try it, let me know.

[zissis]

@sgold

After reading some code, I suspect the PhysicsCollisionEvent.getDistance1() method is intended to return the depth of penetration. ( getDistance1() accesses the m_distance1 field, which is initialized from the constructor’s distance parameter, for which a variable named depth is passed in 2 places…)

Since I have a perfect test harness I tried it. The number does go from 0 up to -0.6x but stays at the -0.6x value as the object goes deaper into the other one. Without understanding what the value context is I am afraid it is useless. The bullet classes have zero documentation in them so that does not help either unfortunately.

[pspeed]

@zissis

The bullet classes have zero documentation in them so that does not help either unfortunately.

I assume you mean JME’s bullet classes. Sometimes you can look at the real C++ bullet documentation for clues… but that doesn’t always work either. Just pointing it out because it was helpful to me on some occasions.

[zissis]

Yes JME classes

[sgold]

Just for my curiosity, what collision shape(s) and what type(s) of collision object did you test?

[zissis]

CollisionShapeFactory.createDynamicMeshShape(this.spatial)

both ghost and ridgedBody through PhysicsCollisionListener