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

[BUG-226352] Generating multiple resolution textures in a single upload. #4917

Open
sl-service-account opened this issue Feb 15, 2019 · 1 comment

Comments

@sl-service-account
Copy link

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.

https://i.gyazo.com/e390bbb1beec630fedf6a17123c666af.png

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.',
}
@sl-service-account
Copy link
Author

Fenix Eldritch commented at 2019-03-08T17:16:10Z

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 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