As noted in my week #11 update, the current release of the LL viewer now effectively “breaks” the remaining invisiprim capability in the viewer, with any object or surface using them rendered as either solid grey or black, something which is seen as less than optimal with regards to long-standing in-world content, prompting some debate as who should be done with invisiprims going forward.
To understand what has been discussed, and what is likely to be done, it is necessary to dip back into some history.
Background
One upon a time, Invisiprims were the means of achieving an alpha mask effect. For example, their use in footwear meant that an avatar’s feet could be masked to prevent them showing through shoes and boots. They could also be used in-world as well, a typical example being their use to mask Linden Water from being seen inside boat hulls or things like dry docks – one of the most famous examples being the dry dock at Nautilus (shown below).
Invisiprims were able to do this by making use of two unique texture UUIDs within the viewer which, when called, would act as alpha masks. However, this always came as a cost to rendering, and could lead to unpredictable results (e.g. glitches with rendering, odd interactions between the invisiprim textures and other textures, etc.). Because these issues became particularly problematic when using some of the advanced rendering capabilities (what is now called the Advanced Lighting Model or ALM) in the viewer, a decision was taken a number of years ago to have ALM ignore the alpha masking effect of the invisiprim texture UUIDs.
Thus, anyone running the viewer with ALM enabled for the last several years has not seen the masking effects of invisiprims; avatar body parts show through wearable items which use them, for example (hence the adoption of more efficient alpha layers by clothing and accessory designers). Nor do in-world invisiprims act a masks for things like Linden Water when viewed with ALM active (as illustrated below), although they would still alpha mask if ALM was disabled in the viewer.
While this latter point – the lack of ability to hide things like Linden Water from view – may have appeared less than perfect at the time the changes were made, it has over the ensuing years become accepted behaviour when seen in-world. So what has now changed to once again make invisiprims a subject of discussion?
The New Problem and Its Proposed Solution
In short, a recent change to the viewer rendering system, (found in the current release viewer, 4.0.2.312269) means that anything using the invisiprim texture UUIDs is now seen as a sold grey or black surface / object regardless as to whether ALM is enabled in the viewer or not. This has led a lot of long-standing, No Mod in-world content looking distinctly odd and unsightly (shown below, again using the Nautilus dry dock).
BUG-11562 was raised highlighting this latter impact to in-world content, with a request that the change be updated so that any surface using the “magic” invisiprim UUIDs is simply rendered as “invisible” (i.e. transparent, as is the case when running with ALM enabled). There has also been some debate among TPV developers about how to adopt the Lab’s code change, as well as the matter being discussed at both the Open-Source Developer meeting and the TPVD meeting held on March 25th, 2016 (audio extract below).
The latter discussions have resulted in both the Lab and TPV developers agreeing that the best solution would be to follow the BUG-11562 suggestion, and have surfaces and objects using the invisiprim UUIDs render and transparent objects whether or not ALM is enabled in the viewer.
A change to support this has already be submitted to the Lab to achieve this. Subject to further testing, it, or a solution similar to it, is likely to be integrated into a future viewer update.
Inara Pey: Living in a Modemworld 