Use library textures to reduce lag?

It seems to me that using library textures where they're appropriate, rather than using a custom texture, would reduce lag because the library textures would be more likely to already be in the client's cache.

Does anyone (Strife?) know if the cache operates purely on UUID or does the sim enter into it, that is, if I have (say) "Fabric/Tie Dyed" in my cache because I saw it in (say) Perry, would SL use the cached copy when I see the same texture (with the same UUID) in Da Boom?

To the best of my understanding, sims have secondary caches in order to reduce requests on the asset server.

Textures are always referenced by UUID and if you are using a library texture, its UUID should be globally identical and if the sim caches are implemented correctly, if you do not have that UUID in your client cache, the sim should be able to satisfy it. Even a widely used non-library texture should exhibit these properties.

There have been some recent reasons to believe that there is some defect in the three layer cache system which cannot be conclusively affirmed nor denied based on available information.

Hope that helps some.

Thats the whole thing though with SL as with other platforms, LAG. Had LL decided not allow or to somewhat limit customization to a degree in this area we would see less lag because less people inclined to making thier own textures and/or creations would populate SL (IMO). I wouldn't be happy with builds if all I saw were really cool builds with textures only made up by LL. MMORPGs already do this for fast play and performance and usually don't allow customization because thier objectives and goals are completely different.

That was and still is a main appeal to me for being in SL. I can live with a little lag for the fact that my texture is just as much a part of me and whatever build as any other aspect of communicating. It's more than just slapping on a pretty picture and performance issues

a texture is half the build, if not 75% of it in some cases and to have the WHOLE if a build designed soley by the artist who dreamt it up come with alot of pride as well once the custom texture is in place and actually cooperates to thier needs.

I honestly didn't know as much about texture impact on any platform until I started implimenting my own in SL.

I think the Library textures are a great reference guide asto what can be done in SL and how it can be done or achieved (this includes lag reducing solutions) but in the end as LL has stated, SL is a platform in which things are derived on "Your World, Your Imagination" Keyword being "Your". Not "Ours" and certianly not "Thiers".

Didn't mean to get off topic (I'm not a tech guru myself on the numbers) but this is why I personally don't use library textures in my final or long term builds even to resolve lag issues.

I asked a similar question a while back, and got some pretty informative answers on it.

The thread is here.

Basically - the cache 'benefit' you get from Library textures isn't that they're pre-cached or anything: Its just that since we all share the same Library textures, there's a greater chance that someone else has already used them in a build around you - making for fewer unique textures.

The problem with many of the library textures, is that they're 512 x 512 Hogs. In many cases you may be better off importing your own textures that are 256 x 256 and below. Any of the library textures I've used at the Shelter - I've saved to disk first, and then re-imported at a much lower resolution - 128 or 256.

Good thing I wasn't recommending that, then!

But I've seen really cool builds that could have used Library textures for some of the textures they DID use without making a visible difference, so having familiarity with the Library textures and using them when they're appropriate should help reduce lag... if the cache works the way I assume it does.

There's also some free non-library textures, like the evil* textures, that are widely used. At first I thought that they would also provide the same kind of improvement... but separate copies of the texture probably have different UUIDs, so there's no win there.

I think that deserves more attention. I was surprised to find out how piggish the standard library textures can be. I'm sure LL has it on the 'To-do' list - but I'm betting it's waaaaaay down at the bottom.

That's what I was assuming, yes. But this advantage is reduced significantly if they're not fetched from cache when you see them on different sims... which is really where my question comes in.

It would be nice if there were a way to submit new textures to the Library, because there's a lot of very common free textures that you see used over and over again that might benefit from sharing a commin UUID... again, if my inderstanding of the cache isn't completely off.

It seems like the Lindens could collect data on such frequently used textures and handle them a bit differently. Perhaps they could even buy them from the creator for the library.

My first response to that was 'what a good idea' - it would give texture artists an incentive to be 'recognised' formally as it were, offer a cash incentive for creative input, provide a large, varied library, all sorts. Then I wondered how much you would sell a texture to LL for, considering how many times it would be used over - then I foresaw the sudden and drastic downfall of the livlihood of every person in SL who makes textures to sell

Bah.

I happened to notice, the other day, that the SAND texture in the library is 1024x512 - I agree the reduction of some of those texture sizes is overdue.

Ah yes, having widely used freebie textures more efficient would be horrible, horrible.

Getting a bit off-topic, but...

Theoretically, if SL does its job right, it shouldn't matter if a texture is, say, left at a native 512x512 or manually reduced to 64x64, except that the latter texture will be looking like crud if you get vaguely close.

SL's backend storage and on-the-wire format for textures offers progressive resolution - the 64x64 version of an image is just the 512x512 version, partially transmitted and decoded. That's a great technical decision for SL's purposes. The idea is that the client decides how 'much' of an image to receive and decode according to on-screen coverage; if a texture is sitting on a prim face that covers only around 64x64 pixels due to prim size and camera distance, then for practical purposes it's cheaply transmitted and decoded as a 64x64 texture, not a 512x512 one.

Of course, some textures just don't have the high-frequency detail to actually benefit from an increased resolution, so it's not like everything should be 2048x2048 - I guess it's up to the artist (uploader) to apply some smarts.

An extra fly in the ointment is that I doubt that SL's actual heuristics regarding resolution cut-offs quite matches the ideal; for example it's probably a bit greedy on the resolution levels in the name of speculative downloading, which keeps too much on the wire, aggrevating lag a little. Also, I love sharp-looking textures as much as anyone, but the higher-frequency progression levels often just don't carry their weight if the uploader erred on the side of 'HUGE TEXTURE PLEASE' as they often do, which isn't too bad for bandwidth but does blindly quadruple client-side texture memory usage for each relatively uninteresting extra progression level, with all that texture memory pressure implies. The SL servers could do a one-off visual cost/gains analysis of each of an uploaded image's frequency/progression levels to help the clients make better cut-off decisions, but I don't think this is done.

I used to think SL dynamically loaded textures into video memory at the best resolution too. Unfortunatly it doesn't seem to, when I played with OGLE it supplied me with separate low res and high res versions of each texture.

While it's quite possible that SL is just malfunctioning in this respect, I wouldn't take the above as a clear indicator for various reasons. For example, low-res versions of textures are cheap and handy to keep around a lot more persistantly than other versions, for instant access (when texture thrashing occurs in a tight area, you'll probably notice that the texture flicks down to the lowest-res level, that is to say it's rare for a texture to be totally evicted back to the grey-square stage - the cheap lowest-res version of the texture is instantly available and much less visually jarring). The presense of any higher-than-expected resolutions would likely be explained by (overly ) speculative loading and an understandable reluctance to drop over-large details levels which can stand in for lower detail levels where the opposite isn't as effective.

Good point. I'd do some tests if I had time, I'm well interested in the inner workings of SL. Unfortunatly, I don't have time. I wonder if a Linden would tell us if we asked nicely...

Another explanation of this would be a multipass resolution increase where a texture is first roughed-in with a low-res texture and then filled in with a higher-res version of the same. This conforms to what one sees in game.

I don't think the dual textures are used for MIP mapping as one can see Moiré patterns on high frequency textures seen at a distance.

I noticed that Yadni Monde biult out a new sim using very few textures, mostly just colored prims for many large buldings. It looks good, making me realize that selectively using colored prims with no textures is probably a good alternative to reduce texture lag.

Hmmm..This is very interesting. I had kind of decided the same thing after watching textures rez with higher resolutions as I get closer. I've noticed this quite a bit since the last update.

So lets say build X has ten 256x256 textures, and build Y had ten 512x512 textures. Does that mean that they will be using the same (or similar) bandwidth/resources when viewed from far away? and that the 512x512 will only need more bandwidth/resources when you get close eough for the highest resolution to be sent?



This is a great idea. I recently spent some time making tile-able version of some free textures. THen just a few hours later I found a build with the same texture - customized and uploaded by someone else. We could have saved some time if we knew that an SL version of the texture already existed.