So I was using the CollisionHandlerPusher as my method of Collision Detection, and I had some success until it came time where I needed to define where (direction) the collision was happening, so I tackled this with the fallowing code.

``````def fall(self, task):
global falling
global prepos
global pospos
dt = globalClock.getDt()
if pospos < prepos:
falling = True
prepos = self.pactor.getZ() + (-4 * dt)
self.pactor.setZ(self.pactor, -5 * dt)
pospos = self.pactor.getZ()
else:
falling = False
prepos = self.pactor.getZ() + (-4 * dt)
self.pactor.setZ(self.pactor, -5 * dt)
pospos = self.pactor.getZ()
``````

What this is trying to attempt was it asks if “pospos” is lesser than “prepos”, as you can see in the code “prepos” Z position before it is reduced and “pospos” is the Z position after reduction, the idea was from documentation of the CollisionHandlerPusher I got the idea that this collider pushes back on the moving object to make the collision, so if something like gravity was constantly moving a object but the object met with this collider, the collider would push back onto the object, but the gravity would push it forward.

So a sort of jamming on the movement position number would occur between the pushing forces, you would not see (you would see the object sitting still), I wanted to take advantage of this theory, so the above code would capture the Z position before it is changed plus reduce it a bit less then what it is going to be reduced by, then actually reduce the Z position, then finally capture it in that reduced state all in 1 frame.

Then on the next frame, it compare the changes, to see if “pospos” is lesser than “prepos”, if “pospos” was lesser, it meant the movement is completed fully uninterrupted, if not, it meant it was interrupted by the collider because it cannot reduce fully (the above jamming theory), this was the idea but it did not work, so after some trial and error, I wanted to look at the “prepos” and “pospos” variables to see if something went wrong.

So I hook up the variables to some text nodes to display them on screen, and though I couldn’t get exact numbers (due to the text pilling up on each other, something I could never fix even with the OnScreen Text), I can see them gathering more digits even when the character stop moving, so my question is, what is happening? shouldn’t the Z position stay set within a range between the competing forces (collider and gravity)?

Is there something I,m missing about Panda’s movement system? or is it the way the CollisionHandlerPusher handles collision that I,m not getting, as always thanks to anyone who is willing to help, I provided the full demo right here for more examination (I linked up the Z position directly to “COLLISION” on the debug text): jnmoveque.zip (399.3 KB)

Okay, I looks like I solved most the issues here, I toke a different approach after I got the text to update correctly, I finally saw what went on, it seems that my jamming theory was correct, but a unforeseen quirk that I encountered was if the numbers where moving, they moved at the same time.

So i got a idea, I rewritten the code to check for a range between “prepos” and “pospos” and have the Z position be in-between those numbers for it flag as True, take a look: jnmoveupdate.zip (399.3 KB)

I,m keeping this thread open for two other questions, if you run the demo, one, there is this strange red line that prevents the character from touching the ground, what is that? and how do I change it? and two, in the demo, when the character collides with a box, multiple lines appear implying that panda3d is detecting collisions from all directions.

Is panda3d capable of returning the direction in which a collision was made? thanks to those who are willing to help.

I,m declaring this thread is answered, as I,m exploring the getSurfacePoint() and getSurfaceNormal() features now, I will probably make another thread later about some questions on those features, after some research.

Take care everyone.