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

[BUG-20171] It's time for higher resolution textures (2048x2048) #2854

Closed
3 tasks
sl-service-account opened this issue Jul 13, 2016 · 6 comments
Closed
3 tasks

Comments

@sl-service-account
Copy link

sl-service-account commented Jul 13, 2016

How would you like the feature to work?

Uploader should allow 2048x2048 texture resolution — possibly only enabled per account after a mesh and content theft style "test" which provides some basic information on texture budgets and video memory.

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

In the 13 years since SL has been around, two major changes have created a substantial need for higher resolution textures. First is the typical display resolution of SL residents. I don't have any stats from SL users, but for general trends http://www.w3schools.com/browsers/browsers_display.asp provides some insight into what sort of display resolutions are common.

of those who visited that site:
10 years ago, 83% had a resolution of 1024x768 or lower
today, 49% have a resolution of 1920x1080 or higher, with the majority being in the "higher" category

Second, with the introduction of mesh and 64m objects, certain features like large floors or exterior walls with baked lighting have created a need for very large textures to keep a reasonable ratio between texture pixels and screen pixels at normal viewing distances. Using up 4 texture faces to build a 2048x2048 out of four 1024x1024 textures is possible but eats up half of the usable faces for a mesh.

Certainly this could open the door to even more of a problem with video memory bloated with too much texture data, but with a little information before the door opens, many creators would pick up some information which would help them make smarter decisions about how they use textures in their work, potentially improving the overall texture budgeting of the grid's designs, rather than worsening it.

Links

Duplicates

Related

Original Jira Fields
Field Value
Issue BUG-20171
Summary It's time for higher resolution textures (2048x2048)
Type New Feature Request
Priority Unset
Status Closed
Resolution Unactionable
Reporter Mel Vanbeeck (mel.vanbeeck)
Created at 2016-07-13T19:22:19Z
Updated at 2019-04-18T14:51:11Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-07-13T19:05:02.833-0500',
  'How would you like the feature to work?': 'Uploader should allow 2048x2048 texture resolution — possibly only enabled per account after a mesh and content theft style "test" which provides some basic information on texture budgets and video memory.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'In the 13 years since SL has been around, two major changes have created a substantial need for higher resolution textures. First is the typical display resolution of SL residents. I don\'t have any stats from SL users, but for general trends http://www.w3schools.com/browsers/browsers_display.asp provides some insight into what sort of display resolutions are common.\r\n\r\nof those who visited that site:\r\n10 years ago, 83% had a resolution of 1024x768 or lower\r\ntoday, 49% have a resolution of 1920x1080 or higher, with the majority being in the "higher" category\r\n\r\nSecond, with the introduction of mesh and 64m objects, certain features like large floors or exterior walls with baked lighting have created a need for very large textures to keep a reasonable ratio between texture pixels and screen pixels at normal viewing distances. Using up 4 texture faces to build a 2048x2048 out of four 1024x1024 textures is possible but eats up half of the usable faces for a mesh.\r\n\r\nCertainly this could open the door to even more of a problem with video memory bloated with too much texture data, but with a little information before the door opens, many creators would pick up some information which would help them make smarter decisions about how they use textures in their work, potentially improving the overall texture budgeting of the grid\'s designs, rather than worsening it.',
}
@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-07-14T00:05:03Z

Please don't even go there until BUG-9898, BUG-2514 etc are fixed.
I feel you're being optimistic in suggesting creators will use the 2048x2048 textures in a sensible way. There is already a huge problem with creators slapping 1024x1024 textures on many tiny objects like buttons & door knobs causing texture memory to max out in a scene.

@sl-service-account
Copy link
Author

Chaser Zaks commented at 2016-07-14T06:54:42Z, updated at 2016-07-14T06:55:10Z

I don't trust (a majority, not all but a majority) content creators with this level of responsibility. All I can see is 8 faced jewelry with 8 unique 2048x2048 textures. There is already an abundance of polygons, this would just make it worse.
As for a "test" for the users to go through, LL did a mesh test on copyright, it did nothing. People just clicked through and corrected stuff until they got through, then went ahead and uploaded models from GTA or other games.

@sl-service-account
Copy link
Author

Mel Vanbeeck commented at 2016-07-14T08:56:24Z

Yes, I agree that a certain level of optimism is needed for this type of advancement, but as 4k monitors become the norm in the coming years, 1024 textures will eventually just be completely inadequate. The jump will need to happen some time. The parallel between the effectiveness of the mesh upload "test" isn't really useful. Obviously it's not going to stop people from doing illegal things just by telling them it is illegal. Chances are they already knew that stealing was stealing. Texture uploads would be similar only to the extent that people that don't care won't change their behavior, however, this is one area where many people just don't understand the issue of textures, limited video memory and SL's performance. With a little info on the basics of texture budgeting, you'd at least have some gains to counter the losses of foolish or ignorant designers. There could be other incentives post-authorization-test to use smaller textures, as well, such as changing the upload fee based on texture size. If a 1024x1024 was increased to 20L, and 2048x2048 to 40L, people may think a little deeper about uploading a dozen massive images when a smaller 10L image would suffice.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2016-07-14T09:35:48Z, updated at 2016-07-14T09:39:02Z

It's utterly ridiculous at the moment that any resolution should cost L$10 to upload.

In a time when LL is crunching down on Avatar Complexity, they need to next reform the texture upload costs with more evaluation, such as texture format, presence of an alpha channel, resolution ratio and of course, resolution size.

Then you might see costs like:

opaque 1x1 - 256x256: L$10
alpha 1x1 - 256x256: L$15
opaque 512x512: L$40
alpha 512x512: L$60
opaque 1024x1024: L$160
alpha 1024x1024: L$240

Texture uploads to the asset server need to be treated as investments, not recreational like they are with my.secondlife.com

A cost range for textures will hopefully force creators to use better judgement with their implementation and revitalize the beta grid's purpose for experimentation and testing.

@sl-service-account
Copy link
Author

Ansariel Hiller commented at 2016-07-14T12:01:52Z

2048x2048px textures with 4 channels use 16MB of memory per each texture. Given the fact that the LL viewer can effectively use 368MB for textures (that's what you get if you choose 512MB in the graphics preferences!), you can exactly show 23 of those high-res textures in a scene. Now figure JohnDoe JewelryMaker that slams that on his bling bling stuff...

@sl-service-account
Copy link
Author

Kyle Linden commented at 2016-07-20T19:02:11Z

Hi Mel,

Thank you for your suggestion. The team has reviewed your request and determined that it is not something we can tackle at this time.

Please be assured that we truly appreciate the time you invested in creating this feature request, and have given it thoughtful consideration among our review team.

This wiki outlines some of the reasoning we use to determine which requests we can, or can't, take on: http://wiki.secondlife.com/wiki/Feature_Requests

Thanks again for your interest in improving Second Life.

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