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 Feb 28, 2024. It is now read-only.
When uploading a texture, allow the automatic generation (through the existing viewer-side scaling) of smaller textures. Ideally, this would be provided for a single upload fee charge, though the complexity the stems from that (how about textures that auto upload with a mesh? what about the creators who take the time to create custom textures for different sizes?) perhaps make that more trouble than not.?
A mockup XML UI could look as follows.
It extends the existing XML to include a multi-checkbox choice of target sizes (note that the size would represent the long edge of any non-square texture.) and also adds an option to append the size (_NNNN) to the uploaded images.
I think that this is a good extension to the upload capability, a further extension could be to preview the different resolutions.
This is one of a number of improvements that ought to be made in this space, it is the simplest and requires least work.
Why is this feature important to you? How would it benefit the community?
Marcello Resident: "Something is rotten in the state of Second Life"
Horatio Resident : "Lindens will direct it"
We have a growing problem with image texture size and the excessive use of the maximum texture size irrespective of the surface area of the mesh it is applied to. Encouraging more responsible use of textures is a stick and carrot task. The stick comes in reform of the land impact and complexity calculations to properly attribute texture density and related resource usage to the rendering cost of an item. The carrot comes in making it simpler for a creator to try the textures and strike the right balance between their "need" for detail and the (render) cost of the object. This change makes a simpler pipeline for importing and managing textures, if the fees are waived for the smaller textures then I think the default would be to bring them all in and experiment, whereas today the creator will most likely slap on whatever looks best and not give it a second thought.
This is not going to change behaviour on its own or overnight, but it helps make it easier to do the right thing.
Original Jira Fields
Field
Value
Issue
BUG-226352
Summary
Generating multiple resolution textures in a single upload.
Type
New Feature Request
Priority
Unset
Status
Accepted
Resolution
Accepted
Reporter
Beq Janus (beq.janus)
Created at
2019-02-15T14:01:08Z
Updated at
2019-03-08T17:16:09Z
{
'Build Id': 'unset',
'Business Unit': ['Platform'],
'Date of First Response': '2019-03-08T11:16:09.658-0600',
'How would you like the feature to work?': 'When uploading a texture, allow the automatic generation (through the existing viewer-side scaling) of smaller textures. Ideally, this would be provided for a single upload fee charge, though the complexity the stems from that (how about textures that auto upload with a mesh? what about the creators who take the time to create custom textures for different sizes?) perhaps make that more trouble than not.?\r\n\r\nA mockup XML UI could look as follows.\r\nIt extends the existing XML to include a multi-checkbox choice of target sizes (note that the size would represent the long edge of any non-square texture.) and also adds an option to append the size (_NNNN) to the uploaded images.\r\n\r\n!https://i.gyazo.com/e390bbb1beec630fedf6a17123c666af.png!\r\n\r\nI think that this is a good extension to the upload capability, a further extension could be to preview the different resolutions.\r\n\r\nThis is one of a number of improvements that ought to be made in this space, it is the simplest and requires least work.',
'Original Reporter': 'Beq Janus (beq.janus)',
'ReOpened Count': 0.0,
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': 'Marcello Resident: "Something is rotten in the state of Second Life"\r\nHoratio Resident : "Lindens will direct it"\r\n\r\nWe have a growing problem with image texture size and the excessive use of the maximum texture size irrespective of the surface area of the mesh it is applied to. Encouraging more responsible use of textures is a stick and carrot task. The stick comes in reform of the land impact and complexity calculations to properly attribute texture density and related resource usage to the rendering cost of an item. The carrot comes in making it simpler for a creator to try the textures and strike the right balance between their "need" for detail and the (render) cost of the object. This change makes a simpler pipeline for importing and managing textures, if the fees are waived for the smaller textures then I think the default would be to bring them all in and experiment, whereas today the creator will most likely slap on whatever looks best and not give it a second thought. \r\n\r\nThis is not going to change behaviour on its own or overnight, but it helps make it easier to do the right thing.',
}
The text was updated successfully, but these errors were encountered:
I wonder if there would be any merit to having unique inventory icons to denote the long dimension instead of (or in addition to) appending "_nnnn" to the file name?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
How would you like the feature to work?
When uploading a texture, allow the automatic generation (through the existing viewer-side scaling) of smaller textures. Ideally, this would be provided for a single upload fee charge, though the complexity the stems from that (how about textures that auto upload with a mesh? what about the creators who take the time to create custom textures for different sizes?) perhaps make that more trouble than not.?
A mockup XML UI could look as follows.
It extends the existing XML to include a multi-checkbox choice of target sizes (note that the size would represent the long edge of any non-square texture.) and also adds an option to append the size (_NNNN) to the uploaded images.
I think that this is a good extension to the upload capability, a further extension could be to preview the different resolutions.
This is one of a number of improvements that ought to be made in this space, it is the simplest and requires least work.
Why is this feature important to you? How would it benefit the community?
Marcello Resident: "Something is rotten in the state of Second Life"
Horatio Resident : "Lindens will direct it"
We have a growing problem with image texture size and the excessive use of the maximum texture size irrespective of the surface area of the mesh it is applied to. Encouraging more responsible use of textures is a stick and carrot task. The stick comes in reform of the land impact and complexity calculations to properly attribute texture density and related resource usage to the rendering cost of an item. The carrot comes in making it simpler for a creator to try the textures and strike the right balance between their "need" for detail and the (render) cost of the object. This change makes a simpler pipeline for importing and managing textures, if the fees are waived for the smaller textures then I think the default would be to bring them all in and experiment, whereas today the creator will most likely slap on whatever looks best and not give it a second thought.
This is not going to change behaviour on its own or overnight, but it helps make it easier to do the right thing.
Original Jira Fields
The text was updated successfully, but these errors were encountered: