V1.10.0 box-box collisions, filters

Hi to all,

I hadn’t gotten the chance to test the latest v1.10.0 [ - 2015-12-26T16:00:51Z - Begin to add snake_case/property interfaces to important direct classes ] collision system until today afternoon and have not had much luck with it. The box does collide with the sphere, but not with another box, here is some code I use to test this:

from panda3d.core import *
from pandac.PandaModules import *
import direct.directbase.DirectStart 

#collision traverser:
traverser = CollisionTraverser('traverser name')
base.cTrav = traverser
box = CollisionBox(boundz[0],boundz[1])
cnodePath = cubr.attachNewNode(CollisionNode('cnode'))
pusher = CollisionHandlerPusher()
pusher.addCollider(cnodePath, cubr)
traverser.addCollider(cnodePath, pusher)
#create duplicate collision geometry at another point:
box = CollisionBox(boundz[0],boundz[1])
cnodePath = dumz.attachNewNode(CollisionNode('cnode2'))
#create a sphere further in for reference:
sphere=CollisionSphere(cubr.getBounds().getCenter(), cubr.getBounds().getRadius())
key_sets={"l":0, "r":0, "u":0, "d":0, "z":0, "x":0}
#move functions:
def chng_keys(key,value):
    global key_sets

def move_mee(task):
    global key_sets
    global cubr
        cubr.setY(cubr, 25 * globalClock.getDt())
        cubr.setH(cubr.getH() + 300 * globalClock.getDt())
        cubr.setH(cubr.getH() - 300 * globalClock.getDt())
        cubr.setY(cubr, -25* globalClock.getDt())
    return task.cont
taskMgr.add(move_mee, "movement")

When I run the above, the “from” object using a collisionBox solid only collides with the sphere and not the box.
[Press the “up” arrow key to move it after zooming out with the camera.]
The collision handler that I use is Pusher, (though I’ll also use PhysicsCollisionHandler later on) and the results on my PC are that collisions with boxes as “from” objects don’t occur with other boxes. The other thing is the silhouette issue persisting which means I still need to add the gl-ignore-filter in the prc file to play the game.

If these issues are resolved it would be great!

Setting “notify-level-collide debug” in Config.prc reveals that it does detect a collision, but the pusher needs a surface normal and surface depth in order to determine which direction to push the box in, and the box-box collision test doesn’t provide this information yet.

I’ll see if I can update the box-box collider to add some of this information to make the pusher able to do something.

For what it’s worth, the pandac.PandaModules import in your code does absolutely nothing except print a deprecation warning. Using panda3d.core et al is the recommended mechanism.

Glad you brought up the filter issue. I recently added another config variable that will more specifically disable texture LOD settings (instead of disabling filters altogether), which I suspect might be causing your woes.
Could you remove the gl-ignore-filter setting and instead try this setting?

gl-support-texture-lod false

Alright thanks, but I hope I can at least use the pusher collision handler with a box and a polygon, and a box and a plane.

Thanks, one less line of code. :smiley:

I did remove the filter setting and tried the lod setting, and while it did indeed remove the texture pixelation, it added a new problem:

Some textured models look like dark shadows the further your viewing point, and only reveal their features the closer you get to them. So that’s the new issue brought up on this old PC with that new setting. :frowning:

A small update, on testing the CollisionBox with the CollisionPolygon, I notice that the same “shakiness” I got with the CollisionSphere persists when using the CollisionHandlerPusher. What I thought that handler does is to check for the depth of penetration that the “from” object has made into the “into” the object, and then re-position the from object accordingly…I could implement something like that using a queue or event handler.

Another thing I noticed is that, when wrapping an actor with a CollisionBox like this:

               pusher = CollisionHandlerPusher()
               pusher.addCollider(cn, self.player_piece.game_nodes)
               self.traverser.addCollider(cn, pusher) 

And playing an animation on the actor, the collisionBox does not adjust itself accordingly. But I suppose if I wanted that, I’d have to use the nodepath returned by “exposeJoint()” and then parent the relevant collision geometry to it…
Do you think, to avoid the whole “shakiness” it would be best to leave the pusher handler alone, and try implementing something using queue or event handlers?

Thanks so much for the clear test case, by the way. It is greatly appreciated.

I implemented the normal/depth information for the box-box collision test. They now interact smoothly with each other.

I also noticed the shakiness that happens when the box collides with the sphere. It’s not an issue with the pusher in general, but there was a bug in the sphere/box intersection tests, which generated the wrong normal/depth information, so it was bouncing off in the wrong directions.

I’ve replaced the box-into-sphere test with a version that does work correctly (and should be faster, too). The box now comes to a stop when bumping into the sphere, and slides smoothly along the sphere when moving it at an angle.

I’ve also changed the behaviour of “gl-support-texture-lod false” slightly. With that setting set to “false” again, please try again.

All this should be available in the latest 32-bit Windows buildbot build. If you encounter more problems, please let me know.

There’s no need to reimplement the pusher, since it works fine as long as the intersection test gives correct depth and normal information. As for box-into-polygon, I’m not seeing any shakiness when I collide a box into a polygon. If you have a test case that demonstrates shaky collisions against polygons, I’d be happy to take a look at it. I’ve also tested box-into-plane, which works very reliably.

As for actors: there are two approaches, either size the solid to be big enough to cover the model with or without animations, or divide it up into multiple solids attached to joints. Which configuration of solids will work best depends on the specific application.

No problem :slight_smile: .

I can’t thank you enough for this! I played with box-box collisions and they are very smooth, they slide off of each other properly; you have no idea the horror I was going through when using sphere-into-polygon collisions, I thought that this entire project would have been all for naught at a point…

Regarding the “gl-support-texture-lod false”, unfortunately, even with the latest version, the error still persists, some models still look like shadows from afar, and as you can see from the below screenshot, the clouds, which are just billboards with png textures, are not transparent where they are supposed to be.

Well, this image should demonstrate what I mean when I say that box-into-polygon at times is very shaky:

The model in blue has collision geometry consisting of multiple polygons, as you can see. When the actor, encapsulated by the big box, hits that model, it jumps and shakes all over, so much so that I can no longer control its motion. This occurs when I use boxes and polygons. However, as I said before, when I use boxes and boxes, even with that particular model and actor, all is ok, and the actor slides off of the model relatively well.

Yes, I ended up implementing both approaches [but the first one doesn’t account for actor animations where the entire actor scales up beyond the bounds of the collision solid]. I have one question about parenting collision geometry to joints, is there any way to get the bounding-box or bounding-sphere of the geometry that goes to form the joint?