yeah, I think it goes:
= 81% area (0.9 * 0.9)
= 72.9% volume (0.9 * 0.9 * 0.9)
yeah, I think it goes:
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
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.
I’ll look into this.
I did a quick search and seems like other found this out the hard way years ago as well.
@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
I’m seeing unexpected behavior from
PhysicsGhostObject, both with
jme3-bullet. In some cases, the 2 libraries behave quite differently. I’m still looking for patterns.
When you move/rotate the ghost object, how are you moving them?
Edit: and when?
set local transform and rotation through the use of my gimble
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.
…but to move physics objects you must set the position/rotation of the physics object. Moving the spatial won’t do anything, I thought.
Quite sure he wants more flexibility than that. Allows for more creativity.
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.
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
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?
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.
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.
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.
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.
Yes JME classes
Just for my curiosity, what collision shape(s) and what type(s) of collision object did you test?
both ghost and ridgedBody through PhysicsCollisionListener