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.
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:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
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.”
Grumpity and Alexa 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 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.
However Animated objects will not (initially):
Have an avatar shape associated with them
Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
Use the avatar baking service
Will not support its own attachments in the initial release.
These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).
[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.
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:
Nalewka Maintenance viewer version 5.0.10.330123, December 21st.
Wolfpack viewer, version 5.0.10.330113, December 20th.
Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11th.
Voice RC viewer, version 5.0.10.330039, December 12th.
Project viewers:
Project Render Viewer version 5.1.0.511446, December 18th.
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:
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.
Each week through the year, I try to get to as many in-world and other meetings held by the Lab to keep an eye on technical developments and updates which are in the works for the viewer and the simulator, relaying the notable items via my SL project updates. As such, I thought it might be interesting to look back at some of the technical changes and updates have come our way in 2017.
Visible Projects
The year started with everyone still getting their heads around 2016’s Project Bento, which reached release status at the end of that year, bringing with it a much extended avatar skeleton with masses of new bones allowing a range of new animations and opportunities for more diverse avatar looks that used bone animations rather than resource-heavy options such as alpha flipping and so on.
Thus, 2017 – or at least the early part of it at least – saw many Bento releases hitting Second Life, from animal avatars through to Bento-enabled avatar mesh heads and hands which offer a greater range of expressions and natural motions, natural jaw and mouth movements to go with Voice or with text chat, and so on. Given the interest in Bento, I offered a behind-the-scenes look at the project from a personal perspective, having been an observer of the work from the initial closed development work all the way through the open beta to release.
I eventually made the move to a Bento head in September 2017, after extensive fiddling with demos from all the major makers, with (r) Lelutka proving to be the best in terms of maintaining much of my “original” (aka “2010 onwards”) look (l), as I played with the demo model & test skin)
The Bento project gave rise to several potential follow-on projects, of which the three most popular among creators at the Bento / Content Creation meetings were: supplemental animations, to allow smooth interaction between animations as a result of conflicts arising between the extended bone groups (currently on hold), animated mesh – eventually renamed “Animesh”, and bakes on mesh – with the latter two becoming a particular focus of the in-world Content Creation User Group meetings, together with the Environment Enhancement Project (EEP).
Animesh is 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. It can be used with 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. During 2017, the focus has been on getting a basic Animesh capability working in Second Life, which by the end of the years saw a project viewer at an advanced stage of development. 2018 should see this move to RC status, and the project as a whole move to release. A potential follow-on project may then see the capability extended to allow more in the way of NPC creation through Animesh.
Animesh allows you to take rigged mesh objects, add animations and controlling scripts to them, associate them with an avatar skeleton, and have them run in-world without the need for any supervising viewer / client
Bakes on Mesh extends 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 (but does not include normal or specular support). Once this initial work has been completed, an intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
Environment Enhancement Project is a set of updates to Windlight settings, etc. These include 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.
While 2017 didn’t see the deployment of many high-profile user-facing projects, it did see a considerable amount of back-end work take place, not all of which was necessarily user-visible, and some of which also affected the viewer. In summary this work included:
A complete overhaul of the simulator code build process, including upgrading the Linux OS for the simulator servers – the first of such rounds of OS update.
Moving most of the remaining SL asset (inventory items) handling from UDP messaging through the simulators to HTTP delivery via the CDN.
Changing how multiple, repeat teleport requests made via scripted HUDs were handled to reduce the impact such requests have on region performance.
The start of a project to revise the complexity calculations (in-world objects and Avatar Rendering Complexity) to make them more accurate / stable and reflective of the true cost of rendering items – this work is still ongoing.
Continuing work to eliminate exploits use to crash regions and to make the simulator code generally more robust, trying to curb illicit content copying, etc.
The Viewer
Much of 2017’s focus on the viewer was directed at moving it to 64-bit for Windows (whilst also maintaining a 32-bit version as well) and for Mac OS X. Started in 2016, with a significant overhaul of the viewer build process and its associated libraries, the first project viewer release for the 64-bit viewer – code-named Alex Ivy (aLeX IVy = LXIV = 64) – arrived in early January, with work continuing throughout the year to refine the viewer, work out issues in the build process, and move the project towards release status – which should now happen in early 2018.
The 360-snapshot viewer received an overdue update which, while suffering from pro resolution issues, did streamline the production of 360-images. This was the only update to the viewer in 2017, leaving it as project viewer status. More work will be forthcoming in 2018.
The revised snapshot floater in the July 2017 360-snapshot project viewer
The Lab also restated their desire to continue with Linux, by offering a Debian build of the viewer – but only with the help ogf the Linux community.
Other updates for the viewer in 2017 included custom folders for uploads, the launch of a new release candidate branch of the viewer specifically to manage fixes and updates to the viewer’s rendering pipe, the first pass at improving region / estate ban lists for estate owners, the viewer’s avatar rendering options (right-click context menu and Preferences > Graphics) were improved to allow users to better define how avatars around them are defined. New region / parcel access controls were introduced and a WORN tab was (finally) added to the inventory floater. There was also the ongoing series of Maintenance RC releases throughout the year, aimed specifically at fixing bugs and issues, which in 2017 gained their own code-name series, each one being named for an alcoholic beverage.
Other Updates and Changes
A new Second Life Community Platform officially launched on Tuesday, March 14th, 2017. You can read my overview of the platform here.
Places Pages officially launched after a beta run, and continued to be refined.
You can follow my updates on SL technical developments and updates through the likes of my weekly SL project updates and weekly viewer release summaries (which also cover TPV releases).
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, December 21st, 2017 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. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. 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.
However Animated objects will not (initially):
Have an avatar shape associated with them
Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
Use the avatar baking service
Will not support its own attachments in the initial release.
These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).
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. This had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.
Animesh Release ETA and Limits
There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:
It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.
The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.
Animesh Use Cases
The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.
Skeleton Use and Bone Naming Convention / Parenting
An extensive discussion on using the skeleton bones.
[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).
As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).
This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).
Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.
“Dropping” Animesh / Mesh
[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require an extensive simulator-side overhaul.
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 mesh surfaces. 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
Viewer work has paused while some back-end baking service issues are resolved.
Other Items
How the Lab looks at Features
One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.
Mesh Uploader
[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.
[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.
Bone Offsets
[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.
SL Viewer
The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.
These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
Inara Pey: Living in a Modemworld 