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

[BUG-41063] [Bento] Some fitted mesh no longer fits on Bento viewers #12652

Open
1 task
sl-service-account opened this issue Dec 15, 2016 · 8 comments
Open
1 task

Comments

@sl-service-account
Copy link

sl-service-account commented Dec 15, 2016

This bug was reported on the Firestorm Bento release by @JimmyV33304.
The same behaviour is seen on the LL Bento viewer.

Repro Items

  • Purchase the (NIRAMYTH) - AESTHETIC mesh body at http://maps.secondlife.com/secondlife/Niramyth/42/216/26
    The demo will reproduce the problem.
    The demo is not available on the Marketplace.
    You will be forced to the landing point - use the teleporter in the store to go to the Aesthetic section of the store.

  • Purchase these sweat pants: https://marketplace.secondlife.com/p/mJ-010-Full-Perm-Sweat-Pants/7082041

  • Both repro items are non-Bento content.

  • Both repro items are fitted mesh and use the same rigging and the pants should fit the Aesthetic body perfectly for all shape variations.

    Steps to Reproduce

  • Unpack the "(NIRAMYTH) - AESTHETIC - Advanced Mesh Body - SMITH DEMO" and replace outfit with this folder.

  • Take off the HUDs and boxer shors and wear any mod shape (the demo shape is no mod).

  • Attach the sweat pants.

  • Edit shape and increase the Butt Size

    Observed Behaviour

  • When Butt Size is over 50, the Aesthetic mesh body butt pokes through the sweat pants.

  • See Fig 1 attached.

    https://i.gyazo.com/4951d2e7b63c6eb9efeef9e214af8bd6.gif

  • Problem does not reproduce on non-Bento viewers.

  • Fig 2 attached shows Butt Size at 100 on a pre-Bento viewer.

    https://i.gyazo.com/6b635a5718cbebcc532d8683627dc07e.gif

    Expected Behaviour

    Fitted mesh should still fit on Bento viewers.

Attachments

Links

Related

Original Jira Fields
Field Value
Issue BUG-41063
Summary [Bento] Some fitted mesh no longer fits on Bento viewers
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Whirly Fizzle (whirly.fizzle)
Created at 2016-12-15T06:46:44Z
Updated at 2016-12-22T13:06:18Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-12-15T21:29:27.352-0600',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Filling in...',
  'What were you doing when it happened?': '...',
  'What were you expecting to happen instead?': '...',
}
@sl-service-account
Copy link
Author

polysail commented at 2016-12-16T03:29:27Z

I remember investigating an issue in the same region of the body, but that issue was an incorrectly scaled tail bone. I'll have to dig for an old avatar_skeleton.xml to go back and double double check that nothing in the male sliders was changed in the butt region. I'll check into that later. I can't really tell exactly what's going on here, but my instinct is to check the vertex data? I know there's some differences between how vertex weighting is handled pre-and post bento. If pre-bento it had some weighting to something else, that somehow got "filled in / replaced" by normalizing the vertex weights, and that process is different in bento somehow? @the clothing designer, what happens if you try uploading the content again post-bento?

@sl-service-account
Copy link
Author

polysail commented at 2016-12-18T08:20:53Z

Is it possible that this behavior is due to the "repaired sliders" that were not working at values above 50% mentioned in https://jira.secondlife.com/browse/BUG-40672

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-12-18T10:15:14Z

Hmm that bug only affected the torso muscles slider on female shapes though...

@sl-service-account
Copy link
Author

polysail commented at 2016-12-19T06:30:32Z

Yeah ~ I just double checked the Butt bone influence in the differing avatar_LAD files. There's no difference between the values, which leads the only explanation to be interpretation.

@sl-service-account
Copy link
Author

Vir Linden commented at 2016-12-21T20:41:01Z, updated at 2016-12-22T13:04:52Z

(edited: the pre-bento count of joints was 52, previously said 53 here. Also fleshed out the explanation a bit.) This one took a while to track down. The short answer is that this is a content problem that was previously masked by limits imposed by our rendering system.

The longer answer with more technical details: It turns out that the skinned mesh is rigged to 53 joints, or at least lists 53 joints as influences. The last joint in that skinned joint list is the BUTT collision volume, ie, it's at element 52 in the zero-indexed array. The joint at element 51 is the PELVIS collision volume, which will become relevant later. Before Bento, only 52 joints per skinned mesh were supported (because the pre-bento skeleton had 26 collision volumes and 26 bones, this was considered the maximum needed), so the maximum legal index was 51. When the mesh was being drawn, indices above 51 would be clamped to 51. In the case of this mesh, that meant that vertices that said they were weighted to the BUTT collision volume (index 52) would wind up getting weighted to the PELVIS collision volume instead (index 51). This would tend to have the effect of flattening out/moving forward these butt-weighted vertices. So pre-bento, the model would not render as designed if it was rigged to the butt. So what "breaks" with Bento? Now the limit is 110 joints per mesh, so the index of 52 is perfectly legal, and no clamping is done. Now items that say they are weighted to the butt actually do get weighted to the butt, so the content renders as designed. This will tend to push those vertices farther back. The easiest way to see that this is the problem is to edit the shader file objectSkinV.glsl and change one line:

// ORIGINALLY:
index = min(index, vec4(MAX_JOINTS_PER_MESH_OBJECT-1));
// CHANGE TO:
index = min(index, vec4(51.0));

Once the index is getting clamped at 51, you should see the original pre-Bento appearance for these meshes.

So it looks like this really needs to be fixed at the content level by tweaking the weights and re-uploading the mesh.

@sl-service-account
Copy link
Author

polysail commented at 2016-12-21T21:15:45Z, updated at 2016-12-21T21:22:52Z

hmmmm~ there is the possibility that this may be a bit more wide-spread issue then.
It's been common practice among 3ds max users to just weight one or more verts to every bone in the body ( I personally would select a single vertex that was 1.0 to a bone and weight it at zero vertex weight to all bones, but there's no guarantee that practice is what everyone else did, as is evidenced by this ) in order to populate the bone array in the DAE file, since the Autodesk FBX exporter chops any bones out that weren't at least included in the skin weight table by default. The FBX exporter is the name of the general exporter module in autodesk software that in this case is producing the DAE file.

The habit is so entrenched in some people they were submitting tickets over not being able to continue to do it : https://jira.secondlife.com/browse/BUG-41066

@sl-service-account
Copy link
Author

Vir Linden commented at 2016-12-21T21:30:40Z

Well, just having a model that's weighted to 53 joints is not a problem. The problem with this particular model is that the BUTT weights are bad, but this was being compensated for by having them remapped to the PELVIS.

@sl-service-account
Copy link
Author

Vir Linden commented at 2016-12-22T00:27:54Z, updated at 2016-12-22T13:06:19Z

Also, there should be no reason for pre-bento content to have 53 joints. The original skeleton had 26 bones and 26 collision volumes, so there must be a duplicate or invalid joint somewhere in the joint list for these rigged meshes. (Or an attachment point, which at the time was not officially supported)

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