[BUG-232082] Prim scale controlled texture resolution

[sl-service-account]

How would you like the feature to work?

This one is kind of hard to explain but I'll give it a try. And, note I'm not talking about mipmapping, because this feature would actually reduce the download size before being retrieved from the server. Whereas mipmapping takes a high resolution and splits into many smaller resolutions and keeps them hanging around in memory and the goal with that is to improve fidelity as you zoom in. The goal with this feature instead is to eliminate the need for the delivery of that extra data to begin with in situations where that fidelity isn't needed.

The feature request is for a checkbox flag on the Texture tab "Autoscale Resolution" or even "Thumbnail Mode"

• It would automatically lower the resolution of the texture being downloaded to for example 256x256 based on the scale of the prim it is in
• It could even be a dynamically chosen square based resolution based on the scale of the prim displaying the texture; e.g. scaling to 10% of a 1 meter prim could 10% a 1024 texture and is equal to 102.4 which snapped to the next square resolution would be 128 that is then divided by 2 to give 64, so the texture delivered would be 64x64. Whereas, a prim sized at 0.5 m could 50% a 1024 texture and that is equal to 512 which is already a square resolution and this is then divided by 2 to give 256, so the texture delivered would be 256x256.
• By default this checkbox would be disabled so most prims would load textures as normal.
• However, object creators who would be okay with this downscaling for performance reasons on objects they know don't have as much screen space requirements could turn it on for their products.
• And, if a customer scaled up the size of the object, the texture resolution provided would be automatically increased causing a redownload of the higher resolution texture.
• In other words, the original 1024x1024 texture is still on the server, it just is downscaled before transmitting it to the avatars visiting the region when in view based on the size of the object.
• The reason you wouldn't turn this on by default for all objects is that everything would look like trash and pixelated then. This is only meant for situations where someone needs to display many thumbnails where the quality isn't expected to be high; e.g. a texture organize board, vending system, playlist carousel with band album covers, massive walls of profiles at dating agencies, land estate auctions, date bidding boards, etc.
• And, now that I think about it. It should be face based and not the prim, because you could have a 8 face mesh where each face represents the thumbnail. And, really the physical surface area of the face is what needs to be used to determine the resolution scaling and not necessarily the link's own scale. But, for now prim scale could be used to get the idea working and calculating based on face area could be experimented with later.
• Another byproduct of this feature is that signs this is used on would download and display very quickly.

• Something interesting that a scripter could do using this is; when an image (say on a multi-product vendor sign) is clicked on, they could scale up the prim temporarily in the center to "show off" the product and the texture would automatically increase to the higher resolution version. Then when the user clicks another image and they scale the prim back down it automatically gets set to the lower resolution while the newly selected prim's texture shows the higher resolution of that one. This would all work automatically with the checkbox enabled.

  Example: I make a ticket board that gives prizes (they're free prizes, the tickets have no value). The sign only shows small square prims that exhibit thumbnails of the prizes offered.

  Currently, I have to make certain to provide a small resolution texture for each of the signs. If I were to instead upload a 1024x1024 texture for each of these signs it would quickly add up.

  Everyone visiting the sim would:

• Be downloading a large quantity of texture data
• Filling up their system and video card RAM with this texture data

• Experiencing lag

  This feature request is important because I'm working towards polishing the sign as a product and currently I make a conscious effort to choose to provide low resolution textures. But, once this is a product, customers who own the board and upload their own thumbnails would most likely just upload the default 1024x1024 textures without giving it another thought. Even if I warn them not to in the documentation.

  Another Example: I used to display a pet board where people visiting the region could display pictures of their real life pets. It was popular, but the lag didn't justify keeping it out. I was able to briefly solve the performance issue by just taking a high resolution screenshot of the whole board, splitting it into two 1024x1024 textures and putting back out as two prims instead of a hundred smaller prims. But, it became tedious to maintain and update it in this way so I stopped putting it out. However, if this autoscale resolution existed I could go back to maintaining such a board as separate faces.

  Sorry that this particular concept is so difficult to break apart and explain. Hope I was clear enough.

  I've attached screenshots of my ticket board so you can see an example; these thumbnails were chosen at 256x256 displayed on 0.5 m prims because at that size the text is still legible, the image is "good enough" and the board is low lag even though it is displaying many images.

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

  Would provide large performance gains and save a great deal of bandwidth for LL (saving on costs) and for customers. Which would benefit people in countries where their internet is metered.

Attachments

• prize_example.JPG 2022-04-26 06:00:08
• prize_zoomed.JPG 2022-04-26 06:00:57

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-232082 | | Summary | Prim scale controlled texture resolution | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Not Applicable | | Created at | 2022-04-26T09:45:03Z | | Updated at | 2022-04-26T10:34:20Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'How would you like the feature to work?': 'This one is kind of hard to explain but I\'ll give it a try. And, note I\'m not talking about mipmapping, because this feature would actually reduce the download size before being retrieved from the server. Whereas mipmapping takes a high resolution and splits into many smaller resolutions and keeps them hanging around in memory. The goal with this feature is to eliminate the need for the delivery of that extra data to begin with.\r\n\r\nThe feature request is for a checkbox flag on the Texture tab "Autoscale Resolution"\r\n\r\n* It would automatically lower the resolution of the texture being downloaded to for example 256x256 based on the scale of the prim it is in\r\n* It could even be a dynamically chosen square based resolution based on the scale of the prim displaying the texture; e.g. scaling to 10% of a 1 meter prim could 10% a 1024 texture and is equal to 102.4 which snapped to the next square resolution would be 128 that is then divided by 2 to give 64, so the texture delivered would be 64x64. Whereas, a prim sized at 0.5 m could 50% a 1024 texture and that is equal to 512 which is already a square resolution and this is then divided by 2 to give 256, so the texture delivered would be 256x256.\r\n* By default this checkbox would be disabled so most prims would load textures as normal.\r\n* However, object creators who would be okay with this downscaling for performance reasons on objects they know don\'t have as much screen space requirements could turn it on for their products.\r\n* And, if a customer scaled up the size of the object, the texture resolution provided would be automatically increased causing a redownload of the higher resolution texture.\r\n* In other words, the original 1024x1024 texture is still on the server, it just is downscaled before transmitting it to the avatars visiting the region when in view based on the size of the object.\r\n* For testing purposes, this checkbox could be off for all objects for now unless turned on explicitly. But, perhaps in the future, it could be forced enabled for all objects if it was found to be assisting greatly in bandwidth, memory and graphics performance.\r\n* And, now that I think about it. It should be face based and not the prim, because you could have a 8 face mesh where each face represents the thumbnail. And, really the physical surface area of the face is what needs to be used to determine the resolution scaling and not necessarily the link\'s own scale. But, for now prim scale could be used to get the idea working and calculating based on face area could be experimented with later.\r\n\r\nExample: I make a ticket board that gives prizes. The sign only shows small square prims that exhibit thumbnails of the prizes offered.\r\n\r\nCurrently, I have to make certain to provide a small resolution texture for each of the signs. If I were to instead upload a 1024x1024 texture for each of these signs it would quickly add up. \r\n\r\nEveryone visiting the sim would:\r\n* Be downloading a large quantity of texture data\r\n* Filling up their system and video card RAM with this texture data\r\n* Experiencing lag\r\n\r\nThis feature request is important because I\'m working towards polishing the sign as a product and currently I make a conscious effort to choose to provide low resolution textures. But, once this is a product, customers who own the board and upload their own thumbnails would most likely just upload the default 1024x1024 textures without giving it another thought. Even if I warn them not to in the documentation.\r\n\r\nAnother Example: I used to display a pet board where people visiting the region could display pictures of their real life pets. It was popular, but the lag didn\'t justify keeping it out. I was able to briefly solve the performance issue by just taking a high resolution screenshot of the whole board, splitting it into two 1024x1024 textures and putting back out as two prims instead of a hundred smaller prims. But, it became tedious to maintain and update it in this way so I stopped putting it out. However, if this autoscale resolution existed I could go back to maintaining such a board as separate faces.\r\n\r\nSorry that this particular concept is so difficult to break apart and explain. Hope I was clear enough.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Would provide large performance gains.\r\n', } ```

[sl-service-account]

palisade.coronet commented at 2022-04-26T10:34:21Z

Probably can't be implemented, removing...