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.
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 18.104.22.1687427 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 22.214.171.1248394) 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 126.96.36.1997487 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”.
- It is likely the Mesh Uploader RC, version 188.8.131.528061 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.
- 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.
- Suggestions included:
- Date of next meeting: Thursday, October 1st, unless otherwise indicated on the CCUG wiki page.