Collision Trouble

Started by AGP, May 04, 2014, 02:02:12 AM

Previous topic - Next topic

AGP

I'm trying to have my character collide against walls without getting stuck or ever going through them. The following code is problematic. My question is broad, I know, but maybe I'm doing something wrong...


     private SimpleVector collide(SimpleVector directionToHead) {
silmaria.collisionObject.setVisibility(true);
SimpleVector direction = hero.get(0).checkForCollisionEllipsoid(directionToHead, new SimpleVector(.15f, 2f, .15f), 5);//.5f, 2f, .5f), 5
silmaria.collisionObject.setVisibility(false);
if (directionToHead.x != direction.x || directionToHead.z != direction.z) {
     collidedThisFrame = true;
     float multiplier = -2f;
     if (currentAnimation == WALKS)
multiplier = -3.5f;
     direction.x = multiplier*directionToHead.x;
     direction.z = multiplier*directionToHead.z;
}
else collidedThisFrame = false;
return direction;
     }

EgonOlsen

You world setup seems to suffer from some "tiny scale syndrom"...with an ellipsoid this small, chances are that floating point errors and inaccuracies add to up to some jittering or similar problems. You might want to increase the size of everything. If that's not possible, try to adjust Config.collideEllipsoidThreshold to a lower value and see if that helps.

AGP

I'm going to play around with this tonight. You seem to have approved the idea of making a World.getFullBounds() or some such method (for informing us, in world units, the size of our scenes). Have you gotten around to making this?

Also, for that soccer test I'm making, how do I get the direction in which the player kicked the ball (the exact direction of the collision with which to translate the ball)?

EgonOlsen

No, i haven't done anything like that yet. To be honest, i forgot about it.... ::)

About the direction...i'm not sure. I don't think that this really relates to a normal collision detection. I would rather implement it as part of the game physics, which in case of a soccer game, i don't feel to be covered by a "simple" 3d collision detection.

AGP

OK, let's say I do it as part of the game physics. How could I even get the direction of the kick (maybe that's more of a Bones question...)?

AGP

I didn't mean the direction that the player is facing, by the way. I meant the direction his foot is going at the moment of the collision.

EgonOlsen

Quote from: AGP on May 27, 2014, 08:26:41 PM
OK, let's say I do it as part of the game physics. How could I even get the direction of the kick (maybe that's more of a Bones question...)?
I would simply try to approximate it. He will always kick into the same direction (relative to his body) or doesn't he?

AGP

Always the same direction is fine. But how could I differentiate between different kicks if not by the angle of the collision (which, I suppose, would be a function of the distance between the player and the ball).

EgonOlsen

Yes, something like that. Maybe based on the angle between the player's direction and the direction vector from the player to the ball or something like this.

AGP

I'm having two collision-related problems in the soccer game. The first one is a huge performance hit. The second one is that I made it so that when the player walks up to the ball a force is added to the ball in the direction in which the player is headed. It works for the first couple of times but if I keep running in the ball's direction I will eventually go through it.

By the way, the crowd's transparency looks horrible in hardware. The following texture (first frame of several, obviously) looks far from opaque:


EgonOlsen

What kind of performance hit? Who is colliding with what and where does the performance drop happens?
About the texture: Setting it to a higher transparency value should fix this (try 100 or 200 for example).

AGP

I think that the performance hit actually took place when I switched to hardware, not with the collision, after all. Now that I'm calling compileAndStrip() on everything, I'm getting distinctly better (if still mediocre) performance.

By the way, what kind of a hit could I expect if I disable mipmapping for all textures (and there's a couple of dozen at 1024x1024)?

EgonOlsen

Depending on the mesh's complexity, it might help to use an OcTree for collision detection (not rendering).

AGP

What about my mipmapping question?

EgonOlsen

Hard to tell....it might go from a pretty big hit to none at all. It highly depends on the hardware and the bandwidth available to the GPU.