There was no deployment to the Main (SLS) channel on Tuesday, February 21st, again leaving it on release 17#17.01.27.323172. However, all regions on the channel were restarted in keeping with the Lab’s policy of restarting a channel every other week, regardless as to whether or not it has received a deployment update.
On Wednesday, February 22nd, all thee RC channels received a new server maintenance package containing “minor” changes. No release notes available.
RC Release E-mail Issue
One of the changes on the RC release is to increase privacy protection on e-mails – which is a good thing. However, it now means that the viewer is performing a check it doesn’t need to do, and as a result, sending snapshots to e-mail ((aka “postcards”) can fail or encounter problems.
There is a viewer-side fix for this in the works, but it has yet to clear LL’s QA, but will be appearing in a viewer once it has. It also means that all viewers which do not have the fix can encounter issues when trying to send snapshots to e-mails, and so will also have to include the fix as well.
SL Viewer
No further updates this week, leaving the various pipelines as:
Current Release version: 5.0.1.323027, dated January 25, promoted February 3 – formerly the Maintenance RC viewer.
RC viewers:
Maintenance RC viewer version 5.0.2.323567 dated February 14th – a range of improvements and features – overview here (initial release version number)
Love Me Render RC viewer version Version 5.0.2.323361, dated February 9th – rendering pipeline fixes and improvements
Project viewers:
Project Alex Ivy (LXIV), 64-bit project viewer version 5.1.0.501863 for Windows and Mac, dated January 10th
360-degree snapshot viewer, version 4.1.3.321712, dated November 23, 2016 – ability to take 360-degree panoramic images – hands-on review.
Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
E-mail Verification Update
The Lab is proceeding with e-mail verification, so again, if you haven’t already done so, please read my post here. There is still no timeline for when the switch-over will occur, and the Lab will provide a blog post as things come into force. Also, while they won’t immediately be affected, this will mean that eventually IMs to e-mail and then marketplace notifications for merchants will ease working for all unverified e-mail addresses.
Other Items
Links Not Clickable in Group Notices
This is quite an old issue (see BUG-10498), but is apparently occurring again. Speaking at the Server Beta User Group meeting, Mazidox Linden requested if anyone encounters it and can reproduce it, could they please raise a new bug report, stating how they encountered and reproduced the issue.
The gathering: people gather for the CCUG, including a Bento ridable dragon, a work-in-progress by Teager (l) and a Bento wearable dragon, also a WIP by Thornleaf (r)
The following notes are taken from the Content Creation User Group meeting, held on Thursday February 23rd, 2017 at 1:00pm SLT at the the Hippotropolis Campfire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.
Core Topics
HTTP asset fetching
Animating objects
Applying Baked Textures to Mesh Avatars
HTTP Fetching
As previously noted, the Lab is working on moving landmarks, gestures, animations, sounds and wearables (system layer clothing) from UDP delivery via the simulator to HTTP delivery via the CDN(s). This work is now progressing to the stage where initial testing is liable to be starting soon. It’s not clear if this is internal testing with the Lab, or whether it will involve wider (Aditi testing) as well. As things progress, expect the viewer-side changes to appear in a project viewer and then progress through the normal route of testing / update to RC and onwards towards release.
Potential Project: Animated Objects
As noted in my last Content Creation UG meeting notes, the Lab is taking a speculative look at using the current avatar skeleton to animate in-world objects to provide a means for users to more easily create animated objects (e.g. non-player characters – NPCS -, plants and trees responding to a breeze, providing mesh animals which do not rely on performance hitting alpha swapping, etc) – see feature request BUG-11368. for some of the ideas put forward which helped prompt the Lab’s interest.
It is important to note that this is still a speculative look at the potential; there is no confirmed project coming off the back of it, the Lab is currently seeking feedback on how people might use the capability, were it to be implemented. No in depth consideration has been given to how such a capability would be support on the back end, or what changes would be required to the viewer.
One of the many issues that would need to be worked through is just the simple matter of how an object might be animated to achieve something like walking, running or flying. These require the simulator to make certain assumptions when handling an avatar which are not a part of object handling. There’s also the question of how the skeleton would be applied to an object.
Having animated objects does give rise to concerns over potential resource / performance impacts. for example, someone having a dozen animated pets running around them as animated objects could potentially have the same resource / performance overheads as thirteen actual avatars in a region.
One possible offset to this (although obviously, the two aren’t equitable) is that mesh animals / objects which currently use a lot of alpha flipping to achieve different “states” of “animation” (such a the squirrel which can jump from the ground and swing on a nut holder and jump back down again, or the peek-a-boo baby bears, etc., all of which are popular in gardens and public regions) could be made a lot more efficient were they to be animated, as the resource / performance hitting alpha swapping could be abandoned.
It was suggested that rather than having the full skeleton available for animated objects, it might be possible to use a sub-set of bones, or even the pre-Bento skeleton. Agreeing that this might be done, Vir pointed out that using the full skeleton would perhaps offer the most flexible approach, and also allow the re-use of existing content, particularly given that things like custom skeletons (also mooted) would be too big a project to undertake.
A closer look at Teager’s WIP Bento ridable dragon with Teager aboard, which has yet to be textured
Applying Baked Textures to Mesh Avatars
Interest is increasing in this potential project, which would allow baked textures – skins and wearble clothing layers – to be applied directly to mesh avatars via the baking service. This also has yet to be officially adopted by the Lab as a project, but there is considerable interest internally in the idea.
As I’ve previously reported, there is considerable interest in this idea, as it could greatly reduce the complexity of mesh avatar bodies by removing the need for them to be “onion skinned” with multiple layers. However, as I noted in that report, a sticking point is that currently, the baking service is limited to a maximum texture resolution of 512×512, whereas mesh bodies and parts (heads, feet, hands) can use 1024×1024.
These is concern that if the baking service isn’t updated to also support 1024×1024 textures, it would not be used as skins and wearable using it would appear to be of lower resolution quality than can be achieved when using applier systems on mesh bodies. Vir expressed doubt as to whether the detail within 1024×1024 textures is really being seen unless people are zoomed right into other avatars, which for most of the time we’re going about our SL times and doing things, isn’t the case.
Troy Linden wears a Bento octopus “backpack”
This lead to a lengthy mixed text / voice discussion on texture resolution and extending the baking service to support mesh avatars (were it to go ahead), which essentially came down to two elements:
The technical aspects of whether or not we actually get to see the greater detail in 1024×1024 textures most of the time we’re in world and in re-working the baking service to supporting 1024×1204 across all wearable layers from skin up through to jacket.
The sociological aspect of whether or not people would actually use the baking service route with mesh avatars front , if the texture resolution were left at 512×512, because of the perceived loss of detail involved.
Various compromises were put forward to try to work around the additional impact of updating the baking service to support 1024×1024 textures. One of these was that body creators might provide two versions of their products if they wish: one utilising appliers and 1024×1024 textures as is the case now, and the other supporting the baking service and system layers at 512×512, then leave it to users to decide what they want to use / buy. Another was a suggestion that baking service support could be initially rolled out at 512×512 and then updated to 1024×1024 support if there was a demand.
None of the alternative suggestions were ideal (in the two above, for example, creators are left having to support two product ranges, which could discourage them; while the idea of leaving the baking service at 512×512 falls into the sociological aspect of non-use mentioned previously). Currently, Vir appears to be perhaps leaning more towards updating the baking service to 1024×1024 were the project to be adopted but, the overheads in doing so still need to be investigated and understood.
Other Items
.ANIM Exporter for Maya
Cathy Foil indicated that Aura Linden has almost finished working on the .ANIM exporter she’s being developing for Maya. The hope is that the work will be completed in the next week or so. She also indicated that, in keeping with Medhue Simoni’s advice from a few weeks ago (see .BVH Animations and Animation Playback), she was able to overcome some of the issues being experienced with fine-tuning .BVH animation playback, although there are still problems.
The .ANIM exporter will be available for anyone using Maya, and is not something dependent upon Mayastar.
Avastar 2.0 in RC
The upcoming fully Bento compliant version of Avastar is now available as a release candidate.
IK Constraints
Tapple Gao has been looking at IK (Inverse Kinematics) constraints within Second Life. These aren’t widely used within existing animations – although up to about eight constraints can be defined – largely because the documentation doesn’t appear to be too clear. Tapple hopes to improve this through investigation and then updating the SL wiki.
Next Meeting
The next content Creation meeting will be in two weeks, on Thursday, March 9th, at 13:00 SLT.
There was no deployment to the Main (SLS) channel on Tuesday, February 21st, again leaving it on release 17#17.01.27.323172. However, all regions on the channel were restarted in keeping with the Lab’s policy of restarting a channel every other week, regardless as to whether or not it has received a deployment update.
On Wednesday, February 22nd, all thee RC channels should receive a new server maintenance package. The release notes had not be published at the time of going to press, however the changes are said to be “minor”.
SL Viewer
There are currently no changes to the SL viewer pipelines from the Lab, with the currently available viewer remaining thus:
Current Release version: 5.0.1.323027, dated January 25, promoted February 3 – formerly the Maintenance RC viewer.
RC viewers:
Maintenance RC viewer version 5.0.2.323567 dated February 14th – a range of improvements and features – overview here (initial release version number)
Love Me Render RC viewer version Version 5.0.2.323361, dated February 9th – rendering pipeline fixes and improvements
Project viewers:
Project Alex Ivy (LXIV), 64-bit project viewer version 5.1.0.501863 for Windows and Mac, dated January 10th
360-degree snapshot viewer, version 4.1.3.321712, dated November 23, 2016 – ability to take 360-degree panoramic images – hands-on review.
Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
The notes in this update are taken from the TPV Developer meeting held on Friday, February 17th, 2017. The video of that meeting is embedded at the end of this update. My thanks as always to North for recording and providing it.
SL Viewer
[00:28] The current official viewer pipelines are as follows:
Current Release version: 5.0.1.323027, dated January 25, promoted February 3 – formerly the Maintenance RC viewer.
RC viewers:
Maintenance RC viewer version 5.0.2.323567 dated February 14th – a range of improvements and features
Love Me Render RC viewer version Version 5.0.2.323361, dated February 9th – rendering pipeline fixes and improvements
Project viewers:
Project Alex Ivy (LXIV), 64-bit project viewer version 5.1.0.501863 for Windows and Mac, dated January 10th
360-degree snapshot viewer, version 4.1.3.321712, dated November 23, 2016 – ability to take 360-degree panoramic images – hands-on review.
Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
[00:38] The 64-bit viewer work is proceeding on three fronts:
A major update to process management and how viewer updates to users are handled (which includes the update mechanism recognising which version – 32-bit or 64-bit – should actually be installed on a PC for Windows)
Adding 64-bit Havok support for the Mac OS X build, and building the OS X build using Xcode 8
A new structure for handling Chrome Embedded Framework (CEF) and VLC for media support. This will bring all platform versions of the viewer up to the same VLC version and remove QuickTime support from the OS X build (although some QuickTime media may still play, depending on how VLC picks them up, but the Lab is not explicitly supporting QuickTime).
The next update to the Alex Ivy project viewer will depend on which of these update paths clears QA first, and whether any jointly clear QA close enough to be merged into a single update.
[02:29] Updates to the 360-snapshot viewer remain on hold pending the completion of the 64-bit viewer CEF work.
HTTP Asset Fetching
[03:09] As noted in my Content Creation User Group update, the Lab is commencing work in moving more assets for delivery via HTTP / the Content Delivery Network(s) or CDNs.
This work builds on the undertaken in 2013/14 to move avatar appearance information and texture and mesh assets delivery away from UDP and through the simulator, to faster, more reliable delivery via HTTP / CDNs, and will encompass the following assets: landmarks, gestures, animations, sounds and wearables (system layer clothing).
Vir Linden is leading the work, which should hopefully eventually remove more of the “non-simulation” message handling for assets away from the simulators to more reliable and faster HTTP delivery. This in turn should result in something of a performance boost in simulator performance, particularly for busy regions. Once the work has been completed, it will mean that the UDP message support for these types of asset transfers will be removed from both the simulator and the viewer code.
Voice Updates
[11:55] The next batch of Voice updates is being tested, and there is a problem with position updates not working correctly so that unless you are facing east, voices do not seem to come from the correct direction. Once this particular issue has been fixed, it is anticipated the updates will appear in at least a project viewer, although this may still be a while.
Music Streaming Default Volume
[13:15] The first TPVD meeting for 2017 included a discussion on audio streaming autoplay found in the official viewer, and the problems this can cause new users. As a result of that discussion, the Lab agreed to revisit the default media volume setting in the viewer, but a change has yet to be made.
Region / Estate Ban List
The Estate / region ban list (highlighted)
[15:38 – 19:42] Currently, the region / estate ban list is confined to a small area within a tab on the estate tools, sharing the space with 3 other lists. It is also non searchable, and when a region – for whatever reason – has a very long ban list, trying to clear the list down based on names / offensives can prove difficult due to the amount of scrolling required to locate, highlight and remove names deemed to no longer be a problem.
The Lab is sympathetic to the issue, and has suggested that rather and a JIRA being filed requesting changes to the current ban list display, a broader discussion is opened between the Lab and TPVs on how best to present the region / estate ban list, etc (e.g. whether they should have their own floater panel / tab within the viewer, with search capabilities, etc). The likely forum for this will be Oz Linden’s Open Source meeting, which takes place on Wednesdays, 07:00 SLT.
E-mail Verification
[23:45] On January 28th, I blogged about verifying e-mail addresses associated with Second Life. The Lab is now working on a number of projects which will require users to have verified e-mail addresses in order to receive information.
Remember: just because you are currently receiving e-mails from Linden Lab does not necessarily mean your e-mail account is verified. You must go through the verification process via your dashboard. Failure to verify your e-mail could eventually result in things like off-line IMs to e-mail failing, merchant notifications failing, etc., and the Lab switches services over to only sending to verified addresses. You many not even be able to request an account password reset if your e-mail address is not verified.
Therefore, if you haven’t already done so, please refer to the blog post linked above, and verify the e-mail address you use with Second Life.
Other Items
Script State Breakage in No-Mod Items
[08:49] A rare, but potentially nasty bug has surface which can result in permanently breakage of scripts in No Mod (/No Copy) objects – see BUG-41379.
Essentially, if an avatar is force teleported home (e.g. as a result of encountering an in-world security system), and their home location is unavailable that the time of their teleport (e.g. it is being restarted or off-line), they will be logged out. On re-logging, scripts in attachments are no longer functional, as they’ve been set to not running.
If the attachments have modify permissions, the scripts can be reset / set back to running. However, with No Mod items, the scripts are permanently broken. Providing the item is Copy, and the original is still in inventory, then it should be possible to “fix” the problem by using a new copy of the item. However, if the item in No Copy as well as No Mod, then it is effectively broken.
The Lab has accepted the bug and will be investigating.
Lab Holiday
[14:46] Note that Monday, February 20th is a holiday at Linden Lab (Presidents Day in the USA). Operations and support will be running as usual.
The Content Creation User Group has re-formed out of the Bento User Group, and is held at the Hippotropolis Camp Fire Circle. Imp costumes entirely optional 😀 .
The following notes are taken from the Content Creation User Group meeting, held on Thursday February 16th, 2017 at 1:00pm SLT at the the Hippotropolis Campfire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.
Core Topics
HTTP asset fetching
Potential project: animated objects
HTTP Asset Fetching
In 2013 / 2014, the Lab made a huge change to how avatar appearance information and texture and mesh assets are delivered to users, shifting them away from UDP (User Datagram Protocol) delivery through the simulators, to HTTP via Content Delivery Networks (CDNs) – see my past reports on the HTTP updates. and CDN work.
As was indicated at several TPV Developer meetings recently (see here for an example), the Lab has been looking to move more asset types for delivery over the CDN, and this work has now started, with a focus on animations and sounds. This should see improvements in both the speed and reliability of assets, which should be particularly beneficial to animations.
The work is in the early stages, and progress will be tracked through my SL project updates.
Potential Project: Animated Objects
A topic of common conversation at various user group meetings is that of animated objects – e.g. objects which can be animated but which are not necessarily part of the base avatar mesh, and / or things like non-player characters (NPCs).
Decent NPC a possible future project? Lab wants feedback on use-cases for animation objects
While it is still very speculative, the Lab is considering how this might be done and what sort of applications people would use such a capability for. One idea has already been extensively documented – “created agents”, which are avatars which do not necessarily have a connection to a viewer in order to operate – see feature request BUG-11368.
The main aim would be to use the same base avatar skeleton for this work, as well as it being compatible with existing rigged objects, rather than introducing something like custom skeletons (seen as a much bigger project). A lot would also depend up things like performance impact (if the simulator is operating a certain volume of NPCs or ridable objects, for example, then these could impact on resources which might otherwise be used by avatars, etc).
One potential way of achieving desired results would be to animate rigged meshes using the avatar skeleton, but without necessarily having the actual avatar base mesh underpinning it. For example, when we use a mesh body for our avatars, we use the base avatar, but hide it with an alpha mask, with the avatar skeleton animating the worn mesh. With an animated object utilising the skeleton, there is no real need to have the underpinning base avatar, as it would in theory never be seen.
One issue is that many mesh models are multiple parts, therefore some means would be required to control them, and this could be lost without the base avatar, together with the ability to attach static objects to something like an NPC. Hence the idea put forward in BUG-11368; the “created agent” would effectively be a special object class, providing the means for multiple animated meshes to operate in concert.
It is unlikely that the bone limit for a given object would be raised to accommodate animated objects, as this is pretty much a limit imposed by people’s graphics cards. During testing, the Lab found that if too many joints are defined for a single object, some graphics cards are unable to render the object correctly. This impact has actually already been seen with some Bento content (FIRE-20763).
Other aspects which would have to be considered are things like Land Impact. Avatars don’t have a land impact, but that may have to change in the case of animated, avatar-like objects – again, seen the performance concerns above. There are also some concerns over possible griefing vectors.
Performance-wise a potential benefit would be animated objects would not require alpha swapping, which requires a fairly hefty performance hit – but this could be countered to a degree (and depending on where you are and how animated objects are used) but the volume of animated objects around you.
Right now the idea is still being discussed internally at the Lab – there is no defined project. However, if you have views on things, attending the Content Creation meetings would be a good place to get them heard.
Other Items
Applying Baked Textures to Mesh Avatars
Still under consideration is a project to allow baked textures to be applied directly to mesh avatars (see here for more). This is still under consideration, but has yet to be formally adopted by the Lab as a project.
Modelling for Efficient Rendering
The subject of efficiency and LODs was the focus of an extended conversation. As I reported in my last Content Creation UG meeting report, Medhue Simoni has been producing a series on the use of Level of Detail (LOD) to help with generating rendering efficient models in Second Life. All three parts of the series are now available on his YouTube channel, and he and I will be discussing them in this blog in the very near future.
In short, there are no deployments scheduled for this week. The Main (SLS) channel will remain on release 17#17.01.27.323172.
While there had been an RC release planned, it apparently didn’t clear QA in time, so all three RC channels will remain on 17#17.01.27.323172 as well. However, all three channels will be restarted on Wednesday, February 15th, in keeping with the Lab’s policy or restarting channels every two weeks, whether or not there is an associated deployment.
SL Viewer
The Maintenance RC viewer updated to version 5.0.2.323567 on Tuesday, February 14th. As reviewed in this blog, this viewer includes a number of updates and new features, including the ability to select your own preferred folders for uploading image, animations, sounds and mesh models.
Outside of this update, the viewer pipelines remain as per the end of week #6:
Current Release version: 5.0.1.323027, dated January 25, promoted February 3 – formerly the Maintenance RC viewer.
RC viewers:
Love Me Render RC viewer version Version 5.0.2.323361, dated February 9th – rendering pipeline fixes and improvements
Project viewers:
Project Alex Ivy (LXIV), 64-bit project viewer, version 5.1.0.501863 for Windows and Mac, released on January 10
360-degree snapshot viewer updated to version 4.1.3.321712 on November 23, 2016 – ability to take 360-degree panoramic images – hands-on review.
Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Nvidia Driver 64-bit Viewer “Blue World” Bug
As I reported in week #4, Nvidia’s release of their 378.49 driver on January 24th resulted in many 64-bit viewer users (TPVs and the Lab’s own Alex Ivy 64-bit project viewer) seeing their Second Life world view turn decidedly blue when running with Advanced Lighting Model (ALM) disabled.
The Nvidia 378.66 driver should fix the “blue world” issue for those using 64-bit viewers with ALM disabled
On February 14th, Nvidia release the 378.66 driver package, and this reportedly fixes the SL issues.