This is my first post, so hello to all.
Hopefully this isn
Uh, you are right… GhostNodes are not supposed to cause collisions…but I also cant see the problem right now, gotta check on this…
:-)Wow, many thanks for your quick response! 
I have another bit of info (if it helps):
I (just) created a second child PhysicsGhostNode, attached it to a new Node, and made that node a child of the original slab PhysicsNode. The child PhysicsGhostNode appears to respond properly to the collision with the other box PhysicsGhostNode (signals an event with no physics response), while the slab (still) physically collides.
PhysicsNodes should not be children of other PhysicsNodes as the physics works in world coordinates and this creates unnecessary computations from world to local coordinates.
A fix for the collision with GhostNodes is now in svn, they actually were missing a flag.
Cheers,
Normen
Many thanks.
Is there a method of (for lack of a better term) attaching a PhysicsGhostNode to a PhysicsNode. I had originally hoped that a PhysicsJoint object could have been utilized, however such is not the case.
Once again my appologies for being dense…
No there isnt, you will have to move the ghostobject to where the physicsnode is each frame.
Hello!
I think I found some more bugs in PhysicsGhostNode.
First of all, it seems to me that everything I attach to it, get some strange rotation (so I must call ghostNode.setLocalRotation(new Quaternion())), to set everything like it was intended.
Second, there is obvious difference in these 2 method calls, I tested it and the one with Vector3f in argument doesn't work:
/**
* sets the local translation of this node. The physics object will be updated accordingly
* in the next global physics update tick.
* @param arg0
*/
@Override
public void setLocalTranslation(Vector3f arg0) {
super.setLocalTranslation(arg0);
}
/**
* sets the local translation of this node. The physics object will be updated accordingly
* in the next global physics update tick.
*/
@Override
public void setLocalTranslation(float x, float y, float z) {
super.setLocalTranslation(x, y, z);
applyTranslation();
}
Hopefully we are not bugging you too much normen! :)
InShadow said:
Hello!
I think I found some more bugs in PhysicsGhostNode.
First of all, it seems to me that everything I attach to it, get some strange rotation (so I must call ghostNode.setLocalRotation(new Quaternion())), to set everything like it was intended.
Second, there is obvious difference in these 2 method calls, I tested it and the one with Vector3f in argument doesn't work:
Hopefully we are not bugging you too much normen! :)
This is from jme2 and jbullet-jme, not from jme3 right?
What exactly is that "strange rotation"? Is it not Y=up? The rotation that is being applied when PhyiscsSpace.update() is called is the standard rotation of ghostnodes. Its best to just set your own if its not correct for what you want to do. Since GhostNodes do not move by themselves you will have to set the values anyway.
The setLocalTranslation() call to apply was simply missing, right, committed that. Anyway I want to switch to updating the physics objects centrally in updateGeometricState() avoiding the frequent calls to updateGeometric.
normen said:
This is from jme2 and jbullet-jme, not from jme3 right?
What exactly is that "strange rotation"? Is it not Y=up? The rotation that is being applied when PhyiscsSpace.update() is called is the standard rotation of ghostnodes. Its best to just set your own if its not correct for what you want to do. Since GhostNodes do not move by themselves you will have to set the values anyway.
The setLocalTranslation() call to apply was simply missing, right, committed that. Anyway I want to switch to updating the physics objects centrally in updateGeometricState() avoiding the frequent calls to updateGeometric.
Yes its from jme2 and jbullet-jme. Are there any differences between this implementation and implementation used in jme3? With strange rotation I mean that things that you attach to PhysicsGhostNode are under some 45 degree rotation angle by default. If you attach them to normal node, they are fine.
Thanks for fast response and commit again! :)
InShadow said:
Yes its from jme2 and jbullet-jme. Are there any differences between this implementation and implementation used in jme3? With strange rotation I mean that things that you attach to PhysicsGhostNode are under some 45 degree rotation angle by default. If you attach them to normal node, they are fine.
Thanks for fast response and commit again! :)
Well the differences on the user side are not so many, but in how the physics / jme transforms are applied its completely different. Ok, I can maybe look into making the default rotation of GhostNodes y-up, especially since the user only notices after the first physics update has run. But right know I dont know why that isnt the case, as with PhysicsNodes everything seems to be ok..
If user can correct it its not such a deal. Although I must admit that its pretty confusing and takes some time before you start thinking about manually setting rotation of the node.
Anyway, after reading documentation of PhysicsGhostNode:
* GhostObject can keep track of all objects that are overlapping.
* By default, this overlap is based on the AABB.
* This is useful for creating a character controller,
* collision sensors/triggers, explosions etc.<br>
I have another question: if this GhostObject keeps track of objects that are in collision with it, is there any way to retrieve those objects or at least retrieve how many are colliding with this one?
InShadow said:
I have another question: if this GhostObject keeps track of objects that are in collision with it, is there any way to retrieve those objects or at least retrieve how many are colliding with this one?
Not like asking the object for a list, no. That works in bullet itself but its not accessible through the wrapper. For now you only have the global callbacks of the PhysicsSpace and have to keep your own lists there.
I plan to use the extended functions of bullet collisions and collision reporting/scanning at some time but the bullet api itself is a bit convoluted in that part and I want to give users some clean and usable functions and not just a bunch of strange possibilities ;) That description I copied straight from bullet just to have an overview of what its supposed to be.
Aha.
Ok collision I can detect, but how is it possible to detect when collision has ended?
You will get a collision event every frame as long as the objects are colliding.