World.checkCameraCollisionSpherical()

[hytparadisee]

Generally this method works without problem. But sometimes if my camera moves too fast, it will still bump out of walls/ceilings.

I'm sure this can be solved by changing some of the values in the parameters, so what to adjust?

FYI: Im using this version:

public boolean checkCameraCollisionSpherical(int mode, float radius, float moveSpeed, boolean slideMode)

[EgonOlsen]

The spherical-stuff is (unlike the ellipsoid variant) not a swept approach, i.e. it detects collisions within the sphere's radius at the end-point of the movement. It doesn't care about collisions in between, which may happen if the speed excels the radius. Try ellipsoid collision detection instead, it will cover this case.

[Melssj5]

This happens becausse the movement is more like a group of jumps than a continue movement, so if the jump if larger than the sphere diameter it wont detect the collision.

o       |

    o    |

      o  |

       o |

        o|

         | o

maybe this can be fixed using the sphere collision detection by simulating a big jump as a set of smaller jumps.

a speed of 20f can be simulated by 10 iteration of movements of 2f on speed. checking each time the collition. This should be done for each thread iteration.

[EgonOlsen]

maybe this can be fixed using the sphere collision detection by simulating a big jump as a set of smaller jumps.

Yes, i forgot about this solution. That's possible too, if spherical collision detection is needed for whatever reason.

[Melssj5]

Is there any use of the sperical one instead of an ellipsoid with the same values for the 3 radius?

If not, why not to change content of the spherical to innerly use the ellipsoid ont taking the radius and setting the x, y, z and z raddios, on that way the sperical can be done using the ellipsoid.

[hytparadisee]

Actually the problem is clear, because I couldn't find an ellipsoid version where the camera can slide. I will try to increase the radius first and see if it helps.

[EgonOlsen]

Is there any use of the sperical one instead of an ellipsoid with the same values for the 3 radius?

Yes, the algorithm is different so that the spherical one can push you out of collisions if they've already appeared (like when two objects insects right in the beginning of the calculation). The ellipsoid approach can't do this, it's there to avoid such cases.

[EgonOlsen]

Actually the problem is clear, because I couldn't find an ellipsoid version where the camera can slide. I will try to increase the radius first and see if it helps.

You may have to tweak collideEllipsoidThreshold and/or recursion depth. The ellipsoid approach can slide. In fact it slides even better than the spherical approach. Have a look in the "manual" for a more detailed comparision of the two.

[hytparadisee]

Alright, i still haven't solved the problem though, but i think i got some more understanding about the issue. My camera is not first person!!! . It is an orbiting camera, so when the camera orbits the object, the velocity is not around a simple axis. Then does it mean that i should use this version:

public boolean checkCameraCollisionEllipsoid(SimpleVector direction, SimpleVector ellipsoid, float moveSpeed, int recursionDepth)

Unfortunately im not specialized in maths stuff. How do I get the correct "direction" parameter, would it be camPos.calcSub(oldCamPos);

[hytparadisee]

Just did the test, but the problem is that the checkCameraCollisionEllipsoid that accepts a SimpleVector as direction doesn't slide my camera. But i will stick to the SimpleVector version atm cos my camera won't go off.

[Melssj5]

Does it works for small speeds? If so, then you can use the aproach I first told, by reducing the speed on sub speeds, is not fanci and may coplicate things but is easy after all.

[hytparadisee]

Nope, it didn't work. But I think it's my problem understanding the issue (Mathematically ).

Take a look at this graph:


When the cam is orbiting and finally meet a wall, it will slide towards the target. This one is already working. But the problem is when the cam continue sliding (until it gets very close to the char), it suddenly goes to the location where my red arrow is pointing to (i.e. return to the original orbiting track).

Actually the problem is not with the collision algorithm, but with the parameters. Firstly, in this case you cannot simple use a camera constant to define the direction because the direction is always not around an axis. Secondly, I dunno how to determine the speed in this case.

[halcor]

Try thicker wall and/or smaller speed.

[hytparadisee]

I think in karga this one was solved pretty well, it tries to move the cam closer to the avatar and at the same time lift the camera a bit up. Is that a home-brew solution?

[raft]

well, if i get you right, each frame you are moving camera starting from it's last position. the problem with this is, if camera ellipsoid is in contact with some polygons (like wall) it will get closer and closer to it each frame and at some point due to rounding errors jPCT will regard ellipsoid as slightly passed through otherside and eventually ellipsoid will pass through the wall. something similar happens when you pull down avatar for gravity each frame starting from its last position. for the gravity case, my solution is to take avatar slightly up (a safety height) then do the collision check for gravity. however this is harder for camera as there's no up direction there.

so what i do in karga for third person camera movement is: each frame i try to pull back camera from some position like avatar's head. pull back direction depends on both avatar's direction and camera's direction relative to avatar. this way if camera hits a wall it smoothly slides next to it. go next to a wall in karga in third person view and turn around, that effect is done by this

hope this helps
r a f t