Agonizing slowdowns...

Blitz3D Forums/Blitz3D Programming/Agonizing slowdowns...

OrcSlayer(Posted 2006) [#1]
Ok, here's a small (performance) problem of mine. Actually it's not that small, it's upwards of 40 FPS loss in the worst case.
1: I have a core "skeleton" mesh which has nothing but bones (pivots). It has 13 bones and nothing but a simple box (for some reason it didn't work without SOME mesh data), which I alpha out.
2: I attach the pieces of my armor mesh (13 total) to the appropriate bones. The total polycount is about 1300.
3: I animate the base skeleton mesh, which causes the pieces to move (obviously, since they are parented to the bones).

I figured this would be a great way to speed up the game, since there won't be any actual bone vertex manipulation going on, simply pivot rotations.

It sounded good in theory, but in my engine the results aren't much better than a 1500 poly model with 20-something bones. This just doesn't make sense, can anyone give me a clue as to why this is going so poorly?

I can have at most 2-4 characters on screen before I start getting slowdowns. At 10 the slowdown is up to 40 FPS, averaging closer to 30.


OrcSlayer(Posted 2006) [#2]
Ok, I believe I found out the cause...each of the 13 meshes will obviously have it's own surface...so I had an overload of surfaces.

So, I suppose the question is in order...can I somehow avoid the vertex manipulation problem (DX7 bone animation being so slow) while still having all pieces be in a single mesh and thus a single surface?


Stevie G(Posted 2006) [#3]
There's a single surface mesh manipulation library in the archives you could try but ......

As you mention - each body part has one texture & therefore one surface, to make single surface manipulation possible you'd have to make a larger texture with all the pieces in one and re-do all the uv's for each body part.

Even then, you would have to manipulate all the vertices a fair bit to achieve the same effect and this is sloooooow. It would probably be much worse in terms of speed than you already have and not worth the effort. I wouldn't recommend it.

I believe someone was working on a single surface animation library which was much faster than your standard animation techniques.. probably in the showcase but not released as yet.

Sorry I can't be of more help.

Stevie


Dustin(Posted 2006) [#4]
Welcome to the wonderful world of B3D animations. Just loading the bone structure shows the hit in FPS. My workaround (In Bad, Bad Bots!) is to limit the B3D animation to only the player and everything else (including robots) is handled by MD2 anims.

Here's a link to the thread that Stevie mentioned:
http://www.blitzbasic.com/Community/posts.php?topic=62559#698906
Not sure of the status but I would love to get my hands on this system!!! Dozens of animations with almost no performance hit.


OrcSlayer(Posted 2006) [#5]
Ok, I did some more testing...if I load the bones/animation set, but only one of the pieces (actual meshes), I can easily push 20 animated characters with no slowdowns.

Each piece I add results in fewer characters being possible, so it would seem the problem in this case is entirely related to surface count. Remember that the whole skeleton is loaded and animated, the only difference is how many meshes I attach to the bones.

However, oddly, if I load the complete mesh (which contains all the pieces in a test mesh, but still uses several textures) it still seems to behave as a single surface mesh, and I can still have upwards of 20 in view with no problems.

The test mesh is fully rigged, and loaded as an animmesh, by the way.

This is getting interesting...


Dreamora(Posted 2006) [#6]
Meshes attached to bones is not the problem

Vertices attached to it is the problem as the whole dynamic skin is done CPU side and needs to be transfered to the GPU for displaying.

So as long as you don't use vertex weight and bone based deformations (ie as long as you do the bone based animation that you could have done with X models as well), there isn't much of a problem.

As wel bone based animations aren't the problem ... its normally more the modeller that don't understand the difference from 3d rendering and games and create the models for games like they do their 3d rendering models which tends to create some serious problems. (50 bones are at least 30 too much on most models, 5000 polygons are again at least 3000 too much for bone based CPU animation in realtime)


OrcSlayer(Posted 2006) [#7]
So you are saying that we can do an animating .b3d file that acts exactly the way I'm trying to do it now (movement of seperate pieces without vertex manipulation or other deformations), with all the pieces in the same mesh?

If so I believe that could easily solve the surface problem (I've done further testing and I can actually get almost ten full characters in view without a terrible slowdown, but this is still pushing it since the full game should be able to push more than that).

I'll refer this to my artist and see if we can't work something out...


Defoc8(Posted 2006) [#8]
Meshes attached to bones are not the problem...well,
it will have an effect...complex hierarchy setups, means
more matrix maths - i dont doubt on most systems this
hit probably doesnt seem too big.. but combining this with
texture/buffer thrashing, your going to get quite a few
stalls...

If you can get by with simpler meshes, you might want to
conisder modeling your character as md2, parenting parts
to mesh in your editor + exporting each part and the main
character as md2.. again you should try to pack as many
images you can into a single texture, using animtextures.

its ugly, but you can usually get lots of md2's onscreen
without all the slowdown associated with b3d..its much
simpler - keep in mind md2's store all the verts for every
keyframe..so ensure your polycount is quite low.

goodluck!


OrcSlayer(Posted 2006) [#9]
I'll just have to get by with the current system then...MD2 is not an option for this project.

I'll just have to be creative about using respawning enemies, and replace corpses with unanimated static meshes.