The number of animated/rigged objects on screen.

OK, there are various things to do to be able to add lot’s of objects.

  1. LOD: As mentioned, your objects need to be simpler. Further objects, should be low poly and maybe have no bones. Then closer, use FK assemblage , closer, use simple mesh with 1 bone per limb, and so on.
  2. Physics: After a while, no matter how your animations are optimized, you’ll have troubles with physics calculations, add physics in you LOD system.
  3. Rendering: the main problem with bones is the rendering of deforming meshes, if only the closest objects ave deformations, the rasterizer will have an easier life. Also try to design your scenes in a way that the objects are hiding. For instance, wolfs wont reveal themselves too easily, so use foliage occluders to make them “hide”. I was able to have 100 animated wolves, but the frames are only at 60 when only rendering a bunch of them, like 30. Adding 200 got me to 17-9 fps the animations was very high.
    I also played with the sensor tics, putting to 1000, makes no difference it seems, but can un-stress the logic(I belive so…).

@MarcoIT

With your file I was able to go from my 11, to 26 wolves., Im very impressed. :smiley: Can you tell me what you think had the most impact on the performance. So I can start there.

@Everyone. Thank you for your input you have given me a lot of things to tinker with. :smiley:

that which you must keep in count is the total number of keyframes which work in the current action
one bone can have 10 keyframes (loc(3)+rot(3)+scale(4))

multiplicate this for the number of active bone(in your blend was 10kf * 30bn …thats is not light of course)

little tips:
many time the scale is unnecessary , so better not save it (check in dopeshet > action)
but save only LOC/ROT
this way the work decrease a bit.

then you can keep many bones , but with less bone in the same action (not know if this way is very easy)

anyway as all optimization the rules is ever one : CUT
few things = hight FPS
:wink:

regard the vertex this should be a work for rasterizer

i not make test, but by logic should be better parent to the armature with “empty group”
then assign it manually

Just for fun i modified the Optimized version even more… works nice here :slight_smile:

  • removed all the EXIF meta data from image files (yes it weights too).
  • converted all textures to power of 2.
  • converted all textures to Mipmapped .DDS
  • make the mesh all triangles (quads to trids).

http://www.pasteall.org/blend/13002

The mipmapped DDS textures doesn’t do anything in trunk. The DDS image is read in as any other image and mipmaps are still generated for it. Cucumber, however, can use DDS/DXT texture correctly (with pre-saved mipmaps too).

Overall, what kind of performance difference did you get with those optimizations?

Thanks Moguri, i know, but… i was think to make files forward compatible-ish, when we got the cucumber the file will be ready “as is”, plus that it dont have any bad effect on the current stable blender.

i got to 23 wolves with juan update

with your version cannot change in solis or texture ,
see ever in wireframe

there some reason ?

PS:I see also other changes … :wink:

Attachments


Check the object display options, it might be set to wire for easy visualization…

Edit:
Here i my tip:

Optimize:

  1. Your mesh: it should deform nicely with as less vertices as possible Use replace mesh for basic LOD.
  2. You armature: take the most out of out of your bones, less bones means less objects to animate.
  3. The animations: Use short actions with minimal frames. For example your wolf model only need bone rotation in the X axis. If you IK animate the armature, then go back in the bones in the Dope sheet and delete unnecessary animation. That can triplicate the animation stress reduction(memory wise). A simple rotation key has 3 variables X,Y,Z. If you use one axis to animate, you can delete the others.
    From there you can add tens of animated objects.

I can run 184 wolves before slow down, whereas with Juan’s i get 100 or so.
Converting quads to tris is useless - the game engine does that on load.
Unless you convert quads to tris and then remove redundant polys, there is no need.

Hi,is not that I have already checked… (I use 2.60.0, can be this? )

EDIT:

Attachments


It could be that your normals are incorrectly aligned, or that you do not, in fact, have any face data!
I have seen issues with BMESH and faces, however the two builds are not in trunk yet, so i cannot see how they’d interact

i found, is not the visualization the issue , but not there the faces ! for some reason thre only all edges (I use 2.60.0)

now there one face :

Attachments


No, it doesn’t. The BGE will actually run mixed tris and quads, but they get put into different buckets. So, I could see forcing a mesh to all tris or all quads offering some (if slight) performance improvements.

Tried the BGE deformation but ugly bugs and deformations happens unfortunately
Restricting the animations update only increases the animations usage and looks bad.

This, I beleive, shows just how easily misled people become :slight_smile:

All mayor game engines uses Triangles.
I convert quads to tris and then remove redundant polys. I am not opposing anyone on this thread.
Its on 2.6.2, also i dont checked the textures, maybe i forget to pack some, you need to config before Play, i dunno.
For now it will be a little slower than plain lossy textures, but still faster than PNG, and looks better than JPG, and when we got MipMap Loading from the textures it will be a lot faster.
I dunno im not an expert, but i researched a lot of game engines and Triangles with MipMaps and NormalMaps seems pretty common, maybe the world is wrong and we are correct, or we are correct and the world is wrong, obviously you need Normals to triangles to look nice, and i know we are not using the MipMap yet, but i see a MipMap on the horizont…