[Solved] Stuck on collisions

So I have been using panda3d for awhile and starting to get used to scripting stuff but now I am facing a issue with how to extend my current collision implementation to include walls and other obstacles with wall sliding.

So my current implementation is that I have a collision traverser and a collisionRay that points downwards from the player character to get the player to collide with the terrain on the Z axis. that code is based on the Roaming Ralph demo with a few tweaks like I removed the wall collision part because It did not slide along surfaces and it got stuck pretty often so that part had to go and now I have a nice collision with the terrain only but thats about it…

Already tried to add a CollisionHandlerPusher and adding it to my player character but that just spazzed out and made the collision to jump around and stuck and just did not work (maybe I did something wrong,maybe it conflicted with the other one dunno). In short it was just a small experiment so I removed that one and went back to the terrain only collision.

Also I have no idea how to make the system in a way so I could use the model geometry as collision for walls and other obstacles with the

<Collide> { Polyset keep descend }

in the egg file

So my current situation is that I am a bit stuck with how to progress forward.

Thanks, Pade

Perhaps when you used the pusher, your collision solid intersected with the ground?

I suspected that at first too but with having collisions visible and I moved the sphere up so I could see that it was properly above ground but that still did not help it

I will experiment with this some more and try other methods.

BTW is there a way to make the terrain only collide with the CollisionRay and the CollisionHandlerPusher only to collide with obstacles?

Thanks, Pade

Collision bitmasks should do what you want, I imagine.

So I tried again with the pusher but I just cannot figure what I am doing wrong, here is a video about the issue I am having at the moment.
http://youtu.be/qQuSoxSvFYA
I am doing it like this

#add to character
pusher = CollisionHandlerPusher()
colPusher = CollisionNode("Player")
colPusher.addSolid(CollisionSphere(0,0,1.5,1))
Node = playerModel.attachNewNode(self.colPusher)

#add to traverser
cTrav.addCollider(Node,pusher)
pusher.addCollider(Node,playerModel)

So kinda stuck for the moment, will look at it tommorrow again…

Thanks, Pade

Hmm… Could the ray (or segment; I forget which Ralph uses) be colliding with the sphere, perhaps?

Additionally, I don’t see any setting of bitmasks, as linked-to above – have you tried that yet? (If the ray/segment is colliding with the sphere then, as with the sphere intersecting the ground, bitmasks should be a reasnable means of fixing the problem.)

Try using cTrav.showCollisions(render) to see what is colliding with what. That might help to see what’s going on.

Also, try playing with the pusher.setHorizontal(True/False) setting.

So I made that the sphere does not collide with the ray by just simply removing the ray from the CollisionTraverser because I could not set BitMask on the terrain without the FPS dropping close to 1, I actually found out what the problem with the pusher is but I have no solution for it, so the pusher actually works great but it works in “reverse” and I found it out by scaling up the obstacle cube

the pusher works as expected but only when I am inside the cube while I wanted that the pusher should keep me outside the obstacle cube so it allows me pass through the wall of the cube but does not let me out and I wanted exactly the opposite

setHorizontal had no effect on the problem I am having but showCollisions has helped me in the debug progress especially now that I know the pusher works but in “reverse”

Still stuck and here is a video to show the problem
youtu.be/eoGGDdf2cv4

so first I am standing outside box and when I move against it I get stuck inside it, once I am inside the box the pusher works brilliantly too bad I want it to work that way but keeping me outside the box instead of trapping me inside

I have tried reversing normals of model but that just messed up the rendering, the box has been exported from blender from the x format with

 x2egg obstacle.x -tbnall -np obstacle.egg

Thanks, Pade

If you can’t get the pusher working you could always try using the CollisionHandlerQueue class instead and just handle the collisions yourself. Every time your character collides with a cube you detect the depth of the collision (how far the character penetrates into the cube) and then just correct the character’s position by this exact amount. This has the exact same effect as the pusher but gives you more control. If you’re interested in trying this I posted a rough implementation of the kind of handler you would need in this thread:

[url]The built-in physics system and terrain penetrations]

Let me ask: did you create the collision geometry for either your obstacle or player, or are they both Panda collision objects (like CollisionBox or CollisionSphere)? If either is the former, then my guess is that the normals of one or both are facing the wrong way: they point inwards, rather than outwards. You should be able to view the normals in your 3D-modelling program, and should be able to flip them there too.

If I’m correct, then simply correcting the normals of one or both should fix the problem of your character being locked into the box.

After a moment messing around in blender with the normals I actually got the sliding collision to work as expected but the problem now is that the render is messed up and I can see “through” models because the normals are reversed

Looks interesting and might give it a shot in case I cannot get this work properly

Thanks, Pade

Which implies that you’ve reversed the normals of your visible geometry too, instead of just reversing the normals of your collision geometry.

First of all, if feasible, I recommend using Panda’s built-in collision shapes (unless you’re using a physics engine other than Panda’s built-in engine, such as Bullet, in which case use the shapes that it provides): this should run faster and more reliable.

However, in cases in which you do want to use your own geometry, I recommend having two sets of geometry: visible geometry and collision geometry. That way you can change the normals of one without affecting the other, and can have simpler collision geometry than visible.

I think I will go with this, this will also allow me to use inbuilt collision shapes by replacing “polyset” with “sphere” and so on.

Thank you everyone for your help!

Pade