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

Green Story; Inara Pey, April 2018, on FlickrGreen Storyblog 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

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

 

 

2018 UG updates #17/3: Content Creator User Group

Dragons by Wanders Nowhere, used in Animesh tests

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 26th, 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.

Animesh Project

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.

Server-Side Updates

Vir believes the Lab is pretty close to a final set of Animesh updates for the server side of things. These include support for the Animesh updated limits and cost formulas, and it is expected that QA will be starting soon on the code in readiness for clearing it for deployment to the Main grid, Agni.

Joint Offset Constraints

One of the reasons the Lab is discussing constraining joint offset is an Animesh bear developed for testing purposes (and which can be found on the Aditi Animesh test regions) which sits some 75 metres off the ground, that’s due to a bad offset being set within the mesh and used with the mPelvis bone, which comes into play when the mesh isn’t being animated.

The bear itself was created as the SL10B wearable avatar, and so demonstrates what can happen with existing wearable content with such errors (which would not become apparent while the mesh is become worn, as the avatar tends to always be in a state of animation) is converted for use as Animesh.

Constraining the distance joints can be offset (say to 5 metres) offers one means of preventing this kind of problem; however, it is recognised that doing so could break existing content – such as the very tall avatar models that are available. Therefore the Lab is considering this an other, more complex options – such as doing something with the bounding box.

Animation Playback Issues

Some are still having Animation playback issues with Animesh objects, notably on initial rezzing or following a region crossing. The advice is it increase the number of animation updates being sent out.

Land Impact

There is some potential confusion with the land impact reports on the mesh uploader and when calculated for an Animesh object when in-world. The uploader calculates the LI for a mesh based on it being a static object. It is only when the object is toggled to Animesh in-world that the revised formulas for LI and complexity are used. This has in turn lead to issues for creators trying to determine what the likely weightings are going to be for their models prior to update.

There have also been some reports that on conversion, models not obeying the new LOD requirements defined as part of the within the new formula suffer heavy penalties when converted to Animesh.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box  (see 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.

Graham Linden has been investigating this issue, and now has some updates for the viewer (yet to be integrated with the Animesh project viewer) which should help with this issue and encourage those creator who have, deliberately or accidentally, gaining an advantage from the issue to offers balanced LOD models for their content.

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

Current Status

Anchor’s most recent work has been:

  • Completing the work to implement three more tattoo slots of the Bake Service: skirt tattoo, hair tattoo and eyes tattoo.  These are designed to extend the tattoo to the same set of slots as for the underwear and clothing layers, and hopefully make the available slots far more flexible in potential use when applying baked textures to worn mesh.
  • Continuing to work on the skirt layer stacking issue.

The basic functionality of taking system wearable layers and applying them to mesh faces is viewed as working. However, as per my previous Content Creation meeting notes, there is still a lot to be decided on how to progress Bakes on Mesh, particularly in reference to Bakes on Mesh and the applier market, and the overall convenience of Bakes on Mesh for applying textures to worn mesh faces, compared to “ease” of using applier systems for consumers.

Internal discussions about some of the ideas raised around this  – such as being able to inject textures into the Bake Service via script – are still be discussed within the Lab as a result of the concerns raised at the previous CCUG.

Bakes and UV Maps / Spaces

Bakes on Mesh has generated a lot of discussion on the effectiveness of custom UV maps and the Baking Service – UV maps being the thing that take was are essentially 2D textures and “wrap” them around a mesh object. In brief:

  • The system avatar has a set of pre-defined UV spaces associated with it. These are used by many of the mesh body makers, and so using system clothing layers via the Bake Service should work on these. Mesh heads tend to be different, and so issues can occur trying to apply skins, etc., to them.
  • The Lab’s view is that there’s no reason in principle why the baked textures must use the system UV space. So, for example, and providing none of the system avatar layers (such as the skin) are to be visible, it should be possible to use a set of tattoo layers defined in a specific mesh body’s UV space which can then be passed through the Bake Service and applied to a set of mesh faces regardless of the system UV space.

  • An issue here is that only tattoo layers can be used with custom UVs, as all other layers have “holes” in them designed to reveal the system avatar skin, allow for eyelashes, etc.  Therefore, it is not currently possible to re-purpose a shirt layer, for example.  Cathy Foil expanded on this, and on the use of system UV space with mesh bodies.

  • Vir expanded a little on the idea that some of the clothing layers that have more “intelligence” built-in (e.g. alpha masking support), hence why they would not work with custom UVs and it would be necessary to use tattoo layers for the textures and re-name them.

Within the meeting, this led to an extended discussion on UV options – such as the advantage of updating the avatar .LAD file and the viewer appearance editor  to allow the use of custom UVs or the system UV space (via an appearance editor check box) over re-purposing tattoo layers.

It’s like that initially, the Lab will lean towards re-purposing tattoo layers, rather than re-working the avatar .LAD and appearance editor, leaving it to body / head creators to offer updated UV maps for those cases where they don’t precisely follow the space UVs.

Next Meeting

There is no CCUG on Thursday, May 3rd due to a conflict with the Lab’s monthly internal meeting. The next CCUG will therefore take place on Thursday, May 1oth, location TBA.

 

April 2018 Web User Group Summary

Grumpity and Alexa Linden host the Web User Group meetings on alternate Fridays at Alexa’s barn.

The following notes are taken from the Web User Group meeting held on Wednesday, April 25th, 2017.

These meetings are generally held monthly on a Wednesday, and are chaired by Alexa and Grumpity Linden at Alexa’s barn. The focus is the Lab’s web properties, which include the Second Life website (including the blogs, Destination Guide, Maps, Search, the Knowledge base, etc.), Place Pages, Landing Pages (and join flow for sign-ups), the Marketplace, and so on and the Lab’s own website at lindenlab.com.

Meeting Format

A point to remember with the Web User Group meetings is that they are informal discussions on things like the Marketplace.

While the Lab does give information on the work they are carrying out, plans they have in-hand for updates to web properties, etc., equally, a lot of what is discussed is ideas and the taking of feedback from attendees, and should not necessarily be regarded as statements from the Lab as to what will happen, it priority, or anything else.

Within these reports, I try to indicate those plans / actions / projects that are in progress, and offer a differentiation between “firm” plans and ideas under discussion.

Web Updates

On April 16th, 2018, the Lab slipped out an announcement on a number of web property updates, which notably include the following.

Marketplace Guidelines Change

The SL Marketplace Fee and Listing Guidelines have been revised with regards to the policy on pricing products on the Marketplace in comparison to pricing the in-world. Previously, the guidelines stated:

The following actions are disallowed. Note that these actions are disallowed by the Second Life Terms of Service, and are restated here for clarification.

  • Anti-Competitive or Abusive Behaviour. Examples include, but are not limited to:
    • inflating prices on the SL Marketplace, in comparison to in-world or other e-commerce sites”

This has now been revised so that in-world pricing is no longer exempted, thus:

The following actions are disallowed. Note that these actions are disallowed by the Second Life Terms of Service, and are restated here for clarification.

  • Anti-Competitive or Abusive Behaviour. Examples include, but are not limited to:
    • inflating prices on the SL Marketplace, or other e-commerce sites”

With the Lab noting:

We’ve removed the section which applied to in-world stores.  This was contrary to your interests and our interests.  Marketplace is a tool to use in your overall product marketing strategy and if you’d like to differentiate pricing between on-line and in-world stores, that’s your decision to make.

Transaction History “Quick Filter” Options

A set of “quick filters” have been added to the transaction history page on the dashboard at secondlife.com. These provide the ability to list all transactions for the current day (“Today”), the last 24 hours (“1 Day”), the last 7 days and the last 28 days.

The new transaction history quick filters available through your Second Life web dashboard

Please refer to the announce for the full set of web-related updates.

Other Items

Legal Question: Resale Prices on Full Permission Items

Is setting a minimum resale price on full permission items legal? this is being referred to the Lab’s legal department. However, such things as recommended retail price options, FTC guidelines on supply chain selling (both of which are slightly different, admittedly), would suggest the practice is acceptable.

Lootbox Legal Status

Questions have been raised on the use of lootboxes in Second Life. In some countries (e.g. China, Japan, Australia, The Netherlands, the Isle of Man (UK) and now Belgium) they are regarded as gambling and subject to regulation / financial penalties. Additionally, lawmakers in the United States and mainland UK are said to be looking at the status of lootboxes. The questions asked in relation to Second Life are being referred back to the Lab’s legal team.

Premium Subscription Changes

At the April 20th, 2018 town hall event, Linden Lab CEO Ebbe Linden confirmed that as a part of pivoting Second Life’s revenue generation away from a heavy reliance on land, the Lab are looking at introducing a range of Premium account options which will have different levels of benefits associated with them – see here for more (includes an audio extract of his comments).

While details have yet to be finalised, Grumpity Linden spoke to some of the ideas under consideration at the Web User Group meeting. Because her comments are likely to be of interest beyond that meeting, I’ve provided a transcript of her comments, with an audio recording.

In Brief

  • Need to comment on a JIRA item (bug report or feature request) and cannot? send an e-mail to letmein-at-lindenlab.com giving your avatar name to request JIRA comment access. Note that if a JIRA has been imported by the Lab or had its status changed, you may still not be able to comment on it.
  • Linden Homes size increase: Linden Homes are currently undergoing a face lift, and Grumpity indicated the plan is to increase them in size (presumably to 1024 to match the “free” tier offered to Premium members. There is no time frame on when the updated Linden Home will be available, although it is hoped they will be ready before the end of 2018.

 

2018 UG updates #17/1: Simulator User Group

Motorheadz Café / Route6; Inara Pey, March 2018, on FlickrMotorheadz Café / Route66blog post

Server Deployments

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

  • According to the deployment thread, on Tuesday, April 24th, 2018, the Main (SLS) channel was updated with server maintenance package 18#18.04.09.514272, previously deployed to the RC channels and containing internal fixes and a fix for BUG-214702. However, a check on the simulator release via Help > About in the viewer reveals the simulator version to be 18.04.13.514504, which doesn’t appear to have associated release notes.
  • According to the deployment thread, there was no deployment to the three main RC channels – LeTigre, Magnum and BlueSteel – on Wednesday, April 25th, which reportedly remain on server maintenance release 18#18.04.09.514272. However, as with the Main (SLS) channel, these channels report as being on simulator version 18.04.13.514504.

Region Crossing Updates

On Wednesday, April 25th, the Snack RC was updated with a release designed to assist with region crossings.

“We’ve made some changes on the back-end with respect to message reliability,” Rider Linden stated at the Simulator User Group meeting on Tuesday, April 23rd. “We are hoping makes the transitions [from one region to the next] a bit more reliable … mostly it was a number of internal changes dealing with how agents get passed between simulators during a crossing or teleport.”

The simulator regions with the updated messaging code are:

Blake Sea – Atlantic
Blake Sea – Galilee
Blake Sea – Cattewater Blake Sea – Crows Nest
Blake Sea – Mizzen
Blake Sea – Nelson
Blake Sea – Thunderer
Blake Sea – Hawser
Blake Sea – Indefatigable
Blake Sea – Jones Locker

All of these can be accessed via the Blake Sea Half Hitch rezzing zone for those wishing to access them. I addition there is a block of region centred on “Est Full2” on Aditi that also have the updated region crossing code.

SL Viewer

There have been no updates to the viewer channels so far, leaving them as follows:

  • 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. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

Other Items

A recent back-end change made to PRIM_MEDIA_CURRENT_URL reportedly broke a lot of content (see BUG-216032), causing a lengthy debate during the Simulator User Group meeting. As a result of this discussion, Oz Linden provided an update on the change and on a further change the Lab has made which they hope will assist those experiencing issues as a result of the original change.

We installed an important security patch, which happened to no longer infer http for a URL that had no scheme (in my opinion a good change). That broke some scripts that had used the field for a URL but left off the scheme (e.g. “myserver.example.com/myapi”) so those were broken. In order to get those slightly sloppy but legit uses working again, we added the scheme for them (but used https because everyone always should).

Storing data in that URL field was never intended to work.

The fact that we broke uses that were never legit is unfortunate, but not something I feel an obligation to maintain compatibility with. We’ll try to help you recover data that’s trapped there, but we won’t change it so you can keep doing that. If you have scripts that you need to get the data back out of, let us know and we’ll try to work with you.

Those still experiencing issues should report them via the JIRA.

2018 SL UG updates #16/2: Content Creator User Group

A rally of (Animesh) raptors on Aditi

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 19th, 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.

Medhue Simoni Live streamed the meeting, and his video is embedded at the end of this summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.

Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.

Animesh Project

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 project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 5.1.4.514468 also brings the viewer to parity with the current release viewer.

Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
  • These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.

[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

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 (see BUG-214736 for more).

[8:44-9:12]  Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.

Environment 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.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.

Continue reading “2018 SL UG updates #16/2: Content Creator User Group”