You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
Update the existing clothing system to support 1024x1024 textures and specular/normal maps.
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.
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.
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.
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.
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.
{
'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.',
}
The text was updated successfully, but these errors were encountered:
How would you like the feature to work?
Update the existing clothing system to support 1024x1024 textures and specular/normal maps.
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.
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.
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.
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.
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
The text was updated successfully, but these errors were encountered: