The following notes were taken from my audio recording of the Content Creation User Group (CCUG) meeting held on Thursday, February 20th 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.
Environment Enhancement Project
A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
- Final review of issues is due on Friday, February 28th. If the project passes this review, the EEP will be cleared for promotion to release status.
- There is a viewer build that the Lab has internally that is liable to be the release version; it’s not clear if this viewer will go to RC prior to promotion or be issued as the de facto release viewer .
- It has again been noted that EEP will not give a precise one-to-one rendering of absolutely every environment (sky, lighting, etc.) in SL when compared to Windlight, as EEP uses a completely different and updated set of shaders, but it is hoped that most will be “very close”.
- Once EEP has has reached release status, it is anticipated that their will be a “fairly rapid” cycle of viewer promotions to clear the remaining RC viewers in the pipelines (i.e. one new promotion every other week).
An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. 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:
- Immediate 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. This work can essentially be broken down as:
- Collect data.
- Update ARC function.
- Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
- 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.
- Vir believes he has a fix for the appearance / Bake Service issue that has been causing problems with ARCTan testing. This has yet to be QA tested. Should it pass, then it will mean internal testing can resume.
- UI tools: one of the issues with the current ARC capability is how the information is presented and how it is interpreted. The question was therefore asked (by Vir) about possible ARC-related tools that could be incorporated into the viewer.
- There are tools already in the viewer (Max Complexity Setting, Always Render Friends, etc.), although how well these are used is open to debate.
- A concern with added further tools is that they could just additionally confuse for users (“more options and sliders!”) or just be ignored.
- Automated / semi automated means of adjusting complexity settings was favoured by some at the meeting.
- The problem with full automation could be difficult to implement due to the broad variance in hardware used to access SL, the complexity of existing content (avatar heads, bodies, etc.), plus people’s personal preferences, etc.
- A mechanism for adjusting / bypassing an automated process could be provided, but then it defeats trying to automate as people will just opt to bypass a the process and ramp up settings.
- An alternative might be to make the current tools more intuitive / easier to access and also more granular, then gradually move towards greater automation (with overrides) as people gain more familiarity with the whole issue of optimised content and performance.
- A suggestion from the Lab was to have some form of “temporary” thresholds: such as when teleporting into a busy region switches to some form of frame-rate threshold / asset load prioritisation that helps to maintain a reasonable frame rate whilst also prioritising CPU cycle use to speed up the initial loading period, then switching back up when done. The complication with this approach is, not everyone has the same bottleneck areas, so a threshold setting that works well for some, might not show any benefit for others.
- Bound up with this is the question of educating users as to:
- What tools are available and how they work (e.g. a capability one of those at the meeting was espousing as something that would be “nice” to see in the viewer, has in fact been a part of it for almost five years).
- What actually is impacting their experience with SL (it is so easy to blame “the servers” and “LL” when actually many of the problems are in fact viewer-side and could be better managed by a user than might otherwise be the case).