Category: SL User Group Meetings

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.

 

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, September 17th 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.

EEP Fixes

There is now only one major EEP issue out of the current batch that has been undergoing work that remains unresolved, and it is being worked on. This means the current Love Me Render (LMR) RC viewer (version 6.4.8.547427 at the time of writing) is close to being ready for update and promotion – although it is likely the current Bormotukha Maintenance RC viewer (version 6.4.8.548394) will be the next viewer to be promoted to de facto release status.

Project Jelly  – Jelly Dolls Improvements

• Vir’s work in updating Jelly Dolls is now available in the Project Jelly viewer, version 6.4.8.547487 at the time of writing).
• A number of bug reports have been filed on this, and fixes are currently with QA, so the hope is the project viewer will be updated “fairly soon”.

Mesh Uploader

• It is likely the Mesh Uploader RC, version 6.4.8.548061 at the time of writing) will move towards release more-or-less as it is now, rather than being held over for significant updates.
• There have been concerns over the design of the new tabs within the updated uploader and how discoverable some of the added controls really are.  However, the consensus opinion at the lab is to leave things as is, and if there prove to be significant UI issues with the updated uploader, to deal with them in a future update.
• Things like the ability to specify pivot points within a mesh (e.g. for hinging doors, etc., rather than having the pivot point aligned through the centre of the object), requires simulator-side support, and so this won’t be dealt with until after the cloud uplift work has been completed.
• So, as it stands, it is felt the Mesh Uploader RC is also in line for possible promotion alongside the Maintenance RC.

Bakes On Mesh

While Bakes of Mesh has seen the introduction of BoM clothing to a degree, the take-up has perhaps not been as widespread as might be the case, with some body / head makers yet to fully embrace it.  Two of the most commonly-cited reasons for this are:

• Lack of full specular / normal map support (something that would require a further large-scale overhaul of the avatar Bake Service, so not easy to implement at this point in time).
• The problem of established user behaviour and an unwillingness to change from that behaviour, It is claimed that people have become used to mesh bodies having multiple alpha cuts (which add to their complexity) and being able to “hide” specific parts of the body at will via a HUD-based, scripted system, and are unwilling to switch to the direct use of alphas, which need to be located and applied manually.
  • Some mesh clothing designers do actually provide a means to “auto hide” parts of a mesh body when their clothing is worn, but they appear to be in a minority of mesh clothing makers.

Cathy foil has been brainstorming how both of these issues might be resolved without the need to necessarily dramatically overhaul the Bake Service in the case of specular and normal maps, and so as to allow the easier application of alpha textures to mesh bodies that would enable more fluid “hiding” of body parts when wearing mesh items or BOM layers. Her solution is to both increase the number of alpha channels available for use with mesh bodies (which would not impact the Bake Service) and Linden Lab “borrowing” from RLV / RLVa to allow a HUD to be used to  apply clothing / alphas to a body directly from inventory, as she explains in the video below.

The alpha solution offered is perhaps not entirely ideal (what about alpha conflicts when mixing / matching clothing from different makers?), and it might be argued that – insofar as the use of the Outfits folder + the WEAR + ADD options for general folder use, that the wearing / applying alphas may not be as significant an issue as might seem to be the case – but again, this can depend on the user behaviour / the clothing itself and how it is worn.  Any “official” adopt of RLV capabilities, even if restricted to just your own avatar, would also seem to be questionable in terms of adoption by LL (if nothing else, the code would need to be contributed).

However, as there was little time at the meeting to go through the video thoroughly, this is a subject that is liable to be further discussed at future meetings – although for any work to proceed from it (or in relation to BOM in general), a feature request Jira will be required.

In Brief

• There was an extensive (and theoretical, at this point), discussion on mesh bounding boxes (e.g. allowing different sized bounding boxes – with certain constraints – per LOD). However, I’ll save further reporting on this until there is a feature request Jira to which I can refer readers (hopefully by the next CCUG).
• Vir asked a general question on whether people would like to seen the animation uploader receive and update pass, and if so, what they would specifically like to see.
  • Suggestions included:
    • Improvements to the preview panel for better tracking of offsets.
    • Running .ANIM files through the uploader (as long as this is not made compulsory, as some animators prefer not to use the uploader).
    • Suggestions focused more on being able to either edit uploaded animations or to use the uploader as a means of exporting your own animations to make change.
  • The conversation also encompassed animation priorities, and the ability to either change them or constrain them better. As priorities can be baked into a mesh, Vir suggested rather than a greater ability to edit and change priorities might be to have them set at runtime, rather than being an object attribute.
  • General feedback on animation improvements included the ability to made adjustments to animation speed on the fly, better pre-loading of animations in a sequence, etc.
  • Jiras on specific features / improvements have been requested to help determine what might need to be done, what the scope of work might be, etc., to help determine feasibility.
• Date of next meeting: Thursday, October 1st, unless otherwise indicated on the CCUG wiki page.