Here's a new feature request on the Second Life JIRA worth following, submitted by Firestorm developer Beq Janus, who explains her reasoning for it in a New World Notes comment:
As was raised in the past in this blog, one of the problems we face in Second Life is inefficient content design, and a move that encourages the creation of high resolution (1024) textures as part of a default workflow is going to lead to a worsening of this situation. To this end I have proposed an amendment to the viewer (and server) that would allow for the simplified creation of multiple resolutions in a single transaction. Ultimately I would like to see this generate a range of resolutions from a single (high resolution) source image, for a single upload fee. I think the feature has value without the single fee change, but the take up would be far lower. The hope is that with such a feature, artists and creators can work with high-resolution images and the viewer will produce multiple resolution uploads allowing the creators to test the appearance and make better decisions about when a 1024x1024 image is really needed.
The UI mock-up pictured here is part of Beq's proposal in the JIRA, a way to subtly encourage mesh creators to avoid uploading unnecessarily resource-heavy, poorly optimized textures which are now choking SL performance:
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.
Strikes me as a good idea. Beq's JIRA has been marked "Accepted", but it doesn't seem to be an assigned to a Linden developer just yet. The more people watching it, I suspect, the more likely it'll be put into official the development queue.
Well, it might make a difference but fixing the fitted/rigged mesh LOD bug/loophole/exploit would be, ahem, huge. Yep stuff will break but hey from the script point of view stuff has been broken before.
And multi-onion-layer bodies (hows that BOM thing going again?).
Confession - we are not in the schmatter/plastic natasha biz so not exactly seeing any carrot here but willing to adjust. Hey, make the upload cost of textures for use inworld an exponential function of texture size (1024 = 20 bucks, say). Now there's a stick/carrot.
Posted by: sirhc desantis | Tuesday, February 26, 2019 at 08:03 AM
There seems to be a massive disconnect here. People who work on the tech side think everything needs to be dumbed down for performance reasons and then you've got the hardcore players who don't care about moving as long as their photos on Flickr look amazing.
The proposed solution is not going to make either side happy. I can tell you right now none of the people who sell popular mesh items are going to reduce the resolution on their textures. If they could use 4096 they would because it would get them more sales from the people who actually spend money. No fashion creator is going to cater to people with potato computers who don't shop.
I get where both sides are coming from. But I have to say, if you have a decent computer these texture issues are far less of a concern then they are being made out to be. Sure you aren't getting 120 fps like other popular games, but SL barely needs 30 fps to feel fine and the people who are paying the bulk of Linden Lab's rent want high rez photos for their social media fan club. Even if that means they are only getting 10 fps. They simply don't plan on moving around that much.
As far as the other side is concerned, if you want to play flight simulator or racing game, there's better platforms for that. If you want to play a combat RPG, there's better platforms for that. If you want to sit around and chat with friends while looking amazing, well, SL is hands down the best thing for that. Just don't expect it to perform like those other games.
Posted by: Summer Haas | Tuesday, February 26, 2019 at 08:42 AM
Aren't mipmaps (like mesh LOD, but for textures) supposed to handle the dynamic resolution of textures? I thought SL had mipmap support? (I've seen a WIKI entry somewhere about it but can't find it) If so, how does this work into mipmaps? Is SL's mipmap implementation poor?
Posted by: vwfan | Tuesday, February 26, 2019 at 11:09 PM
Nevermind. I think I get the point of this feature now. It's not about some dynamic resolutions thing but rather allows people to explore various texture sizes without the penalty of L$ for those multiple texture sizes. Seems like a handy feature to have IMO.
Posted by: vwfan | Tuesday, February 26, 2019 at 11:29 PM
That tech is otherwise known as mipmapping. It works really well in SineSpace
Posted by: Trilo | Friday, March 01, 2019 at 01:38 PM