Category: SL User Group Meetings

2018 SL UG updates #20/2: Content Creator User Group w/audio

Posted on by Inara Pey

Bay of Dreams; Inara Pey, April 2018, on FlickrBay of Dreams – Blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, May 17th, 2018 at 13:00 SLT.  The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts from the meeting are included, where relevant. Please note, however, that Vir’s microphone occasionally seemed to cut out while I was recording, so some of his comments may sound a little choppy.

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Project Viewer

The Animesh project viewer was updated on Tuesday, May 15th to version 5.1.4.515420. This update comprises:

  • Bug fixes, including improved handling of animation notifications which should result in fewer cases of animations failing to display for some Animesh objects.
  • New checks on when a skeleton is needed for a nominally Animesh object  – now one should be present only when the linkset contains at least one rigged mesh, and this should update correctly when link/unlink operations take place, or other state changes.
  • The ARC calculations for animesh objects has also been updated based on some feedback with the previous build.

Alongside of this there has been a simulator update in support of some of the changes in the viewer (e.g. with regard to animation notifications and updates). Also, to help with persistent across things like region crossings and region restarts, animation information is now stored in the state of the Animesh object itself, when it gets serialised. However, there are reports the animation data is lost on a SHIFT-copy action.

Server-Side Work

As well as the simulator updates for Animesh mentioned above, the Lab is continuing with QA work on server-side support for Animesh to prepare it for deployment to the main (Agni) grid. However, no ETA as yet for the server-side code.

Remaining Major Issues

Rigged Mesh Level of Detail / Bounding Box Issues:This has been the subject of several recent CCUG report in these pages, and is the subject of BUG-214736. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Investigations had led to questions in the Lab of how to get things to behave correctly while recognising there may be broader performance issue that need to be addressed. So Graham Linden has been trying to make sense of what might be pulled into the current Animesh project to improve things and what might require a deeper dive into performance in general as a separate piece of work. So at present this remains in the category of “to be determined” in terms of moving to making Animesh available on the main grid.

Joint Offset Constraints: It’s been noted that setting (deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results (the cited example is an Animesh test bear on Aditi appearing to stand 75 metres off the ground when not animating). This has led the Lab to consider constraining he distance a joint can be offset to no more than 5 metres for Animesh objects. However, as this is recognised that doing so could break existing content, a more elaborate solution is still being investigated by the Lab.

Adjacent Regions and Animesh Animations: There is an issue where Animesh objects in adjacent regions fail to animate from a avatar’s perspective when someone logs-in. This is thought to be a handshaking / viewer update issue. Essentially, it can take up to a minute for adjacent regions to understand an agent (avatar) in another region can “see” objects within it, and needs to start sending animation updates to the viewer controlling that avatar.

90-degree Rotation Issue: It’s been noted that when converting some static mesh objects to Animesh, the visual mesh appears rotated through 90 degrees when seen in the Animesh viewer. However, the physics mesh doesn’t have the same rotation applied, leaving it perpendicular to the visible mesh – see BUG-139251.

This appears to be related to the fact that the viewer expects the mesh to be aligned to +x=forward – whereas mesh creation tools such as Blender and Maya don’t – by default – use the same orientation. As the issue only affects some mesh (and in theory could be corrected by setting the required rotation in mesh building tools), Vir asked the question if this is something that should be addressed in the viewer.

  • If this issue isn’t addressed in the viewer (which is where it manifests), it potentially means a good proportion of existing content which might otherwise be converted to Animesh will exhibit the same issue when associated with an avatar skeleton, possibly eliminating it from use as Animesh.
  • If the issue is to be addressed in the viewer, the problem is how to apply the logic to ensure mesh items which don’t exhibit the physics rotation issue don’t end up exhibiting the issue as a result of the fix being incorrectly applied.

Z-Axis offset un the Mesh Uploader: This currently doesn’t work when a  skeleton is applied to a mesh object.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Additional Bake Channels

Anchor Linden is investigating adding further channels to the Bake Service in addition to those recently added, again specifically for use with Bakes on Meshes (they will not work with the system avatar). These will hopefully comprise:

  • Separate channels for the left arm and left (currently these are mirrored from the avatar’s right side) to allow for asymmetrical avatar options.
  • Three additional “general purpose” channels to be defined and used as required by creators.

These channels will eventually be surfaced as tattoo layers in the viewer, which will have an updated UI for creating new layers.

Injecting Texture Information into the Bake Stack

There has been a request to allow applier creators to use a scripted means to “inject” textures into the Bake Service via a script (see BUG-216137).

It has arisen out of concern that Bakes on Mesh a) won’t offer the same ease-of-use as HUD-based appliers many users are familiar with; b) it could make the majority of existing applier systems obsolete as mesh head / body creators move towards less complex “onion layer” designs, requiring applier makers to completely re-work all of their existing clothing options. Offering a means to provide Bakes on Mesh with a similar capability as applier systems and allow applier makers to more easily update their existing systems. However:

  • The proposed solution is a non-starter, as the Outfit system on which the Bake Service relies, has no notion of textures. Thus, offering a means to “inject” textures into the bake stack essentially creates a separate (and potentially conflicting) representation of the bake stack.
  • If it is seen that a more applier-like approach to Bakes on Mesh, any solution will form part of a follow-up project, rather than being part of the initial implementation.

 

2018 SL UG updates #20/1: Simulator User Group meeting

Posted on by Inara Pey

The Apothecary; Inara Pey, April 2018, on FlickrThe Apothecary – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, May 15th, the Main (SLS) channel received server maintenance package 18#18.05.07.515224, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.
  • On Wednesday, May 16th, the Release Candidate channels were currently marked as TBD at the time of writing. However, during the Simulator User Group meeting on Tuesday, May 15th, Rider Linden indicated there would be two RC deployments:
    • The BlueSteel and LeTigre deployment should comprise internal fixes, together with simulator-side updates for better management of estate level ban lists – although these will require a viewer update to be visible.
    • The Magnum RC update should comprise the same internal fixes, together with the simulator-side updates for abuse report categories.

llRequestUserKey and llName2Key

llRequestUserKey and llNameToKey, both of which will be across all RC channels following the Wednesday deployment, are in connection with the upcoming return of Last Names (see this blog post and this blog post for more). These functions can be summarised as:

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

Abuse Report Category Capability

As I’ve noted in my TPV Developer meeting updates, a new capability is being introduced that will allow the viewer to call abuse report categories from the simulator, rather than having them hard-cored into the viewer itself. This will help ensure abuse reports are filed using valid AR categories, while at the same time making it easier for the Lab to maintain the AR categories.

The deployment to the Magnum RC is the first phase of this work to be made to the grid. Once the simulator changes are available grid-wide, a viewer with the new capability should be made available, with a request that TPVs adopt the updates as soon as they can in their own release cycles.

SL Viewer

The Ouzo Maintenance viewer has updated to version 5.1.4.515016 (dated May 7th, but the update wasn’t listed in the Alternate Viewers page until week #20).

The Animesh viewer updated to version 5.1.4.515420 on May 15th.

The rest of the viewer pipelines remain as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Mesh Pivot Points and the Uploader

A long-time problem with the mesh uploader is that it ignores pivot points set within tools like Blender when a model is uploaded to SL. This means, for example, that doors set with a pivot point in Blender won’t work using that pivot when uploaded to SL. A feature request to enable the uploader to recognised pre-set pivot points in mesh objects was raised in 2015 – see BUG-37617 –  and more recently, Beq Janus has been looking to add further information to it.

Region Crossing Updates

Code to improve communications during region crossings went grid-wide in week #19. A further round of simulator-side updates is likely to be deployed in the next few weeks. In the meantime, Joe Magarac (animats) believes most of the minor issues relating to “partial unsits” can be handled with changes to scripting / the viewer – see BUG-214653. He’s offered to rally support to help the Lab dig more deeply into this issue, by arrange group tests, etc., if the Lab can made simulator-side changes to help improve things.

Three major issues for vehicles are No Script parcels / regions, ban lines and scripted security systems. The  former can be harder to deal with, as there is no advanced warning that scripts are disabled until the boundary is crossed. Scripted security systems tend to provide some warning which can generally allow those straying into a private area time to get out (unless the delay time has been set ridiculously short). Ban lines are somewhat insidious, however, as they can physically “snag” a vehicle whilst ejecting the occupants – with the vehicle often remaining in place with no auto-return.

There has been a feature request to handle ban lines better (BUG-216276), with another request for ban-lines to “deflect” vehicles, rather than allowing vehicle to cross them and becoming snagged when the occupants are ejected. It’s not clear if the Lab will adopt these ideas.

2018 SL UG updates #19/2: TPVD meeting

Posted on by Inara Pey
Maison de L’amitie: Salar de Uyuni – blog post

The following notes are taken from the TPV Developer meeting held on Friday, May 11th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it.

This was another short meeting – around 30 minutes, with about half of that covering SL projects, which are noted below. The rest of the meeting was more general conversation, and I’ll leave it to the video to cover them. As always, time stamps in the text below will jump you to the relevant points in the video.

SL Viewer

There have been no updates to the current crop of official viewers during week #19. This leaves the pipelines as:

  • Current Release version 5.1.3.513644, dated March 27th, promoted April 13th – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

[1:53 -2:45] Currently, the Ouzo Maintenance RC has a slightly lower crash rate than the Love Me Render RC, and so at this point in time looks like the more likely of the two to gain promotion to de facto release status.

Forthcoming Updates

[2:46-3:28] There are a number of viewer-visible updates which will be surfacing in upcoming viewers in the near future. These include (and in no particular order):

  • Updates to the estate management tools for better management and update of ban lists, etc.
  • Changes to viewer texture caching.
  • Further SL Voice improvements.
  • [24:43-25:39] New capability for abuse reports to be called from the simulator by the viewer, rather than being hard-coded into the viewer. This work had some delays while the AR categories were translated into other languages for display by the viewer. However both the simulator and viewer updates are now progressing
  • [30:45-31:35] New capability for receiving off-line IMs to avoid loss of IMs on logging-in. This capability is also now in testing.

GDPR and the Viewer

[5:25-7:17] The Lab recently offered an initial blog post on the upcoming European Union General Data Protection Regulation (GDPR – also see my blog post on the subject as well). Subject to further updates on the matter from the Lab, it would appear that the view being taken that data gathered by the viewer which is used in-world will not be subject to any requirements defined by the GDPR. A benefit the Lab has had in terms of GDPR compliance, is that the company has never viewed users’ personal data as a potential asset for revenue generation.

Other Items in Brief

  • [8:03-10:35] Texture Copying: There have been requests for the Lab to make texture copying “harder”. Given that texture data is held on a local computer, and UUIDs are trivial to capture, and the data they point to can also be obtained, this is no easy task. The Lab therefore finds itself caught between trying to offer better protection for textures and risking giving the impression they can prevent all texture copying, although they do look at ways to at least deter it.
  • [11:18-12:42 (mainly text chat) and 14:28-16:50 (with text chat)] Parcel Banning and Object Information: there appears to have been a recent change that means if an individual is banned from a region, they no longer receive information about objects on that parcel. The change, if made, may have been with good intent but is possibly having unwanted side effects. A JIRA is to be raised on the issue.
  • [12:43-14:20] BUG-216032: A recent back-end security change made to PRIM_MEDIA_CURRENT_URL reportedly broke a lot of content. Following initial complaints, the Lab offered to help those experiencing problems as a result of the change if they got in contact with the Lab. Some are reportedly still having issues, however, the Lab do not appear to have been contacted for assistance. so if assistance is required – contact Oz Linden.

2018 SL UG updates #19/1: Simulator User Group meeting

Posted on by Inara Pey

Luane's World; Inara Pey, April 2018, on FlickrLuane’s World – blog post

The following notes have been taken from the Simulator User Group, held on Tuesday, May 1st, 2018.

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, May 8th, the Main (SLS) channel received server maintenance package 18#18.04.30.515008, which includes updates to simulator communication protocols aimed at improving region crossings and teleports.
  • On Wednesday, May 9th, all three main RC channels should receive server maintenance package 18#18.05.07.515224, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.

Region Crossing Updates

Commenting on the region crossing updates, Simon Linden revealed he’d be out of the office for next week, but:

After I’m back I expect to continue region crossing work … the servers are now doing a better job tracking all the attachments and objects you may be sitting on. The goal is to know when the region thinks that’s all done, and the viewer acknowledges it. If that doesn’t happen, it can do better fixing it.

llRequestUserKey and llName2Key

llRequestUserKey and llNameToKey, both of which will be across all RC channels following the Wednesday deployment, are in connection with the upcoming return of Last Names (see this blog post and this blog post for more). These functions can be summarised as:

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

SL Viewer

There have been no SL viewer updates for the start of the week, leaving the current pipeline as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Region Restarts and Server Moves

Once upon a time, the Lab used to put effort into trying to ensure adjacent regions in the same server or nearby server. This was most notably done through server re-balancing exercises (see my notes on one of them here, for example), carried out a couple of times a year and which could take some 6 weeks to complete. These operations generally required additional restarts for the regions being moved, and were thought to bring improvements to teleports and physical region crossings.

With hardware and infrastructure improvements over the years, coupled with other sets taken to improve overall grid performance, these operations are no longer carried out – although efforts are taken to ensure multi-region events are placed on simulators all located on the same or adjacent servers. However, nowadays, for the majority of region, they are moved purely as a part of the weekly rolling restarts.

Those wishing to know which regions might be sharing a server with their own can use Tyche Shepherd’s Grid Survey (use the region search and then click the region name link in the results). However, keep in mind not all the result may be up-to-date.

Next Meeting

As noted above, Simon Linden, who usually leads the Simulator User Group meeting will be out of the office in week #20. However, the meeting for the week will still go ahead as scheduled.

2018 SL UG updates #18/1: Simulator User Group meeting

Posted on by Inara Pey

Green Story; Inara Pey, April 2018, on FlickrGreen Story – blog post

The following notes have been taken from the Simulator User Group, held on Tuesday, May 1st, 2018.

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • The was no deployment or restart for the Main (SLS) channel on Tuesday, May 1st. The channel remains on server maintenance package 18#18.04.13.514504, containing internal fixes and a fix for BUG-214702.
  • On Wednesday, May 2nd, the simulator release candidate channels should be updated as follows:
    • BlueSteel should receive server maintenance package 18#18.04.20.514703, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.
    • Magnum and LeTigre should receive server maintenance package 18#18.04.30.515008, which includes updates to simulator communication protocols aimed at improving region crossings and teleports, deployed for the last week to a number of selected regions on Blake Sea via the Snack RC channel.

LlRequestUserKey and LlName2Key

The Lab has released two new LSL functions: llRequestUserKey and llNameToKey, both of which are in connection to the upcoming return of Last Names (see this blog post and this blog post for more):

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

SL Viewer

There have been no updates to the current SL viewer pipelines, leaving them as follows:

  • Current Release version 5.1.3.513644, dated March 27th, promoted April 13th – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Ouzo Maintenance RC, version 5.1.4.514802, dated April 27th.
    • Love Me Render RC viewer, version 5.1.4.514788, dated April 25th.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

Environment Enhancement Project (EEP)

Rider Linden re-confirmed that while EEP will allow different Windlight settings at altitude above a region / parcel, the zones will be set at 1000 metre intervals (1,000, 2,000, 3,000 and 4,000) and set by the simulator – they will not be user-configurable as can be done with Firestorm (viewer-side only). His hope is also to have scripted per-agent Windlight settings as part of the initial deployment of EEP; however, this is TBC.

2018 SL UG updates #17/4: TPVD meeting

Posted on by Inara Pey

Ruins of Deepmarsh; Inara Pey, March 2018, on FlickrRuins of Deepmarsh – blog post

The majority of these notes are taken from the TPV Developer meeting held on Friday, April 27th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.

Once again, this was a short meeting, but one with extended periods of silence; hence some of the gaps in the time stamps below. There’s also a conversation on the forthcoming Bid A Linden Bald event, as part of the Relay Rockers annual

SL Viewer

[0:07-0:36] The Love Me Render RC viewer updated to version 5.1.4.514788 on Wednesday, April 25th, 2018, and the Ouzo Maintenance RC updated to version 5.1.4.514802 on Friday, April 27th. Both of these RC viewers have had “significantly higher” crash rates than the default viewer, so the Lab will be watching to see what happens with the two updates, and with the crash rate for either is reduced as a result of their release.

Otherwise the viewer pipelines remain as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

[0:39-1:24] The 360 snapshot viewer remains “on hold”, receiving updates to maintain parity with release viewer, but otherwise not receiving any significant work on its key features at this point in time. Work will resume in the future as the specialist resources become available. Both the Animesh and Bakes on Mesh viewers are referred to in the meeting as being “close to coming over to Agni”, although this only hold true for the Animesh project viewer, as the Bakes On Mesh viewer should work on the Main grid already (albeit with the Bake Service’s current 512×512 texture support, as the support for 1024×1024 textures has yet to be deployed).

Viewer Texture Cache Work

[1:46-2:14] The Lab continues to work on the viewer texture cache, and it is hoped that the latest attempt will lead to a “big improvement” in how textures are handled. Currently this code is not available for public consumption, but the hope is that there will be a project viewer with the code available “pretty soon”.

Updated Estate Management Tools

[19:30-20:10] Work is again progressing on enhancing the Estate Management tools in the viewer (e.g. refining ban list management capabilities, etc.). It is hoped that a project viewer will be emerging in the next few weeks. The viewer updates themselves are largely done, and things are awaiting server-side support.

Environmental Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

[11:39-12:38] Rider Linden has been engaged in some other work for most of the past month, but is now largely back working on the project. It is now a focus for the Lab going forward, with the hope that Rider will not be diverted into other work at EEP’s expense. Some test regions for EEP are also being prepared on Aditi.

Other Items

Testing Viewer Options and the Shared Experience

[5:00-5:45] TPVs sometimes introduce features and options which might be considered as breaking the “shared experience”. The question was therefore asked if allowing people to test / play with new rendering options – as developed by a TPV rather than Linden Lab – might be considered as breaking the shared experience. Oz Linden offered a response which provided some guidance on similar kinds of updates:

I think the best I can give you in terms of a general answer is if it’s the sort of thing that’s going to cause a merchant to include a note card with a product that says, “to see this product correctly, you have to run this viewer with that option turned on”, that’s a sign you’re breaking the shared experience … On the other hand, if you want to experiment with something that you’re then going to contribute upstream [i.e. to the Lab for inclusion in the base viewer code (which is used by all TPVs)] that’s a different problem altogether.

Catznip Displacement Maps Experiements

The question itself was prompted by Kitty Barnett of Catznip, who is working on using displacement maps in the viewer, as well as some other normal mapping tweaks.

Displacement maps, currently being experimented with by Kitty Barnett, can add further depth to surfaces. For example: top left – a prim wall with a brick texture; top right: a prim wall with a texture and normal map applied, as we’re used to seeing in Second Life – some depth is added to the cement grouting between the bricks etc. Bottom centre: the same prim wall with the same texture added, but now using a displacement map: note the greater apparent depth between bricks and cement grouting, etc (highlighted). However, such a capability will have a Land Impact cost.

It would seem that if successful, this work will be contributed to Linden Lab for evaluation and consideration. It’s important to note that Catznip’s work is in the early stages, more work is required on level of detail impact / modelling / potential Land Impact costs, etc., for which Catznip may look to the Lab for assistance.

[6:26-6:46] In the meantime, Oz Linden reiterated that, quite aside of the Environmental Enhancement Project (EPP – see above), the Lab is working on a number of other environmental (render-side) improvements. Previous discussions on rendering improvements have indicated that Graham Linden is already working on a series of environment updates alongside the EEP work being carried out by Rider Linden, which appears to include support for Godrays, potential pre-baking of some environment effects, etc. It’s not clear from Oz’s comments whether he is referring to this work, or something further downstream.

Natty Linden’s Marketplace Job Ad

[16:37-17:00] Natty Linden posted a Marketplace listing for a job at Linden Lab. While offering a little fun, the listing has a serious edge: there is an open Marketplace web developer post at present. As such, Natty’s listing is a further way of reaching those already engaged in Second Life who may have the requisite skills sets, who live in the right location and who may be interested in joining the Lab (which frequently does employ Second Life users – as seen with the likes of Patch Linden, Xiola Linden, and Rider Linden, to name but three of the more well-known resident hires made by the Lab over the years, and who work in different areas within the SL team).