2018 SL project updates 2/3: TPV Developer meeting

Tranmore Bay; Inara Pey, December 2017, on FlickrTramore Bayblog post

The following notes are taken from the TPV Developer meeting held on Friday, January 12th 2018. The video of that meeting is embedded at the end of this update, 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.

Viewer Pipeline

[0:00-4:24] The Nalewka Maintenance RC updated to version 5.0.10.330173 on Wednesday, January 10th, and the Wolfpack viewer has been withdrawn. This leaves the remainder of the SL viewer pipelines as follows:

  • Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
  • Release channel cohorts:
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

The Update to the Alex Ivy 64-bit RC viewer (Tuesday January 9th, and reported in Part #1 of this week’s updates) will be the last such update for that viewer as an RC, and it will most likely be promoted to release status in week #3 (commencing Monday, January 15th). There should be an official blog post accompanying the promotion when it happens, encouraging those on Windows who can upgrade their version of Windows to 64-bit / Windows 10 to do so.

  • [28:16-30:11] A reminder that Alex Ivy is Windows and Mac, and that the Lab has a separate project for Linux. This will require support from the Linux community to help move the Linux viewer build to a Debian package using system libraries, so allowing TPVs to add the dependencies they require for their flavour of Linux build. If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to require support from the Linux community for fixes. A repository for code submissions will be made available, together with a blog post / open-source community notification on the specifics, after the 64-bit viewer has been promoted to release status. Those wishing to support the work will need to sign a contribution agreement with the Lab.

The Voice RC has no known outstanding issues, and should be ready for promotion once Alex Ivy has been promoted to release status and the Alex Ivy code has been merged into the viewer.

The 360-snapshot viewer is looking set to move from project viewer status to a release candidate viewer.

A new viewer branch is being prepared – the media branch, which will be specifically for Chrome Embedded Framework (CEF) changes and other media handling updates. This will likely appear some time after the Alex Ivy viewer has been promoted to release status.

A further viewer project on the horizon is a further update to the viewer build chain, and bring that more up-to-date with things like Visual Studio, etc.

Viewer Deprecation

[4:25] Once Alex Ivy is promoted to release status, the Lab will be deprecating all versions of their viewer not using Asset HTTP loading (e.g. viewers prior to version 5.0.6). At some point after this, work will then commence on removing all UDP asset messaging from the servers, so anyone still using a viewer not fully supporting Asset HTTP will be unable to load gestures, animations, sounds, etc.

Avatar and Object Rendering

[9:26-10:32] Work on revising the current avatar complexity and object rendering calculations is due to resume “in the next week or two”. It is hoped this will allow the Lab to adjust the formulas used to make a reasonable generalisation in the rendering cost of things, and whether or not objects are being reasonably accounted for in those calculations, although things may not change that much. However, the Lab is “determined to fix some of the bad incentives in the current calculations”.

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; a new environment asset type 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

[33:32-35:06] Rider linden is making progress, with his next step being to get the new setting objects defined as assets which can be stored in inventory. Once this has been done, he will be comfortable with setting up test regions on Aditi ready for testing once a project viewer is available. The viewer will require new UI elements for manipulating windlight assets, the initial design work on which, Rider jokingly claims, has already given him a nervous twitch in his left eyebrow!

In Brief

  • [13:35-15:32 ] Group Notices failures: some work has been done on this, showing that problems can start to occur if the group chat servers are left running too long, so a round of restarts should hopefully prevent this. Work is also going to be put into making group notice delivery more robust when logging-in, and this will hopefully be out in the next few months.
  • [22:49-26:55] Viewer widget documentation & additional viewer documentation: the viewer web widget wiki documentation is currently out-of-date, and a request has been made to update it. The Lab doesn’t have any documentation on the viewer (e.g. design documents etc.), outside of what is available on the wiki.
  • [32:04-32:45] IMs to E-mail: there have been reports at the recent Web Group and Simulator User Group meetings that some IMs to e-mails failed over the holiday period. This has been investigated, and the issue did lie with the Lab. However, it has been rectified, and all IMs to verified e-mails addresses should work correctly.
  • [11:02-11:48 – in text+ voice comments] The next Firestorm release will not allow changes to the debug RenderVolumeLODFactor which go above 4 to persist between log-in sessions. People will still be able to set the value above 4, but will have to do so each time they log-in. [18:33 – in text] There is to be one more beta release of the new Firestorm, which should be followed in about a week’s time with a formal release (late breaking issues allowing).

 

Advertisements

2018 SL project updates 2/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 11th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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 article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!

– Vir Linden joking about the name “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.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Performance Profiling

[2:08-3:58] Work is now starting on performance profiling for Animesh to determine suitable limits (e.g. tri counts, LI, etc.) when Animesh goes live. This is regarded as being one of the last steps before the project moves to the main grid. As a part of this, Vir has been adding the ability to control the triangle count limits for Animesh objects on a per region basis. This will be used to set different limits on different regions for the Lab’s internal performance profiling, and a region with the capability will also be made available on Aditi for public testing, and details will be made available once the region is up and running.

Object Animations And Animating Animesh

[43:13-55:34] A convoluted enquiry requiring a feature request in order to be made clear, but appears to be a request to provide a means for object animations to override an Animesh object’s own animations. So, for example, an Animesh hamster could be placed into a treadmill, and the treadmill either override the hamster’s in-built animations (stored in the hamster object’s Contents tab of the build floater) and cause the hamster to run, in much the same way as in-world objects can override avatar animations.

Such a capability could offer additional flexibility for Animesh – if a creator brings out a new toy for a pet (e.g. the treadmill, above), a means by which the treadmill could override the pet’s behaviour would avoid the need to update the pet as well in order for it to make use of the new toy. It’s unlikely such a capability will be considered for this phase of Animesh; however, Vir has requested a feature request on the idea is filed, so it can be considered alongside other work in a future Animesh update.  Hopefully, any feature request will avoid the use of pseudo technical terms such as “faux permission system” and “reverse animation system”, which initially caused some confusion when the idea was raised at the meeting.

In Brief

  • [4:00-8:10] Performance (FPS) issues when camming on Animesh: there has been a report of some mesh items causing drops in FPS rates when converted to Animesh, leading to choppy camera motion for some. Vir has been looking at one of the models in question, and believes the problem lies with the recalculation of attachment overrides, which can be excessive and even be carried out when there is no change in the object itself. Improving when and how the calculations are handled should hopefully resolve the problem, which can obviously be exacerbated through models having more joint positions defined. The fix, once implemented – hopefully in the next Animesh viewer – may help with other instances where there is a performance drop-offs when camming / zooming.
  • [8:51-10:55] LOD Drop: this is not considered an Animesh specific issue. Essentially, Animesh objects are being treated by the viewer as if they are avatars, and so get a similar boost in LODs, which needs to be tweaked.
  • [31:02-33:29] “Dropping” Animesh objects (i.e. allowing avatar to put pets, etc., down on the ground, without having to detach them back to inventory first, then rez them in-world): as per my 2018 week #1 CCUG meeting notes, this is still considered too big a piece of work to add to the Animesh project, as it requires changes to a variety of elements: land impact calculations, physics updates, etc. It could also result in forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again. However, such a capability for dropping mesh might be looked at again in the future.

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. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

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

Current Progress

[8:21-9:25] Anchor Linden is working on issues around getting the appearance service updates out. These include on problems specific to Animesh attachments. A setting is also being added which means that the texture resolution increase (to 1024×1024) isn’t applied by the baking service until there is a mesh surface requiring it. Work on adding further baking servers is also required to manage the compositing / baking load at 1024×1024. However, the updates are now available on Aditi.

[11:04-21:12] A further explanation as to what Bakes on Mesh is, born from expressed confusion over the term “baking” in terms of 3D rendering, and the fact that the current work only applies to meshes worn by avatars.

[21:22-26:00] Bakes on mesh for Animesh: this would be part of any “phase 2” work that follows-on from the initial work on Animesh, once Animesh objects have a formal inventory structure. This would be required in order for the baking service to be able to recognise and use textures with Animesh objects. Includes a discussion on how the baking service currently works.

Other Items

[1:14-2:03] Mesh uploads: recognising linkset object names: as mentioned in my previous update, when uploading mesh objects, only the name of the root item in a linkset is recognised, everything else is simply “object”, rather than carrying over any naming convention used when creating a model (e.g. “dog”, “dog_head”, “dog nose”, “dog_tail”, etc., or some variation of more useful naming). Various requests have been made to change this for consistency of item naming. The Lab has been looking into this, and a problem is that the server itself ignores any linkset object names outside of the root object. This means that preserving object names is more complex than had been hoped, although investigations on what might be done are ongoing.

[38:08-39:20] *JOKE**: comments on mirrors and raytacing: do not take seriously! An explanation is supplied.

2018 SL project updates 2/1

D o X; Inara Pey, December 2017, on FlickrD o Xblog post

Update, January 10th: Subsequent to this post being published, the deployment plans for the RC channels were revised, and details have been add below to reflect this. My thanks to Kyouko for drawing my attention to the updated server deployment thread.

Server Deployments

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

There are no planned deployments for 2018 week #2. All channels remain on the same server release 17#17.12.01.511131. However, the Main (SLS) channel was restarted on Tuesday, January 9th, 2018.

There was no deployment to the SLS Main channel on Tuesday, January 9th, 2018, leaving it on  server release 17#17.12.01.511131. The channel was, however, restarted.

Following the original publication of this update, the server deployment thread was updated to indicate there would be a deployment to the major RC channels on Wenesday, January 10th: server maintenance package 18#18.01.08.511751, comprising internal logging improvements.

SL Viewer

The Alex Ivy RC viewer was updated to version 5.1.0.511732 on January 9th, 2018. All other viewers currently remain as per the end of week #1:

No Copy Exploits Update

An area of concern / upset for content creators has been the use of server exploits to generate copies of No Copy items. While a long-standing problem, the issue has gained a lot more coverage of late due to the frequency with people have been using various exploits to illegal copy and then sell gacha items. In November, the Lab closed one exploit used in generating No Copy items, and reported this, and the steps they put in place to help recognise when someone might be attempting to use it (see: Exciting Improvements to SL Fee Updates to Enable Even More).

Since then the Lab has continued to work on issues (see my SL project update from 2017 week #47). However, there have been mistaken claims that the Lab stated it had resolved “the” exploit, which is not the case – see the Lab’s blog post above), which Oz and Simon sought to correct in the meeting, with Oz Linden stating:

We never said we were sure we’d fixed all possible exploits, and we won’t say that because we might not know about them all.

Simon then added:

I know that statement and we deliberately and clearly said it wasn’t done. There was more work but we were making progress. I know a lot of people reading it probably wanted it to say (and mean) we fixed everything. We know we haven’t.

In terms of what more is being done, Oz said:

If I were to tell you now that we’re working on “method X” for object copying, I’d be letting people who might not know about it that it existed, and telling those who know how to use it to hurry up while the getting is good.

Other Items

  • New Linden: the Simulator User Group meeting on Tuesday, January 9th was joined by Bugsly Linden. A new member of LL’s QA team, he joined the Lab around a month ago – and is a former Second Life resident.
  • Group chat issues: there has been a noted uptick in group chat issues. Commenting on this, Simon Linden said, “We looked into group chat recently and did a few things that should have helped. [In the meantime] for group chat lag problems, please send in a support ticket – the group name is crucial as its most likely a specific server needs attention. Also [give the] time it happens, and the region you’re on. Sometimes it’s the region’s issue.”

2018 SL project updates 1/3: Web User Group and viewer

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

The majority of these notes are taken from the Web User Group meeting held on Friday, December 8th, 2017. These meetings are generally held on alternate Fridays, and 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.

Not all of these topics will be discussed at every meeting, however, the intention within the group is to gain feedback on the web properties, pain points, etc., and as such is very much led by comments and input from those attending. Along with this are two points of note:

  • Specific bugs within any web property  – be it Marketplace, forums, Place Pages or anything else), or any specific feature request for a web property should be made via the Second Life JIRA.
  • Alex Linden provides routine updates on the Lab’s SL-facing web properties as and when appropriate, which can be found in the Second Life Web thread.
  • Note that the SL forums are not covered by the Web User Group, as the management of functionality of the forums falls under the remit of the Support Team.

Web Single Sign-On

Single sign-on (SSO) should have been implemented for most of the Lab’s web properties (e.g. sign on to your account dashboard and then visit the Marketplace using the same browser, and you should be automatically logged in there) – although there are some properties (such as the JIRA and the land auctions domain) which are not currently part of the SSO process. However, there seem to be inconsistencies in how it is working, with some reporting that:

  • If the log into their dashboard, they can access the Marketplace via the Shopping link OK, but if they attempt to use the Marketplace via a separate tab, they sometimes have to log-in again, or
  • They also have to sign-in to different properties when opening them in new tabs, even if already signed-in elsewhere.

Having very restrictive cookie settings could cause problems with SSO. There may be a specific order of log-in that is required for it to work, which the Lab will check. Otherwise those experiencing such problems are asked to write-up a details JIRA on the problems they are experiencing, and the domains where SSO appears to be failing.

Governance, Legal, Finance and Technical

Often at user-group meetings questions are asked around matters of governance or which may be related to legal / financial issues (e.g. fraud or alleged cases of fraud). All of these matters are overseen by teams outside of the technical personnel who attend the in-world meetings, and so  – while it may be frustrating for those raising the questions – cannot comment on or address such issues.

Marketplace

  • Blank folder names in listings: see BUG-9984 – this is still occurring, and the JIRA has been re-opened for comment, with a request that specific recent instances of the problem are reported (you may need to send an email to LetMeIn@lindenlab.com & request access to comment.
  • Variants in listings: this is a long-standing request – to allow things like colour variants of an item in a single Marketplace listing, rather than having to list the variants individually. This is something the Lab wants to address, although it is not on the short-term list of work they will be tackling, nor is it necessarily an easy thing to implement, but it is climbing slowing up the list.

  • Marketplace Demos: demos are a pain point for some users of the MP, in that they cannot be easily filtered out of searches, even when using boolean parameters. various ideas have been put forward over the years for better handling of searches / excluding demo items. However, most are difficult to implement successfully, simply because of the way the system can be gamed (e.g., boolean exclusion of “demo” can be currently gamed by people listing items as “d_emo” or similar). The Lab is aware of the pain points with demos and free item listings, but again, this are things which have yet to rise to the top of the list of improvements they would like to make to the Marketplace.

Feature Requests

Feature requests – raised via the Second Life JIRA – are the best way of bringing ideas to the Lab’s attention. These are reviewed an assessed (triaged) on a weekly basis. When raising a feature request, remember to state a clear user case: what the issue being addressed is, why it matters, how your idea improves things, an indication (the more detailed the batter) of how the idea can be implemented, and so on. If you’re proposing a UI improvement, then consider including mock-up images of whatever you are proposing; if it is possible to illustrate the idea clearly some other way, do that, and provide an explanation. Try to be as clear and direct as possible.

Place Pages

The Lab continues to tweak and improve Second Life Place Pages, the most recent addition being to the seach option, which now titles thumbnail images and descriptions of places matching the search criteria.

Place Pages search now titles results with thumbnails and descriptions

Other Items

  • The wiki search is currently broken: this is a known issue at the Lab and is being actively investigated.
  • Inventory & load times: The Lab hopes to do further work on inventory, looking to improve things like load times and overall inventory robustness. This work will initially focus on fixing some bugs and deprecating various old UDP messaging, mostly likely sooner in the year than later, before moving on to hopefully making it more performant.
  • Aditi inventory syncing: there is still an issue with synchronising Aditi (the beta grid) inventories with main grid inventories. The latest issues occurred just before Christmas and are still being investigated.
  • Re-activating old accounts: if yo have a Basic account you have not used in a number of years and wish to activate it, it is possible that its associated inventory has been place in what the Lab call “cold storage”, and could subsequently exhibit continued slow response times. If the account is to be regularly use, a request can be made to support to have the associated inventory for the account moved – although this must be done at a time when you are not using the account.
  • Keeping abreast of web property updates: Alexa Linden routinely posts updates on various SL web properties on the forums, where they can be seen and commented on.

SL  Viewer

On Thursday, January 4th, the Nalewka Maintenance RC viewer updated to version 5.0.10.330148. On Wednesday, January 3rd, the follow two viewers were updated:

The rest of the viewer pipeline remains as:

2018 SL project updates 1/2: Content Creation User Group

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 4th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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 article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

General Project Status and “Must Dos” List

[33:24-34:10] There are around 14 “must do” items remaining on the list of work to be completed for Animesh before it can really move towards release. Some of these are fairly major – such as performance profiling (tri, count, LI, etc., limits evaluation, and so forth). There are also a number of bugs to be fixed or determined to be trivial enough so as not to prevent Animesh from moving to release / require work outside of Animesh.

Bug Stomping

[1:12-1:54] Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. It now appears this is a race condition issue, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

Shadow Rendering Issue

Animesh could exacerbate an issue with rendering shadows for faces of rigged / static mesh using transparencies

[3:33-13:52] There has been a long-standing issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by the latter to render incorrectly (shadow rendering conforms only to the geometry silhouette). Animesh can exacerbate this issue on some objects (note the image of the tree on the right, and how the shadows of the leaves (faces using transparencies) are render.

As this appears to be a rendering pipe issue, rather than a specific problem with Animesh, it may require investigation and resolution by those handling viewer rendering pipe issues, If so, this could take time to complete, and so is currently being viewed as outside of the current Animesh project, and not a blocker to any initial deployment of this phase of the Animesh work.

“Dropping” Animesh / Mesh

[43:12-47:25] As previously noted in these updates, worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This makes the ability for people to pick up Animesh pets, carry them, then put them down in-world awkward.

The Lab’s view is that as dropping mesh directly in-world was never considered, the code-path for achieving this is not clear, touching as it would on a variety of elements: land impact calculations, physics updates, etc; there’s also a risk of forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again.

However, pets are seen a major use for Animesh, so not having a means by which they can easily be put back down in-world after being carried is seen as a potential limitation in the adoption of Animesh by pet creators; as it is, many have kept to using (render-intensive) sculpties with their pets, simply so they can retain the ability to pick them up and then put them back down in-world, rather than having to force users to detach and re-rez the pet after holding it.

The issue is again being that back to the Lab for further discussion.

In Brief

  • [14:49-17:12] Global scaling and resizing: not something that is going to be implemented for Animesh with this initial work, but may be added later. It is possible to get the effect of global scaling on a rigged object by scaling in joint in the hierarchy individually, but this may not give consistent, expected behaviour.
  • [17:32-20:29] Setting position and rotation of rigged meshes: slight confused discussion on whether rigged mesh attachments can be re-positioned / rotated. Generally, rigged meshes cannot be re-positioned / rotated as their the vertices are recorded to set distances from the avatar bone. However, Animesh attachments (which have their own skeleton) should be capable of position / rotation changes releative to their attachment points.
  • [20:44-24:40] Slider support for Animesh: avatar shape sliders are not supported in the initial Animesh work, as these require a shape to be associated with an object which, as per the summary notes for the project (above), is considered a possible Animesh follow-on project. For this phase of the work, shape changes can only be defined by setting joint positions / using animations. The reason why shapes, sliders, etc., are seen as a potential follow-on project is that they will require an extensive overhaul of the baking service (which manages appearance information), so that it recognises Animesh objects and can handle them.

Continue reading “2018 SL project updates 1/2: Content Creation User Group”

2018 SL project updates 1/1

Sol Existence; Inara Pey, October 2017, on FlickrSol Existenceblog post

Server Deployments

There are no planned deployments for the opening week of 2018. There are currently no DRTSIM projects on Aditi (the beta grid) awaiting promotion to the Main grid, however, there may be new RC deployments for week #2 (commencing Monday, January 8th).

SL Viewer Updates

There have been no SL viewer updates over the holiday period. This leaves the viewer pipeline as per the end of 2017:

  • Current Release version 5.0.9.329906, dated November 17th, promoted November 29th – formerly the “Martini” Maintenance RC
  • Release channel cohorts:
  • Project viewers:
  • 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.

TPV Updates

The following  third-party viewers updated over the holiday period:

  • Black Dragon updates to version 2.9.6.
  • Cool VL viewer updated to version 1.26.20.40 (stable), and 1.26.21.6 (experimental).
  • Catznip updated to version R12 on January 2nd, 2018 – see my overview for more.

My weekly viewer release summaries will resume from week #2, 2018.

SL Feature Summit

The next Second Life “feature summit” when potential projects and major updates for SL are considered / reviewed, is due to take place in February 2018. These meetings are generally held around every 6 months.