SL project updates 16 13/1: Aditi inventory, invisiprims

Posted on by Inara Pey

[G]aio; Inara Pey, March 2016, on Flickr [G]aio – blog post

Server Deployments Week #13

There are no scheduled deployments or restarts planned for the week. The next deployment should occur in week #14 (week commencing Monday, April 4th, when the release candidate channels should receive a server maintenance package containing some (as yet)  unspecified fixes.

SL Viewer

The Project Bento viewer, containing the new avatar skeleton extensions, updated on Tuesday March 29th to version 5.0.0.313150. The remaining viewer channels remain unchanged from the end of week #12:

  • Current Release version: 4.0.2.312269, dated March 17th – formerly the Maintenance RC viewer
  • Release candidate cohorts:
    • HTTP updates and Vivox RC viewer, version 4.0.3.312816, dated March 23rd – probably the next viewer in line to be promoted to the de facto release status
    • Quick Graphics RC viewer, version 4.0.2.312297, dated March 11th – possibly to go through a further update (tests were being carried out with  the Avatar Complexity settings in week #12)
  • Project viewers:
    • Oculus Rift project viewer updated to version 3.7.18.295296 on October 13, 2015 – Oculus Rift DK2 support (download and release notes)
  • Obsolete platform viewer, version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Aditi Inventory Problems

As noted in part #2 of my last project update, there are issues with the new Aditi inventory syncing mechanism.

One issue is that items created on Aditi following one inventory syncing process will disappear from inventory when logging into Aditi following the next inventory syncing run (see BUG-11651).

This is likely the result of the viewer using the same cache, regardless of the grid you log-in to. The current fix is therefore to clear the viewer cache completely or to delete the inventory .gz files from your cache folder), and then log back into Aditi.

However, this approach in turn causes an issue of its own.

When logging back into Agni (the main grid) after clearing cache as described above, the Aditi assets will appear to be listed in your Agni inventory. However, any attempt to rez or wear or share the assets from Aditi will result in an error message, because the assets themselves are not physically part of your Agni inventory. Again, the solution is to clear cache  / remove the inventory .gz files from your viewer cache and re-log into Agni.

Also noted in the JIRA is this issue results in some very odd duplication of Calling Cards on Aditi.

The Solution

The desired fix is to have different inventory caches for each grid visited, and as noted in the JIRA report, this is how the Lab intends to proceed.

Invisiprims

As noted in the part #3 of my last project update, there is a new issue with invisiprims, which sees any object, worn or in-world, using the texture UUIDs associated with them rendered at a solid grey or black surface or object, regardless of whether ALM is enabled in the viewer or not. Prior to this issue occurring, the result of a change made in the current release viewer (version 4.0.2.312269), invisiprims would either mask whatever was behind them with ALM off, or simply be ignored if the viewer was running with ALM enabled.

The new invisiprim issue is that regradless of whether a viewer is running with ALM disabled (l) or enabled (r), worn or in-world objects using them now appear either solid grey or black (click image for full size, if required)
The new invisiprim issue is that regardless of whether a viewer is running with ALM disabled (l) or enabled (r), worn or in-world objects using them now appear either solid grey or black (click image for full size, if required)

As having grey surfaces and objects appearing on avatars in in-world (remembering that there is a lot of old, No Mod content in-world which makes extensive use of invisiprims and their associated textures, and this approach makes them look very unsightly to anyone viewing them), the suggestion has been put forward that the viewer should be modified to simply ignore the invisiprim texture UUIDs or treat them simply as “normal” transparent textures regardless of whether or not ALM is enabled in the viewer, and a fix has been submitted to the Lab to achieve this.

Asked during the Simulator User Group meeting on Tuesday, March 29th, if the Lab had reached a decision on adopting the fix, Simon Linden said, “We were talking about it earlier … nobody wants to do anything to break content; so we have the hole-in-the-water use, which is nice for boats and such.”

Oz Linden then added, “We’re going to do some testing of alternatives… so I guess the answer is that we don’t have a final decision yet.”

Published by Inara Pey

Eclectic virtual world blogger with a focus on Second Life, VR, virtual environments and technology.

6 thoughts on “SL project updates 16 13/1: Aditi inventory, invisiprims”

  1. I wonder how much content got broken, besides that dockyards. I suspect it isn’t much, considering that it is *years* that invisiprims are half-broken (with ALM) anyway, and more and more people have ALM on. As for boats, invisiprim was an interesting workaround, as SL engine still lacks that feature. Boats now are made floating (unnaturally) high above the waterline.
    There aren’t so many invisiprims shoes around now too. Even if you had ALM off, they looked funny years ago already to people having ALM on. Even before ALM, they had glitches, and it looked like you had semi-transparent boxes around your shoes, against some kind of floor. Only few less popular TVPs can render invisprims with ALM enabled, but glitches are still there. There is something that was modifiable, but sculpty shoes are now rather obsolete anyway (I kept only few that were really unique or amusing).

    Like

    1. In terms of in-world content, there is rather a lot to be found across Mainland, much of it No Mod, but which at least looked OK with ALM on, but now really does look distinctly strange with black or grey surfaces and blobs on it when viewed with ALM on or off. I simply opted to use the Nautilus dry dock as an example in my articles because it is perhaps the most well-known, having been used extensively to illustrate the “water problem” when the deferred rendering engine (ALM) was updated such that it ignored the invisiprim texture UUIDs.

      Like you, I don’t see footwear being a major issue – although I would say that I’ve been surprised at the number of people I still encounter on a weekly basis in my SL travels who still use legacy footwear, and were unaware of any issue as they run the viewer with ALM turned off. The one benefit in having the invisiprim texture UUIDs treated uniformly by the viewer whether or not ALM is enabled, at least reveals the problem to everyone. I just agree with those who frequently encounter in-world content which uses these UUIDs: better to have the viewer ignore them or render them as transparent, than encountering what seem to be untextured surfaces and blobs when encountering such content.

      Like

    1. It’ll take a while for it to appear, and will be interesting to see if this will be a long-term solution, or if the Lab come back and look at things again in the future. Thanks for the heads-up!

      Like

  3. Pingback: Second Life: Aditi Inventory | Nalates' Things & StuffNalates' Things & Stuff

Comments are closed.