Jump to content

Should LL Incentivize Use of Smaller Textures By Charging More to Upload Large Ones?


You are about to reply to a thread that has been inactive for 889 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

16 minutes ago, Profaitchikenz Haiku said:

Is there any chance of extending the Firestorm 32-bit option to limit textures to 512 so that the 64-bit viewrs can take advantage of it? Or is reducing the texture size not a cache-storage operation but a GPU-loading one and so would further increase the processing?

It is already an option. In 32-bit it is mandatory, due to the memory limitations but in 64 bit you can set it form the rendering tab in the preferences

d5d769852495b3730d36ddd03e32c731.png

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

6 hours ago, Ayeleeon said:

I think this would have a very negative impact on the SL art scene.

It shouldn't. We're only talking about reducing the texture resolution to what can be displayed on the screen so it wouldn't make any difference to the texture's actual appearance.

 

2 hours ago, Beq Janus said:

One idea that I have proposed before is to give all the sizes for a single upload fee. Given that (excuse the broad sweeping generalisation here .....) most people upload at the highest resolution, the space cost of providing all the lower power of two textures is an extra ~33%.

Maybe better to implement true mipmapping with the lower resolution versions of the texture being generated automatically by the uploader. LL must have considered this when they created SL and I'm not sure why they decided against it. But I would guess they decided the extra bandwidth and VRAM wasn't worth it.

Link to comment
Share on other sites

6 minutes ago, ChinRey said:

Maybe better to implement true mipmapping with the lower resolution versions of the texture being generated automatically by the uploader. LL must have considered this when they created SL and I'm not sure why they decided against it. But I would guess they decided the extra bandwidth and VRAM wasn't worth it.

Progressive texture encoding is a product of SL's age, back then we barely had DSL.

We did play about with only loading full resolution textures and it didn't work out .. because the CDN appears throttled and wont deliver content even close to the bandwidth we have.

Link to comment
Share on other sites

Big textures are only a problem because the texture loader in the viewer is too dumb. That was supposed to be fixed as part of Project Interesting, and there are bits of code which clearly try to do something, but they don't work.

As I've mentioned before, I've been working on this for my own experimental Rust/Vulkan based viewer, where I can try out advanced approaches without dealing with legacy C++ code. Here's an early test. (This is a long way from being useful to end users.)

http://www.animats.com/sl/misc/accessmalltest.mp4

This is simply a video of looking around a fashion shopping event with many high-detail images. You can see textures loading and grey objects becoming textured. There's a lot of texture level of detail swapping going on for distant objects, but most of that isn't visible.

Note the absence of blurry objects in close-up. This improves the shopping experience. You can see all the displays.

The rules used for texture loading are simply this:

  • Try to load and unload textures to maintain one texture pixel per screen pixel.
  • Texture loading priority is based on screen area involved.
  • Constantly adjust the loading queue as the viewpoint moves.

Unless you get close to an object, the system won't load a high-resolution texture. So it doesn't matter if you have 1024 x 1024 or even 2048 x 2048 textures. By the time you get close enough to load such a texture, the object is filling most of the screen and deserves to be loaded. If you never get that close, the detail is not loaded. If you get close enough, you will always get the full texture. Fast.

Technical notes:

  • Beq Janus points out that this is not optimal for some cases with texture atlases, but in practice that doesn't seem to come up much. Testing continues.
  • Efficiently adjusting the loading queue on the fly is somewhat difficult technically. Fortunately there's a standard Rust library to do much of the heavy lifting. This reduces the priority change overhead from O(N) to O(log N). The standard C++ priority queue in the STL is useless for this, because you can't change the priority of a queued object. The Boost priority queue, maybe.
  • This works better if you have multiple threads on multiple CPUs working on the problem, so queue updating does not affect the FPS. If you have to do this from the main draw thread, it may reduce frame rate.

 

  • Like 2
  • Thanks 4
Link to comment
Share on other sites

8 hours ago, Coffee Pancake said:

There is an active SL art scene?

Indeed there is! And indeed they would go out of business or raise prices which are very modest as it is, to enable "SL scale" of prices compared to RL.

You can't just look at the final product of a painting and its upload from, say, a RL work. There are many works that involve 3D scenes, sculptures, mixed media, etc. that have all kinds of uploads on the way to creating them. 

Link to comment
Share on other sites

From a content creator's perspective, the difference between L$10 and L$64 is negligible, you'll make it back on the first sale.

With web browsers starting to support the AVIF format, I haven't seen anything about its use in game engines yet. Is it feasible for Second Life, would it trim 50% from file sizes and squeeze more textures into your memory.

Edited by Mr Amore
  • Haha 2
Link to comment
Share on other sites

14 hours ago, Paul Hexem said:

To be fair, for most people when they log into SL and get a fraction of the FPS they get in everything else they play, that would appear to be a thing that's broken.

"why does the fps suck in this game" I hear it daily,  I explain to them why, "that's such bull****, they should fix it, delete everything and start the game over"  daily..

Link to comment
Share on other sites

5 hours ago, Mr Amore said:

... and squeeze more textures into your memory.

It won't really. Cache memory is hardly ever really an issue. It's VRAM that is a common bottleneck and the texture files stored there have to be in decompressed raw format.

A more efficient compression would reduce bandwidth but AVIF is known to be slow to decode so it would probably increase the load time.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Anyone familiar with Tom's?

 

https://forums.tomshardware.com/threads/how-important-is-vram-for-gaming.3316086/#:~:text=So high-res textures (1024x1024,smaller versions) %3D 6 MB.

 

Edit: Some creators are including both 1024s and 512s in their products so you can change the texture to a lower res if you need to.

Edited by Silent Mistwalker
  • Like 1
Link to comment
Share on other sites

6 hours ago, Silent Mistwalker said:

Anyone familiar with Tom's?

I wasn't and that's a really interesting web page, thank you!

I have two questions and one comment about it and I think I'll have to page @Beq Janus or @animats again.

Quote

A texture is actually stored in multiple sizes in VRAM (Mip Mapping), so the card can just grab the appropriate-size texture for how large the object will appear on the screen, instead of having to scale down the size of the texture every time.

Is this true for Second Life? SL does generate mipmap textures automatically but based on the data from FS' obejct inspect function I understood that these are not stored in the VRAM.

 

Quote

So high-res textures (1024x1024) end up taking (1024^2 pixels)*(4 color bytes)*(1.5 for smaller versions) = 6 MB.

This formula stipulates that all textures are stored in VRAM with four channels even if they only have three. That's what FS' implies too but is it correct?

These two factors make quite a bit of difference. For a 1024x1024 it means:

  • Three channels, no stored mipmaps: 3 MB
  • Four channels, no stored mipmaps: 4 MB
  • Three channels, stored mipmaps: c. 4.5 MB
  • Four channels, stored mipmaps: c. 6 MB

---

Quote

2k textures take 4x as much, or 24 MB. 4k textures take 4x as much again, or 96 MB. So unless you're using 2k or 4k textures, there isn't really much danger of running out of VRAM. If the game is running with a thousand different 1k textures loaded, it'll still be at about 2.5 GB of VRAM. Typically, a game only keeps a few hundred textures loaded at once

There seems to be a typo in that quote, a thousand 1k (that is 1024x1024) textures use about 6 GB of VRAM according to the formula in the previous quote from the same post. But in any case, this does not apply to Second Life since it's not at all unusual for a scene there to have several thousand textures.

---

Oh, and a final question to the experts, not related to the article:

20 hours ago, animats said:

...

That was supposed to be fixed as part of Project Interesting, and there are bits of code which clearly try to do something, but they don't work.

One thing that showed up during the Project Interesting mayhem was that profile pics were loaded into VRAM and they were even given priority over scene textures. I don't mean your own profile pic only but every single profile pic for every person on your friends list, every group you were a memeber of, every person who had posted something in a chat you had open and every person in the same region as you and in neighbours regions. One of the tricks some of us learned back then to reduce texture thrashing, was to close all group chats the moment they popped up. How are profile pics handled nowadays, are they still wasting tons of VRAM?

Edited by ChinRey
  • Like 1
Link to comment
Share on other sites

On 10/18/2021 at 9:43 PM, Beq Janus said:

Perhaps we could even buy items that allow us to pick the texture resolution we'd like to have in use?. 

The knowledgeable amonst us would be able to make informed choices to great benefit, no doubt. Other users (the vast majority, 90+%?) will surley just think, "I want it to look good, I'd better get the big one."

The choice would need to take account of the client's system, too, making it impossible for the creator to even suggest a recommendation?

On 10/18/2021 at 6:45 PM, Chic Aeon said:

We HAVE made progress getting creators to make better LODs (and physics for the most part) but I doubt that anything will change the way they use textures.  For many folks a 1024 texture looks better. And it does, I agree. But for me there needs to be a point where "looks" are balanced by "usability".  As long as the highly textured and often dense mesh items sell --- I doubt seriously that many creators will make a change.  

Chic alluded to the creator's likely perspective of this. Add in the likely user's perspective as well and I strongly recommend keeping well away from walls suitable for banging your head on!

If things like this don't happen automatically, they're unlikely to happen at all. Never lose sight of the audience you're playing to!

  • Like 1
Link to comment
Share on other sites

5 hours ago, Jennifer Boyle said:

 

On 10/18/2021 at 11:52 AM, Silent Mistwalker said:

Please stop trying to fix things that are not broken. They should be fixing what actually is broken and completing things left half done (EEP) instead of nickel and diming us to death. LL is not hurting for profit.

This is one misconception that has helped keep SL stagnated for a decade.

Fix the boogs is no different from shouting at the sky "why are hemorrhoids". If the gods can even hear us, they have no idea what we're so upset about.

Fixing the boogs implies things are broken (and specifically misbehaving). This mess we have is working as expected. By design. This is it. On purpose. Bought and paid for.

The problems and weirdness are typically misunderstood features, intentional part of the architectural design or long lost oddities that we have built entire systems around and LL have gone to great lengths to replicate.

We need new systems designed from scratch. We need to accept that content may just break as a result. We need to very clearly be saying in with the new and we will replace everything lost.

 

Link to comment
Share on other sites

On 10/18/2021 at 8:52 AM, Silent Mistwalker said:

Please stop trying to fix things that are not broken. They should be fixing what actually is broken and completing things left half done (EEP) instead of nickel and diming us to death. LL is not hurting for profit.

Charging different rates for texture uploads isn't about making a profit, it's about changing the behavior of creators. Where does the average SL resident learn about the importance of using the right texture? It's buried on the internet and will never be seen unless sought out. I don't think a price change should be necessary though. Just a little pop-up message every single time you upload that either explains the need for good texturing or links to a website. 

  • Haha 1
Link to comment
Share on other sites

28 minutes ago, Bree Giffen said:

Just a little pop-up message every single time you upload that either explains the need for good texturing or links to a website. 

All that will do is annoy people who have been in SL for more than a few weeks especially when all they are doing is uploading a profile pic which are treated as textures.

The more of this sort of thing you throw at people the lower the retention rate will fall. Complicating something that is already complicated isn't a smart move.

IF LL is going to do something like that, they need to make it part of the beginner's tutorial.

22 minutes ago, Coffee Pancake said:

and the first thing FS will do is disable the prompt via some unfindable checkbox

I doubt it. More than likely they'd put it in prefs where it will be searchable and easy to find.

Edited by Silent Mistwalker
  • Like 2
Link to comment
Share on other sites

8 hours ago, Silent Mistwalker said:
8 hours ago, Coffee Pancake said:

and the first thing FS will do is disable the prompt via some unfindable checkbox

I doubt it. More than likely they'd put it in prefs where it will be searchable and easy to find.

We'd make it a dismissable "stop nagging me" box I expect, findable and, yes, findable in the prefs. I added the notice to the rigging tab to ask people to stop attaching everything to right hand. That was not a popup just used some available space. That had to go when the lab added the new weights list box.

On 10/19/2021 at 11:08 PM, ChinRey said:
Quote

A texture is actually stored in multiple sizes in VRAM (Mip Mapping), so the card can just grab the appropriate-size texture for how large the object will appear on the screen, instead of having to scale down the size of the texture every time.

Is this true for Second Life? SL does generate mipmap textures automatically but based on the data from FS' obejct inspect function I understood that these are not stored in the VRAM.

This is a misunderstanding. MipMaps and discards are two separate things. MipMaps (true mipmaps) are GPU hosted and frequently GPU generated. In SL we have discards which as CPU side versions of MipMaps, whilst they are similar beasts I would be wary of considering them as the same because the GPU has nothing to do with Discards. 

As for memory...you are right.. in so far as perhaps the inspect is wrong. 

The VRAM and TRAM numbers are calculated based solely on the size and number of components (RGB & A), they do not account for discards or any such thing which is not really very correct. That said, it might reflect a misunderstanding on my part so I won't say categorically that it is wrong, but I would consider adding a third to all those numbers to be safe. I will make a note to revisit those sometime. If you feel like raising me a jira to remind me to look at it again please do, they serve as a good TODO list, not that I have any shortage of TODO items 🙂 

Having said all that, the Tom's hardware thread seems to be scattered with miscalculations. The cost of Discards/MipMaps is ~33% not 50% each smaller size being 25% of the previous thus 100%+25%+6.25%+1.56%+0.78% 

  • Like 2
Link to comment
Share on other sites

37 minutes ago, Beq Janus said:

We'd make it a dismissable "stop nagging me" box I expect, findable and, yes, findable in the prefs.

As an irregular FS user, we seem to have very different ideas about what findable means :P

In all seriousness, between the 3.4 million checkboxes in a bucket by the door and pathologically renaming everything else .. I can't find a thing in FS.

A search is based entirely on the premise that the searcher has some idea what the checkbox of their desires might be named.

 

Link to comment
Share on other sites

2 hours ago, Coffee Pancake said:

A search is based entirely on the premise that the searcher has some idea what the checkbox of their desires might be named.

This is very true, and at the risk of repetition (bzzzz....) I had this in mind earlier in the thread when I asked could there be a guide for the non-coderatti to say what some/all of the many available tweak buttons actually do, when they should be used, and what happens if you eat too many of them at once?

Link to comment
Share on other sites

On 10/18/2021 at 1:36 PM, Ayeleeon said:

There are several Sims dedicated to art, full of art galleries run by SL artists. I doubt all of these would continue if suddenly it cost 64L to upload a 1024x1024 texture, that already is reducing the resolution of the original quite a bit.

If the fate of SL art truly depends on whether a texture upload costs a nickel or a quarter, it's doomed and best to put it out of its misery already.

(Also, IMHO, SL art would be vastly improved if it weren't so focused on 2D textures anyway. Sure, there are accomplished SL image artists, but in general the genre so underappreciates the medium.)

That said, I have no idea if the proposal would have the desired effect. Certainly there are plenty of occasions where a 1024x1024 image is simply needed, and certainly there are many more where it's a complete waste of download bandwidth (whatever it does to rendering, which seems much less a problem than everybody fusses about: un-downloaded textures render fast enough, but it's not very satisfying).

Someone mentioned the beta grid being inaccessible for a long time, which was indeed annoying, but for the purposes of testing textures there's almost always an option of using local textures without any upload cost—nor delay: after it's incorporated in a practiced workflow, it's both faster and more convenient to use local session textures.

On 10/18/2021 at 5:03 PM, Katherine Heartsong said:

And as an aside, the textures I upload for my artworks are 1024x683 (as all my work is done is a 3:2 format for SL). I spend a lot of time on my original works getting the textures right, I don't want them pixelated.

I found this confusing. All SL textures are converted on upload to power-of-two resolutions, so a 1024x683 image will be stored at 1024x1024. I'm not sure now if the original aspect ratio is stored with the texture when the uploader performs the conversion; that might make this worth doing even though I'm skeptical that uploader scaling is as good as the several options offered by Gimp.

Link to comment
Share on other sites

9 minutes ago, Qie Niangao said:

Someone mentioned the beta grid being inaccessible for a long time, which was indeed annoying, but for the purposes of testing textures there's almost always an option of using local textures without any upload cost

But not for clothing items where you would need Bake on Mesh?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 889 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...