Water Ripple missing in second life as of yesterday.

[bigmoe Whitfield]

10 hours ago, Alwin Alcott said:

for me it's depending on the water setting

phototools blackwater



whirly water

I believe one relies upon a default water texture and the other one does not.  if I am remembering right @Ardy Lay might know more.

[Ardy Lay]

28 minutes ago, bigmoe Whitfield said:

I believe one relies upon a default water texture and the other one does not.  if I am remembering right @Ardy Lay might know more.

That is correct.

[Conifer Dada]

I have the same problem - completely flat water. I also have another problem, possibly connected with the water . . .

Standard "bumpiness" not showing.

None of the standard 'bumpiness' textures are showing - I mean the ones you can select from the build editor, such as concrete, tree bark, discs etc.  Other user-created bump maps are showing fine but not the standard LL ones.

I haven't changed any of my settings. I use the standard LL viewer.

Edited August 28, 2022 by Conifer Dada

[Henri Beauchamp]

8 minutes ago, Conifer Dada said:

I have the same problem - completely flat water. I also have another problem, possibly connected with the water . . .

Standard ”bumpiness” not showing.

None of the standard 'bumpiness' textures are showing - I mean the ones you can select from the build editor, such as concrete, tree bark, discs etc.  Other user-created bump maps are showing fine but not the standard LL ones.

I haven't changed any of my settings. I use the standard LL viewer.

Same problem: these textures used to be *.j2c files distributed with the viewer, but in recent (?) viewers, they are no more bundled and must instead be downloaded from the servers. Obviously, someone at LL did a blunder and removed the corresponding texture UUIDs from the servers tables/database...

I wonder why LL removed the textures from the distributed files in the first place: the latter allowed (and still allow, for v1 viewers) a much faster ”rezzing” of all those commonly used textures...

[Conifer Dada]

Further to my previous post, I followed the suggestion to visit the sim Debug1. When I arrived the sea had ripples on, like it should be. I then returned to a beach near my home and the ripples were there too.  So half the problem is solved.

The other half of the problem, missing bumpiness, still exists. I rezzed a sphere and applied bumpiness to it and it stayed smooth.

Edited August 28, 2022 by Conifer Dada

[arabellajones]

In all this talk about textures going missing, whether a texture, a bump-map, or a specular-map, I can see reasons why LL have moved them from being part of the viewer download to being part of the general download-from-server system.

But we still seem to have very old defaults for the cache and the download bandwidth, and other elements that could affect these.

My understanding is that the "bandwidth" setting only affects UDP traffic, and texture downloads now use HTTP. Most of us have a far higher total download capacity, but are some of us pointlessly increasing that "bandwidth" setting?

A bigger-than-default cache size should help, though some of us do have disk-space limits.

Could these default textures be better handled by distinct cache-like storage which only deleted a file when an update was available? Done right, this pseudo-cache could be applied to different viewers but I am not sure I could trust the Lindens to get that right.

How many people, complaining about these missing-texture problems, have even bothered to report their cache-size?

 

[Henri Beauchamp]

30 minutes ago, arabellajones said:

I can see reasons why LL have moved them from being part of the viewer download to being part of the general download-from-server system.

I can't... It seems like a bad move, and this incident demonstrates it. I mean, these textures are used every session by everyone: why would you (or LL) think that having to transfer them over the network and cache them would be a better solution than having them stored as part of the immovable, immediately available, viewer files ?

30 minutes ago, arabellajones said:

My understanding is that the ”bandwidth” setting only affects UDP traffic, and texture downloads now use HTTP. Most of us have a far higher total download capacity, but are some of us pointlessly increasing that ”bandwidth” setting?

The sim server to viewer UDP bandwidth setting is of absolutely no concern here since, indeed, all textures are now transferred via HTTP from CDN servers in SL (this is not the case in OpenSim where baked textures are still local to the sim server and thus transferred via UDP). Also, the UDP bandwidth is auto-throttled by a custom viewer/server protocol, and the ceiling is determined by the server, so you can without any fear raise your UDP bandwidth to the max (it helps rezzing faster on arrival in a sim); note that throttling does not even happen any more nowadays (each sim server can serve simultaneously like a hundred 10Mbps UDP clients or even more).

30 minutes ago, arabellajones said:

A bigger-than-default cache size should help, though some of us do have disk-space limits.

.../...

How many people, complaining about these missing-texture problems, have even bothered to report their cache-size?

The cache size is not an issue, as long as it is not made ridiculously small: the cache is coded so that textures used often will not get evicted (i.e. the textures that have not been seen/used for the longest time are evicted first, when part of the cache is purged to keep it under its max size).

30 minutes ago, arabellajones said:

Could these default textures be better handled by distinct cache-like storage which only deleted a file when an update was available? Done right, this pseudo-cache could be applied to different viewers but I am not sure I could trust the Lindens to get that right.

I have this kind of ”static” cache implemented for the Cool VL Viewer, for UI sounds, because those are sadly not part of the UI elements bundle that LL allowed to redistribute with TPVs (here again, I do not see the reason why). The full story behind this feature can be found here.

But why coding a separate cache when the files could simply be made part of the viewer installation (like they used to be for the textures that went missing today) ?... It still puzzles me how people think it is best to complicate things, sometimes...

Edited August 29, 2022 by Henri Beauchamp

[Love Zhaoying]

I guess LL is "lucky" that the "bumpiness" issue didn't impact oh say, every single avatar appearance. 

If it did, it would probably be fixed quicker.

[Count Burks]

After visiting the Debug region to download the texture again the issue returned today. I did not even Clear Cache. Having to visit the Debug region every couple of days is also not much of a fix.

Is it not possible to directly download the texture and put it in some folder of the viewer? Maybe it will be fixed this week during the update. Otherwise anyone has ideas to place this texture in a viewer systems folder?

[Qie Niangao]

Presumably the cache flushes textures that are (more or less) the Least Recently Used (LRU), so assuming these special textures are treated as normal cached entries, I'd expect that a large enough cache, and having rippled water around to look at occasionally, would keep it available.

On the other hand, one might imagine that going shopping at some landlocked events could load enough textures to make the water ripples the least recently used. Other, non-LRU caching algorithms exist but are usually more overhead than they're worth in  all but specialized applications.

[Count Burks]

28 minutes ago, Qie Niangao said:

Presumably the cache flushes textures that are (more or less) the Least Recently Used (LRU), so assuming these special textures are treated as normal cached entries, I'd expect that a large enough cache, and having rippled water around to look at occasionally, would keep it available.

On the other hand, one might imagine that going shopping at some landlocked events could load enough textures to make the water ripples the least recently used. Other, non-LRU caching algorithms exist but are usually more overhead than they're worth in  all but specialized applications.

I have a 2GB texture cache and constantly near ocean water. It would be strange for that particular texture to vanish so fast.

[animats]

Seems to be OK today. I went to Bug Island/60/22, where there's a row of spheres with an example of each built-in bump map. Starting Firestorm from a clear cache, they all looked fine. The ocean was rippling fine, too.

Check the dirt in the pot around potted Linden street trees. That uses the built in bump maps.

The built-in bumpy textures are from the days before materials. Those are strange and special, equivalent to normal maps but stored as greyscale depth maps. There's brick, concrete, dirt, etc. They are expected to be on the asset servers. There's a file built into the viewers with that short list of UUIDs.

Did LL perhaps do a purge of unused textures from the asset servers, and forget to keep the special textures known to viewers? LL supposedly runs a cleanup job once in a while to recover disk space. Those textures aren't used in the ordinary texture UUID slots of in-world or inventory objects. So something has to tell the purge of un-referenced assets not to delete those.

[Aishagain]

6 minutes ago, animats said:

Did LL perhaps do a purge of unused textures from the asset servers, and forget to keep the special textures known to viewers? LL supposedly runs a cleanup job once in a while to recover disk space. Those textures aren't used in the ordinary texture UUID slots of in-world or inventory objects. So something has to tell the purge of un-referenced assets not to delete those.

This makes me wonder.  some time ago I noticed that none of those pre-materials bump texures appear to work on objects I was editing and dismissed the issue as trivial.  The above makes perfect sense to me.

I suspect that when hiring newer staff the Lindens have failed to impress upon them that some of SL's considerable legacy assets are in fact of some use!

Another argument in favour of a considerable overhaul of the system?

Edited August 29, 2022 by Aishagain

[Monty Linden]

No interns can be blamed for this event.

[Love Zhaoying]

Can we add a "Fudge Ripple" option? I like that flavor!

[Love Zhaoying]

1 hour ago, animats said:

Did LL perhaps do a purge of unused textures from the asset servers, and forget to keep the special textures known to viewers? LL supposedly runs a cleanup job once in a while to recover disk space. Those textures aren't used in the ordinary texture UUID slots of in-world or inventory objects. So something has to tell the purge of un-referenced assets not to delete those.

That kind of thing was my guess but was told "no". ("Did the asset get deleted?") I liked the explanation of how it was bundled with the installs, etc. 

[Ardy Lay]

I am sitting here trying to imagine that I somehow caused this problem.  Hmm...  I reported that viewers were falling back to UDP asset transfers when the HTTP transfers were either timing out or giving 404 errors and that the simulator hosts were fulfilling these asset requests via UDP.  I wasn't quite right about what was happening.  Turns out the users were deliberately disabling "HTTP textures" in their viewers.

What if these "legacy textures" were never made available to the CDN(s) and were still being delivered via UDP by the simulator hosts and somebody turned that off in a recent simulator host software release because it was brought up in conversation, investigated, and determined to be undesirable?

Did I do that?  😉

[Ardy Lay]

6 minutes ago, Love Zhaoying said:

That kind of thing was my guess but was told "no". ("Did the asset get deleted?") I liked the explanation of how it was bundled with the installs, etc. 

Yes!  Viewer installers user to have quite a few world textures bundled within them.  Some were in the default skins texture folder and some were in a folder named "local_assets".

[Chic Aeon]

Nacon's Water (in FS and other 3rd party viewers), fixes this for me.

Edited August 29, 2022 by Chic Aeon
spelling