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

[BUG-10495] Update the SL clothing system for mesh #820

Open
4 tasks
sl-service-account opened this issue Oct 17, 2015 · 0 comments
Open
4 tasks

[BUG-10495] Update the SL clothing system for mesh #820

sl-service-account opened this issue Oct 17, 2015 · 0 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 17, 2015

How would you like the feature to work?

  1. Update the existing clothing system to support 1024x1024 textures and specular/normal maps.

  2. The standard SL clothing system creates temporary "baked" clothing textures for the standard mesh. If it were possible for scripts to access this texture UUID, clothing could be applied to partial or complete mesh avatars without need for applier systems. It would be necessary to make it so that a script could only access the UUIDs of one's own baked layers to prevent abusive cloning.

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

Currently, anyone purchasing or designing clothing for SL has a great deal of complexity to surmount in order to handle mesh avatars. There are proprietary applier systems, and one "universal" appliers system, but support across various products is always a question mark. Were it possible for mesh to simply use the baked textures of the old clothing system, the question of clothing compatibility would be simplified down to a single check box on the mesh item itself — does it support standard SL clothing?

There are several key reasons this is a vital addition to SL.

  1. Mesh body part creators have to deal with substantial challenges in order to allow their products to support third party clothing systems. Security and versatility are always in major conflict in this area. The problem of how to apply complex clothing to SL avatars was already solved for the original avatar mesh. It would be a relief for mesh creators if this solution could be extended to custom mesh.

  2. Clothing creators have to learn the protocols of any mesh applier system they wish to create for. This creates extra work for both the clothing and mesh creators as they deal with the confusion of the various protocols. The standard SL clothing system with its drag-and-drop GUI is a far simpler solution.

  3. Baking clothing and skins to a single texture is much better way to do clothing! Currently, putting clothing on mesh requires several extra copies of each mesh body part, and extra textures to handle the layer. This is incredibly inefficient and represents a major waste of rendering resources. Avatar mesh is often the most complex object in a scene, and having redundant copies on every avatar results in a poorer experience for everyone.

  4. Baking clothing layers offers far more versatility for combining multiple layers, and bypasses some of the major glitches of sandwiched mesh clothing layers such as alpha sorting issues, clipping issues, and reasonable limits on the number of layers.

Links

Related

Original Jira Fields
Field Value
Issue BUG-10495
Summary Update the SL clothing system for mesh
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter Mel Vanbeeck (mel.vanbeeck)
Created at 2015-10-17T19:16:44Z
Updated at 2017-11-08T16:32:37Z
{
  'Business Unit': ['Platform'],
  'How would you like the feature to work?': '1. Update the existing clothing system to support 1024x1024 textures.\r\n\r\n2. The standard SL clothing system creates temporary "baked" clothing textures for the standard mesh. If it were possible for scripts to access this texture UUID, clothing could be applied to partial or complete mesh avatars without need for applier systems. It would be necessary to make it so that a script could only access the UUIDs of one\'s own baked layers to prevent abusive cloning.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Currently, anyone purchasing or designing clothing for avatars has a great deal of complexity to surmount in order to handle mesh avatars. There are proprietary applier systems, and one "universal" appliers system, but support across various products is always a question mark. Were it possible for mesh to simply use the baked textures of the old clothing system, the question of clothing compatibility would be simplified down to a single check box on the mesh item itself — does it support default SL clothing?\r\n\r\nThere are several key reasons this is a vital addition to SL.\r\n\r\n1. Mesh body part creators have to deal with substantial challenges in order to allow their products to support third party clothing systems. The question of security and ease of use are always in major conflict in this area. The problem of how to apply complex clothing to SL avatars was already solved for the original avatar mesh. It would be a relief for mesh creators if this solution could be extended to custom mesh.\r\n\r\n2. Clothing creators have to learn the protocols of any mesh appliers system they wish to create for. This creates extra work for both the clothing and mesh creators as they deal with all the confusion of the scripting protocols. The standard clothing objects with its GUI interface is a far simpler solution.\r\n\r\n3. Baking clothing and skins to a single texture is much better way to do clothing! Currently, putting clothing on mesh requires several extra copies of each mesh body part, and extra textures to handle the layer. This is incredibly inefficient and represents a major waste of rendering resources. Avatar mesh is often the most complex object in a scene, and having redundant copies on every avatar means much poorer frame rates for everyone.\r\n\r\n4. Baking clothing layers offers far more versatility for combining multiple layers, and bypasses some of the major glitches of "hovering" mesh clothing layers such as alpha sorting issues, clipping issues, and reasonable limits on the number of layers.',
}
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