checkForCollisionEllipsoid() framerate drop

[K24A3]

Basically I'm trying to increase the frame rate as much as possible.

I'm using checkForCollisionEllipsoid to collision check the main character but it's dropping the frame rate down from 60FPS+ to about 30-35 FPS, even when using the lowest recursionDepth of 1.

The checkForCollisionEllipsoid frame rate drops even when there are no COLLISION_CHECK_OTHERS objects nearby (they are visible though), does checkForCollisionEllipsoid do any object/mesh distance filtering before calculating using ellipsoid collision?
Perhaps the function could be modified to do a translation/boundingbox distance check before focusing on the ellipsoid precision.
The function seems to be based on the visibility of objects since the framerate dropped as soon as the objects were visible.

I tried using three checkForCollisionSpherical() checks which helped considerably, the frame rate was around 45-50FPS. However I would like to improve the FPS a bit more if possible


Perhaps a new checkForCollisionDualBox() function can be introduced that does dual-box calculations?
i.e. the function would parse two boxes, one large/main box to cover the main body, and another smaller box to cover the head and feet.
checkForCollisionDualBox(SimpleVector translation, SimpleVector box1size, SimpleVector box2size)

[Thomas.]

Checking collision is very expensive for CPU, for improve frame rate you can divide level geometry and create special object for some complicated geometry (for example you do not need checking collision of your character with car that has thousand triangles, but is easier checking collision with only simple box) ... in this time, my game has something around 20 thousand triangles and is running 50-65fps (I used more optimalization, but creating a map takes much more time)
edit: firstly is used AABB, after that if it makes sense is calculating collision with real geometry... Egon, please correct me if it is not

[EgonOlsen]

edit: firstly is used AABB, after that if it makes sense is calculating collision with real geometry... Egon, please correct me if it is not

Yes, that's the way it works. Collision detection has absolutely nothing to do with objects' visibility on screen. I'm not sure why this should cause such a huge drop unless you are using a large amount of objects...are you? Does it slow down further, if you increase the recursion depth? If it does, there have to be some intersections between the ellipsoid and the bounding boxes.

[K24A3]

@Thomas, I am using my own code to set objects invisible (using Object3D.SetVisibility) if they are not in the camera's bounding box. Plus I am recycling objects so they respawn in front of the camera when they are not visible.

@Egon, I have about 32 objects set to _OTHERS, but only about 16 are within the immediate area at any time. And those objects are quite far away most of the time, with only 1 or 2 objects very close to the camera/player (say 50 translation units). I could have 16 objects 1000 translation units away, but the ellipsoid function still processes them.

It makes no difference if the objects are visible in the camera frame or behind the camera.

I removed the skydome and removed various objects to check if an object has strange geometry or something, but it made no difference. The frames drop further when there are more objects nearby.

I think there might be a bounding box glitch in the checkForCollisionEllipsoid function because the Sphere function is not dropping frames much at all.
I tested each one at the same location in a frozen state:

45FPS = No collision
41FPS = Sphere collision
31FPS = Ellipsoid collision (1 recursion)
31FPS = Ellipsoid collision (5 recursion)
31FPS = Ellipsoid collision (50 recursion)

Does the Ellipsoid function use the same bounding box filtering as the Sphere function?


Edit: Here's the collision calling section:

Code Select Expand


SimpleVector vcoll = new SimpleVector();
if(nDebug == 0) vcoll = newpos;
if(nDebug == 1) vcoll = player.checkForCollisionSpherical(newpos, 2f);
if(nDebug == 2) vcoll = player.checkForCollisionEllipsoid(newpos, new SimpleVector(2f,2f,2f), 1);
if(nDebug == 3) vcoll = player.checkForCollisionEllipsoid(newpos, new SimpleVector(2f,2f,2f), 5);
if(nDebug == 4) vcoll = player.checkForCollisionEllipsoid(newpos, new SimpleVector(2f,2f,2f), 50);



[EgonOlsen]

The bounding box calculations are fine. Otherwise, you would get a massive drop in frame rate when going from 1 to 50 as recursion depth. The calculations differ between spherical and ellipsoid detection, because the ellipsoid one has to happen in ellipsoid space, which requires some transformations on the bounding box. In addition, it happens multiple times for each detection because it's a swept algorithm. However, i'm wondering why the drop is so huge in your case...which version of jPCT-AE are you using and on which hardware?

[K24A3]

I'm using the latest version (1.23) on a 1GHz Tegra 2 Tablet.

The frame drop happens on a DesireHD as well. With 20 objects in range (only 2 close by), I get these framerates:

23FPS No collision
20FPS Sphere
15FPS Ellipsoid

[EgonOlsen]

Are you using cloned or deserialized objects for this? If so...there was a flaw in build() that caused the bounding box of these objects to be ignored under some circumstances (has to bang my head against the wall for this one...). If so, try this version instead and see if that helps: http://jpct.de/download/beta/jpct-ae.jar

[K24A3]

Yes 90% of the objects are cloned using Object3D.cloneObject() after loading the original ones from 3DS files.

I will try that beta version later today, thanks.


Edit: I'd like to add that the framedrop seems to happen mostly at the (0,0,0) world location so perhaps the bounding boxes of cloned objects are not being translated or updated.

[EgonOlsen]

Edit: I'd like to add that the framedrop seems to happen mostly at the (0,0,0) world location so perhaps the bounding boxes of cloned objects are not being translated or updated.

No, they are just not going to be evaluated. The new jar should fix this, which should also improve rendering of such objects when not in view.

[K24A3]

Installed the Beta and it made a huge improvement!

The Ellipsoid function barely causes a framerate drop now (if at all), plus overall rendering performance has more than doubled. I even tried placing 128 objects in the scene and the frame rate is surprisingly maxing out at 60FPS most of the time.

That's the performance I was looking for, thanks

[EgonOlsen]

This was a really stupid bug that remained unnoticed for months. My test case for collision detection simply didn't cover this and as long as most objects are in sight, you don't notice the reduced rendering performance either.

[neo187]

Hi Egon

Sorry to re open this, but I am having the same issue. That's most likely due to the phone I am using for development which is quite low end (600 Mhz CPU, 256 MB RAM, v2.1) but basically when activating the Elipsoid collision detection the frame rate drops from 30FPS to 18-20...

The model I am using is roughly 1800 vertices with 4 frames of animation, and the world has got around 20 models, all very low poly, only 5-10 of which are set to collision_check_others (I too noticed that reducing the amount of these or simply the amount of visible objects makes quite a difference)... and the recursion depth I am using is only 1. The objects are all stripped loaded from serialized files....

Is there any other step I could try to improve the framerate while maintaining the ellipsoid collision?

Thanks a lot

[EgonOlsen]

If it's a 600 Mhz thingy, it's most likely something like the G1 uses. Which means that it has no fpu and does all floating point calculations in software emulation on the cpu. I don't see much room for improvement. I can upload a new jar tomorrow that includes some additional performance tweaks for ellipsoid collision detection, but i doubt that it'll help much.

[neo187]

Thanks for your prompt reply. Yes it's a very skimpy thing, so I thought as much... I need to get a better one... However I can see now that the keyframe animation plays a big part in it, disabling it while keeping the ellipsoid detection gives me 25FPS instead of 18 which, for this device, I think it's quite good...

Can the animation be optimized in any way? Does the number of frames affect performance? Currently I'm stripping all the animations...

Thanks for your prompt help.

[neo187]

P.S.

If you did find the time to upload that optimised Jar I'd really appreciate it! So I could let you know if it does make a difference on performance on low end devices such as mine...


And Number 2: how do you handle animations and variable frame rate? Do you always advance the animation by a fixed increment regardless or do you modify it with the delta time? I'm guessing that both ways there will always be a bit of stutter.....

Thanks very much for your time Egon!