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

ONI Zen; Inara Pey, May 2018, on FlickrONI Zenblog post

Server Deployments

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

  • On Tuesday, June 5th 2018, the Main (SLS) channel was updated with server maintenance package 18#18.05.25.515749, containing internal fixes and server-side support for the upcoming new Estate Management ban list management changes.
  • On Wednesday, June 6th, the three main RC channels – LeTigre, BlueSteel and Magnum – should be updated with a new server maintenance package, 18#18.05.30.515812, comprising:
    • Additional work to support localised Abuse Report categories.
    • Improvements to object updates as part of ongoing performance improvements.
    • Removal of the logging of a trivial message.
    • Internal fixes.

Week #23 should see the decommissioning of the RC Cruller channel, established to help those experiencing issues with the use of media URLs for data storage (see BUG-216032). Those affected by the update who are unable to complete their unpacking of data stored in media URLs by the end of the week, should use the deployment thread to indicate how much longer they need.

SL Viewer

There have been no updates to the current group of viewers in the pipeline at the start of the week, although merges and updates following the recent promotion of the Love Me Render viewer are expected. At the time of writing, the list reads as:

  • Current Release version 5.1.5.515811, dated May 31, promoted June 1 – formerly the Love Me Render Release Candidate – NEW
  • Release channel cohorts:
    • Pálinka Maintenance RC viewer, 5.1.5.515527, dated May 21.
  • 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.

Environment Enhancement Project (EEP)

EEP is coming along. There is a possible fix for the back-end issue we were seeing. I’m wiring up some of the UI so that people can start to use it… Just pulled in a couple of the shader updates that one of the other Lindens has been working on.

– Rider Linden, discussing EEP progress, Simulator User Group, June 5th, 2018

Other Items

Region Crossings

I am making small steps … for example, tomorrow’s update has better logging where the target region you cross into is tracking everything and logs when it has re-seated an AV on a vehicle, and sent updates for all attachments … I’m not aiming for a big system monitoring region crossings in real-time, but I’d like to know better stats on how long they take and the failure rate … I know it would look ugly but it really would make sense technically if crossings forced you to stop, get across, then keep going and not estimate movement and all that.

– Simon Linden, discussing region crossings at the Simulator User Group, June 5th, 2018

The last of Simon’s points is something Joe Magarac (animats) has been working with through the use of scripts, as previously discussed in these pages.

llName2Key

llName2Key is one of two new LSL deployed in connection with the upcoming return of Last Names (see this blog post and this blog post for more). It’s been noted that the wiki page (linked to above) lacks proper information (its companion, llRequestUserKey as a wiki page which is also a little brief).

The function should return the Agent ID for the named avatar (based on it seeking the first name or the first name and last name), if the avatar is in the region where the function is run. If the last name is omitted, “Resident” is assumed. However, there appears to be a bug some search criteria work when they should fail (e.g. “Firstname R” (or “@R”) seems to work when “Resident” avatars on a region, when it should fail. A bug report is to be raised.

 

2018 SL UG updates #22/3: TPVD meeting

Village of Ahiru; Inara Pey, May 2018, on FlickrVillage of Ahirublog post

The majority of following notes are taken from the TPV Developer meeting held on Friday, June 1st 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, 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.

Server Deployments

On Wednesday. May 30th, all three primary RC channels were updated to a new server maintenance package, 18#18.05.25.515749, comprising and internal fix (presumably for the unspecified bug which prompted the roll-back of #18.05.14.515432) and the simulator-side support for the updated Estate Management tools.

SL Viewer

[0:52-2:33] The Love Me Render viewer was updated to version 5.1.5.515811 on May 31st, and promoted to de facto release status.

All other viewers in the various pipelines remain unchanged from the start of the week:

  • Release channel cohort:
    • Pálinka Maintenance RC viewer, 5.1.5.515527, dated May 21.
  • 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.

It is likely all of the above will be updated as they are merged with the Love Me Render release.

360 Snapshot Viewer

[27:48-28:32]  The 360 snapshot project viewer has been on hold in part due to two reasons: the prime resource (Callum Linden) was assigned to another project; work on the viewer has been awaiting the development of an interface to allow direct uploads to Second Life Place Pages. In the meantime, the viewer code base is being maintained in parity with release versions of the viewer.

[28:57-29:34] There are also some graphics challenges that need to be addressed is trying to support the necessary high resolutions 360-degree images require couple with the low-end graphics systems many SL users have.

Upcoming Project Viewers

[2:34-3:07] The new project viewer with the updated Estate Management tools (ban list management, etc.) is expected “pretty soon”. This will work with the simulator-side Estate Management updates currently on the RC channels.

[5:26-5:42 and 7:20-8:35] Another upcoming project viewer has re-vamped texture caching. It’s hoped this will help with viewer performance. With it, users will be able to define a much larger overall cache size on their computer if they so wish. It is also hoped this work will include improvements to VRAM handling – although a problem here is that some systems incorrectly report the amount of VRAM they have available. Further, providing a recommended setting and assuming users will adhere to that recommendation doesn’t always work.

(There is also a text discussion on caching among games, etc.).

Viewer Camera Presets

[5:53-6:34] This is a contributed project from Jonathan Yap (who was responsible for developing and coding the graphics presets options in the viewer). It will allow users to define their own placements for the SL camera around their avatar (e.g. an over-the-should view, a view from overhead, etc.), which can then be saved and selected / used as required – see STORM-2145.

The work has been stalled awaiting a couple of new controls for manipulating the camera position being implemented. However, it is a project the Lab isn’t going to lose sight of, and it remains on the active project list.

Crash Reporting Changes

[18:18-21:04] The Lab is about to start experimenting with viewer crash reporting, removing the existing Breakpad based crash reporting tools and replacing it with BugSplat, a commercial service. If this works on a trial / experimental basis, the Lab will probably switch to using  BugSplat as their crash reporting mechanism.

Should this happen, TPVs using the current crash reporting mechanism may not want to merge the associated changes to use BugSplat, and continue to use the Brakpad mechanism (or introduce an alternative bug reporting solution of their own – such as Crashpad, regarded as the successor to Breakpad). Those wishing to use the BugSplat code will need their own subscription to the service and update the viewer code accordingly when using it in their own viewers.

From the Lab’s perspective is that dealing with crashes requires the maintenance and use of a lot of historical data which needs to be routinely searched, analysed, updated, etc., and a third-party company that specialises in this kind of work can probably do so and provide the necessary tools a lot better than the Lab can do on its own.

Project ARCTan

[4:24-5:22] This is the code-name for the project to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. As I’ve previously noted, the Lab is sensitive to the implications of doing this – particularly in the area of Land Impact, and will take steps to avoid disruption (e.g. through object returns) once the project reaches that point in time. (One area of potential impact is sculpties, which currently do not have their render cost accurately reflected in their land impact.)

The Lab has been gathering data as the first step in this work, and is “homing in” on better formulas, although Oz notes there is still a lot of work to be done and the project will be a “long, slow roll-out”. It’s likely that when a project viewer for this work appears (no time frame on this), it will include contributions for jelly dolling avatars with excessive texture use.

Land Auctions and Place Pages

[28:35-2855] The new auction system (users being able to auction their own land holdings will be run through the Second Life Place Pages. This has been a focus for recent work on Place Pages, which has delayed the development of the 360 snapshot viewer interface referenced above.

[30:27-31:47] The auction capability might even be made available (to some degree) in June 2018. This is likely to be just for Linden-owned land to start with, so the Lab can deal with issues without too much disruption / confusion, prior to the service being extended to users with land holdings.

The new user-to-user land auctions will be run through Second Life Place Pages, with Linden-run auctions starting the process off

As Ebbe Altberg has indicated, the plan will then likely to be to allow Mainland land holders auction their land directly to other Premium users, and then expand the ability from there.

The use of Place Pages for auctions means that those wishing to auction their land will need to create a place page for it.

Other Items In Brief

  • [11:32 and 13:30-13:40] 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 – see BUG-216294. This is regarded as expected behaviour. This includes a largely text-based conversation on options for de-rendering objects on other parcels, together with the idea about SL not being a place necessarily intended for isolated living, extending through to [18:10].
  • [22:23-22:47] “Social” tools in the viewer: it’s unlikely the Lab will make any changes to user profiles in the viewer any time soon; back-end work is being considered for group interfaces in the viewer, but this most likely won’t take place until after the cloud migration work has been completed.
  • Fun fact: Linden staff are subject to the same constraints in behaviour and activities when using ALT accounts as when using their official accounts. This means for example, a Linden staffer cannot participate in the upcoming user-to-user land auctions, and improper behaviour will be regarded in the same way as if they were using their official account.

2018 UG updates #22/2: CCUG meeting w/audio

Soul2Soul Med; Inara Pey, May 2018, on FlickrSoul2Soul Medblog post

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

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.

Resources

Current Status

Server-side support should now be largely “done”. There remains one issue awaiting resolution. Once this has been cleared, discussions will start on wider deployment of the code – potentially Aditi first, then to an RC channel on Agni (the Main grid). Still no release date due to ongoing work on the viewer.

Rigged Mesh Level of Detail / Bounding Box Issues

(BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.

A new approach to resolving this is being attempted which involves removing non-rigged mesh asset sizes from the rigged mesh bounding box.This will not involve changes to avatar scaling / height calculations. If it works, it should result in better bounding boxes for avatars and rigged mesh attachments in general, not just for Animesh. Currently, it is awaiting some back-end updates.

Avatar Limits and Cost Calculations

These were revised several weeks ago – see the link to Vir’s update in the resources list above – and are unlikely to change. At the previous CCUG meeting, there was some discussion over the streaming cost calculation for the Medium LOD, but again, this will not be changing.

Vir reminded people that the ARC calculation for Animesh is now related to the streaming cost calculation (as per the current project viewer – version 5.1.4.515420 at the time of writing). It therefore shouldn’t be subject to quite the same kinds of issue related to scale-based distortions as previously. It may also go through further tweaks.

On a broader note, costs (streaming, impacts, etc.), are going to be looked at as a part of a separate (to Animesh) project – Project ARCTan – see below.

Broken Rotations Issues

These comprise:

  • (BUG-139251), some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
  • When linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

No updates on these were available at the meeting.

Joint Offset Constraint

Setting (either deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results. To prevent this, a 5m joint offset constraint was introduced in the project viewer. This has / will be now backed out as it has been seen as overly restrictive. An alternative solution will be sought, and Vir hopes that having a fix for the bounding box issue (above) will help in this.

Animesh and Attachments

There has been confusion over Animesh and attachments. In brief:

  • One one Animesh object can be attached to an avatar at a time.
  • Animesh objects, while they have a skeleton, do not support avatar-style attachments. Instead, additional objects (e.g. a collar for an Animesh puppy) should be made a part of the Animesh linkset, and then driven by the Animesh skeleton / scripted animations within the Animesh (although objects in n Animesh linkset could be animated by their own scripts / animations if required).
  • The above has been discussed at length in previous meetings, due to concerns as to how No Mod Animesh items could be made to work with different options (e.g. a puppy wearing different styles of collar).

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 has been working to adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators). All of these had been intended to be extensions to the tattoo layer. However, in testing, it was found that feeding a wearable layer with these new channels to a viewer without the necessary support to use the channels, the viewer gets “unhappy”.

To avoid this, this Lab has opted to create a new wearable type which will know about these new bake channels. It will sit above the tattoo layer and below the clothing layers.  This should allow those wishing to make use of the new channels to do so without risk of impacting older viewers, which will simply ignore any new wearable layer they’ve not previously encountered. The flip side is, this extends the amount of work required to introduce a new wearable to the inventory service, in additional to the simulator, appearance service and viewer changes already required were the tattoo layer to be used.

A name for the layer has yet to be determined – but “universal” is under consideration – although Rider Linden (with tongue firmly in cheek) suggested “Bob”.

Scripting Support for Bakes On Mesh

No decision on whether this will be addressed, or if it is to be addressed, whether it will be a part of the initial release.

Continue reading “2018 UG updates #22/2: CCUG meeting w/audio”

2018 UG updates #22/1: Simulator User Group meeting

A Little Bit of Soul; Inara Pey, May 2018, on FlickrA Little Bit of Soulblog post

Server Deployments

The was no deployment to the Main (SLS) channel on Tuesday, May 29th, 2018.

RC Roll-back and Deployments

On Friday, May 25th, the deployments to the Magnum and BlueSteel RCs channels were rolled back from update #18.05.14.515432, which included server-side support for an upcoming capability to deliver estate information to estate owners and managers, to #18.05.07.515224. the roll-back was due to an unspecified bug.  The updates have remained deployed to the LeTigre RC.

There is due to be a further RC deployment on Wednesday, May 30th, 2018, but at the time of writing, details were still TBA. Commenting on the overall situation at the Simulator User Group on Tuesday, May 28th, 2018, Simon Linden said:

Let’s see … for server news, we had a roll-back last week of the RC channels for a bug. we’re going to have updates out tomorrow that have that fixed … and possibly another release that has a few other items in it. It’s all internal changes, as far as I know.

Upcoming Server-Side Maintenance Periods

The Lab has announced a series of upcoming server-side maintenance periods over the next several days (including the RC deployments these are set for:

  • Wednesday, May 30th, 2018 from 06:00 SLT (and rolls into the RC deployment window).
  • Thursday, May 31st, 2018 from 06:00 SLT.
  • Monday, June 4th, 2018 from 06:00 SLT.
  • Tuesday, June 5th, 2018 from 06:00 SLT (and presumably rolling into any planned Main (SLS) channel deployment planned for week #23).

During these maintenance periods residents may be logged off and will not be able to log in until maintenance is complete. In addition, residents may temporarily be unable to send messages or initiate group chats until the maintenance is complete.

Please refer to the Grid Status Page for more.

SL Viewer

There have been no further updates to the current SL viewers in the pipeline for the start of the week, leaving the list as:

  • Current Release version 5.1.4.515016, dated May 7, promoted May 16 – formerly the Ouzo Release Candidate.
  • Release channel cohorts:
    • Love Me Render RC viewer, version 5.1.5.515528, dated May 22.
    • Pálinka Maintenance RC viewer, 5.1.5.515527, dated May 21.
  • 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.

Environment Enhancement Project (EEP)

I’m plugging away at the first project viewer for EEP, and as soon as I get a blocker out of the way we’ll be able to get something into people’s hands.

 – Rider Linden, discussing EEP at the Simulator User Group meeting, May 28th

We have a blocking problem on the back-end at the moment … once we’ve gotten that fixed, we’ll deploy the back-ends that it depends on (simulator and inventory at least), and then put out a Project Viewer. y hope/expectation is that the Project stage will go well and we’ll get feedback quickly … Once we’ve responded to that, it’ll advance to RC, and at that point we won’t object to TPVs integrating it … The good news with respect to that is that the closer we get, the higher its priority gets, and the blocker is even higher priority for other reasons, so prospects are good.

– Oz Linden discussing EEP at the Simulator User Group meeting, May 28th

The meeting exhibited some lack of understanding on how EEP will operate. In brief EEP is a set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
    • Includes  arbitrary paths for both the sun and the moon.
    • Day cycles consist of a series of fixed skies. Each sky has a sun and a moon position.
    • In transitioning from sky to sky the sun or the moon will follow the great circle from one position to the next.
    • Can, howver be overrideen by the viewer (as per current “local” windlight settings.
  • 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 scripted functions.
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator, as well as viewer changes, and includes some infrastructure updates. The document linked to above (by Rider Linden) provides a summary of the document, and I attempt to offer updates through these Simulator User Group meeting notes and my Content Creation User Group meeting notes, as and when updates from the Lab are made available.

Grid-Wide Experiences

Work on grid-wide experiences is currently at a lower priority that other work currently being carried out (e.g. EEP), and so progress is slower. As with existing experience creation, only Premium members will be able to create grid-wide experiences. However, anyone will be able to accept and participate in them.

On-Line Friends Not Showing as On-Line

The is a recurrent bug that can affect people at different times and on different regions – all friends for the affected person appear as off-line. sometimes it can be rectified by IM’ing someone known to be on-line,forcing the Friends list then re-populates itself correctly. Simon Linden acknowledged the bug with the following comments:

It’s not caps fail – it’s a lost packet. There’s work going on to convert that to a cap so it’s more reliable, I believe. A work around is to tell folks to open up the web site and look at the friends on-line list there – that should be more reliable … The fact that you get an inaccurate list when you log in, and maybe a different one if you log out/in again, is due to packet loss. When you first land at a region, it needs to look up all your friends and status and send (or not) them the “is on-line” message, and also send a list to you. At the same time you’re getting updates for all the world around you, all your off-line IMs, etc. So there’s way too much traffic at once.

– Simon Linden, Simulator User Group meeting, May 28th

There also appears to be a similar issue that can be region-specific (see BUG-7557). This generally requires a region restart to resolve, and the underpinning causes still seems to be unknown.

 

 

2018 UG updates #21/2: Content Creator User Group

La Clef des Champs; Inara Pey, May 2018, on FlickrLa Clef des Champsblog post

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

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.

Current Status

  • Work is continuing on moving towards a main (Agni) grid deployment of the server-side code to support Animesh.
  • Everything has been through QA, and there is a remaining issue with validating attachments. This is liable to require an additional fix.
  • It is likely that the simulator code will initially be deployed grid-wide on the beta (Aditi) grid for a shakedown period, prior to starting its deployment to the main grid through the usual process of RC deployments ahead of a full deployment.
  • There are still a number of issues that are TBD within the viewer:
    • Broken Rotations Issue: two potentially related problems.
      • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
      • The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.
      • What is to be done about this still hasn’t been determined, although the Lab has been playing with playing the physics shape in the root of the object.
    • Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. Graham linden has been working on some fixes for this which should improve accuracy and performance, but further work may be required. Once this has happened, there will be a further update to the project viewer.

Additional Animesh Discussions

  • Animesh Complexity: there is a further update to come to the Animesh complexity values (Advanced menu > Performance Tools > Show Avatar Complexity – applies to both avatars and Animesh objects in the project viewer). This should fix some inconsistencies in the reported values.
  • Animesh updated limits and cost formulas discussions:
    • Land Impact: streaming cost: some have questioned with some question with the 50% bounding on LODs could be more stringent. Vir’s view is that 50% is sufficient to allow for a broad range of capabilities among creators, and being more stringent could simply result in a greater addition to land impact, which could affect the use of Animesh. There is an argument that some models require 75% bounding between the high and medium models.
    • Triangle count limit: There have been requests for further changes to the triangle count limit (e.g. allowing land owners to somehow be able to change it). As the limit was raised to 100,000, it is unlikely to be changed again before Animesh is deployed, and the idea of land owners being able to adjust it is seen as potentially in inconsistencies in how Animesh works in different locations. If it is seen that there is a need to raise the tri count limit, it will be done globally.
    • Avatar attachments: due to performance concerns, the limit of only one Animesh attachment to an avatar at any given time is not going to be changed ahead of Animesh deployment, but might be revisited in the future.
  • Animesh ignores SL scale settings:  this is a result of how rigged meshes are handled – scaling doesn’t matter for worn mesh items, as other mechanisms are available for avatar scaling (e.g. the shape sliders, etc.). As these mechanisms aren’t available for Animesh in the initial release (e.g. there is no actual body shape associated with Animesh objects, ergo, no sliders), scaling is dependent upon custom joint positions.
    • Including more capabilities, such as possibly associating a body shape with an Animesh object, is seen as being a follow-on project to come some time after the initial release.

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 continuing to work on adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators) and the associated tattoo layer UI support to the viewer to allow them to be used.

This is a three-way set of updates, requiring changes to the appearance service, the simulator and the viewer. This, combined with concerns over maintaining backwards compatibility in the appearance service means that getting the work to a testable state is taking a little longer to achieve.

In the meantime, the changes to the appearance service seem to have caused a glitch which can make some avatars appear to be wear “black skirts” when seen on the Animesh test regions Aditi. This will hopefully be corrected soon.

In Brief

Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette).

Graham Linden is now looking at the issue, however, the release of Animesh is not contingent on the basis of any fix, which will probably be part of the ongoing rendering updates Graham is working on.

Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

Imposter Clipping: imposter avatars can appear “clipped”. This appears to be related to the problem of not having a good real-time bounding box associated with rigged meshes (which can result in some meshes appearing clipped as well). This is being looked at, and the hope is that if a better means of defining the bounding box for rigged meshes can be found, it will resolve the importer issue. However, the release of things like Animesh are again not contingent on a fix for this issue being implemented.

 

2018 UG updates #21/1: Simulator User Group meeting

The Shire; Inara Pey, May 2018, on FlickrThe Shireblog post

It’s a quiet start to the week.

Server Deployments for week #21

There are no server deployments planned for week #21! To quote Mazidox Linden in the server deployment thread:

Hey everyone! We’ve got a bunch of things we’re still testing this week and don’t have any rolls for any channels (Second Life Server, RC Bluesteel, RC LeTigre, RC Magnum, or RC Cruller), and we don’t anticipate any rolling restarts. We’re aiming to have at least one new server version through testing by next week, and hopefully we’ll have a better view of that by Thursday. If you’re interested please join us at the SBUG meeting on Aditi.

RC Cruller is likely one of the smaller RC selections (like Snack and Cake), and is apparently named for the small cake made of rich dough twisted or curled and fried in deep fat (I can feel my arteries hardening just typing that!).

SL Viewer

The Ouzo Maintenance viewer, version 5.1.4.515016, was promoted to the de facto release viewer in week #20. As a result:

  • The Love Me Render RC viewer containing rendering fixes and improvements updated to version 5.1.5.515528 on May 22nd, 2018.
  • A new Maintenance RC viewer, code-named Pálinka, after the traditional fruit brandy popular in Central Europe, was release on May 21st, 2018. Maintenance RC 5.1.5.515527 contains some 36 fixes and improvements, as specified in the release notes.

Outside of these updates, the viewer pipelines are as follows:

  • Current Release version 5.1.4.515016, dated May 7, promoted May 16 – formerly the Ouzo Release Candidate.
  • 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.