The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, July 15th, 2021. These meetings are chaired by Vir Linden, with dates available via the SL Public Calendar and the venue for the CCUG is the Hippotropolis camp fire.
The Fernet Maintenance RC updated to version 184.108.40.2061414 on Wednesday, July 14th. The rest of the available official viewers are as follows:
- Release viewer: Project UI RC viewer, version 220.127.116.110520, dated June 14, promoted June 23 – overviews: Lab issues Project UI viewer aimed at new users and The Project UI viewer: a look at the new user Guidebook.
- Project viewers:
- Legacy Profiles viewer, version 18.104.22.1680519, dated October 26.
- Copy / Paste viewer, version 22.214.171.1243365, dated December 9, 2019.
- Project Muscadine (Animesh follow-on) project viewer, version 126.96.36.1992999, dated November 22, 2019.
- 360 Snapshot project viewer, version 188.8.131.529111, dated July 16, 2019.
General Viewer Notes
The Fernet Maintenance RC should have been promoted, but an error in the merging process meant that it has only just been merged with the current release viewer, so a further RC version has been issued to soak for the next few days in preparation for promotion, possibly in week #29.
Summary: An attempt to re-evaluate both Avatar Rendering Costs and the cost of in-world scene rendering, with the current focus on avatar rendering cost / impact, and in-world scene rendering / LI to be tackled at some point in the future.
- Work is continuing on the new performance floater, which has seen some further redesign work.
- This work is currently separate to the work on revising that actual formulas used for calculating avatar complexity.
- It has been suggested on a number of occasions that it might be preferable to hold-off issuing any viewer with the new floater until the new avatar ARC calculations are available and used, to prevent people just ignoring the information as being “wrong”, even when the new calculations do come into use.
- There is a strong probability that without proper education, users will simply ignore the information anyway, but the objections to issuing the viewer ahead of the correct calculations being available has been acknowledged, so internal discussions are still in progress as to when the viewer might be released.
- Beq Janus is working on her own variant of avatar ARC calculations, which she has dubbed “TrueARC”, which currently simply overlays avatars with colours (green, yellow, red) to indicate their rendering load from low to heavy. This work is in its early stages, and Beq plans to keep LL updated on her work / findings.
- The Graphics team are working to integrate the Tracy debugger / system analyser for cross-platform graphics development. This will be used to look for performance “hot spots” in the rendering code.
- Callum Linden has now resumed work on the 360-degree snapshot viewer.
- Mainland EEP settings: since the release of EEP, multiple Mainland regions suffer from their default EEP settings being too dark. The fix for this has been awaiting the implementation of new tools on the back-end, which are now available. As a result, a simulator using updated environment settings for Mainland is currently on test, and will be deployed Soon™.
- BUG-230677 “llSetAgentEnvironment transition doesn’t work” – a fix for this should be in the next Love Me Render RC viewer (LMR-6).
- Following the EEP discussion at the Simulator User group (notes here), Vincent Nacon has raised his concerns / ideas in a set of Jiras:
- BUG-230973 “[EEP] Obscured option to reset Cloud Scroll to the default position” – bug awaiting review.
- BUG-230974 “[EEP] Increasement [sic] to max limit on Cloud Scale” – bug awaiting review.
- BUG-230975 “[EEP] Brightness Slider for the Sun” – this is currently awaiting the weekly Feature Request triage.
- It is possible the two bugs might be picked up for inclusion in an LMR viewer.
Mesh and LODs
Investigations have started into ways to improve mesh LOD model generation using the open-source Mesh Optimiser (originally used within Sansar). No ETA on potential visible output from this work at present.
This sparked a discussion on whether, and if introduced, auto-LODding should be enforced on existing content.
- The “pro” argument for this approach is that it would “rectify” content with poor / missing LOD models.
- The arguments against the idea include:
- Many content creators do properly craft their LOD models correctly – and any enforced “re-optimisation” of in-world content could see these LODs replaced by poorer automated LODs, causing understandable upset.
- Image matching (the suggested means of re-examining content) cannot contextualise content in terms of things like visibility (e.g. the interior of a vehicle might be intentionally entirely low-LOD, as it is designed to be seen from only a handful of metres away).
- While LL have AWS under them, the process of re-examining thousands and thousands of in-world assets would be processing-intensive and come with a cost. – so who pays?
- A counter suggestion would be to make any such re-optimisation opt-in: if a creator has content they’d like to pass through the system, they could opt to do so and then utilise the automatic LODs.
- LL have also been in internal discussions on where the 16-bit limit on mesh faces originated, with the view that allowing a higher number of polys into a face would a) make rendering easier, and improve object decimation (it would likely be replaced with some form of global limit). However it has yet to be determined if changing this would require changing the mesh asset format. As such, there are no current plans to implement a new mesh format – but doing so in the future has not been ruled out.
- A question was asked how any “dominance” between two worn rigged items that use position overrides for the same joint. Vir noted that there is no assigned dominance per se, other than via mesh ID (UUID), so it is something that cannot be directly controlled by assigning a priority or anything like that.
- The question was asked as to the difference, functionally, between a mesh and a sculpt. In short: a sculpt is a texture used as a cylindrical displacement map, whilst a mesh is a physical asset, which has had its ID “kludged” (Vir’s term) into the spot originally intended for sculpt IDs. If Vir recalls things correctly, whether the ID is for a Sculpt texture or a mesh is determined by the presence (or not) of an additional bit of information. Overall, information is to what an item is – prim, flexi, sculpt or mesh – is still held within the “prim” container.
In-Viewer Mesh Editing Tools
There is a view circulating that during his Meet the Lindens (MTL) session at SL18B, Patch Linden indicated that there are “plans to implement mesh editing capabilities inworld”. However, this is something of an incorrect extraction of what was actually said, based on Patch’s initial response to a question asked about content creation and scripting (“I think this is absolutely something we should tackle”). While he did start his reply using these words, Patch also added further context around them by:
- Broadening his reply in terms of the existing 3D tools in the viewer – how people have started with them before going on to model in mesh via Blender, Maya, Unity, etc., – and the more important need for LL to understand what incoming users need today by way of an updated toolset in order to engage in content creation.
- Noting that while Grumpity Linden might agree on this in principle, she would likely have very different idea on if / how / when any such work might be tackled, and so deferred to her on this aspect of any potential tool update.
As such, his comments shouldn’t really be seen as any form of statement that in-world mesh building tools is a project the Lab is about to embark on – and it certainly was not mentioned by Patch or Grumpity at their respective SL18B MTL sessions as being a part of the roadmap of work planned for the next 12-18 months.
The original question and Patch’s complete answer can be heard in the official video of his SL18B Meet the Lindens session, between 1:32:28 and 1:34:52.
Date of Next Meeting
In theory, Thursday, July 29th. However, Vir will apparently be out of the office then, so the meeting is dependent on someone deputising for him. If no-one does, then the next LL-attended CCUG should be on Thursday, August 5th.