Validate rig performance about pyblish-magenta HOT 8 CLOSED

Hello
Ithink this is because Deformers use in the rig, Skinning, Clusters and Wrap deformers for bending arms and legs.
Deformers decrease performance.
but in rig there is proxy models for animator that speed of it is more than deformed model.

from pyblish-magenta.

Hey @madoodia, I'm not referring to any rig in particular, just in general.

In it's fastest mode, all required rigs in a single scene needs to remain real-time. And this would be a validator for that.

Implementation-wise, it would require a rig to have a predictable way of determining it's animation controls, along with a "workout" animation clip (such as a Trax clip) used to test it's performance.

from pyblish-magenta.

I said in general.
Deforming model will decrease Speed.
:)

from pyblish-magenta.

Interesting issue.

I think at most a Validator for performance would raise a warning whether the rig (especially for complex characters) is up to par with an (arbitrary?) standard for performance. Disallowing/obstructing a rig to be published just because it's a heavy character will be too limiting and restrictive in real-world productions.

Note that with multithreading, gpuCaching, etc. much of the performance is dependent on the setup of the viewport, the amount of viewports, settings of caching and the complexity of the movement. Some rigs might even have real-time sims (eg. for tail/hair) which decrease peformance only when playing back.

With that in mind a possible performance check could be done like so:

• Retrieve all possible controls that can be animated, this could be instance.data('controls')
• Assign 5 temporary keys over 25 frames with psuedorandom values (which are reproducible for the exact same rig, so values might be dependent on a hash of (control_name, frame number, attribute name, attribute ranges)) for all controls that are linearly interpolated.
• Perform a 25 frame playback with play every frame set for playback speed and record its duration.

The above should always be done with a single viewport active (maybe even no viewport?) that is of a relatively small size so updating the rig is mostly dependent on updating the rig's DG network. That would be the only element not dependent on how the animator has set up his viewing settings in a shot.

Note: With Maya 2016 having parallel computation and gpu caching implemented the exact slowdown from multiple rigs in a single scene will likely have a much less linear degradation of performance.

Also, do we check the proxy rig or renderable rig? Or how do we ensure that what we're checking/comparing is related only to the proxy rig?

from pyblish-magenta.

@> I think at most a Validator for performance would raise a warning whether the rig (especially for complex characters) is up to par with an (arbitrary?) standard for performance.

This warning might come in the form of an optional plug-in. I'd consider it optional as well, good point.

Note that with multithreading, gpuCaching, etc. much of the performance is dependent on the setup of the viewport, the amount of viewports, settings of caching and the complexity of the movement. Some rigs might even have real-time sims (eg. for tail/hair) which decrease peformance only when playing back.

Good point, we'd have to find a way to make the validation as true as possible regarding "actual" user-experience when animating.

Also, do we check the proxy rig or renderable rig?

TLDR; the validation should cover the fastest version of a rig.

Since the issue is only ever a problem for animators working with the fastest, least accurate representation of a rig, then this is what I'd test with. Typically a proxy, including anything that is critical to a final performance. For example, if the character has long hair which will have a great impact on it's silhouette, then either hair is part of the validation, or the rigger implements a proxy for the hair which is tested instead.

Intermediate and final rigs doesn't necessarily have to be real-time, that would limit the quality of a final output and is generally unrealistic as it removes many potential features that are difficult to make real-time to begin with, yet remain important to a final performance, such as muscles and sliding skin.

Or how do we ensure that what we're checking/comparing is related only to the proxy rig?

I would make this a responsibility of the rigger. For example, it could be a requirement to include a proxy object set which includes all relevant nodes and settings.

from pyblish-magenta.

This has proven to be complex. Even more with the parallel evaluation in Maya 2016 and the differences in behavior per viewport. Also productions and different types of rigs will allow different performances in a production and it's hard to pinpoint "what is valid".

I can imagine a Game Production might want to validate the "maximum influences per point" in skinning, the amount of joints or the amount of polygons in a mesh. But those are also more specific than just "rigging performance".

Since this is so abstract that it doesn't make much sense in any context we should close this up.

from pyblish-magenta.

I think this is still very important. It's practical too, it just takes thinking outside the box for a moment.

1. As with any performance test, the test needs to be run multiple times, where an average of all runs determines the final result.
2. The actual motion to determine the performance can be a default animation of sorts, sometimes called a "workout", that the rig is put through.

With a default animation, run multiple times, validating rig performance comes down to simply:

1. Import rig
2. Apply animation
3. Play up until a certain number of frames

Whether it should be in Magenta is another matter, I'll leave that to you @BigRoy.

from pyblish-magenta.

Even though interesting I think it's outside of scope for any current problems we're trying to tackle with Magenta (and any "small" pipeline for that matter).

from pyblish-magenta.