www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: Thomas. on September 21, 2012, 06:49:40 pm
-
Egon, could you check if the CollisionEvent.getFirstContact() is right when you use World.checkCameraCollisionSpherical(SimpleVector, 10, 1, true)? I think returned SimpleVector is bad in my game.
-
The docs say:
If the algorithm is spherical collision detection, this isn't the first point but the end position (caused by the way this algorithm works).
Maybe that causes the confusion?
-
I know about this. If collided plane is under camera, y of returned SimpleVector is every same as camera position. Is it right?
-
It might be...looking at the code, i don't see anything wrong. If the the camera is about to move inside the plane and it's distance from the plane is the radius of the sphere, then it will be adjusted to hover above the plane in the distance of the radius. And the fist contact vector shows this. What are you using it for anyway? For FPS movement, ellipsoid is way better.
-
I have camera with radius 10. I expect if camera collide with plane that is under, returned y of vector will be camera position + <0; 10>. Y of returned vector is same as camera position, but direction length is <1 and speed is 1, so it does not make sense for me... Spherical collision is for underwater moving. And FPS movement... from my testing ellipsoid is good when all objects in the scene are least as height as ellipsoid's half height, otherwise it causes a lot of unexpected things. Could you implement capsule collision detection, please? when you take a minute off... I offer bribe in the form of some model for your game ;)
-
I'm not sure if i understand exactly what you mean...a drawing might help.
Regarding collision detection: Sorry, but i'm not going to add any other means of collision detection and i'm not sure what the problem with ellipsoid collision detection should be!? It's the only approach that lets you climb stairs or obstacles reliable. It might be needed to tweak the parameters to match your scene though. It might also be unwanted that it collides with the actual geometry of the collision target but in that case, you can use collision meshes instead (there's no build-in support for this, you have to code it yourself), i.e. a simplified mesh that is used for collision detection only. In my RPG thing, i'm using this for fences and NPCs to prevent the player from climbing up on NPCs... ;) I simply have an option in my views to enable collision meshs. In that case, i calculate a bounding box of the mesh and add it as a child. Before a collision detection, i set the object to invisible and the collision mesh to visible, do the collision detection and reverse the setting.
-
Length of direction is smaller than 1. Camera radius is 10. Speed is exactly 1. Slide is on (true). What does not make sense to me -> returned contact is as high as camera position.
(http://s13.postimage.org/isefvoln7/spherical_camera_collision.jpg) (http://postimage.org/image/isefvoln7/)
I'm using different mesh for rendering, movement, shot and interaction for maximal speed. But if you use ellipsoid collision detection for movement and any of objects will be smaller than position of ellipsoid, camera sometimes jumps on the object, sometimes comes into the object. I tried a lot of combinations for tweak ellipsoid collision, but nothing was correct. You can try it. And BB as collision mesh, is not the best way for indoor scenes.
-
Length of direction is smaller than 1. Camera radius is 10. Speed is exactly 1. Slide is on (true). What does not make sense to me -> returned contact is as high as camera position.
That's what the docs say: ...but the end position. The end position is the position of the sphere's center after resolving the collision...which is 10 units away from the plane.
I'm using different mesh for rendering, movement, shot and interaction for maximal speed. But if you use ellipsoid collision detection for movement and any of objects will be smaller than position of ellipsoid, camera sometimes jumps on the object, sometimes comes into the object. I tried a lot of combinations for tweak ellipsoid collision, but nothing was correct. You can try it. And BB as collision mesh, is not the best way for indoor scenes.
Well, use whatever suits your needs best. I just don't understand the problem here. I used ellipsoid collision detection on outdoor, indoor and whatever scenes and it worked fine all the time. The only drawback is that sometimes you start to climb objects that you don't want to and i usually solve this by using collision meshs as described in my previous post.
-
OK, tomorrow I'll do some example of my problem. And about spherical, now it is clear, I just understood end point differently ;)
-
I finally found some time and created a test application for the ellipsoid collision.
http://dl.dropbox.com/u/26148874/Collision%20test.zip (http://dl.dropbox.com/u/26148874/Collision%20test.zip)
-
Of course it gets stuck that way...your code ignores the y-vector of the corrected direction vector by setting it to 0. That way, the ellipsoid can never climb the obstacles and runs into them. And once it does that, ellipsoid collision detection can't resolve the situation (even more because y will still be set to 0). Just remove the temp.y=0; line and will work better.
-
Thanks, it helped, but still is not right. Ellipsoid is not moving smooth.
-
No idea what you mean...i never ever use anything else and it works just fine!?
-
You can try remove temp.y=0 line and see what happens. You can set Config.collideEllipsoidThreshold by touch turn up/down...
-
I did remove the line...i've no idea what should be wrong. Looks fine to me.
-
Replace this line
SimpleVector direction = new SimpleVector(1, 0, 0.5f);for this
SimpleVector direction = new SimpleVector(1, 0, 0);
It should be the same, right? Ellipsoid collides with wall at left side (in front of the camera), so speed should be approximately same in both cases?
-
I see what you mean, but i don't see the problem with that behaviour. With that additional translation, you are moving the ellipsoid right and into the back wall at the same time. The resulting translation vector reflects that. It might be a little shorter in total than the initial vector because of the threshold and the recursion depth and maybe some inaccuracies in the process, but i don't see why this should be a big deal. It's an artifical problem...if you use this approach in a fps game (take a look at the fps example for example), you won't notice any problems of that kind.