The following notes were taken from:
|
Table of Contents |
Please note that:
- This is not a full transcript, but a summary of key topics.
- “[Video]” time stamps refers to the CCUG meeting livestream recording; “[Pantera]” refers to the TPVD meeting video provided by Pantera.
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.
- The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
- Dates and times of both meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.
Official Viewer Status
- 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.11750364439, November 12.
- 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.
Mobile Notes – CCUG Meeting
- Adding PBR support to SL Mobile is on the roadmap, with ah hoped-for target of some time in Q1 2025 (Jan-March).
- SL Mobile voice support is experimental, and utilises WebRTC.
CCUG Meeting
Graphics Team Work – General Recap
[Video 0:28-5:31 and 25:04-32:33]
- Core focus remains on performance work and will remain so until “everyone is happily on PBR-enabled viewers.”
- Hope is still to have ExtraFPS promoted to release status by the end of 2024.
- This viewer should see some “significant [performance] improvement” on certain types of hardware – e.g. the Intel HD4000 series (launched May 2012), which is “remarkably popular” among SL users.
- This work is focused on developing a “classic” mode (also known as a “potato mode” which will see various rendering options disabled (e.g. HDR, Tone Mapping, Reflection Probes, the Emissive channel) to render SL more in keeping with its pre-PBR appearance when running with ALM enabled (aka Deferred Rendering).
- To achieve this and ensure decent frame rates, comparative benchmarking is being carried out:
- If an older GPU runs a non-PBR viewer at a higher FPS with ALM enabled than with it disabled – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer. Or;
- If an older GPU runs a non-PBR viewer at a higher FPS with ALM disabled (thus using the old Forward Renderer) – – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer, but with ALM-like graphics fidelity.
- A major element of this work is to get older harder performance back up without creating a rendering schism through the re-introduction of something like Froward Rendering.
- This work is being carried out alongside “various end of year this and kick-off the next year things.”
[We’re] doing our level best to ensure everybody who can use Second Life on Firestorm 6.6.17 can upgrade to some version of 7.x [PBR] without suffering negative consequences. That’s what we’re doing; we’re chasing all the crashes that we can and all the performance issues that we can.
– Runitai Linden.
- [Video 33:28-35:10] A reiteration that a lot of the issues impacted older / lower spec systems are not PBR-related per se (they just happen to have been surfaced within PBR-enabled viewers). Rather, they are the result of things like running out of VRAM due to the updates made to the texture streaming system.
- Where issues have been due to PBR (e.g. exceptionally heavy PBR in-world builds) there are additional optimisations that are being done.
- A point to remember here is that PBR is a part of the glTF 2.0+ specification which LL are adopting – and glTF is designed to support a very wide range of hardware, including mobile ‘phone upwards, and so is not itself particularly resource-intensive.
- Until now, issues with the quality of water reflections on PBR viewers has not been seen as a priority to fix, as it is not performance related and has thus been “taking a back seat” in the queue of fixes. However, if it is seen as a significant issue that prevents users from moving to a PBR viewer, this might be reviewed.
Texture Blurring and downscaling
- In response to comments about texture blurring, Runitai Linden noted that the viewer will start down-scaling textures as it detects a system is running low on available VRAM.
- This can result in some scene textures close to the camera remaining blurred until focused / zoomed-in upon.
- Runitai believes there is more work that could be done as to how the fall-off curve for this works to reduce the need to zoom “right in” on textures doing this in order for them to render properly.
- He further noted that the old behaviour of just using mouseover on a texture to get it to load is no longer applicable, as that actually caused most of the textures in a scene to load at full resolution, causing a performance hit.
- In addition, there are still some bugs which can result in the viewer getting the wrong answer as to how much VRAM is available on a system (and start downscaling textures when it may not need to). To check if this might be the case:
- Open the viewer’s texture console (Develop(er) → Consoles → Texture Console / CTRL-SHIFT-3).
- Check Est. Free (top line of the Console display) and compare the number with something like GPU-Z or Task Manager (via GPU option).
- If the two are very different, then there is likely a bug. Please file a bug report with hardware details (Help → About → Copy to Clipboard and paste info into report).
- Note that on integrated graphics system, the amount of VRAM usually gets reported as the amount of system RAM, and this is referenced by the Sys Free number in the viewer’s Texture Console. Sys Free also reports based on the fact that the viewer tries to minimise its total memory footprint to under 16 Gb.
- There is no set “minimum” or “maximum for VRAM with SL; LL are committed to enabling SL to run on GPUs with as little as 2 Gb of VRAM, and it is felt that systems with a minimum of 4 Gb and a Draw Distance of 128 metres should be able to manage most scenes – but this is a very broad rule of thumb; the viewer will continue to use VRAM until it runs out, if necessary – there is no upper limit, although some TPVs do allow caps to be set.
- When downscaling occurs, it should be a) because VRAM has been used; b) commence with textures in the background / off-camera before moving to those in-view.
- Note that textures will also be off-loaded from VRAM when SL is minimised / put in the background, to allow other applications access to VRAM. This can also cause blurring as textures are reloaded when SL is brought back to the foreground and resumes using all available VRAM as best it can.
In Brief
- [Video: 18:32-21:02] WebRTC: LL are still awaiting more users to move to viewers with WebRTC support prior to disabling Vivox.
- [Video: 23:31-24:40] Older EEP (e.g. Windlight, they’re that old – such as CalWL) settings can look blown-out on PBR views.
- LL have been attempted to auto-adjust them, but this has proven subjective in terms of results.
- Therefore, going forward, work will be limited to trying to make them look like they used to, which is acknowledged as not being great for PBR content, but is the “least bad” in terms of keeping EEP settings people like looking the way people like to see them.
- Hopefully, this work will be finished in time to be included in ExtraFPS; however, if it misses ExtraFPS, it may be issued as a viewer hotfix.
- [Video: 39:15-40:10] A note of two long-term risks, graphically speaking, that have to be addressed within SL at some point:
- COLLADA support: support for COLLADA is waning world-side, and so SL needs an interchange file format that is not dependent on COLLADA. Again, glTF is seen as the best solution here.
- Similarly, OpenGL support is waning, so SL requires a rendering engine that does not rely on OpenGL [and this has been an on-going discussion for the last couple of years or so].
- [Video: 40:12-45:10] Land Impact: it has long been acknowledged that the Land Impact calculation needs to be revised; there is both a lack of real incentive within it for creators to optimise their builds, and it misses some key adjustments for things like large builds. The question here is more when it will be revised – although doing so may not eliminate all the ways in which some people game the system to produce lower LI items, as this is something of a separate issue.
- A general discussion on glTF and mesh imports (incl. scenes) via glTF. In short, no-one working on things at present, given the focus on the performance issues. The local preview remains available in those viewers with the code – by Runitai reminded people that the preview does not use texture streaming; everything gets pulled in at full resolution – and so VRAM can easily be gobbled up.
TPVD Meeting
Much of the TPVD covered ground already walked during the CCUG meeting. Therefore, the following is thus a summary of additional points discussed. Time stamps reference Pantera’s video, below.
Note the meeting formally ended at around 29 minutes, although the video runs through until just shy of 41 minutes, covering a more generic conversation.
- A recap of the “classic” / “potato” mode work (get PBR viewers running on lower-spec machines running at the same or better FPS than the hardware can run a non-PBR viewer).
- Debunking the PBR myths:
- It is not necessary to run the viewer on Ultra quality in order to view PBR content.
- LL are not removing support for Blinn-Phong (or “classic” or “legacy”, however you want to call them) materials. PBR is an extension to materials support in SL, not a replacement.
- A general conversation on Blinn-Phong and PBR Materials, notably in terms of providing the former as “fallbacks” to the latter to accommodate people on non-PBR viewers and prevent them seeing grey / white / plywood surfaces / features.
- [Pantera: 9:42-10:42] Some people may experience issues with PBR not just because of computer hardware limitations, but also because of network / router issues (e.g. instead of a single diffuse map, PBR calls multiple maps, resulting in multiple HTTP requests which can cause some routers to choke).
- To counter this, the “classic / potato” mode LL is developing already doesn’t use the emissive map; if this is shown to work and push up performance, then LL will likely go through as see what other maps might be ignored without compromising the overall visual look of “classic” mode, and hopefully further lift performance in these cases.
- [Pantera: 15:11-16:45] A reiteration that LL are continuing to work on trying to resolve performance issues, and that anyone experiencing such issues should file a feedback report with as much detail as possible (including hardware information (Viewer Help and use the Copy to Clipboard button and paste info into the report).
- Specifics are important, as there is only so much info LL can pull from their stats. This is particularly true when terms such as “performance craters” are used, as these are so broad-ranging as to be meaningless.
- [Pantera: 16:50-20:00] SL viewer’s use of CPU cores and threads: thread usage is variable depending on the number of CPU cores.
- Those with a specific interest in this, the Steam Hardware Survey is “pretty close” to SL, although SL’s install base tracks “a little closer” to the lower end of hardware, so reduce what is reported in the Steam Hardware Survey 10-20%, and that’s fairly representative of SL.
- Overall with SL, the main processing loop is single-threaded; texture rezzing and some audio processing occurs on background threads.
- Runitai Linden has been experimenting with adding threads – such as a dedicated idle thread – and these are showing a “lot of promise”, particularly when Vsync is used.
- As most GL processes are multi-threaded, hints are sent to things like Nvidia drivers to put themselves into multi-threaded mode.
- [Pantera: 20:38-25:35] Frame limiters / Vsync: some TPVs use frame limiters to assist with performance, and LL would be interested in receiving a code contribution for one of these.
- However, it is felt that if trying to limit frame rate to screen refresh, then Vsync remains the better option; whilst a frame limiter is more suited to use in other situations. But, and depending on the frame rate, Vsync can cause more screen jitter than a frame limiter.
- In this discussion it was noted that a fix from Apple at the OS level means Vsync with work at 100/120 Hz.
- It was noted that Firestorm are now defaulting to 60fps with their frame limiter.
Next Meetings
- CCUG: 13:00 SLT, Thursday, December 5th, 2024, at the Hippotropolis Campsite.
- TPVD: 13:00 SLT Friday, December 20th, 2024 at the Hippotropolis Theatre.
† 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 