I would also like to suggest an adjustment of Land Impact calculations should 2k textures be allowed.

Right now Land Impacts quickly balloon just because a basic cube is 4mx4m for example, but a 1 million vertice 1m object can be quite low.

As per my other post, textures (for me and others I know) appear to be the bottleneck, the lag causer, and even FPS drops as textures try to load in.

I might be an advocate of larger 2k textures, but as long as the actual 'texture load' of the asset is taken into account in the Land Impact.

So for example, if the texture load is 8mb (because only 1 or 2 texture sets/faces are used) it would have a lower impact than say the same product with 8 x different 2k materials. Obviously the download and display of bigger textures and MORE of them definitely impacts things.

It would also encourage creators to seek ways (and learn) better ways of texturing, and they would be rewarded with this by having great looking products (as some do by now, but by using 8 x 1024s!), but at a much lower Land Impact because they optimized their use of textures.

So yes, let them go ahead and use 8 x 2k textures on their jewelry or 2m piece... when they upload, perhaps there Land Impact will count quite high.

I believe allowing 2k textures to the majority out there is going to make SL chug even more than it does right now. The issue I find from my hours and hours of studying other people's work as I learned what and what not to do in SL has shown a serious overuse of multiple textures on many things. Or turning on the texture console and see the complete tsunami of textures that I only see 5% of... then I move an inch and another flood of textures comes in, and all the while seeing FPS drop.

In fact I would say that my FPS is directly linked to how many textures (and their sizes) are trying to load into my viewer at any said moment.

One can go to a land, or their own where there are less textures, and the FPS is gained.

That being said, 2k textures are good (and required for large areas, trim sheets) like big walls, buildings, and terrains so we at least have a decent Texel Density to work with. My projects are really targeting 512px/m, which seems suitable for SL as people use it with over-shoulder cam distance, and would require (maybe) a 2k texture for a 4m wall (I'm working with 4m x 4m sections and 2k texture).

Even then with clever trimming, depending on the object, MUCH MUCH can be done with just a 1k, with quite acceptable appearance, and with a combo of a trimsheet + tiling texture strategy, tons and tons can still be done.

My concern is that the average user (and even some experienced creators!) will do as they do now - overdo it with up to 8 x 1k textures, regardless of the product size.

I'm all for 2k textures, because I know I can use them efficiently. Most of my models and products are maybe 1-2 textures if that - so it won't be a problem for me, and it would be great for me!

But for the average (or less-experienced), it may/could cause a chug-fest.

I am in the beta grid in the region "rumpus room 2048" I am trying to upload 2048 px textures with the latest viewer "Second Life Release 7.1.5.8472515256 (64bit)" but I always get that error, is it a normal error? Do you know when this capacity will be available in the main grid? I have several projects to finish and I don't know if it would be advisable to wait to be able to use this texture size

Still wish that APNG request from long ago had gotten traction. That said, my bigger concern would be loading times and bandwidth. Bandwidth for SL assets probably doesn't grow on trees, and sending larger assets can eat into that depending upon the content, resulting in tighter margins for LL. Maybe 2048x2048/4096x4096 textures for premium members to help make up for their added server costs? Maybe even a slider called "maximum texture size" for everyone so that users with less Bandwidth/VRAM could choose to see the smaller texture? Just adding thoughts.

This is just going to encourage creators to use 2048x2048 for every single part of their item and have it, if more creators actually used a UV map that wasn't a single texture for each piece, i'd be for it.

I'm for this. Unfortunately my JIRA request for 4k has been lost, where I provided a way around the issues a lot of people have with this feature.

Essentially, my jira entry requested that the client negotiate with the server and let it know it can't handle 4k either because of hardware or network issues or if the user selected they didn't want the 4k in prefs. The server can then automatically downscale the texture and cache it on the server-side on the fly at a lower resolution, e.g. 512x512. If it's been a long while, e.g. weeks or months (this interval is up to LL to mitigate server storage costs), since that texture has been requested then the server can automatically delete the old lower resolution cache file for that texture automatically to free up space at the lab.

This completely solves the performance and networking issues everyone has with the feature while allowing 4k for the users that desire and can handle it. Effectively the client can auto-dial in the tightness of the resolution.

LL will have to sit down and have a meeting about feasibility; the proper intervals to put on storage times, and how to implement the feature in a cost effective way. But, I think it can be managed. Also, if they're worried about cost they could make 4k a premium account feature, and even the premium accounts could turn it off if they don't want it. Since there are way more non-premium users, they would all still stay on non-4k and put less burden on LL.

Also, my other amazon glacier storage (lower cost) archival feature request was lost from JIRA, which if paired with the 4k feature attempt would also help mitigate costs and make this all possible. That feature request was: detect if textures haven't been accessed in years (the amount of time is up to LL to decide is reasonable) and use Amazon Glacier to move the textures into cold storage. Cold storage costs mere pennies compared to active storage, Amazon states it is 68% cheaper than the usual storage costs. The only problem with cold storage is that it takes time for it to be unfrozen (1–5 minutes) so you'd have to display an indicator or something letting people know a texture is being unfrozen, maybe the texture itself says "BEING UNFROZEN" or something on it. This would rarely happen, literally people would have had to not view a texture for several years for it to have been frozen. Why this is important is that right now LL has a massive amount of data stored that it is financially buckling under. If they can glacier storage a large amount of content that hasn't even been touched in years it can mitigate such a large amount of cost that not only can they hire more engineers but it would cover the cost of storing 4k textures and even the cost of the caching idea I mentioned above. They'd want to set up an AI that can go through the images and make sure to not include lewds in the cold storage, however.

My webp jira entry was also lost and if they implemented that; storage space for all images would be lower, network bandwidth usage would be lower, and we would also get animated webp instead of having to convert gifs to textures with 3rd party tools.

One thing I'd really like to know, is how the viewer is going to handle partial textures.

It was mention during CCUG/TPVD meetings that viewer now only requests up to X resolution texture if it does not need a higher resolution version, which is great in theory... but what happens if:

The viewer decides it wants up to 512x512 texture due to low memory, or graphics settings etc. and the source texture is 2048x2048. Due to Jpeg2000 format, that is fine, the viewer partially decodes the texture and uses it, however, what about all the compression artefacts? 512x512 is 16x less pixels than 2048x2048 and compression optimizes for space usage in general, meaning that if you did download 2048x2048 texture, and downsampled it to 512x512, the end result will look a lot better than partially decompressed image from 512x512 worth of data.

Not to cause strife, but those opposed for the sake of VRAM are the biggest contributors to Second Life falling behind. The introduction of PBR is a start towards a modern engine but a long ways away. Any new features aren't going to be ideal for some, but it's either progress with loss or stagnation with loss.

The Valve Source Engine supports 2048, and that was in 2004 ... Second Life must move with the times or be left behind.

Count me among the opposed.

However, what I would suggest is at least the possibility to reallocate the texture area, so you could for example upload a texture that is 2048 pixels wide but only 512 pixels tall. Useful for panoramas!

Seems a lot of arguments against this, are actually arguments for it. You don't want a ton of VRAM used up in textures, and yet people are just using a ton of 1024s on different faces to get what they want.

You say that the texel density is too high, without counting mip maps and discard levels that could be set per-viewer to whatever maximum detail level you like.

Then there's the ways in which 2 and 4K textures could be used to increase efficiency. Why have seperate 1K textures for each and every part of a thing, when you can have a single high rez map, with everything intelligently UVmapped onto it? Only one texture to load and then half your entire scene is taken care of.

Yes, bad creators will always make bad things, and they will continue to make bad things regardless. This should not be used as a reason to not implement changes that could, in the hands of people who know how to work with them, result in regions actually running and loading faster than if they were limited to 1K textures.

If your worries are based on trying to negotiate the insanity of the Madlands with a 2GB video card, well, that's already a lost cause and always has been. It's always been in your power to lower your viewer's max detail levels. Nothing will change that.