CollisionHandlerPusher - CollisionPolygon - Strange behavior

Scripting Issues
1

Hello!
I have been working on a first person game.
I am using a ColisionHandlerPusher for wall collisions and a CollisionHandlerGravity for floor collisions.
Those worked with Box and Sphere Collision Solids.
Now I have added a CollisionPolygon from an egg file and some strange behavior has happened.
The polygon should act like a wall stopping the player.
But when you come closer you get teleported and sometimes get stuck inside the polygon.
The player travels rather slow and this even happens if the player tube collider is not in direct contact with the polygon.

Here is the code i use to add the Objects Collision:
“Cube/Cube” is just the default name of the blender file i generated the egg file from.
The collision polygon get’s displayed correctly (with show()). Just it’s behavior is “wrong”.

def addCollision(self, render):
        col = self.loader.loadModel(self.basedir + "/rsc/models/" + "connector_collision.egg")
        col.reparentTo(self.model)

        walls = render.find("**/connector_collision.egg/Cube/Cube")

        #debug
        if walls is not None:
            print(walls)
            walls.show()

Does someone have an idea what the problem could be?

2

Hmm… Could the polygons be facing the wrong way? That is, could they be facing into the wall, rather than out of it?

1 Like
3

I checked and all normals point outwards.
Even after flipping them the problem still persists.

4

Hum. What collision solid (or solids) are you using for the player? And do you have a scaling factor applied to the collision of either the player or the walls?

1 Like
5

The player has two CollisionCapsules one for the body and one used for checking if a block is above the player when crouching. Two Rays one for gravity and floor collision and one to check what the player looks at.
A scaling factor is applied to the parent of the polygon collision.

6

Ah–what happens if you remove that scaling factor and simply make the object itself bigger?

1 Like
7

Sadly it still doesn’t work.
Removed the scaling, tested on simpler geometry (a box), tested with normals inside and outside.
Still teleports/traps the player.

8

Very strange. What happens if you replace the player’s capsule with a sphere? Perhaps there’s an issue with capsules colliding into polygons.

1 Like
9

Yes. Same problem with the sphere.
I used the Pusher Example from the documentation and loaded the collision from my model.
Same problem.
I could write my own ‘pusher’ with a collision queue.
Not the optimal solution of course.

10

Odd indeed! It might be worth waiting to see whether anyone else has any ideas–perhaps there’s something that you and I are missing!

1 Like
11

Yes, I’ve been on this for a while now. Should take a break.
Thanks for your help up till now.
Here is the test program and my egg file:
tests.7z (1.5 KB)

1 Like
12

It’s not a solution for your particular case, but I have taken your program and shown how this kind of interaction could be modeled. Check it out here: tests.zip (50.8 KB)

I wouldn’t say it’s recommended to use an Interval combined with collision modeling. This is basically guaranteed to fail, in my experience. It’s better in many cases to use the Task system to apply increments, if you’re going to be collision modeling dynamic objects.

maze_bounce
maze_bounce797×633 23.4 KB

You can see (especially if you run the file I provided) that the sphere drops down onto the center of the maze, bounces off into the gap a bit, and then jiggles on the floor without passing through. This looks like natural behavior, to my eye.

All this said, it occurs to me that there may just be something wrong with the .egg file you provided. I can’t really check this out without the original model, and even then I may not be able to determine what the case may be.

This is what happens when the program is run with your original Interval format with this known good maze model:

maze_bounce_2
maze_bounce_2795×633 53.7 KB

Basically the same interaction occurs – the sphere descends toward the middle of the maze, bounces off into the gap, rests without jiggling on the floor, but only for a few moments, and then disappears through the floor.

1 Like
13

Ah, I think that I’ve found the problem! And it’s pretty much as Simulan says, above.

To start with, intervals aren’t really suited to cases in which their action might be interfered with (as by a collision-handler), I think.

And indeed, even with an obstacle-model that doesn’t itself cause problems (see below), the use of an interval results in the moving object bypassing the obstacle anyway, from what I’ve found.

As to the obstacle-model, I found that replacing the cube-model with one of my own resulted in the collision response becoming less glitchy.

Investigating the provided egg-file, I found that the polygons were declared to have the “BFace” tag. And removing that tag once again significantly improved the collision response.

As far as I can tell, the tag in question results in polygons being made double-sided. I’m guessing that this is resulting in each polygon being represented by two polygons, one facing the expected direction, and one facing the opposite direction.

As a result, when a collision-object collides with it, that collision-object likely collides with two polygons, each facing opposing directions, and thus each pushing the object in opposing directions. This, I think, results in much of the glitchiness.

Thus, it seems likely that the problem is twofold: a problematic model, and the use of intervals in a situation that involves using a pusher to stop the object being moved.

(Quite why the model ended up with “BFace” tags I don’t know. It might be that, in the modelling package, the mesh has some attribute enabled that is resulting in this–a check-box labelled “two sided”, or some such thing.)

2 Likes
14

After looking into it, I found out that in Blender 2.8 and above, BFace is enabled by default.

Deactivating BFace does make it less glitchy.
But like you said it still has some problems.

What would you do to fix the interval problem?
I am not sure if i understand the problem completely.
I am thinking to fix this I could implement the function of a pusher with intervals or make movement work over events.

1 Like
15

In short–and presuming that I have it correct myself–the problem is thus:

A position-interval moves a given NodePath from a starting-point to and ending-point. In order to do this, it simply places the NodePath at successive points further and further along the line between those start- and end- points.

This means that even if the NodePath collides with something, the interval will simply place it at the next point along regardless. Eventually that “next point” might be on the other side of the obstacle, and the NodePath will move on.

Myself, I simply wouldn’t use intervals for this purpose.

Instead, I’d suggest creating a task (or using one that you already have, as appropriate). In that task, I would suggest updating the object’s position such that in each frame it’s moved a small distance from its previous position.

Since the movement is relative (and since it’s slow), when the object collides with something and is pushed back, it should on the next frame move from that new position. As a result, collision should in general stop it as expected.

(Where an interval would just place it at the next point at which it’s “supposed to be” between the given points.)

16

Here is what i found after some more debugging:

  1. BFace needs to be deactivated (as said before)
  2. CollisionCapsule does not work properly with CollisionPolygon.
  3. It is possible to glitch trough connected polygons if their angle is obtuse enough.
  4. It is easy to “fall through the floor” because polygons making up the bottom of a shape have normals pointing downwards. This can be fixed by deleting the floor or by making it smaller then the actual object.
  5. CollisionSphere can glitch between two BoxCollisions.

I am taking a look at the bullet physics system now.
I hope it can work better for my program.
Thanks for all the answers.

1 Like