The Result of checkForCollisionEllipsoid gets me stuck.

[AGP]

Calling moveTowardsWithCollision gets my player character stuck. I can't increase the radius of the sphere but I have increased the recursion up to 4. It didn't help. Is the answer to simply increase recursion or should I do something else?

Code Select Expand


     private void moveTowardsWithCollision(Object3D toMove, Object3D towards, float amount) {
SimpleVector center = toMove.getTransformedCenter();
SimpleVector center2 = towards.getTransformedCenter();
SimpleVector direction = new SimpleVector((center2.x-center.x)*amount, (center2.y-center.y)*amount, (center2.z-center.z)*amount);
SimpleVector newDirection = collide(direction);
toMove.translate(newDirection);
     }
     private SimpleVector collide(SimpleVector directionToHead) {
collisionObject.setVisibility(true);
SimpleVector direction = hero.get(0).checkForCollisionEllipsoid(directionToHead, new SimpleVector(1f, 1f, 1f), 4);
collisionObject.setVisibility(false);
return direction;
     }


[EgonOlsen]

Try to adjust http://www.jpct.net/doc/com/threed/jpct/Config.html#collideEllipsoidThreshold. You might have to lower or increase it...it depends on the scene and the scale of your geometry.

[AGP]

Neither Float.MIN_VALUE nor Float.MAX_VALUE (nor lots of values in between) helped. Still getting stuck.

[EgonOlsen]

No, we aren't talking about such kind of values. Keep in mind that this value is the length of the movement vector below which the recursion will stop. Setting it MIN_FLOAT or MAX_FLOAT makes no sense at all. If the default is for example 0.5, try something like 0.05 or 0.01 or 0.005...that kind of values. Combine this with changing the recursion depth to maybe 3 or 5 and see if that helps. Also make sure that you don't start inside of a collision already. Sometimes, this might happen due to inaccuracies in the calculations. Try to lift the object a little before doing the detection. You'll have to implement gravity anyway to make the hero follow the terrain. How is your collision code ATM (brief description, i don't need the actual oode).

[AGP]

Entire collision code is in my first code. The "gravity" is handled with a simple call to calcMinDistance.

[EgonOlsen]

Entire collision code is in my first code. The "gravity" is handled with a simple call to calcMinDistance.

That might cause the problem. If you use a ray-polygon detection followed by an ellipsoid one, the result of the ray-polygon check might move your camera into a situation where the ellipsoid is already stuck in something when starting to move and ellipsoid collision detection isn't very good in resolving existing collisions. It's all about avoiding them in the first place. Try to replace your calcMinDistance-gravity by some that uses ellipsoids like the fps example does it.

[AGP]

Would simply alternating between calling calcMinDistance and testing for the collision each frame solve it?

[EgonOlsen]

I'm not sure what exactly you mean by that...

[AGP]

On one frame I would call calcMinDistance. On the next test for collisionEllipsoid. And so on.

[AGP]

I tested it and walked right through the walls, because I'm only testing half the time for collisions!

CalcMinDistance is by far the most intuitive way of following a terrain. Why not just improve checkForCollisionEllipsoid to consider calcMinDistance?

[EgonOlsen]

There is nothing to improve. The problem isn't related to both methods being used in the same iteration, it's related to the way they work. ray/polygon collision detection (calcMinDistance is nothing more than that) works for one point on the surface. If you take the distance to that point and adjust the hero accordingly, the ellipsoid that covers the hero extends far beyond that point in all directions and, depending on the terrains geometry, it might intersect with some geometry that is a few units away from the point but still in the ellipsoid's radius. There's not much you can do about it except using the same ellipsoid for gravity calculations.

[AGP]

What about a method that clears the results of the previous test?

[EgonOlsen]

That's not the point. The point is that your gravity calculation moves you into situations that can't be solved by the ellipsoid collision detection. There's nothing to clear or fix...they are just two collision detection approaches that don't mix very well.

[AGP]

OK, talk to me like I was a child. Every iteration I cast a ray downwards to determine the height of the current polygons on the terrain. You claim that this produces an ellipsoid that is somehow later re-used by checkForCollisionEllipsoid. Am I right so far? And, if so, why not just clear this ellipsoid so that I can make another collision test on the walls?

[EgonOlsen]

You claim that this produces an ellipsoid that is somehow later re-used by checkForCollisionEllipsoid. Am I right so far? And, if so, why not just clear this ellipsoid so that I can make another collision test on the walls?

No, that's not what i mean. It doesn't create anything. The methods are totally independant. But to adjust an entity's height based on the ray-polygon collision and then try to do an ellipsoid collision detection might fail like in this artful drawing:



As you can see, the ray won't hit the obstacle, but the ellisoid intersects with it. And that will make it stuck there. I won't always be as obvious as in this case though, but it illustrates the basic problem with this approach. But if you would use the ellipsoid in the first place, this won't happen because the entity will never end up like in the second drawing but it will hover on top of the obstacle.