Meeting Purpose
- The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
- Meeting dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
- The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.
Official Viewer Status
[Video: 1:28-2:19 and 3:43-4:32]
- Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
- Release Candidate: ExtraFPS RC, version 7.1.11.11565212741, October 30.
- Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain; additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
- Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
- UI Optimisations.
Near-Term Viewer Release Roadmap
- ExtraFPS work remains focused on bug fixes.
- The first maintenance RC to follow ExtraFPS will be a viewer bringing together the updates originally planned for the Maint B and Maint C viewers which were side-lined with the focus on viewer performance (Atlasaurus, DeltaFPS, ExtraFPS).
WebRTC Update
WebRTC communications protocol (RTC=”real-time communication”) is the new Voice communications protocol for Second Life, replacing Vivox Voice.
- Situation remains that Linden Lab are waiting for more users to switch to a WebRTC enabled viewer prior to switching over to using WebRTC only, and disabling Vivox.
- A core sticking point here appears to be Firestorm users remaining on a pre-PBR (Vivox-only) release of that viewer, and they are being strongly encouraged to try swapping to the latest Firestorm release (7.1.1) or if performance with that doesn’t suit them to temporarily consider moving to an alternate viewer to help LL with enabling WebRTC (which is a superior Voice option to Vivox) / avoid losing Voice altogether should it reach a point where the switch is thrown for WebRTC.
Graphics Team Work
Viewer Performance
- Core focus remains on performance work , and will remain so until “everyone is happily on PBR-enabled viewers”.
- Average viewer performance for most users is believed to be “pretty good” for PBR, but the Lab remains aware of the fact that their are cohorts of users who, due to hardware, etc., are “suffering some pretty significant performance loss”.
- “Hunting down” and trying to fix these issues is now the priority, but will take some time.
Pre-PBR / PBR A/B Testing
- LL is carrying out A/B testing with Firestorm 6.6.7 (pre PBR) and SL Viewer’s ExtraFPS (RC viewer at the time of writing) to try to better understand performance differences and which lower-end hardware is being particularly hit under PBR (e.g. lower-spec Intel systems (integrated graphics?), some AMD GPUs).
- In terms of Nvidia, Runitai believes performance on PBR viewers is “pretty close” to levels enjoyed pre-PBR, although there are still issues to be ironed out with some older GPUs / cards with low VRAM (such as those with only 2GB). Some of this is likely to be a case of “turning down” some internal settings in the viewer so it its friendlier towards lower-end GPUs with limited VRAM.
- One thing that has been identified is behaviour on launch / entering a scene (location):
- Pre-PBR viewers like Firestorm 6.6.7 tend to launch with high frame rates which then decreases as the scene loads and memory is used, before stabilising.
- PBR viewers tend to front-load textures, resulting in a low frame rate from the get-go, which improves as the scene loads the the viewer rationalises the textures it needs to display. This gives a false impression that performance is “bad” from the outset and only liable to get worse, potentially causing people to quit using a PBR viewer before they witness the increase in frame rates.
- Part of the work in testing involves automation: the Lab has established a “potato farm” of laptop with limited resources and which are used with SL in order to carry out automated tests to determine where performance issues might reside
Tone Mapping
- Originally slated as being a part of the viewer to follow ExtraFPS, the Khronos Neutral tone mapper, intended to improve overall ambient lighting in SL, making things somewhat brighter and more vibrant.
- Khronos Neutral was to have been the default, with the option to switch back to ACES via Preferences → Graphics. However, following feedback, the decision has been made to leave the default as ACES and make Khronos Neutral the option, together with the ability to disable Tone Mapping.
- Setting Tone Mapping will eventually be a Sky setting within EEP.
- The recommendation to content creators remains don’t bake the Tone Mapping into your textures, allow the post-processing the the viewer handle it – in other words, Tone Mapping belongs to the camera, not the object.
- The above rule also applies to thigs like lighting under PBR as well.
Auto-Exposure Work
- Geenz Linden is now working on both the Tone Mapper and on auto-exposure.
- Work has already been done within the auto-exposure process to make transitions “softer / easier on the eye”, and Geenz is now extending this work to make it more configurable (e.g. a “maximum”, a “minimum” and and “offset” for auto-exposure that users can set to their personal preference).
- The intent is to have these new auto-exposure controls within the EEP Sky settings.
- This work should help with issues such as the environment looking “dim” over water, snow, and similar.
In Brief
- [17:36-25:40] Mina PBR Hair issue: Mina Nakamura indicated a possible alpha issue she is experiencing when using the specific PBR versions of some of her hair styles, which has only become apparent with the release of DeltaFPS. This may be a result of multi-layering of alpha blends, but copies of the hair have been passed to LL for testing.
- [27:48-28:49] It was noted that there have been problems in get various content artists (hair makers, skin makers, etc) engaged in the Content Creation Discord channel, which has impeded some of the work relating to Baking, alpha/gamma, etc.
2K Bakes on Mesh
- 2K Bakes on Mesh remains in general QA on Aditi (the Beta grid), and content creators are asked to test content there and provide feedback.
- Specific feedback being sought includes: bakes coming out at the correct resolution (e.g. if all layers at 1024×1024, that the Bake is also 1K); everything appears visually correct without any compression artefacts or similar; that the general experience with Bakes is the same as on the Main grid.
- As a part of this work, the Bake Service as a whole has received some performance improvements. However, this aspect of the work has yet to be deployed to Aditi, plus once deployed, they may not result in a visually faster bake, depending on the complexity and resolution of the layers being baked.
- If all goes according to plan, it is hoped there will be some form of 2K Bakes on Mesh support to the Main grid (Agni) by the end of November – although this is subject to confirmation; and they the Lab will provide a date when 2K skins, etc., can start to be listed on the MP, etc.
- There was a reminder that account syncing with Aditi should now be automatic at the time of log-in (no need to raise a support ticket). However, anyone encountering issue still with Aditi access should contact support.
Viewer Discussion
This was a wide-ranging discussion commencing at the 29:14 point of the video. The following attempts to summarise that discussion, however, to try and keep a general sense of context, the bullet points may not reflect the order in which comments were made.
- LL are looking to encourage greater engagement in testing new capabilities and features for SL, rather than having to wait for Firestorm to ship a viewer with support for the new feature / capability, in order to avoid a similar situation as occurred with PBR.
- The SL viewer (SLV) has a good cross-section of hardware running it, but the overall pool of users is much smaller than that of Firestorm, and of those that do use it tend not to be so engaged in the platform so as to test and try things / report issues, which can result in problems such as those seen with the deployment of PBR: the Lab doesn’t have a sufficient deep pool of engaged users to report issues as they are encountered as new features / capabilities are being developed.
- The question was asked as to what makes Firestorm attractive to users. This boiled down to four major areas:
- The additional UI elements Firestorm have built to expose functions native to the viewer, but otherwise hidden within Debug settings.
- Dedicated additional features created for Firestorm (e.g. Contact Sets), our specific new UI elements which pull together options and setting from assorted elements of the viewer and present them as a cohesive whole in their own right (such as the Phototools code contribution; the Graphics Improvement floater, etc.).
- Very basic quality-of-life improvements, e.g. the ability to de-render / block the rendering of in-world objects (see below for more on this); the additional options to position tollbar buttons in the window (e.g. make them left or right ranged along the bottom).
- The level of in-world and additional support Firestorm provides: in-world classes teaching how to use the viewer; in-world support groups providing “live” support in multiple languages, etc.
- Shortfalls within the SL viewer were noted as:
- Loss of simple quality-of-life elements (e.g. the chat bar) and lack of accessible in-world support.
- A lack of general support documentation / material (in this, TPVs have a distinct advantage, in that users of those viewers are willing to produce their own tutorials and guides, whereas few do so where the official viewer is concerned).
- General misapprehensions about viewers. for example:
- The idea that the SL viewer “doesn’t have capability X or Y, as it remains hidden with Debug settings.
- The belief that features capabilities added by LL are “Firestorm” (or whichever viewer is being used) simply because it is first seen in that viewer, and thus are “missing” from the official viewer.
- The idea that LL “doesn’t support” older hardware; as Runitai Linden noted, LL does not intentionally seek to make the SL experience any worse for those on older / less capable hardware; when this happens, the Lab does make efforts to redress things.
- [Video: 49:19-End] An extended discussion on the Derender capability within Firestorm, with pros and cons, together with whether it should be generally surfaced for new users, due to the impression it gives (“welcome to our world; yes some of it is naff, so you might want to derender it”).
- Pros: the ability to stop unwanted objects being rendered in a scene either for a session or until cache is cleared. This is very hand for a variety of reasons such as in-world photography.
- Con: the ability to de-render mesh clothing on other avatars.
- The discussion also touched upon alternatives to derendering for certain use-cases (e.g. the ability to click-through something like mesh “rain” to touch a vendor board – something which can now be set, as Rider linden indicated).
- Also mentioned was the option for a degree of automation to help deal with some instances where de-rendering might otherwise be used (e.g. some form of flag mechanism / land setting such that should someone enter a G/M public space with genitalia / “adult” attachments on display, the simulator orders the viewer to remove them (see below for this).
Post-Video Discussion
- A discussion on streaming on Twitch to reach new users – which Philip Rosedale has previously noted, is a subject of ongoing discussions between LL and Twitch, with the caveat that seeing Twitch as a possible “marketing / promotional” channel for SL is not ideal, due to the younger age demographic of many Twitch users.
- It was noted that VRChat, which has “adult” content manages to be able to have people stream from it to Twitch.
- It was also pointed out that Twitch is a channel for content creators to produce tutorial-like live streams on how to use external content creation tools (Substance Painter, Blender, etc), to create content for SL – but they are unable to steam video of the content being used in SL via Twitch.
- The idea of a flag mechanism was discussed in broader terms: as well as having a specific land control switch, having a switch in the viewer which derenders “adult” attachments on avatars. This:
- Would provide the control at a per user basis (don’t want to risk seeing “adult” attachments? Leave the switch set; no objection – turn the switch off and allow “adult” attachments to be rendered.
- Allows, when combined with the land control, the greatest flexibility of use: store owners or owners of G / M rated public regions, for example, could opt to set the flag at Land level, and thus automatically prevent rendering of any / all “adult” attachments in their regions in all viewers in that region.
- The above led to a conversation on Second Life continuing to allow adult content whilst working to ensure there are workable safeguards to ensure those not wishing to see it do not see it. This discussion touched upon:
- Issues of Marketplace content not being properly flagged as adult / being tagged too broadly so that either someone with the MP content rating set to General or Moderate still gets to see adult content; or b) adult content appears in entirely unrelated categories.
- The need for a more granular rating system. There are many reasons for this (e.g. Adult is often a catch-all, rather than indicating “sexual” (or possibly offensive): art galleries, for example, will often opt for an Adult rating, simply to avoid the risk of being reported for displaying nudity, genitalia, etc., within art.
- Philip Rosedale asked about the appropriateness of clothing in public spaces (specifically indicating his own use of chaps with a “stained glass” crotch area in a public meeting venue – even through the chaps revealed nothing, they still drew people attention to his crotch).
- Suggestions were made that the new user experience should provide mor details on common activities within Second Life, to give incoming joiners a clearer idea of what to expect / what they might discover.
- This included an idea that anyone expression an interest in “Adult” content should be “sent straight to Zindra” – which (personal opinion here) I believe would be a bad move, as Zindra is most strongly associated with sexual content – and as noted earlier in the meeting, “Adult” in SL does not automatically equate to sexual activities. But, by pushing people who click the option merely out of curiosity directly to Zindra, risks reinforcing attitudes that SL is focused on sex / porn.
- Philip also provided some updates on matters raised during his November 1st, 2024 Community Round Table:
- That work is being put into place to better explain the user name selection in the join flow, and the difference between the user name and the Display name, to help overcome issues of people choosing user names they come to regret (e.g. “xyzmnop3210”).
- A reiteration of the (oft-voiced at UG and Meet the Linden / Lab Gab technical sessions) fact that the reason Groups are capped for membership levels is that activities such as sending Group message comes an a non-trivial computational process (and associated cost) of the back-end systems having to look up which users are in a particular group in order to receive said message(s).
- The above comments led to a series of personal requests being made directly to Philip, which as he pointed out, highlight the fact that prioritising requests is not easy – those who talk loudest / most persistently do not necessarily represent the majority thinking, and thus their request – even if apparently easy to achieve – many not reflect what “the community” (a term itself hard to quantify) actually wants.
- In this, he specifically reiterated some of his comments from his Community Round Table about trying to find mechanisms by which the Lab can better engage with groups of users on topics / ideas, in order to get a broader representation of people’s views without either a) responding only to the most dominant voice in a group; or b) having a group so large, it is impossible to get a broad consensus on feedback / ideas.
- Amidst the general airing of points-of view, Philip asked a question which is of potential relevance to many; as such I’ll include it here:
One of the things I’m trying to think about is how to make Second Life more accessible to all of you. What I mean by that is, for that one thing that brought you in, is Second Life also accessible to everyone else for whom that one thing is also true? So, for example, I spoke to someone the other day who is hard of hearing; and I can imagine that’s a pretty good reason to want to be in Second Life, because being in the real world sometimes can be quite difficult if you’re hard of hearing, right? Potentially, Second Life can make that easier, but only if we do the accessibility work to make that functional.
So I kinda ask the broader question – and again, if you want to follow-up with me by e-mail, please do so. The broader question is, what is it that brought you here, and then is Second Life easy to use for everyone else like you, is kind-of the way I’m thinking about right now. It seem like so many things are hard; in different ways, Second Life is appealing, but then many, many other features of it make it excruciatingly difficult. Like, we talked earlier about if I’m a teacher who wants to play around with using Second Life at university, but I’m so exposed to sexual content that I just decide “no”, that would be a perfect example of that; so in that case, Second Life is just not accessible to me as a university teacher, because it’s just too sexual.
- The above led to a range of opinions on what SL is, griefing, accessibility in terms of supplied avatars, etc, running through the last 10 minutes of the session. However, given Philip’s question and the fact that some might wish to respond – to Philip via e-mail, not in the comments here, which he may not read! – I will close the summary here as it is already well into the realm of TL;DR!
Next Meeting
- CCUG: 13:00 SLT, Thursday, November 21st, 2024, at the Hippotropolis Campsite.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.
Inara Pey: Living in a Modemworld 