[SOLVED + PATCH] GeometryBatchFactory for skeleton animation done by anyone already?

@wezrule said:
Instead of having everything batched, you could have a few batches with either a delay or a different animation and spread them around, so they don't look exact. Would be good for things like crowds in arenas as well.

This would be kind of complicated as you'd have to set the number of vertices for each group so it knows from what vertex (with the correct anim index) it should start adding the offset. As kirill said, the vaertices are only "recognized" by the bone group.
@normen said:
This would be kind of complicated as you'd have to set the number of vertices for each group so it knows from what vertex (with the correct anim index) it should start adding the offset. As kirill said, the vaertices are only "recognized" by the bone group.


I think he's saying that if you have 200 Sinbads then don't add them all to one batch. Add them 10 each to 20 different batches and then you can animate those 20 different batches separately. Though you still have to worry about where they move and stuff... which sounds hard to me.

batching sinbad only will give a speedup, and oto only not. yes.



batching 200 sinbads is a different thing



basically you face some challenges by batching several animated models. first you would have to position them, as you would not want all your sinbads to be at the origin. this is no problem at all. next you would merege them to one batch, which would merge all vertices, bonewieghts, etc. also feasible. but then you would have only one skeletoncontrol for the whole batch. you would update only one animation, one bonematrix for all your batched different models, and an even bigger challenge would be to address seperate parts of the batch for positioning. your batched mesh has just one world position, so any movement will affect all 200 sinbads. and we are not speaking about models crossing different height sections. all your 200 sinbads would be positioned to the left, to the right, go up and down the hills at once, hill below a mesh or not.



200 windmills as suggested, static positions, but animated to some degree could work. making batches of 10 sharing the same timing should be feasible out of the box. batching 200 and introducing some sort of difference in animation time shifts would not be feasible out of the box (perhaps through a shader tweak)



technically you just throw all mesh data into a big pot, but the whole pot just uses one timing value, one skeleton, one bonematrix, one world position.



hope this makes it all a bit clearer.

ghoust said:
200 windmills as suggested, static positions, but animated to some degree could work. making batches of 10 sharing the same timing should be feasible out of the box. batching 200 and introducing some sort of difference in animation time shifts would not be feasible out of the box (perhaps through a shader tweak)


That's why I thought about scenery, I don't know anything about making animations so I might be completely off track but say you have a maze-like game and each room has an identical clock or that you batch 10 types * 20 windmills and spread them out over your terrain-tile, or 10 types * 20 trees and make animate swaying in the wind.

If I understand what’s going on… the problem with these scenarios is that the origin of each model is no longer the origin of the “spatial” that is being animated. It works ok for batching one model (which may be many geometries) but it would only work for batching 200 if they were in the same location.

Mhh ok…the problem is that you have only one control…

That’s why i didn’t get how it worked…



There are 2 way to address this :

  • merge the skeletons…but i can be very difficult and kind of messy.
  • Make the skeleton control aware of what range of indices it has to consider and find a way so that the modified mesh is the one from the batched geometry in the applySkinning method. and just let the controls as they are before batching.



    The batchNode keeps underlying geometries in the scenegraph so controls on those geometries still works as intended as long as they don’t modify the meshes buffers.



    The rigidBodyControl for example works fine like this.



    So what we would need is some kind of API in Geometry to access a range of indices on it’s mesh buffer.Unbatched it would be 0 to nbVertices in the Geometry mesh batched it would be startIndex to nbVertices + startIndex in the batched geometry.



    This way you would manage your sinbads the same as if they were not batched and would even play different animations.

    That’s just theoretical, I didn’t try it.

@jmaasing the swaying trees is a nice idea.

@pspeed when you create assets the are mostly created around the origin, so batching the as they are would be no good. but you could place them at thir world position and the batch them together.



the idea with the trees should be possible. but again, you suffer the “perfect timing” problem as I would name it. all trees would display the same bending amount.

again batching them in small groups and let the groups intersect could improve this, but then you would not want to make big groups because of culling issues (the bounding box would most of the time be in the frustum, so the trees groups would still be rendered though only one tree is visible etc.).



but in total it’s a nice idea for the trees. if anybody has some good ideas on how to break up the “perfect timing”. In he meantime I could try to create some kind of demo with groups of trees for this.

@nehon said:
So what we would need is some kind of API in Geometry to access a range of indices on it's mesh buffer.Unbatched it would be 0 to nbVertices in the Geometry mesh batched it would be startIndex to nbVertices + startIndex in the batched geometry.

So something like an extended version of mesh that creates and manages its buffers internally? ;)
@pspeed said:
If I understand what's going on... the problem with these scenarios is that the origin of each model is no longer the origin of the "spatial" that is being animated. It works ok for batching one model (which may be many geometries) but it would only work for batching 200 if they were in the same location.

mhh true....maybe you'd have to transform anim data...or offset the skeleton with the local translation of the geometry...
Not sure it occurs though...
@normen said:
So something like an extended version of mesh that creates and manages its buffers internally? ;)

:D
I think Kirill had that idea once ;)

Or even a wrapper that works like a sublist on collections.



In other words it looks like a Geometry but when you query the points it gives you the ones for its part of the overall batch. It could even offset co-ordinates automatically too depending on how clever you are being.

Well the batchNode already does that for transforms.



ahhhhh so much things to try…