Second Life News 2013-30

I’ve been hoping the SSA feature would roll to the entire grid. The Lindens just aren’t listening to me. The main channel is going to get the Experience Tools package, which is an infrastructure upgrade that is basically invisible to us.

Content and Mesh Meeting 2013-30

Content and Mesh Meeting 2013-30

Blue Steel get the package that ran  on Le Tigre last week. This is bug fixes and a change to Materials handling to improve performance. It gets the Experience Tools upgrade and may be a fix or two.

Magnum and Le Tigre are going to get the SSA package. It updates to include the Experience Tools update and a couple of fixes. The combined region count for Le Tigre and Magnum is near 4,000 regions.

The way this is going we might see all three RC channels running SSA in week 31.

While it seems that SSA is working well something else is amiss. I’ve been seeing more textures on objects that just never render. Others stay blurry forever. It has made it very difficult to enjoy Hair Fair. I can’t really reproduce the problem on demand, so I have yet to file a JIRA. It seems others are in the same boat. The Lindens seem unaware of the problem. Also, it is not happening to everyone. But, I am seeing more people mentioning it.

Loki mentions it in his blog post: We’re sorry, but something went wrong.

I’m also hearing more about it in various groups.

If you can reproduce the problem on demand, please file a JIRA.

 Firestorm Materials

One of the Firestorm team members is saying said the Materials version of Firestorm will be going to the beta testers ‘soon.’

Texture Thrashing

This is the term used when you see a texture on an object fully render, then go blurry and start reloading. The process repeats without end. This is a case of the video ram filling up. The card then starts unloading some textures to make room for rendering other textures. The card is cycling through its list of textures that need to be rendered. Because the card is discarding previously rendered textures it still needs the list can never be completed.

Along with that problem some are seeing the viewer request new downloads of the textures. That indicates a caching problem. For some reason the cache is failing to supply the texture. The repeated downloads throw unnecessary load on the viewer and servers.

This is another problem where the Lindens need more information. If you are some place and see that happening please file a JIRA report.


Some are noticing some problems with Materials. Full Bright does some odd things that don’t look right. In some cases colors get washed out. When you see problems file JIRA’s.


There seems to be a rash of little problems. These are the types of problems that Lindens and their QA teams are not seeing.


4 thoughts on “Second Life News 2013-30

  1. I noticed my home looking somehow foggy or the walls slightly glowing. Maybe that is related. It started with the materials update.

  2. The “texture trashing” is mostly seen when memory gets low (or more exactly, when the virtual address space gets full: we are speaking about “only” 2, 3 or 4Gb here, depending on the OS (32/64bits) and its OS/application memory split setting) on the CPU side (albeit it could happen with VRAM filling up on *very* old graphics cards, since all “new” cards have much more VRAM than the viewer will ever use). It’s a problem with the “discard level” (at a 0 discard, the texture is shown at full resolution, at a 1 discard at half the resolution, etc…) which is yo-yoing on close textures because the viewer can’t find far textures that can be “discarded” enough to make room in memory for the closer ones: when the discard level increases, the textures get blurrier and the memory usage decreases, which allows the discard level to decreases on close textures (making them crispier again), but which also raises again the memory usage, etc, etc…

    In the Cool VL Viewer I implemented a proportional discard level calculation and an hysteresis to minimize this effect but it can still be seen sometimes happening in extreme conditions. The improved algorithm is as follow: the discard level increases without delay and directly proportionally to the memory usage (instead of step by step over several seconds) when needed so to avoid out of memory conditions, but it decreases progressively over a few seconds (step by step, this time) when memory is freed, also letting the time for the viewer to recalculate the “textures priority” (which depends on the face size, distance to camera and visibility (occluded, not in field of view, etc)), calculation that was also changed to extend to more textures per second when the memory gets low, so to have more chances to find far, “discardable” (or now occluded/out of FOV) textures.

    Note that the texture (apparent) re-fetching is often just the fetching of a lower discard level (i.e. higher definition/resolution) of the same texture (JPEG2000 textures are “progressive” textures that got their lower resolution versions at the start of the file, so the viewer only downloads part of the texture file when the discard is above 0 and can then download the rest for the same texture when the discard level decreases)… Also, IIRC (but I would have to check for certainty), only non-discarded (0 discard) textures are actually cached (far textures that never reached a 0 discard level are therefore likely to get downloaded each time you relog or come back at the same point).

    • Actually it’s far more easy than your description of the edge case where the viewer runs out of virtual memory:

      The viewer is allowed to use only 384 MB of video memory at maximum for actual textures, no matter if your graphics card has a multitude of that. Now if people set their draw distance to a crazy high value (like everything over 200m) and creators dump 1024px textures on every face of their items, you easily end up reaching 384 MB texture memory usage and the viewer starts discarding texture details, sending you straight into texture thrashing hell. For instance at this “lag” house at SAU (skybox), where you stand in a room and texture memory usage goes up to almost 1 GB (tested with a special viewer build allowing up to 1 GB texture memory)…

Leave a Reply

Your email address will not be published. Required fields are marked *