[BUG-226427] Root bone is not centered on avatar

[sl-service-account]

What just happened?

I put on an object which has vertices which are skinned to the root bone. ("Marionette Controls and Strings" from Curio Obscura) but the vertices attached to the root rendered at a great distance and inside the ground.

What were you doing when it happened?

Putting on an attachment. Walking around.

What were you expecting to happen instead?

For many years, the root bone has been positioned where the avatar is located in the sim so that vertices attached to the root bone could appear near the avatar's location but only be moved by actual movement, not animation. I have products that depend on that assumption. My marionette strings, for example, have a wooden frame skinned to the root bone with strings that end at various bones on the arms and legs so that it looks like there's a wooden frame floating above the avatar with string hanging down to attach to the avatar, the frame staying still while the avatar animates.

Other information

I realize that my use of the root bone was off-spec so I would understand if recent upgrades to SL required changing the behavior of the root bone permanently. However, I would greatly appreciate a response to let me know if this is a bug which needs to be fixed or a permanent change which will not be undone, so that I can pull my affected products from public sale if appropriate.

Attachments

• marionette_fix.JPG 2019-04-02 10:50:00
• screenshot.jpg 2019-02-25 12:50:48

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-226427 | | Summary | Root bone is not centered on avatar | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Pandora Wrigglesworth (pandora.wrigglesworth) | | Created at | 2019-02-25T17:55:08Z | | Updated at | 2019-04-02T14:52:16Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2019-02-26T08:01:35.335-0600', "Is there anything you'd like to add?": 'I realize that my use of the root bone was off-spec so I would understand if recent upgrades to SL required changing the behavior of the root bone permanently. However, I would greatly appreciate a response to let me know if this is a bug which needs to be fixed or a permanent change which will not be undone, so that I can pull my affected products from public sale if appropriate.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'I put on an object which has vertices which are skinned to the root bone. ("Marionette Controls and Strings" from Curio Obscura) but the vertices attached to the root rendered at a great distance and inside the ground.', 'What were you doing when it happened?': 'Putting on an attachment. Walking around.', 'What were you expecting to happen instead?': "For many years, the root bone has been positioned where the avatar is located in the sim so that vertices attached to the root bone could appear near the avatar's location but only be moved by actual movement, not animation. I have products that depend on that assumption. My marionette strings, for example, have a wooden frame skinned to the root bone with strings that end at various bones on the arms and legs so that it looks like there's a wooden frame floating above the avatar with string hanging down to attach to the avatar, the frame staying still while the avatar animates.", 'Where': 'http://maps.secondlife.com/secondlife/Business%20District%20Foxtrot/250/184/2601', } ```

[sl-service-account]

Whirly Fizzle commented at 2019-02-26T14:01:35Z

https://marketplace.secondlife.com/p/Curio-Obscura-Marionette-Control-and-Strings/4073972

[sl-service-account]

Whirly Fizzle commented at 2019-02-26T14:15:43Z

Looks like this broke with Animesh.

Firstly testing on Firestorm, the puppet thingy renders correctly on Firestorm 5.1.7 (pre-Animesh): https://prnt.sc/mqdis1 Bug reproduces on Firestorm 6.0.2 with Animesh support: https://prnt.sc/mqdl4e

[sl-service-account]

Kyle Linden commented at 2019-02-26T16:26:43Z

Easy to reproduce with affected content. Puppet strings stretch off to regions 0,0,0 coordinates. Similar to past rendering issues seen in beta stages of bento dev.

[sl-service-account]

Beq Janus commented at 2019-02-26T16:48:31Z

My first guess is that this gets affected by the dynamic bounding box calculations but the behaviour is still odd. I would have expected it to be offset some distance but not completely trashed. I'll have a fiddle and see if I can work out exactly where it is going awry, I have an ancient marionette thingy pretty sure it is not Pandora's one though. I'll check if that uses the same trick and if not pop on to MP and buy the Curio Obscura version.

[sl-service-account]

Beq Janus commented at 2019-02-26T17:13:33Z

hmm they don't appear to go to 0,0,0 for me, they literally go down to infinity.....

To test this I went to <0,0,0> and the wires still extend straight down.

It does NOT appear to be related to bounding boxes, or at least, show BB does not give us a BB extending downwards to infinity.

 

[sl-service-account]

Beq Janus commented at 2019-02-26T23:17:32Z

yeah....so.... the simple answer (sorry Pandora) is that this is perma-b0rken (but see below)

Unless I am mistaken this is rigged against the avatar centre attachment point which in avatar.lad is the mRoot "bone".

If you try to upload this mesh today it will (should - please be true) fail because the uploads are validated against the list of valid bones before the upload button is enabled. 

historically this was not true. In my tests of animesh, I found a number of cases where the code failed if we assumed a sane skeleton

I even made a "note to self" that this was still happening 

The result is that we load the bind matrix, but we cannot do anything about the world rotation as we have no joint to lookup and so the final combination of inv bind and world do not occur and you end up with nonsense.

You should see something like the following in your Firestorm.LOG (not sure if LL has the same logging enabled)

2019-02-26T18:16:28Z WARNING #Avatar# newview/llskinningutil.cpp(213) LLSkinningUtil::initSkinningMatrixPalette : ONCE (900th time seen): Beq Janus rigged to invalid joint name mRoot (23) num -1

Pandora did your product ever work on the LL viewer or just on Firestorm (and perhaps other TPVs)?

One of the changes to Firestorm between 5.1.7 and 6.0.x was to adopt the LL newly added rigging to attachment points in place of our own version, This was hard to test as very little content uses this undocumented feature and the test meshes I had worked fine but I suspect that avatar centre -> mRoot may have fallen foul of this. I'm not 100% convinced though. 

It may be that we could add a mapping to allow for this. I can see some value in having this, but it is something that I'd want to discuss with Vir Linden before adding back on FS (it would be far better for it to work across the board), It would be good to see the specification of the DAE for this (a mockup to repro would be useful) so that I can confirm the joint mappings. 

 

At the very least this product is broken for the foreseeable and you'd be best to remove it for the time being.

 

 

[sl-service-account]

Whirly Fizzle commented at 2019-02-27T14:34:29Z

Pandora did your product ever work on the LL viewer or just on Firestorm (and perhaps other TPVs)?

I can confirm that it renders just fine on an older LL Love Me Render 2 RC build I just happened to have still installed. This build is pre-animesh. https://prnt.sc/mqvutn

Viewer build used: http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/5.1.8.518751

[sl-service-account]

Vir Linden commented at 2019-04-02T14:52:16Z

The logic for handling invalid joints changed a bit in animesh. The intended behavior is that invalid joints like mRoot get mapped to mPelvis, but mRoot in particular did not get detected as invalid - it's a bit of a special case.

I think that correcting this behavior will cause the marionette to work as before. The attached image marionette_fix.jpg shows the behavior with the fix. Here mRoot is still considered invalid, but it now correctly gets mapped to mPelvis and that seems to give reasonable behavior. If that behavior is not consistent with what you were seeing before animesh, please let me know.