Why doies animation priority have to be set at upload, and why is it immutable?

[Jennifer Boyle]

It seems to me that it would be very useful to be able to set and alter the priority after upload, as different priorities would be better for different applications.

Why is it like it is?

[Aglaia]

Obviously yes. There's a JIRA about it: https://jira.secondlife.com/browse/BUG-228287

[Jennifer Boyle]

 

18 hours ago, Aglaia said:

Obviously yes. There's a JIRA about it: https://jira.secondlife.com/browse/BUG-228287

I didn't know if there was a technical reason for it to be the way it is. Hopefully, the jira will be acted upon.

 

[OptimoMaximo]

Priority is serialized in the binary encoded anim file, which has to match specific requirements and therefore data blocks can't be omitted, in order to be able to deserialize it.

[Extrude Ragu]

I do wonder how well a script function that allows you to set script priority at run time will work - Specifically, lowering the priority might not work, depending on how it is implemented

What most people are not aware is that inside the animation file, besides the base priority, each individual joint in the animation also gets a priority. Most of the animation software people use hides that fact from the user so most people are unaware, but if you dissect the anim file format it's there.

Tools people typically use to animate, such as Avastar, if you look at a .anim animation file produced by Avastar with AnimHacker you'll see that not only does Avastar set the base priority to what you exported, but they also set the joint priority to the same value. That means that most animations out there now have non-zero joint priorities.

I actually suspect (programmer instincts) that what Avastar exports is kinda wrong and the joint priority should be set to zero to indicate they use the base priority - Because the trouble is now if you were to just edit the base priority to a lower value, nothing would change because the viewer would instead just use the joint priorities, which are all higher than the base priority.

If the LSL function were made to override all the joint priorities, that might mean that if say your future AO with the ability to set priority had a walking animation where the arms had a lower priority to the legs to allow you to hold bags and stuff, that data would now be flattened and lost, which is something to think about.

Edited May 14, 2022 by Extrude Ragu

[OptimoMaximo]

9 hours ago, Extrude Ragu said:

What most people are not aware is that inside the animation file, besides the base priority, each individual joint in the animation also gets a priority.

Actually, the specific joint priority is the only influencial value in all the serialized data, the "global" priority has no effect in regard to animation execution. It is the header, and as for most file formats headers, it's function is just provide general information (like the number of animated joints, for example) but not a list of joint names, as it currently stands.

Now, if we had the chance to change priorities as you said, how would that be implemented? Reading the header is OK and quick, but to get a list of involved joints means that the entire animation has to be deserialize first, provide the user a UI to pick from and a value field to change that joint priority. Then what? Save it back to the asset? How would that behave at that point? If those changes would go to the asset you got a LICENSE TO USE, could that mean that every single derived copy would be affected? Or would that save a new asset, which you should be marked as creator of if we follow the current creation pipeline, when clearly you aren't? Then you pay the fee for the new asset creation, but the original creator is still the creator? And the original permissions? If those inherit from the original, you pay for an asset that you do not own anyway?

And if not saved, your changes would be valid and running only on a per-session basis. Not really practical.

Much food for thought.

[OptimoMaximo]

9 hours ago, Extrude Ragu said:

Tools people typically use to animate, such as Avastar, if you look at a .anim animation file produced by Avastar with AnimHacker you'll see that not only does Avastar set the base priority to what you exported, but they also set the joint priority to the same value. That means that most animations out there now have non-zero joint priorities.

On this chunk:

I am one of those who made an animation exporter, for Maya, and the per joint priority feature is quite clear in my implementation. However, finding users that actually need or care to differentiate joints priorities isn't that common, at all.

As I was saying in the previous post, joint priorities values are the only ones that actually matter. The "global" value is just a shortcut to set all joints at the same value, while providing a convenient interface to set the header info. Many years ago I collaborated at the making of Avastar to the animation and rigging features (the horse used to this day in Avalab website is the one I made for the quadrupedal rigging tutorial) , with the original coder Magus Freston, and that is the most sound and logic route of action. It is the same route used by the bvh uploader in the viewer, by the way. The Lab was just too lazy to implement an interface to allow per joint priorities in their bvh uploader, as it could have been done from the very get go of SL.

 

[Jenna Huntsman]

6 hours ago, OptimoMaximo said:

Now, if we had the chance to change priorities as you said, how would that be implemented?

In my head, based on what I've heard (that changing priorities would be an LSL-specific feature), I'd imagine that it'd be a minor modification to the existing system wherein the viewer is told to ignore all joint priorities within the file, and instead play all joints at the given priority level. Essentially that would break individual joint priorities, but as you say, the usage of individual joint priorities is fairly limited, so it would most likely be seen as an okay compromise.

An alternate way to approach that might be the ability to specify the priorities through a parameter value, for example, using a constant called "JOINT_ALL" would target all bones, but you could also specify JOINT_ALL and another joint, for example, JOINT_MNECK and the animation would play all the joints (except the neck joint) at priority A, and play the neck joint at priority B. An example of that might be as follows:

llStartAnimationSetParams("myAnimName",[JOINT_PRIORITY,JOINT_ALL,3,JOINT_PRIORITY,JOINT_MNECK,1]);

The above example would function as mentioned above, animation "myAnimName" would play all joints (except the neck joint) at Pri 3, but play the neck joint at Pri 1.

Another benefit to doing an approach like that might be the ability to specify other parameters about an animation, e.g. Ease-in time, Ease-out time, Loop

Edited May 14, 2022 by Jenna Huntsman

[OptimoMaximo]

13 hours ago, Jenna Huntsman said:

In my head, based on what I've heard (that changing priorities would be an LSL-specific feature), I'd imagine that it'd be a minor modification to the existing system wherein the viewer is told to ignore all joint priorities within the file, and instead play all joints at the given priority level. Essentially that would break individual joint priorities, but as you say, the usage of individual joint priorities is fairly limited, so it would most likely be seen as an okay compromise.

An alternate way to approach that might be the ability to specify the priorities through a parameter value, for example, using a constant called "JOINT_ALL" would target all bones, but you could also specify JOINT_ALL and another joint, for example, JOINT_MNECK and the animation would play all the joints (except the neck joint) at priority A, and play the neck joint at priority B. An example of that might be as follows:

llStartAnimationSetParams("myAnimName",[JOINT_PRIORITY,JOINT_ALL,3,JOINT_PRIORITY,JOINT_MNECK,1]);

The above example would function as mentioned above, animation "myAnimName" would play all joints (except the neck joint) at Pri 3, but play the neck joint at Pri 1.

Another benefit to doing an approach like that might be the ability to specify other parameters about an animation, e.g. Ease-in time, Ease-out time, Loop

Very unpractical method in my opinion.

First, it shuts it off from the grasp of the majority of end users, who usually aren't very script inclined.

Second, currently scripts communication with the viewer isn't supported for this kind of operations (scripts changing viewer behavior)

 

[FridayAfternoon]

Ability to set individual joint priorities is of high interest to me. Is it fair to say the only tool that will do that is animhacker, or are there others.

big question: is the joint priority set per joint for the entire animation, or can it change from one key frame to another? I have a case where I’d like certain bones in the first half of the animation to be one priority, and a different priority in the second half. 
 

 

Edited May 21, 2022 by FridayAfternoon
Fixed type

[animats]

The real reason is that starting an animation is done with a message over UDP, and it's really hard to change the UDP message format. All viewers have to change at the same time. The whole system relies on everybody using the same message template file.

[OptimoMaximo]

5 hours ago, FridayAfternoon said:

Ability to set individual joint priorities is of high interest to me. Is it fair to say the only tool that will do that is animhacker, or are there others.

big question: is the joint priority set per joint for the entire animation, or can it change from one key frame to another? I have a case where I’d like certain bones in the first half of the animation to be one priority, and a different priority in the second half. 
 

 

My exporter for Maya does support per joint priority, as well as Avastar does. The way to make it work is just not in plain sight within Avastar though, as opposed to my plug in which has a convenience interface for that.

Anyway, for how the animation is serialized, a per frame -  per joint animation priority is simply not possible