Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-11407] [Bento] Scripted method to position bones #1604

Open
1 task
sl-service-account opened this issue Feb 15, 2016 · 2 comments
Open
1 task

[BUG-11407] [Bento] Scripted method to position bones #1604

sl-service-account opened this issue Feb 15, 2016 · 2 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Feb 15, 2016

How would you like the feature to work?

I would like to see an LSL command, such as llSetArmature to pass an array of bone positions to the client to animate oneself, or, with permission granted, to animate another user. Currently, the only way to position bones realtime in-world is to have many many thousands of animations and pick among them for each joint. Now with Bento, this is impractical as not only are there many more bones, these new bones can be used in any way a designer wishes. There are no practical limits on rotation or translation as there are on human bones, so using pre-made animations for these new bones is impractical.

I would see the form of the array passes as the internal .anim format, and that it would only be cached by the client, and not stored in the SL object databases to clutter it up. My reasoning behind using anim format is it won't impose on the server to do a BVH to anim conversion each time the command is called, but if there is another format that needed to be used (say for easier limits checking) then we can discuss this. (collada?)

The anim sent could be a single static pose, or it could be an animation. That decision would have to be made by LL if a single frame or full animation was allowed, or simply limited by LSL array limits. The command would accept the array and a destination avatar UUID(or possible object UUID if NPC armatures are allowed in the future). The output of the command would be a handle to use later to stop the animation. Possibly as an adjunct to llStopAnimation.

To facilitate future expansion, another command, llGetArmature would be useful to extract the current list of bone names and their hierarchy, so that future skeleton types can be supported, as well as possible NPC armatures. The command would accept an avatar UUID (or object UUID for NPC). The output of the command would be an array of bones. To protect content, there would be no way to obtain the users current bone positions, although it might be useful to obtain bone offsets should the llSetArmature format require bone offset data.

Why is this feature important to you? How would it benefit the community?

In-world pose and animation creation tools have made it possible for both non-technical and advanced users to add poses and animations to their products. I have many users that can attest to this. It has also brought a lot of pose flexibility to SL photographers and machinimists. Unfortunately, Bento has made the current method of doing this impractical for the additional bones.

Links

Duplicates

Original Jira Fields
Field Value
Issue BUG-11407
Summary [Bento] Scripted method to position bones
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter Phate Shepherd (phate.shepherd)
Created at 2016-02-15T22:39:53Z
Updated at 2017-09-27T12:21:46Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2017-09-27T07:21:13.443-0500',
  'How would you like the feature to work?': "I would like to see an LSL command, such as llSetArmature to pass an array of bone positions to the client to animate oneself, or, with permission granted, to animate another user. Currently, the only way to position bones realtime in-world is to have many many thousands of animations and pick among them for each joint. Now with Bento, this is impractical as not only are there many more bones, these bones can be used in any way a designer wishes. There are no practical limits on position as there are on human bones, so using pre-made animations for them is impractical.\r\n\r\nI would see the form of the array passes as the internal .anim format, and that it would only be cached by the client, and not stored in the SL object databases to clutter it up. My reasoning behind using anim format is it won't impose on the server to do a BVH to anim conversion each time the command is called, but if there is another format that needed to be used (say for easier limits checking) then we can discuss this. (collada?)\r\n\r\nThe anim sent could be a single static pose, or it could be an animation. That decision would have to be made by LL if a single frame or full animation was allowed, or simply limited by LSL array limits. The command would accept the array and a destination avatar (or possible object if NPC armatures are allowed in the future).\r\n\r\nTo facilitate future expansion, another command, llGetArmature would be useful to extract the current list of bone names and their hierarchy, so that future skeleton types can be supported, as well as possible NPC armatures. The command would accept an array to populate, as well as a username (or object name for NPC). To protect content, there would be no way to obtain the users current bone positions, although it might be useful to obtain bone offsets should the llSetArmature format require bone offset data.",
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'In-world posing has made it possible for non-technical users to add poses and animations to their products. I have many users that can attest to this. It has also brought a lot of pose flexibility to SL photographers and machinimists. Unfortunately, Bento has made the current method of doing this impractical for the additional bones.\r\n',
}
@sl-service-account
Copy link
Author

Phate Shepherd commented at 2017-09-24T14:31:04Z

I may have a quick short-term solution to BUG-20070, but it is closed so I can't comment there.

In LSL, you can set textures by UUID, you can play sounds by UUID, but you can't play animations by UUID. Is there a reason that animations can't be played by UUID? If it were possible, then the inventory of my objects could be trimmed down from thousands of animations down to just a few scripts to store the UUIDs.

On a side note, when you have Debug -> Avatar -> Animation Info turned on, it always shows NULL_KEY for the animation, even if it is one that you created. Is that feature busted, or intentional behavior?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-09-27T12:21:13Z, updated at 2017-09-27T12:21:47Z

Debug -> Avatar -> Animation Info showing NULL_KEY for all animations apart from internal animations is, as far as I'm aware, expected behaviour.
Ref: BUG-41245, which was accepted.

There have been several requests in the past to allow playing animations by UUID, for example:

  • BUG-8162 - llStartAnimation can be used with UUIDs
  • SVC-5309 - Proxy Keys to "Hide" assets from scripts and allow for UUIDs in llStartAnimation()
  • SVC-4569 - Allow animations to be specified by key
  • Related (see comments): SVC-6374 - llGetInventoryKey() returns NULL_KEY for animations that do not have full-permissions

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant