Clear your cache!

[Qie Niangao]

Yesterday I was trying the Firestorm beta (mostly to see if those devs happened to do anything about my currently most annoying PBR misfeature) and took maybe an hour to tweak some PBR scales and offsets and correct a misapplied metallic-roughness map on a few surfaces. This morning I logged in with the Linden viewer, flew and teleported around other regions for like an hour, teleported back to that build and everything I'd fixed yesterday had reverted completely! They showed the old, pre-edited scales and offsets in the editor, and the wrong metallic-roughness map I'd corrected yesterday.

Puzzled and distraught, I logged off and switched back to Firestorm, and everything was un-reverted, my fixes still applied. That's a relief, for sure, but it means the Linden viewer was using cached copies of all that PBR Materials information, which I confirmed by clearing cache and restarting the viewer.

Is this caching behavior normal? Would I see the same thing if I tweaked Blinn-Phong textures and switched viewers? I've been doing that for many years and don't think I've ever seen this.

[Gabriele Graves]

Re-read the OP and realised that it's the caching behaviour of the LL viewer in question, not the FS viewer.

Answer: Seems like a bug in the new LL viewer to me.

Edited February 20 by Gabriele Graves

[Candide LeMay]

I have a separate settings file ("--settings" viewer parameter) with different cache locations for all the viewers/grids I use.

[Zalificent Corvinus]

52 minutes ago, Qie Niangao said:

That's a relief, for sure, but it means the Linden viewer was using cached copies of all that PBR Materials information, which I confirmed by clearing cache and restarting the viewer.

I think the correct response to the discovery that the Official Fail-Viewer, PBR Fubar Edition is a Fail, is best summed up with the words "I told you so".

 

Also, never use the SSAME cache for TWO different viewers. That's just ASKING for problems.

 

[Gabriele Graves]

I agree with @Zalificent Corvinus whenever there is a significant new update around assets (materials) or texturing, it's a good idea not the share the cache between two versions of the same viewer.

Edited February 20 by Gabriele Graves
changed once re-read.

[Qie Niangao]

Just to be clear, I certainly use different cache locations for each viewer which is only prudent—although in this particular case using the same cache might have prevented the problem I'm describing, although I'd still never try it.

There's nothing here to suggest a problem with the Firestorm beta; the problem was the Linden viewer was relying on its cache for information I'd never expect it to continue to use long after the objects' actual Materials properties had changed. (My hunch is, though, the same would have happened in the opposite direction too. Pretty unlikely Firestorm devs have gotten 'round to changing how PBR Materials caching works.)

I'll probably file a Linden bug report eventually, on the theory that changed PBR Materials are somehow overlooked in determining whether a cache entry is valid. But I'm kinda waiting in case somebody explains that this is all behavior everyone should expect so no need for a bug report. 

[Gabriele Graves]

Yeah, sorry that was my reading fail.  I've updated my posts.

[Love Zhaoying]

I wonder what other "settings" are unexpectedly cached - that would appear different between viewer only because of the caching? Or, is this behavior limited to PBR / materials type of settings?

[Zalificent Corvinus]

1 hour ago, Qie Niangao said:

I'll probably file a Linden bug report eventually, on the theory that changed PBR Materials are somehow overlooked in determining whether a cache entry is valid. But I'm kinda waiting in case somebody explains that this is all behavior everyone should expect so no need for a bug report. 

Parameters for the faces of rezzed objects are supposed to be stored as part of the data for the region, and sent to the viewers when somebody logs in,  walks or teleports there.

If the PBR Fubar Viewer is ignoring UDP packets and reading stuff out of it's cache, that is VERY VERY wrong, sounds like a "junior coder" who doesn't understand SL, trying to compensate for performance loss by taking a short cut.

 

"If we read the face settings from the cache we don't have to wait for all those pesky interest list UDP packets! Kewl Beanz! What could go wrong?"

 

File a Not-JIRA-Anymore, so they can fix that before throwing busted-ass merge code at TPV devs and demanding all the viewers be busted-ass.

[Qie Niangao]

Okay, I submitted https://feedback.secondlife.com/bug-reports/p/pbr-materials-in-cache-used-long-after-object-has-changed on the theory that I won't be the only one finding this behavior "unexpected" when they encounter it.

[Love Zhaoying]

33 minutes ago, Qie Niangao said:

Okay, I submitted https://feedback.secondlife.com/bug-reports/p/pbr-materials-in-cache-used-long-after-object-has-changed on the theory that I won't be the only one finding this behavior "unexpected" when they encounter it.

Good idea. "Why does this other viewer stink" is not a good look for PBR.

 

[Jaylinbridges]

18 hours ago, Candide LeMay said:

I have a separate settings file ("--settings" viewer parameter) with different cache locations for all the viewers/grids I use.

I think that's the only safe method when running multiple viewers.  And for both caches and other parameter files.  I need to find the options listed for those command line parameters for Firestorm.

Just assigning a different cache location for PBR and Release candidate in Preferences does not work with FIrestorm. The last cache used would have some parameters but the prior cache would still contain all the texture and object data.  Eg, I had a ReleaseCache folder, and a PBRCache folder, on a separate drive, specified in the Preferences/Network &FIles/Directories sections for Release and PBR Firestorm.   FS ignored the different caches, and just used the prior one, after adding basic cache structures to the specified one.  I had some unusual behavior with saved settings, since PBR and Release caches were still shared.

I know this is different than an SL Viewer and FS viewer caches interacting, no idea how that could be.

 

Edited February 21 by Jaylinbridges

[Henri Beauchamp]

TPVs do not use the same cache folders neither the same settings files than SL's viewer: each TPV uses its own private folders for caches and when sharing the same settings folder as SL's viewer (this is the case for my viewer), they use different settings file names.

There should be no interaction whatsoever between different viewer ”brands” related to cache and/or settings !

[Qie Niangao]

4 hours ago, Jaylinbridges said:

I know this is different than an SL Viewer and FS viewer caches interacting, no idea how that could be.

4 minutes ago, Henri Beauchamp said:

There should be no interaction whatsoever between different viewer ”brands” related to cache and/or settings !

In case these are referring to the situation I described in my original post, to reiterate, the problem was not that the different viewer caches interacted in any way but rather that the viewer relied on cached Materials information long after it was no longer valid in the sim.

The only relevance of there being another viewer involved at all was that I used that other viewer to make the changes in the sim, unbeknownst to the viewer that had cached an earlier version of those Materials settings.

If that was all obvious, sorry for the redundancy.

[Love Zhaoying]

17 minutes ago, Qie Niangao said:

unbeknownst to the viewer that had cached an earlier version of those Materials settings.

Since the cached information was not actually "valid"/"correct", doesn't that imply the caching scheme is not valid? Whether that means "materials should get a new UUID if properties change" (thus failing a cache check), or something else..?

In other words, it's not the "cache's fault" (data), it's the scheme used to determine if something is cached or changed that is at fault.

Hope that makes sense (whether or not you agree).

[Qie Niangao]

The cache is a black box to me. It's clear that the viewer did a fine job of populating the cache and using what was in there, but somehow it didn't know to get a replacement from the region. I imagine that could be the fault of the viewer or the region or even the foundational SL implementation of glTF Materials. I filed the bug report under viewer and supplied only viewer versions as "Platform" info but later changed that to include server version when regions were restarting and I remembered that for some reason the region is on the "Ferrari" release channel, which I've never actually seen anywhere else.

[Zalificent Corvinus]

1 hour ago, Qie Niangao said:

I imagine that could be the fault of the viewer or the region

Probably the Viewer, or else loads of people would have been complaining before this "I'm using viewer X and it doesn't show changes".

 

1 hour ago, Qie Niangao said:

or even the foundational SL implementation of glTF Materials

Test with an old pre PBR LL viewer? One of the project viewers maybe.

 

1 hour ago, Qie Niangao said:

some reason the region is on the "Ferrari" release channel, which I've never actually seen anywhere else.

O,O

Test on a main channel sandbox region.

 

[Qie Niangao]

Tried retesting and had to add this to the Canny report:

Quote

Well heck. I can't replicate this now. There's no question that it happened as reported, but trying to do the simplest repro now doesn't trigger the mistaken reliance on the old cached settings of the Material as applied to the build.

The one big change in my testing is that the Linden viewer updated to Second Life Release 7.1.3.7821226606 (64bit) so maybe that "fixed" it somehow? Nothing relevant stands out in the Release Notes "Resolved Issues" (but those are jira links so I can only judge by titles).

Or maybe it was just a fluke somehow? But it's not like I imagined it: there were easily a dozen distinct surfaces with different modifications that were ignored until I cleared cache.

Currently, the Ferrari channel region is running the same simulator version as the Main channel, but I couldn't replicate the problem on either channel today. The Ferrari region where it happened before hasn't (yet) been restarted for six days, long before the problem appeared, so that's not a factor in the failure to replicate there today.

[Gabriele Graves]

Surely the texture cache works something this?:

1. Viewer receives a bunch of texture UUIDs and associated version bytes for all the objects, etc. that are within draw distance.
2. Viewer checks each texture UUID to see if there is a cached copy.
3. If there is a cached copy, compares the version byte to decide whether it has the latest update.
4. If it's up-to-date it uses it to render with.
5. If it's not, the viewer requests the latest version of the texture and caches it along with the latest version byte.

The version byte would stop the viewer using an out of date set of textures which could be very wrong and then look weird when it all snaps to the correctly downloaded versions.

Edited February 21 by Gabriele Graves

[Zalificent Corvinus]

1 minute ago, Gabriele Graves said:

Surely the texture cache works something this?:

1. Viewer receives a bunch of texture UUIDs and associated version bytes for all the objects, etc. that are within draw distance.
2. Viewer checks each UUID to see if there is a cached copy.
3. If there is a cached copy, compares the version byte to decide whether it has the latest update.
4. If it's up-to-date it uses it to render with.
5. If it's not, the viewer request the latest version of the texture and caches it along with the latest version byte.

The version byte would stop the viewer using an out of date set of textures which could be very wrong and then look weird when it all snaps to the correctly downloaded versions.

Therein lies the possible problem.

Textures/meshes don't NEED version checks, if you alter a texture/mesh, and re-upload, it's a DIFFERENT texture/mesh with a different UUID.

The exception to this would be BOM bakes, where it always re-streams.

Other ALM-PB Materials parameters, the tint colour and numeric params and scaling/offsets, are part of the OBJECT, and sent in the UDP packets that tell the viewer to fetch textures and meshes from CDN/Cache.

 

But GLTF presets are not textures/meshes, but not objects, they are a bunch of settings that should be part of the packet data for what the material is applied to. If somebody decided that GLTF presets are "just a texture pack" and nerfed the reading of the properties from the object in favour of a cached version because "textures don't change ever, right? same UUID, same texture/settings", that might cause this kind of problem.

 

Hmmm.

13 minutes ago, Qie Niangao said:

But it's not like I imagined it:

Had an auto update to the LL viewer since noticing the problem?

 

[Qie Niangao]

2 minutes ago, Zalificent Corvinus said:

Had an auto update to the LL viewer since noticing the problem?

Yeah, that's what I was mumbling about with this:

17 minutes ago, Qie Niangao said:

The one big change in my testing is that the Linden viewer updated to Second Life Release 7.1.3.7821226606 (64bit) so maybe that "fixed" it somehow? Nothing relevant stands out in the Release Notes "Resolved Issues" (but those are jira links so I can only judge by titles).

[Gabriele Graves]

9 minutes ago, Zalificent Corvinus said:

Therein lies the possible problem.

Textures/meshes don't NEED version checks, if you alter a texture/mesh, and re-upload, it's a DIFFERENT texture/mesh with a different UUID.

How does the viewer know not to render the original mesh/textures for an object in it's cache when there is going to be a replacement set of mesh/textures with different UUIDs?

Update: Or is it that those mesh/textures are associated with the object UUID and the viewer just renders the cached version until a new set also associated with that object UUID is received?

Edited February 21 by Gabriele Graves
possibly answered my own question

[Zalificent Corvinus]

13 minutes ago, Gabriele Graves said:

How does the viewer know not to render the original mesh/textures for an object in it's cache when there is going to be a replacement set of mesh/textures with different UUIDs?

The viewer renders  whatever objects/textures it's told about in the "interest list" sent via UDP packets from the server, it checks to see if it has the received UUID's in the cache, if it doesn't, it streams them from the CDN.

 

That's why interest list UDP packet loss causes invisible objects you can't walk through. The Server knows the wall is there, and wont let you walk though it, but your viewer didn't get valid data to either load from cache or stream from CDN, so it shrugs and gives up.

 

Server: "Attention viewer, your  user can see Gabby's Skybox, UUDI [data destroyed by cloudcrap], textured with wall tex 01 UUID [data destroyed by cloudcrap]

Viewer: "Huh? if you don't tell me the UUID, I can't find if I have it, or request it if I don't"

 

Those "old outdated versions" sit in cache unused until they get rotated out and replaced with some other cached content.

 

[Prokofy Neva]

I usually have clear my cache several times on a typical day in SL. Maybe it's my 250,000+ inventory which is sorted quite a bit into folders -- too many likely, mostly induced by merchants who produce these folders when you click to move the contents into inventory from a HUD.

But it has to be done or things won't rez for me at all. It's hugely frustrating.

Meanwhile, I have one friend, to be sure with a better computer set-up than me, who never clears their cache. They fear clearing their cache and haven't in like 10 years for fear of losing content.

This makes me wonder if I should just stop clearing my cache too, as I never have the same number of my loaded inventory on any given day, even if I haven't added or subtracted from it.

Yet...I want to see the world.

: (

[Ceka Cianci]

This reminds me of what would happen using say, The Emerald viewer and making changes to your avatar.. Then going into another viewer and be in the avatar you had before making the changes..

They had this whole huge to do, about users having the same experience across every viewer.. I wonder if they have to put in some sort of fix or whatever  it was they did years ago, where every PBR viewer will have to line up in the same way?

It's been awhile since all of that so I don't remember much about it.. But it does sound similar in a way.

Edited February 23 by Ceka Cianci