www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: Thomas. on December 31, 2010, 10:56:49 pm
-
Why is ellipsoid camera collision so slow? I tried checkCameraCollisionSpherical and game is running stable 54-55 fps but if I use checkCameraCollisionEllipsoid frames drops to 17 fps
-
Simply because it's much more demanding. You can play around with the recursion depth to tweak it a little bit.
-
it is extremly demanding, I have same result with number 1 or 5 on recursion depth... and collide offset is sets to 40
-
Well...yes. It's much heavier on the fpu (or its emulation on older devices), because it has to transform vertices of objects in question into ellipsoid space, which can be expensive on Android. What's the exact scenario in which you are using this? If it's a rather complex and huge mesh (like a level), you might want to try to use an octree for collision detection. Or you can use a alternative, simpler mesh for collision than for rendering. To do this, simply make the simple one visible and hide the complex one, do the detection and reverse the process again for rendering.
-
I see... I am doing first person shooter game... the "main" object has not so much polygons, but almost every object in level has about 500 polygons and those are a lot of... I will try to do another system for check player collision ...
-
Polygon count matters only if an object is the way of the translation of the ellipsoid. Everything else will be discarded pretty quickly by a bounding box check.
-
Thanks for explanations :) ... I want to do everything the most modifiable, so alternative simpler mesh can not be and check collision spherical is doing issue...
-
My game is much more complicated now and I want to use alternative objects for collision... but when I use obj.setVisibility(false) object is not visible, but also is not calculated for collision... how can I set object just for collision? and why jPCT-AE is not supporting for portals?
-
You have to toggle the objects, i.e. make the collision objects visible, do the detection, make them invisible again. Or use another world that only stores the collision meshes.
-
thanks, what will be faster world or toggle? or it is same?
PS: I have tested toggle now, but this collision running in another thread and object is blinking
-
Then either opt for an additional world, sync the rendering with the collision detection or don't do it in multiple threads. Doing this in multiple threads is asking for trouble anyway IMHO. I wouldn't recommend it.
-
this collision is from touch event thread
-
the touch event itself is also pretty demanding,
I dont know if you have already done so, but adding a Thread.sleep(25); to the touch method might help a little bit..
-
this collision is from touch event thread
Don't do this...doing the collision detection and especially transformations in parallel to the rendering thread is asking for trouble. I quote myself: http://www.jpct.net/forum2/index.php/topic,1994.msg14695.html#msg14695 (http://www.jpct.net/forum2/index.php/topic,1994.msg14695.html#msg14695) and http://www.jpct.net/wiki/index.php/Multithreading#Thread_safety (http://www.jpct.net/wiki/index.php/Multithreading#Thread_safety)
-
Are possible to do some objects for collision by player "body", some objects for shoot, some for enemies,... ?
PS: solved
-
So, work on collision system for switching rendered objects and objects for check collision is finished, but... when I moving with player method sets for rendered objects visibility(false) and for collision objects visibility(true)... but it has not any affect to check collision time... where could be the problem?
edit: I was looking on fps... improve 2ms when I hide all additional objects from map (12/10ms)
-
Which problem exactly? Collision detection is expensive only if a collision happens. For objects that can be discarded quite early, because they aren't in the translation path, it's pretty cheap. Not checking for these objects doesn't do much. The idea of using special objects for collision is to use a simplified version of them for that. That will improve performance but only if there actually is a collision with that object. The bounding box check that happens before doesn't care about the complexity of the object. Maybe the collision detection with the level geometry itself consumes most of the time?
-
yes, collision with level geometry takes about 5ms... geometry will splited to many rooms, it could help :)
-
You might want to try to use an octree for collision detection (not for rendering). If that doesn't help, using separate objects won't help either.
-
geometry is splited, collisions takes 8ms (ellipsoid for player and spherical for gravity)... how to slide with player along a wall?
-
That is part of the collision detection, if you using ellipsoid. Just use an iteration depth larger than 1 and will happen automatically.
-
higher values are doing problems, camera can go through some objects, stop and oscillate in objects...
-
Try to play around with it the value (it doesn't have to be very high...3-5 should be sufficient) as well as with the threshold setting in Config. Also have a look at the fps example in the desktop distribution.