2020 Content Creation User Group week #25 summary

Thermae, May 2020 – blog post

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

SL Viewer

  • It had been planned that the next viewer to be promoted to de facto release status would be the Love Me Render (LMR) RC viewer. However:
    • LMR is being held over pending the inclusion of various EEP bug fixes, including a fix for the HUD issues (see BUG-225784) and a fix for the specularity problems (see BUG-228781 and BUG-228581).
    • This means the next viewer that will likely be promoted will be the CEF RC viewer, and this could be promoted in week #26 (commencing Monday, June 22nd).

Viewer Caching

  • Work is continuing to try to improve viewer caching.
  • First outcome of this work is liable to be a viewer that has improved VFS caching (the system used to cache information on in-world objects). This will be a complete replacement of the VFS cache with a new format that retains data better and is more performant.
  • The next element of work after the VFS update is liable to be an overhaul of the viewer’s texture caching.


Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering either in the viewer. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

As of January 2020 ARCTan has effectively been split:

  • Viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity.
  • Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
  • The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.

Current Status

  • Vir now trying to roll the jelly doll updates into the rendering cost calculations and performance measurements.
  • One thing the core work on ARCTan has been awaiting is a fix to the Bake Service for errors arising when calculating height offsets with complex mesh items, which can result in the avatar bake failing. The fix for this is in place, and the updated Bake Service should be exposed to a simulator RC for testing “fairly soon”. The change itself should have no visible impact other than to correct the rare instances where the issue occurred.

In brief

  • There have been reports of avatar bakes taking longer to complete recently.However, it is not clear if this is an actual issue; LL have not noted any Bake Service processing issues, and also note that users may be noting a perceived “slowing” due to changes made a while ago to try to prevent avatars de-clouding fully nude (e.g. due to latency between the viewer and the CDN, or local caching issues, etc.).
  • In terms of avatar rezzing, there is also work being put into reducing the instances of rigged mesh elements rezzing offset / incorrectly sized related to an avatar (e.g. clothing appearing off to one side and rotated to be on its side; gigantic heads rezzing, etc.).
  • Next meeting: Thursday, July 2nd, 13:00 SLT.

2 thoughts on “2020 Content Creation User Group week #25 summary

  1. It seems pretty obvious that the SL17B landscape was designed and built by people using EEP-capable viewers. The specularity bugs you list above have a clear effect. Run an EEP viewer, and the landscape is at the general brightness of the mainland. Run Firestorm, and the result is rather gloomy. You can pick a brighter Windlight, get SL17B looking tolerable, return to the mainland, and get results that a photographer would class as obvious over-exposure.

    Yes, I have checked my monitor settings.

    At the moment, it also seems that the EEP package is implemented around the assumption that every parcel has its own EEP settings set. That seems to be what the viewer defaults expect, and the results in the current reality of the Grid are unfortunate. At the moment, I haven’t been able to reliably set a personal default which is maintained through a log-in. I expect I am missing something so obvious that the Lindens saw no need to explain it.


    1. “Run an EEP viewer, and the landscape is at the general brightness of the mainland. Run Firestorm, and the result is rather gloomy. ”

      I’d venture to suggest that this isn’t so much because the EEP regions have been designed with EEP in mind (although some of the core regions – e.g. those for the Auditorium – specifically leverage EEP custom settings that can be seen with EEP-capable viewers), but rather part of the general issue of EEP being grid-wide server-side, and non-EEP viewers being unable to consistently render environment settings as a result. As a grid-wide traveller (mostly) running non-EEP Firestorm, I frequently encounter the issue you describe (everything appearing “gloomy” on a return home) after visiting any region using custom environment settings, EEP or otherwise. Hopefully, things will settle down once all TPVs have an EEP-capable viewer on release to all users.

      As to expected defaults and as far as I’m aware, EEP-capable viewers “expect” a “default” environment setting to be applied simulator-side in a similar manner as we’ve had with Windlight. However, the ability to apply environments at the parcel level could well result in the viewer having to deal with multiple different environment settings – such as when flying over a region where multiple parcel-level settings have been used. But again, this can be countered by the fact EEP allows “personal” settings to be applied to an avatar, which could ensure a far more consistent view of the world when travelling (and obviously includes the option to swap to region / parcel settings when required).


Comments are closed.