Hi all,

we just started using JimmyRIG (http://www.origamidigital.com/typolight/index.php/what-the-rig.html) to automatically rig and animate models using free mocap data which works quite well (it's the only tool I know that does this, anyway...).
I animated a free model from Turbosquid which has ca. 30000 faces and ca. 180 keyframes that JimmyRIG exported. I imported it into MED as an FBX file and the frames etc. look alright.

However, when I use the model as a player model with a WALK animation in a very simple environment, the framerate goes down to 3-4 frames (on a decent PC that can run recent commercial games without problems).

Of course, I would reduce the polygons for using the model in an actual game but I would have thought, that 30k faces should not be a problem (there were no other MDLs and only a few blocks in the level). Therefore, I am wondering whether a single model should not have that many polygons or whether I need to reduce the number of keyframes.

You can download and test the animated model at http://www.woofiles.com/dl-208646-dZiNvEZ6-SamusHIGH.mdl.

I would be grateful for any hints on how to use these models in a game project and avoid these performance problems.

Thanks and best regards,

Stefan

that's probably a bug in your script, not the model. 30k polys should not be a problem.

So it will probably more helpful if you upload that simple environment and your script.

Thanks for the hint. I'll try to upload the whole scene (only a few objects and some basic setup code) tomorrow.

However, I tried replacing the model with the sf_women.mdl file that Gamestudio provides and also with another animated model (ca. 2000-3000 faces) in the same script and the frame rate is perfectly normal...

I would be grateful for any suggestion based on the example scene since the workflow with JimmyRIG is exactly what we are looking for (we're using Gamestudio in an undergraduate game design class).

Cheers,

Stefan

Most games aren't very CPU intensive since the stuff that runs on the CPU generally isn't scalable (essential gameplay and logic), and their minimum requirements need to be fairly low.

Point being, animation is by default performed on your CPU, and animated vertex counts will have a direct effect on your performance, and your CPU probably isn't very fast (even if your PC can handle beastly games).

Use a bones-animation shader to move animation onto the GPU. Look up matBones in the manual.

Jibb

btw that model is not 30k faces, it has all lod steps in single model and has alot overlapping model parts.

Here is more food for thought...
Your avatar is being rendered in a game engine therefore your animated model is sending rays in an effort to locate itself pertaining to collision detection....
When you have a large number of verticies that look for collision this causes the frame rate to drop conciderably... (At least as I have noticed....) Also... in the new 3dgs versions it is almost manditory to surround your entire game area with a hollow cube.... that helps with that ray/ collision detection... by shorting the rays... I guess... you can make the hollow cube invisible too....
Anouther thing you can do is reduce your texture size as small as possable but maintain quality... I use .dds images they help a great deal too....
Best of luck...

Each LOD of the model has 100% of the first LOD.
30.000 faces animated versus not animated makes big difference in performance.
The model is way to highpoly and not worth to be used.
As Quadraxas mentioned, many overlapping faces.
A good modeler could make it with 1.500 faces.
Look for a better model and try it again.

Thanks a lot for the very helpful comments (I didn't get notifications about further replies, that's why I just read them...)!
I guess the problem really is the model which is a relief because it was just a random downloaded humanoid model for testing.
Moreover, I just found that the FBX import allows for reducing the number of frames per second so that instead of using all 40 frames of a JimmyRig walkcycle I can only use 6-8 which makes things tidier.
Thx again for the clarification.