deformation slows blender down

[solmax]

at least this is my impression. ik itself works quite fast when used on armatures which don't deform a mesh.

just try this ( as i did): take a relatively hi poly mesh, let's say 20-40k, turn subsurf on and rotate the view - works fine.
now make an armature and parent the mesh to it: what happens? redraw speed goes down to some c64 level. and there is no ik applied at all!

so from my point of view it's the deformation code that blender uses to apply bone transform to the vertices of the mesh.

what can be done? (from a non-programmer point of view)

- deformation calculation dont't need to be recalculated repeatedly, but only on transform changes (so that you have at lest reasonable speed when reorienting the view)
- speed up deformation calculation in general, there has to be a way*)
- a function which allows the use of a proxy low-res model for animation would be fine. like a field where i put in the name of the lores mesh and a toggle which switches between lores and hires. of course deformation calculations should be done only on lores model until you hit render, where automatically the hires mesh is used. using layers for that doesn't help right now - see above.

*)to all programmers - i don't know how, i just know what. this doesn't mean i don't respect you. i just saw in other threads that you guys seem quite sensitive to thinks like "i saw that in maya, so make it work in blender". this is the way users think. so please don't flame me.

i actually started learning c++, so in 2 or 3 years i may understand you fully, too

best regards

solmax

[ton]

*)to all programmers - i don't know how, i just know what. this doesn't mean i don't respect you. i just saw in other threads that you guys seem quite sensitive to thinks like "i saw that in maya, so make it work in blender". this is the way users think. so please don't flame me.
solmax

In contrary, reports like this are extremely welcome and useful. It gives immediate and simple clues for coders to attack the problem.

The threads you refer to, are about a single individual (thorax), who is annoying everyone who's active here at blender.org. He's already being moderated at a mailing list for that reason. However, moderating people at forums is the last thing I would do, and typically restricts to postings that intentionally insult or harm people. I cherish free speech a lot, it just has its downside...

If you ever notice people being flamed for suggesting "i saw that in maya, so make it work in blender"... just notify me.

Best regards, and thanks!

ton (at) blender.org

[ton]

I've spent yesterday at the Armature code in Blender. Although the 'make displist' call in the main drawing loop causes a slowdown, it was especially evident that in multiple locations of the 'draw armature' function a lot of overhead takes place. The most striking problem is the fact that for even reading the position of a single Bone, the entire chain is being calculated recursively, back to its root.

The current implementation seems to be based at delivering 'a correct result' and has no optimizing built in at all. What needs to be done is:

- getting rid of 'make displist' and recursive evaluation calls from drawing loops
- creating a new and optimized 'set correct pose for armature' function, that only gets called once for each frame change or while editing.
- rebuilding the vertex-grouping code. It works extremely slow. Reading back a file with vertexgroups for a 40k vertex Mesh takes ages!

(but: I couldn't find issues with IK)

It looks like the person who built this system in NaN (Reevan, excellent job!) was aiming to make it working in the game engine first. His implementation works fairly well with low-poly and simple game character Armatures.

My attempts to do a first reconstruction of this code immediately gave great speedups, but unfortunately resulted in lagging and instable Armatures. I just lack experience with this animation system.
So I've passed it on to Chris Want (Hos), who's already activily working on it, and quite better suited to do it. Together we'll investigate it further.

Sorry, I also hoped a simple solution existed. But Reevan was not entirely stupid, he delivered something that works, although it doesn't deserve a beauty prize...

[solmax]

but more important, my impression was right, that it's not the ik calculations which are slow.

ahh, I wish I could watch the blender matrix in coded form AND understand it myself

question to the gurus: what is that displist? not the first time i see it here.

best regards

marin

[ton]

displist = display list.

a way to draw 3d models optimal and/or uniform, independent of type.