I created a quite complex full body rigging control (about 70 contraints and 30 controls some even as rigidbody) on a HighPoly avatar.
I grouped all in various levels "Arms,Torso, Legs, Face Expressions, Toes,Hands, Hairs ecc.
Every group is collected in the Rig Builder component.
Profiling i see that every contraints generates a playable and the job/burst combination works well spreading the cpu code on all workers.
I have even a low poly version of the avatar to use as LOD handling, so i tried to use a rigging subgroup for the background avatars, for example disabling Face Expression, Hairs, Toe ecc… unchecking runtime the groups inside the Rig Builder when I switch on the low poly configuration.
I discovered that the cpu doesn’t change unchecking the Rigs inside the Rig Builder, so actually i’m not able to optimize runtime this configuration.
Only if I disable the Rig Builder component you see that really the rigging and cpu stops.
I modified experimentally the rig builder to allow multiple rig builders on the same object and then swicthing on them in a mutally exclusive way and that seem work but I modifed the package.
Any better idea to handle that?
Hi,
Toggling rig layers is the same as setting weights to zero on a constraint or a rig. When the RigBuilder is initialized, it creates a PlayableGraph with the complete rig and adjusts the weights of branches that will not be evaluated. This allow to dynamically toggle in layers afterwards in runtime.
If the constraint is evaluated, it is considering the zeroed out weight and skips most of the calculations, but the cost will still be noticeable.
Removing the rig layers from the RigBuilder entirely is your best bet in ensuring they don’t exist in the PlayableGraph from the start. If you want to handle LOD levels of rigs, you can always write a MonoBehaviour that will create the RigBuilder and its associated layers at runtime before it gets initialized.
Hello Simonbz,
yes,I noticed that unchecking inside the rigbuilder is equivalent to weight zero the related Rig group.
The saved cpu cost in my tests isn’t so noticeable, i could say less than 5% , but i’ll ckeck it again.
With a large group of avatars with complex rigging active i reach the cpu limit before the gpu rendering limit, so i think it is a quite important factor to control.
I created a script to handle three levels (full, parzial and disabled) and seem to work as I wanted.
By the way could be useful have a direct support of that directly in the package, allowing more righbuilders with a sort of priority, mutually exclusive index or another component to select one of them.