Day: March 27, 2016

A cheerful visit in Second Life

Posted on by Inara Pey

[G]aio; Inara Pey, March 2016, on Flickr [G]aio – click any image for full size

There are some extraordinary lovely regions popping up across Second Life right now, several of which I’ve been fortunate to visit recently, and I’m adding. [G]aio (Italian: cheerful, happy) to the list.

The work of cambiamento Radikal, [G]aio is a homestead region nestled between tall green mountains, presenting the feeling of being a small cluster of islands sitting on a lake and caught in a perennial summer’s morning, the sky yellowed by a slowly rising sun gradually hauling its way up over the eastern peaks.

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

The largest of the islands offers  a Tuscan farmhouse sitting to the south-west, the outhouses of which present games rooms and the chance to enjoy a little wine. Those who prefer can dance out in the courtyard (touch the sign next to the house for poseballs), or they can sit and sip wine and watch the sheep drinking at the water trough alongside a small coral. The latter is home to a saddled horse awaiting anyone who might want to ride him.

Outside the farm buildings, a stone path leads the way along a tongue of land running east, past grapes growing on the vine and corn on the cob, to a children’s play area. Beyond this, the tongue of land continues east then north to arrive small headland crowned with a copse of tall fir trees through which sunlight slants.

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

A rope bridge connects this headland with the second largest island as it sits cupped in the arms of the first. A rutted track undulated across this island, under the boughs of trees and between thick hedges. Two stone bridges, hopping to a much smaller island offer the way back to the farm, leading visitors past a magical faery ring in the process.

[G]aio may not appear to be as extensive as other region designs, but this doesn’t make it any less endearing. There is a beautifully rural feeling to it, perfectly underlined by a gentle ambient sound scape. It is also a place which naturally lends itself to photography under a range of windlight settings (there are also poses available, and rezzing is set with a 60-minutes return time).

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

For those who simply want to spend time together, snuggling, exploring or dancing, [G]aio is equally the ideal destination, offering plenty of opportunity for all three, with cambiamento a convivial host (we spent a good part of my most recent visit in conversation). Should you enjoy your visit to {G]aio, do please consider making a donation towards the region’s upkeep (via the courtyard water trough).

SLurl Details

SL project updates 16 12/3: invisiprims

Posted on by Inara Pey
Invisiprims: as they were with ALM disabled (left) and ALM enabled (right) and as they appear now, with or without ALM enabled (LL official viewer)
Invisiprims: with ALM disabled (left) and ALM enabled (right); and as they appear now in the official viewer, with or without ALM enabled (click for full size, if required)

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).

As it used to be: the Nautilus dry dock uses an invisiprim to mask the Linden Water - but for the last few years this has onlt worked for viewers with Advanced Lighting Model (ALM) disabled
As it used to be: the Nautilus dry dock uses an invisiprim to mask the Linden Water. For the last several years, this has only worked when the Advanced Lighting Model (ALM) in the viewer is disabled

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.

As it has tended to be: the Nautilus dry dock uses an invisiprim to mask the Linden Water, the texture of which is completely ignored by the viewer when rendering with ALM enabled.
Following the changes made a few years ago to the Advanced Lighting Model, the “magic” invisiprim texture UUIDs are ignored during rendering, with the result that they no longer mask things like Linden Water when seen in a viewer with ALM enabled

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).

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)
A change to the 4.0.2.312269 release viewer means that invisprims now render as solid grey or black surfaces / objects whether or not ALM is enabled in the viewer. With in-world content, this has led to some unsightly results, such as the Nautilus dry dock looking like it has been filled with cement (click image for full size, if required)

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.