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

[BUG-233884] changing shapes does not reset volume bone joint positions set by previous shape #10910

Open
sl-service-account opened this issue May 17, 2023 · 4 comments

Comments

@sl-service-account
Copy link

sl-service-account commented May 17, 2023

What just happened?

Some of the shape editor sliders also effect joint positions of the collision volume bones (fitted mesh bones). Mainly the body fat slider.

If a rigged mesh object is using custom joint positions for the volume bones, wearing a different shape does not reset the positions that were set by the previous shape, resulting in a deformed avatar.

What were you doing when it happened?

wearing a rigged mesh object with volume bone joint offsets
wearing a shape with body fat slider set to 50
changing the shape to another shape that has its body fat set to 0

The body fat slider moves volume bones downwards for some reason (maybe to simulate gravity's affects on the fat tissue?) and than does not move them back into their original locations when the 0 body fat shape is worn

What were you expecting to happen instead?

the volume bone positions should be reset back to 0 to respect the new shape setting

Other information

I have made some examples:
Images marked with a 1 shows how things are supposed to look like before the deformation occurs
Images marked with a 2 shows how it looks after the deformation bug
I have also included a blend file and and a DEA file for easy testing

Steps to reproduce:
create 2 new shapes
set the body fat to 100 in one of the shapes, leave the other shape as it is
wear the "bug test.dae" object and the body fat 100 shape
switch between the 2 shapes, the cube will become misaligned with its corner markings

Right clicking and choosing the reset shape option fixes this so it should be an easy fix to maybe make the viewer do this automatically whenever a shape is changed?

Attachments

Original Jira Fields
Field Value
Issue BUG-233884
Summary changing shapes does not reset volume bone joint positions set by previous shape
Type Bug
Priority Unset
Status Accepted
Resolution Triaged
Reporter Utilizator Mode (utilizator.mode)
Created at 2023-05-17T11:35:34Z
Updated at 2023-06-13T18:13:32Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-05-19T13:25:20.826-0500',
  "Is there anything you'd like to add?": 'I have made some examples:\r\nImages marked with a 1 shows how things are supposed to look like before the deformation occurs\r\nImages marked with a 2 shows how it looks after the deformation bug \r\nI have also included a blend file and and a DEA file for easy testing\r\n\r\nSteps to reproduce:\r\ncreate 2 new shapes\r\nset the body fat to 100 in one of the shapes, leave the other shape as it is\r\nwear the "bug test.dae" object and the body fat 100 shape\r\nswitch between the 2 shapes, the cube will become misaligned with its corner markings\r\n',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Some of the shape editor sliders also effect joint positions of the collision volume bones (fitted  mesh bones). Mainly the body fat slider.\r\n\r\nIf a rigged  mesh object is using custom joint positions for the volume bones, wearing a different shape does not reset the positions that were set by the previous shape, resulting in a deformed avatar.',
  'What were you doing when it happened?': "wearing a rigged mesh object with volume bone joint offsets\r\nwearing a shape with body fat slider set to 50\r\nchanging the shape to another shape that has its body fat set to 0 \r\n\r\nThe body fat slider moves volume bones downwards for some reason (maybe to simulate gravity's affects on the fat tissue?) and than does not move them back into their original locations when the 0 body fat shape is worn",
  'What were you expecting to happen instead?': 'the volume bone positions should be reset back to 0 to respect the new shape setting',
}
@sl-service-account
Copy link
Author

Dan Linden commented at 2023-05-19T18:25:21Z

Hi Utilizator,

I'm not able to reproduce this on Second Life 6.6.12.579987.
Here's what I did.

  1. Wore the Ruth outfit from the Library.
  2. Edited the shape, set the Body Fat to 100% and saved a copy of that shape.
  3. Wore the "Thin Shape" again.
  4. Uploaded the "bug test.dae" after checked the "Include joint positions" checkbox in the Rigging tab. (This is correct, right?)
  5. Wore the "bug test.dae". It looked like c1.jpg
  6. Wore the "Body Fat 100%" shape
  7. Wore the "Thin Shape" again.

It looked like c1.jpg for me and an observer. It doesn't look like c2.jpg.

Could you try your test on the Second Life viewer and see if you get the same results?

@sl-service-account
Copy link
Author

Dan Linden commented at 2023-05-19T18:46:22Z

Just moments after posting the above, 2 other viewers saw it repro and look like c2.jpg.
I tried several more times to repro it again, but without success.

Will investigate this more later, but do share if you find a way to reproduce this consistently.

@sl-service-account
Copy link
Author

Utilizator Mode commented at 2023-05-21T10:24:38Z, updated at 2023-05-21T10:27:06Z

sorry for the late response, i did some testing on the official viewer, seems its partially a firestorm problem but i can still reproduce it on the official viewer too, only its not a problem there because it automatically fixes itself as soon as i exit the "edit outfit parts" window

here are the steps:

  1. create a new shape and wear it

  2. edit body fat and set it to 100, save and exit the "edit outfit parts" window

  3. edit the shape again and set body fat back to 0, the cube should be now displaced

saving the shape and exiting the edit outfit parts window makes it return back to its normal position

@sl-service-account
Copy link
Author

Dan Linden commented at 2023-06-13T18:13:33Z

Thank you for the report, Utilizator!

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