Animation benchmarks

[idkm23]

I am currently doing skeletal animation on one joint with no other motion on the model and experiencing about 5 fps. I am only rendering about 1500 polys. I started with 3000 and have been simplifying my model more and more. I am running this on a smart eyeglass with a 1.5GHz processor and 1 gig of ram. Is this many polys unrealistic given my situation? I figured going this low would let me run it smoothly but this is not the case. Also, if it matters at all, I am texturing the character with a tga file. I appreciate any information, thank you.

[EgonOlsen]

I would expect it to run faster. How does it perform when you omit the actual animation and/or touch calls?

[idkm23]

Currently I am measuring 30 fps with no skeletal animation. If I apply a rotation to one joint and update it for every draw call then I am measuring 7 fps. I also forgot to mention the processor is dual-core. When I monitor the CPU load in android device monitor the cpu has 2/3 of the chart filled with my process and the remaining mostly idle. Also, what do you mean by "touch calls"? If you mean touch listeners, I disabled them on my views and there was no affect.

[EgonOlsen]

No, with "touch" I meant this: http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#touch()...but I guess that Bones does it automatically, so there's no way to omit it without modifying Bones.

Looking at this Smarteyeglass device, I somehow doubt that it is very powerful, so maybe the results reflect the actual power of that device. It might not even run @ 1.5Ghz under heavy load. 7fps is almost half of 15, which itself is half of 30. The device might by limited by vsync as well, so that, if it can't reach 15fps, it refreshes at 7.5fps instead, even if it could actually render 14fps (there's no way around that BTW...).


I would try to add some timing code around the actual animate()-call to see how that performs. If that's not the bottleneck, then the upload to the GPU is (which you can omit by not calling touch(), hence the idea).

[EgonOlsen]

Oh, and maybe you want to play around with http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#forceGeometryIndices(boolean) and see, if that changes something to the better or worse.

[idkm23]

I think I misled you when I said 'smarteyeglass' I wasn't referring to sony's product, but these glasses: http://developer.osterhoutgroup.com/wp-content/uploads/2015/12/R-6-TechSheet-8.pdf
I was using it as a general term. I will look into your other comments, thank you.

[EgonOlsen]

I see...it's pretty unlikely that such a device will run at full speed all the time because of cooling and battery runtime.
How does the 3D view works? Do you have to render the image twice?

[idkm23]

That is an interesting thought. I don't believe they have to render it twice, though. There is a projector for each lens which displays the exact same image.

[idkm23]

Small update:
I measured the time between frames and then the time it took to do the skeletal animation of one joint and here are the results,
Time to perform the onDraw method of my view: 80ms
Time to perform the skeletal animation that is run within the onDraw method: 75ms

This is the function taking ~75ms to perform:

Code: [Select]

public synchronized void update(Matrix rotation, int selector) {

        skeletonHelper.transformJointOnPivot(selector, rotation);

        skeletonHelper.getPose().updateTransforms();
        skeletonHelper.getGroup().applySkeletonPose();
        skeletonHelper.getGroup().applyAnimation();

    }

[EgonOlsen]

Seems to be a really slow device then. Neither the rendering nor the calculations are particularly fast. I don't see what to do here other than reducing mesh complexity even further. One option would be to modify Bones, so that it does the skinning process on the GPU instead of on the CPU. But given the performance characteristics of this device, I don't think that it would be worth the trouble.

[EgonOlsen]

...but are you 100% sure that you mesh has only 1500 polygons. The device may be slow, but these performance figures really puzzle me. My trusty 800Mhz single-core in my first Android device from 7 years ago would be faster than this...

[idkm23]

So I moved the skeletal animation to another thread and now I am getting 32 fps, but on the thread that is performing the skeletal animation it takes 61ms to perform each so it still appears laggy. Here is the model I am using: https://goo.gl/Q9Aj8J

[EgonOlsen]

...sorry, but I can't open max files.

[EgonOlsen]

So I moved the skeletal animation to another thread and now I am getting 32 fps, but on the thread that is performing the skeletal animation it takes 61ms to perform each so it still appears laggy.

Yes, because you are just rendering the same frames over and over again without the animation having changed. You will get a slight benefit by doing this, because rendering and animating can happen in parallel but they actually do anyway for the most part, because the GPU can render in parallel to the CPU. And you will be rendering inbetween states of the animation this way, because there's no synchronization between the rendering and the animation. If there where, I doubt that you would get such a high frame count.

[idkm23]

So are we accepting that the issue is a weak CPU / too many polys for it? Should I just try and take out more polys again?