www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: AGP on May 04, 2014, 02:02:12 am
-
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;
}
-
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.
-
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)?
-
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.
-
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 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.
-
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?
-
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).
-
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.
-
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:
(https://dl.dropboxusercontent.com/u/93826015/Torcida_Idle0000.png)
-
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).
-
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)?
-
Depending on the mesh's complexity, it might help to use an OcTree for collision detection (not rendering).
-
What about my mipmapping question?
-
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.
-
Here's the problem I'm having with the collision-detection against the ball only working the first couple of times. As the video shows, even when the collision against the ball stops working, the collision against the other players works.
https://dl.dropboxusercontent.com/u/93826015/java%202014-06-28%2004-23-58-66_x264.mp4 (https://dl.dropboxusercontent.com/u/93826015/java%202014-06-28%2004-23-58-66_x264.mp4)
-
What exactly are you using for player-ball collisions?
-
This:
SimpleVector direction = collideWithBallEllipsoid(new SimpleVector(selectedPlayer.getRoot().getZAxis().x*-.5f, selectedPlayer.getRoot().getZAxis().y*-.5f, selectedPlayer.getRoot().getZAxis().z*-.5f));
ball.direction.add(direction);
private SimpleVector collideWithBallEllipsoid(SimpleVector playerDirection) {
SimpleVector direction = selectedPlayer.get(0).checkForCollisionEllipsoid(playerDirection, new SimpleVector(1f, 4f, 1f), 3);
if (direction.equals(playerDirection))
return SimpleVector.ORIGIN;
else if (!direction.equals(playerDirection) && !ball.ball.wasTargetOfLastCollision()) {
selectedPlayer.collided = true;
return SimpleVector.ORIGIN;
}
direction.y = 0.00f;
return direction;
}
-
So the ball gets the correctly player direction assigned to it? If that's the case, what happens to the player then? Ellipsoid collision detection is a collision avoidance algorithm. It can't handle the case that a collision is present already when you call the method. So if it can happen that the player already insects the ball before the call, the results won't be great. To be honest, i wouldn't use this kind of collision detection at all for this kind of problem but some heuristic method based on positions and movement instead.
-
OK, thanks, but first things first: isn't it a bug that after a couple of successful collisions the collisions stop working altogether?
When would you use actual collisions? And which type of collision-detection would you prefer?
-
No, i don't think it's a bug. As mentioned, the idea is to correct the translation vector of the colliding object in a way that the collision doesn't happen and the method is actually really stable in providing this. You actually don't use it that way but you apply the translation to the obstacle instead to move it out of the way if i got that right. I think that this might cause the problems that you see, albeit i'm not entirely sure what's going on exactly. It might be the case that the player would actually climb onto the ball but because you apply the translation to the ball instead but without the y component of the translation, the player might move into the ball...or something similar.
However, ellipsoid collision detection is the most tested method in the whole engine and you can be pretty sure that it works the way it's intended to. I know that this sounds stupid, but if it doesn't work then you are either doing it wrong or you are using it in a way in which it's not meant to be used.
About the alternatives...i'm not sure...i would try something based on ball and player position, player direction and radius.
-
Egon, I'm in dire need of that World.getScaleInWorldspaceUnits() (or so) method about which we talked. Would you be so kind as to implement it before your next release?
-
I'll look into it.
-
Please give this jar a try: http://jpct.de/download/beta/jpct.jar (http://jpct.de/download/beta/jpct.jar)
it adds a getBounds() method to World. The parameter allows you to limit the calculation to visible objects only (true) or all (false).
-
Awesome. Thanks a lot, pal.
-
The first thing that I noticed is that the jar is 5 KB smaller than the previous latest version. And is it possible that it got a little slower?
-
No idea why it's smaller. Might be that i built it in another way the last time. It shouldn't be slower. Performance sometimes slightly changes between versions because of different memory alignment of the code and stuff like that. There's nothing you can do about that.