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

[BUG-5893] This feature is aimed to avoid the use of "appliers" in mesh body parts and mesh wearables #13802

Open
3 tasks
sl-service-account opened this issue Apr 29, 2014 · 5 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Apr 29, 2014

How would you like the feature to work?

The viewer should interpret a number of conventional texture UUID (not corresponding to a fixed texture the way invisiprims worked) replacing them with a set of baked textures obtained by skin and wearables worn from the avatar displaying the given conventional texture.

IE the texture with UUID 0000-0000-0001 and -002 should be replaced by the baked skin and the five tattoos (upper part and lower part)
texture with UUID 0000-0000-0003 and -0004 by the baked version of all the 5 undershirt and 5 underpants baked together.
5 and 6 shirt and pants, 7 jacket.
Also cumulative textures should be allowed, like -0010 for skin+tattoos+undershirt -0011 for skin+tattoos+undershirt+shirt

and so on...

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

This would allow every skin designer to support every custom body part without having to provide specifically designed "appliers", scripted objects only working for that specific brand or part.
What designers would be required to do sholud be just to apply the conventional texture uuid, IE for skin and tattoos to the mesh body and have it textured with the skin and tattoos currently worn by the default avatar.

Making baked textures available to designers shouldn't represent a potential security issue because nobody should be able to save a texture given its UUID.
Nor an IP violation, since a user is required to own that specific skin and/or wearable to have it textured on the mesh part using the conventional baked texture.
It would immensely increase the empowering of users, allowing the creation of mesh attachments that could be used in conjunction of existing wearables.
It would save designers the burden of creating and supporting a plethora of appliers in order to have their creations work for a fairly high number of mesh attachments to be sellable.

Links

Related

Original Jira Fields
Field Value
Issue BUG-5893
Summary This feature is aimed to avoid the use of "appliers" in mesh body parts and mesh wearables
Type New Feature Request
Priority Unset
Status Been Triaged
Resolution Triaged
Reporter Quinn Ying (quinn.ying)
Created at 2014-04-29T08:28:41Z
Updated at 2017-11-08T16:32:37Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-05-11T00:39:16.679-0500',
  'How would you like the feature to work?': 'The viewer should interpret a number of conventional texture UUID (not corresponding to a fixed texture the way invisiprims worked) replacing them with a set of baked textures obtained by skin and wearables worn  from the avatar displaying the given conventional texture. \r\n\r\nIE the texture with UUID 0000-0000-0001 and -002 should be replaced by the baked skin and the five tattoos (upper part and lower part)\r\ntexture with UUID 0000-0000-0003 and -0004 by the baked version of all the 5 undershirt and 5 underpants baked together.\r\n5 and 6 shirt and pants, 7 jacket.\r\nAlso cumulative textures should be allowed, like -0010 for skin+tattoos+undershirt -0011 for skin+tattoos+undershirt+shirt \r\n\r\nand so on...',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'This would allow every skin designer to support every custom body part without having to provide specifically designed "appliers", scripted objects only working for that specific brand or part.\r\nWhat designers would be required to do sholud be just to apply the conventional texture uuid, IE for skin and tattoos to the mesh body and have it textured with the skin and tattoos currently worn by the default avatar.\r\n\r\nMaking baked textures available to designers shouldn\'t represent a potential security issue because nobody should be able to save a texture given its UUID.\r\nNor an IP violation, since a user is required to own that specific skin and/or wearable to have it textured on the mesh part using the conventional baked texture.\r\nIt would immensely increase the empowering of users, allowing the creation of mesh attachments that could be used in conjunction of existing wearables.\r\nIt would save designers the burden of creating and supporting a plethora of appliers in order to have their creations work for a fairly high number of mesh attachments to be sellable.',
}
@sl-service-account
Copy link
Author

China Lubitsch commented at 2014-05-11T05:39:17Z

That would be really great. Even more simple, and flexible, there could be an option at run time for meshes in the Edit panel that allows to choose "baked head texture" or "baked upper texture" or "baked lower texture" as a texture for the mesh. If the option is thicked, the mesh texture is overridden with the corresponding baked texture, otherwise the mesh shows its own texture.

@sl-service-account
Copy link
Author

Alexa Linden commented at 2014-05-22T18:15:27Z

Thank you for your suggestion.

@sl-service-account
Copy link
Author

Quinn Ying commented at 2014-06-10T09:27:11Z

Why even logged users can't vote anymore?

@sl-service-account
Copy link
Author

Quinn Ying commented at 2014-06-17T07:08:04Z

Why logged people coming here can't vote anymore for this feature?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-06-17T07:20:18Z

Heya Quin,

This issue is in a resolved state and you cannot vote on issues that are in a resolved state. This is just the way that JIRA works. There is an improvement request for the makers of JIRA to allow voting on resolved issues - see https://jira.atlassian.com/browse/JRA-13360

The reason this issue is in a resolved state is because Linden Lab have already triaged it - which means they have already looked at the proposal and discussed it at one of their meetings.

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