Day: October 2, 2020

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, October 1st 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are are available on the Content Creation User Group wiki page.

Content Creation Related SL Viewers

EEP Fixes

As noted in my viewer release summary for the week and my SUG meeting summary, the EEP fixes have been promoted to de facto release status with the issuing and promotion of the Love Me Render (LMR) #4 viewer (version 6.4.9.549455, at the time of writing).

Mesh Uploader

• As a result of the EEP fixes release, the Mesh Uploader was merged to the release code, with version 6.4.10.549686,  issued on Thursday, October 1st.
• If there are no significant problems with this version of the viewer, it is likely to be the next  viewer to be promoted to de facto release status. There is some debate as to whether this will occur in week #41, or if LL will hold off for a week in order to not make three back-to-back promotions in as many weeks.

Jelly Dolls Project Viewer

• The Jellydoll Project viewer also merged up to the current release code, with version 6.4.10.549690 issued on October 1st.

New Maintenance RC Viewer

• A new Maintenance RC viewer, coded named Cachaça, was issued on October 1st. Among other things, version 6.4.10.549752 includes several more EEP fixes and also some fixes for CEF.

Viewer UI Improvements

Steeltoe Linden, who handles most (/all) for the work around the viewer UI attended the meeting in what was billed as potentially the start of a semi-regular appearance in order to discuss viewer UI updates that the Lab is considering.

• For the first session, he raised what was referred to as a “trivial” change: offering a new inventory icon for HUDs.
• Instead of showing HUDs as an object cube, the idea is to show it as a distinct icon type – the example being a cog-like icon, in order to make HUDs more easily recognisable when scanning Inventory folders.
• This icon would also be visible in the Outfit and Received Items panels.

• The viewer would use the HUD attach point (stored with the object data)  to identify HUDs as such, and so display the icon.
• It was noted that this could (allowing for trying to remember all of the icon types) pave the way for items that attach directly to the avatar have a unique icon type.
• One suggestion at the meeting was to also add HUDs as a distinct option when filtering inventory, and Steeltoe indicated he has already ask one of the viewer engineers to look into this.
  • However, he noted that filtering works on object type, rather than attachment location, so it would require an additional layer of code for filters to distinguish attachments like HUDs from other objects.  This might make filtering for things like HUDs too computationally expensive.
• Overall, the response from those at the meeting was positive.

Proposed Bakes on Mesh Improvement: llWearFromInventoryTemp

• This is a proposal by Rider Linden that has been filed as a feature request – BUG-229423 to allow public comment / feedback.
• It is aimed primarily for Bakes on Mesh (BOM), but may have wider applications.
• The basic idea is defined within the feature request:

Mesh bodies used a system of alpha cuts to hide parts of the body that should be obscured by clothing. Alpha cuts were originally controlled through a HUD associated with the body. Clothing creators and body vendors then developed a system to automatically turn some of these alpha cuts on and off through a script in the clothing item.

BOM provides no similar mechanism. In order to hide parts of the body, the users must search through their inventory for an appropriate alpha layer and attach it or add it to the outfit manually.

This function will allow clothing creators to create BoM enabled clothing without forcing their consumers to search for the appropriate alpha layer.

• So essentially, it would be a scripted function clothing makers could use to ensures that when a clothing layer is utilised in BOM, the appropriate alpha is also applied, and similarly, when the item is no longer being worn, the alpha is automatically detached.
• Due to the way SL is configured, this would only apply to the Clothing object type (skin, hair, eyes, and shape would be excluded, as only one of each of these can be worn at any time, so trying to deal with what happens to these wearing / removing, if they were included in the system becomes complicated and potentially conflicting.
  • If you wear clothing that have a shape associated with it, the function could end up removing the clothing *and* the shape, leaving your avatar a cloud, for example.
• Currently, the idea is only under consideration – and if feasible, any work on it would not occur until after the cloud uplift work has been completed.
• This approach would also offer an alternative approach to part of the idea put forward by Cathy Foil at the last CCUG meeting, which would require LL to adopt elements of the RLV / RLVa code base.
• Precisely how the capability would be implemented is still to be determined; there is some antithesis to having a script directly access an agent’s inventory (as RLV / RLVa can do, using the #RLV folder), so the precise functionality might focus more on being driven by script within an attachment (such as a HUD)  or even added to the clothing layer itself (if I am understanding Rider correctly – although I don’t know how this would work in practice).
  • A  negative seen with the RLV / RLVa approach is that it dictates how items that it is to access are organised (through the #RLV folder tree), which in turn places constraints on the freedom users have to organise their inventory as they would prefer.
  • Further, given that people do organise their inventories differently to one another, having a  script that accesses inventory directly means that it must somehow be able to determine where and how within their individual inventories users have organised and placed  clothing layers and alphas.

Main Grid Regions in the Cloud

Publicly-accessible regions on the main grid (Agni) have been quietly appearing. As far as I know, these are predominantly Linden-owned regions – such as Hippotropolis, used for various in-work user group meetings (although I would suspect any private region holders who may have their regions running on AWS to be potentially subject to an NDA  or similar, in order to avoid LL being inundated with requests for regions to be uplifted).

Patch Linden also posted a forum update on a number of topics (the availability of Linden Stilt homes, the work in partnering with various organisations with in-world events, for example), which included a reiteration of the Lab’s view that the Uplift project is proceeding well, and the work should hopefully be completed by the end of the year.

Date of Next Meeting

• Thursday, October 15th, 2020.