Category: SL User Group Meetings

November 2017: Web User Group, SL viewer

Posted on by Inara Pey
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, November 10th, 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.

Marketplace Related

Marketplace Search

  • Search can be too broad (even with the boolean functions). for example, attempting to search by store name can bring up avatar names, many of whom do not have an active store. Addition of more refined filtering mechanisms (check boxes?) could help eliminate some of these problems. This was noted at “useful feedback”.
  • Boolean search, whilst useful, can also be limited in impact when trying to eliminate things like demos from results, although this seems to be down to the creative use of demo item descriptions to foil the use of booleans like “XXX NOT demo”, and is thus harder to overcome.

Marketplace Listings

  • Default order for listings on the Manage Listing page is date ascending (oldest to newest).  It would make more sense – particularly when creating new listings – to have the default as date descending (newest to oldest), so that the newest listings – and the ones most likely to need editing – appear at the top  / on the first page of a listing – or have the merchants preferred listing order saved. This has been a JIRA issue since 2014 – see BUG-4705. It’s now regarded as something that “should be” fixable, and has been added to internal tracking by Alexa.
  • Grouping Colour variants for items has often been requested – for example, see BUG-6424 and feature request BUG-10853. This is seen as a much harder capability to add to the MP.

Marketplace Gifting

  • Some people apparently get confused over the gifting work flow: this should be: find the item > click Add to Cart as a Gift > enter recipient’s name & a message > click Finished > go to the shopping cart icon (top right of the window) to purchase / send. However, after entering the recipient’s information, some people at clicking on the Buy Now button in error, thus purchasing the item for themselves. See also WEB-3020 and feature request WEB-3531.
  • Gifting requires recipient’s full user account name not Display Name – as the latter can default to sending a gifted item to a recipient with an account name matching the display name. Note that “Resident” should be automatically appended to any single name account entered.

Marketplace Clean-up

Another long-standing request in for some form of Marketplace clean-up. For example, there are good for say that may contravene more recent SL policy changes; there are goods for sale and unsupported because the creators have long since left Second Life; there are goods listed on the marketplace that have not sold in years, and the creators (if still active have not removed), and so on.

The problem here is how should any removal be policed? Even if a creator has departed SL, it doesn’t mean their goods are no longer being purchased? How should a time limit for force removal of non-selling goods be enforced? One year without a sale? Two? Three? More?

Clean-up is something the Lab has been struggling with and considering different approaches. There may also be possible alternatives to removal – such as more refined weightings on search capabilities, or the ability to see when an item was last updated. At the moment, Alexa and Grumpity are on a feedback mission concerning this issue, so except this subject to droll forward in future meetings.

Listing fees: once suggestion for handling the proliferation of various listing types was for listing fees to be added, potentially tied to a benefit for Premium members. This understandably caused heated debate (particularly given the January 3rd 2018 increase in fees for processing credit transactions) – with creators at the meeting divided on the matter. However, it’s important to note this was just a suggestion; it is not something the Lab is planning on introducing.

Second Life Maps

Two specific requests were made:

  • Update the map generation to properly display mesh in map tiles.
  • Fix region surrounds causing a region’s map tile to be displayed as a blank green tile.

Commenting collectively on these, Grumpity Linden said:

Maps… yeah, we’d like to do that and have several ideas for how, but none of them are easy fixes. Map tile generation is different from displaying them… and none of the ideas for fixing the generation are easy or fast.

A Note on JIRA Acceptance

This routinely comes up at Content Creation meetings and came up at the Web meeting, so is worth repeating.

Following initial triage by Linden Lab (roughly daily for bug reports, usually weekly for feature requests), the status of a JIRA may be updated to “Accepted”. However, this does not mean it will be actioned in the near future.

Depending on the nature of the JIRA, “Accepted” may result in it being prioritised and actioned in the short-term; however it may also mean it has been imported and tracked by the Lab, but held for action pending the clearance of more urgent items / ideas that necessarily need to be actioned ahead of it or it may be tracked until such time as it (or something like it) fits into a tranche of work / updates the Lab is planning to implement.

SL Viewer Updates

The SL viewer is not specifically discussed at the Web User Group, however, in keeping with my summary of recent viewer updates which generally forms a part of my SL project updates, here’s an end-of-week summary of changes.

  • The current Maintenance RC viewer updated to version 5.0.9.329795 on Wednesday, November 8th.
  • The Animesh project viewer updated to version 5.0.9.329815 on Thursday, November 9th – see here for more.

Otherwise, the SL viewer release pipelines remain as:

  • Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
  • Release channel cohort:
    • Alex Ivy 64-bit viewer, version 5.1.0.510354, November 2 (still dated Sept 5 on the wiki page).
    • Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
  • Project viewers:
  • 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.

SL project updates 45/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, November 9th, 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. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

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

Resources

Viewer Progress

[3:51-5:33] The project viewer updated to version 5.0.9.329815 on Thursday, November 9th.

  • The major change is that Animesh linksets can now include non-rigged items (e.g. prims), and allow the root objects to be a prim rather than a rigged mesh.
  • Animesh objects should now render the same way as mesh attachments and generate shadows.
  • The viewer also includes a number of bug fixes.

[42:25-44:50 + text chat] However, while the root of an Animesh object can now be a prim, this doesn’t mean mesh objects such as pets can be dropped in-world (e.g. so someone could “pick up” their Animesh pet, carry it, then put it down again somewhere else), because the code required for “dropping” mesh is not provided on the simulator on the ground that dropping meshes can cause physics issues.

Animesh Attachments

Note: there is an extensive discussion in text chat around this subject from the 13:00 minute mark which continues throughout the meeting.

[12:59-18:06] One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects (see here and here). In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add  / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets  / characters Modify opens them to the risk of exploitation.

One proposal has been put forward via feature request BUG-139168. Vir Linden has also put forward a number of ideas. Of these, the mod key proposal (2nd bullet point in Vir’s notes and somewhat aligned to BUG-139168) is seen as a potential solution, with LlAllowInventoryDrop used to avoid the need for the root Animesh object having to be modify (and leaving it exposed to the exploits outlined by Piscine and Medhue). Vir is currently seeking further feedback from people on this being a possible approach, or if there are other potential alternatives.

  • [21:11-22:51] Two concerns on this approach are that a) any scripted mod key capability could be withdrawn at any time by the creator, potentially leaving users with broken content. However, there is no obvious means of safeguarding against this (unless it is made some kind of one-time function operation by the Lab, if possible); b) there is a risk the mod key could be accidentally exposed / leaked in being shared between those using it.
  • [25:52-26:12] The most “obvious” means of handling this issue would be to implement a change to the permission system to cater for the specific user-case of allowing attachments to be added to Animesh objects. However, the Lab is hesitant to consider such changes due to the risk of unintended impact, risk of content breakage, etc. As such a precise proposal on how to update the permissions system and the use cases it would meet would have to be properly defined for consideration.
  • [28:15-30:40] A suggestion is made to have a new flag “only allow scripts compiled by the object creator run on this object”. However, this could limit cases where models are built by one person, animated by another and scripted by someone else, or situations where a creator is using full permission scripts sold by another creator, etc., and so seen as potentially less than ideal.
  • [56:07-1:01:56] Determining whether Animesh attachments capabilities (e.g. using the mod keys idea) can or cannot be implemented relatively easily is seen by the Lab as a critical aspect to moving Animesh towards a release. If doing so proves problematic, the project will likely move ahead without such a capability being implemented. In the meantime, as there isn’t currently an available solution, creators are advised to handle Animesh the same as any other product they are developing for the time being, and focus on Animesh at the functional level.
    • [1:01:57-1:05:05] An example of complexity is defining how a mod keys capability would work. If it is limited to one specific group of people creating a poduct line, it is relatively easy to control. However, if a creator wants too support an ecosystem whereby other creators can all offer attachments for a product, then it becomes far more complicated in terms of keeping the mod key secure.

Given the complexity of this subject, continued discussion through the Animesh forum thread is encouraged.

Animation Playback Speed

[51:47-52:37] It has been noted that the speed of the animation depends on the distance from the viewer’s camera to the animated object – see BUG-134259 and this MP4 (note particularly the two elephants). This appears to be the result of the debug UseAnimationTimeSteps being set to TRUE (default viewer behaviour). Setting it to FALSE fixes the issue, and doesn’t appear to cause any other performance impacts.

Land Impact and Other Limits

[54:53-56:05] It’s unlikely that the current baseline limits (LI, tri count, rendering), will be altered  until there is confidence that the viewer functionality is relatively stable in terms of features, bugs, etc., at which point reliable performance testing can begin. Once this point is reached, then the Lab will be able to gather reliable data in order to start adjusting / potentially relaxing the limits.

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

[8:25-10:32] Rider Linden is “very close” to removing the old windlight environment code from his EEP version of the viewer, allowing it to use all the new EEP assets, allowing the local environment to be set via windlight inventory assets.

Once this can be done, test regions capable of supporting the assets will be established on Aditi (the beta grid), and a project viewer will be made available for more general testing.

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

[35:41-36:33] The performance testing has been carried out, and the results point to the need for additional bake host servers to account for the additional load in handling the higher resolution textures.

Other Items – In Brief

  • [36:30-37:29] Region crossing loads: the question is asked about what is the biggest load / cause of lag on region crossings (direct or TP). The short answer is scripts. That is, suspending them, saving their state, packaging them, handing them off to the next simulator, unpacking them alongside everything else (e.g. the avatar and / or vehicle they are running against), setting them back to running from their saved state. Obviously, the more individual scripts an avatar (+ vehicle, where used) is running (regardless of individual script size), the bigger the load placed on the hand-off process / receiving region.
  • [47:03-47:19] Materials system update: this is frequently requested, but currently the Lab do not have any plans to revisit the materials system.
  • [49:32-49:45] Cannot pathfind through a hollow object – intentional? Short answer – yes; physics simulations going into concave objects is expensive
  • [49:45-50:18] Will RenderVolumeLOD be revisited? – Short answer – yes, as a part of the work in re-evaluating rendering costs, land impact, etc.

 

SL project updates 45/1: server, viewer

Posted on by Inara Pey

Sol Existence; Inara Pey, October 2017, on FlickrSol Existence – blog post

Server Deployments for Week #45

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

On Tuesday, November 7th, the planned Main (SLS) channel deployment was cancelled when the restart system overloaded while trying to restart a few thousand regions around the same time. Some reported that RC regions were also being restarted during the deployment attempt, which may have contributed to the problem – although this has yet to be confirmed as being the case by the Lab.

Once the cause of the problem has been diagnosed, the deployment will be re-tried, although Oz Linden indicated this may not be before the usual Tuesday deployment in week #46.

There is no planned deployment to the RC channels on Wednesday, November 8th, 2017.

SL Viewer

The Wolfpack RC viewer which was functionally identical to the release viewer, but included additional back-end logging, was withdrawn from the Alternate Viewers page at the start of week #45. Otherwise, the viewer pipelines remain as for the end of week #44:

  • Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Alex Ivy 64-bit viewer, version 5.1.0.510354, November 2 (still dated Sept 5 on the wiki page).
    • Maintenance RC viewer, version 5.0.9.329707 October 31.
    • Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
  • Project viewers:
  • 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.

New Premium Benefit

On Tuesday, November 7th, 2017, Linden Lab announced their new Premium benefit: a 90-day transaction history – read more here and here.

SL project updates 44/2: TPV Developer meeting

Posted on by Inara Pey
The updated official viewer splash screen for general users (i.e. not first-time log-in)

The following notes are taken from the TPV Developer meeting held on Friday, November 3rd 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

The Voice RC viewer has one remaining significant bug, which causes some of those on the Windows version of the viewer to connect to the wrong voice channel, which is preventing this viewer progressing further.

The 64-bit Alex Ivy RC viewer updated to version 5.1.0.510354 on November 2nd, 2017. Overall, this viewer is described as doing “really well”, although there are still crash issues with it. These are most noticeable with people on 32-bit Windows systems (those on 64-bit versions of Windows running the 64-bit version of the viewer are experiencing far fewer crashes).

The latest update should correct issues with the viewer’s updater, and it is likely more users will be added to the RC cohort usage pool before this viewer is promoted to release status.

Work is once again proceeding with the 360-snapshot viewer, with improvements to image quality and processing speed, and a new update should be appearing soon. The Lab is also working on a new means to upload 360 snapshots from the viewer to SL Place pages.

Inventory UDP Messaging

Work has started in deprecating all UDP inventory messaging. This is not progressing “super fast”, as it is being progressed alongside other work, and the projected end date is some time “fairly soon” after the end-of-year holidays, when back-end support for the UDP messaging will be turned off. This means that any active viewers still using the UDP inventory handling routes should be making the move to HTTP.

No Change Windows

With the end-of-year holiday season approaching, the Lab is looking at dates for no change windows – periods when they will not be making and simulator or viewer releases, and would prefer to see TPVs do the same.

The first of these periods will be the US Thanksgiving holiday period, when a no change period is liable to be enforced from Wednesday, November 22nd, with the all-clear on Monday, November 27th (subject to formal confirmation).  The Christmas no change window is still TBD, but will likely be from at least Friday, December 22nd through until shortly after the new year.

Other Items

Resource Usage tools

Chalice Yao has proposed a feature to the Firestorm team to allow users better understand the resources they are using, both through their avatar’s VRAM usage and the VRAM, triangles and vertices for any selected object (see FIRE-21793). As the Lab is currently working on amending how rendering cost calculations, a more detailed discussion on these ideas has been tabled for the next TPV Developer meeting, on Friday, November 17th.

Firestorm Release

The next Firestorm release has been delayed of late, but recently entered beta testing, with the aim of it appearing before the end of the year. When it arrives, I’ll have me usual overview of significant updates, but Beq Janus recently blogged about a couple of updates she has contributed to the release, and the Lab have indicated their own interest in possibly adopting the updates, if contributed.

Second Life Minimum System Requirements

It has been noted that the specified minimum system requirements for Second life may be out-of-date (see BUG-139301), and this may be exacerbated with the Alex Ivy viewer. It’s likely that the specifications will be looked at again.

SL project updates 44/1: server, viewer

Posted on by Inara Pey

Pandora Resort; Inara Pey, October 2017, on FlickrPandora Resort – blog post

Server Deployments for Week #44

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

  • There was no deployment or restart for the Main (SLS) channel on Tuesday, October 31st
  • leaving it on package #17.10.06.509394.
  • On Wednesday, November 1st, the RC channels should be updated with a new server maintenance package, #17.10.25.510119, comprising internal fixes – notes still to be posted at the time of writing.

SL Viewer

The current Maintenance RC viewer updated to version 5.0.9.329707 on Monday, October 30th. All other viewers in the current pipelines remain as per the end of week #43:

  • Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Wolfpack RC viewer,version 5.0.9.329478, dated October 20 – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
    • Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 5.
    • Voice RC viewer, version 5.0.8.329250, dated September 1.
  • Project viewers:
  • 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.

 

SL project updates 43/2: Content Creation User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi!

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

Audio extracts are provided to provide additional content. Note that some of the audio extracts have been gathered from various points in the meeting and presented here as a concatenated whole by subject heading for ease of reference.

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

General Status

  • The project viewer is now available, and testing can be carried out on  5 regions (4 Moderate + 1 Adult) on Aditi: Animesh1, Animesh2, Animesh3, Animesh4 and Animesh Adult.
  • Feedback can be offered through the Animesh forum thread, while specific issues, bugs, and / or feature requests related to the project should be made via JIRA.
  • A filter for raised JIRA reports is available.

Root Prim Object

There have been a number of requests to allow Animesh objects to have a non-rigged mesh (e.g. a prim) as the root object. Vir has been working to make this possible. He’s also looking at the issue of non-rigged mesh links in an Animesh object becoming invisible when the Animesh flag is set.

Limits

As has been mentioned numerous times in these updates, Animesh will have some constraints / limits placed upon it in the interests of the capability not unduly impacting performance. For the purposes of test, these have been set at 200LI and a maximum of 20K tri maximum per Animesh object, and only one Animesh can be attached to an avatar at a time. As data is gathered on performance, etc., it is hoped these can be relaxed; however, some creators are requesting limits such as the tri count be raised sooner rather than later. Vir, understandably, would rather wait until more data has been gathered, rather than randomly changing constraints.

There has been a proposal for an alternative method of account put forward with regards to Animesh – BUG-139203.  Vir also reiterated the likelihood that the Animesh limits, once finalised, will have a smaller emphasis on constants such as land impact or the cost of having one attached, and a greater emphasis on the complexity of the Animesh itself (tri count).

Linksets / Permissions Issues

See also Piscine Mackenzie’s forum post on this.

As currently defined, Animesh does not allow for any avatar-like attachment  / detachment of objects (e.g., allowing a pet cat to wear a hat sometimes); the approach is more along the lines that everything that is intended to form the Animesh is attached as the time to object (/linkset) is flagged as Animesh.

This is because adding an avatar-like means of supporting attaching / detaching objects was seen as too high an overhead in terms of development time frames and complexity – although it is not entirely ruled out as a possible future capability.

In the meantime, scripted means to attach / detach items from an Animesh object is possible, but this requires the base Animesh to be modifiable. As detailed in Piscine’s post, and highlighted in the following post from Medhue Simoni, this opens the door to potential exploits / threat vectors (e.g. compromising a supporting ecosystem for pets / breedables to the potential for launching DDOS attacks against the external servers managing pets and breedables).

Vir recognises the issue, and has stated he’ll look into the in more detail. One possible solution has been suggested via feature request BUG-139168, and a possible scripted workaround has also been suggested – although it potentially has its own problems.

An offshoot of this is that it could lead to people including multiple accessories within the Animesh linkset. The problems here being a) doing so would immediately require much higher tri counts per object even after the current 20K limit is raised; b) it will require alpha swapping to hide / reveal different accessories, creating performance hits; c) it will limit the ability for new accessories to be easily added to creations.

Sitting Animesh Objects

Will it be easy to have Animesh sit on other objects (e.g. to have Animesh “mannequins” which could be used with demos of furniture so couples poses could be checked by just one person, etc)? Short answer: not easily. Sitting on objects is avatar-specific, which, among other things, involves re-parenting the avatar to the object it is sitting on, and there is no means to replicate this when trying to “sit” an Animesh (which the server sees and just another in-world object) on another object.

In Brief

  • Lack of Shadows with Animesh objects: this is a know bug, thought to reside within the rendering pipeline, which has yet to be tracked down.
  • Dropping mesh: as noted in my previous CCUG update, by default, mesh attachments cannot be dropped in-world. This means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory. Vir has been looking at this, and it is not any easy fix, requiring server-side work (including with physics handling to ensure things land correctly – such as pet on its feet rather than on its side / head) which may preclude it being dealt within the immediate future.


Medhue examines Animesh. Via Medhue Simoni

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

Load testing with the updated server using 1024×1024 textures is in progress. The next phase is liable to be comparing the load test data with that of an existing baking server using 512×512 textures.

Bakes on Mesh and Animesh

Because of the complexities involved with Bakes on Mesh, it is not seen as a dependency for Animesh, as doing so would greatly extended the time frame for delivering Animesh. The Lab would rather implement both incrementally, rather than try to run everything into one huge project.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) 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

No major change from my previous work. Rider has been working on a simhost issue unrelated to EEP for much of the time.

Final Notes

  • Those requiring access to the JIRA to comment on files issues / request, can send an e-mail request to LetMeIn-at-LindenLab.com.
  • There is no CCUG meeting on Thursday, November 2nd, 2017. The next meeting will be Thursday, November 9th.