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 generally held on alternate Thursdays at Hippotropolis.
- Dates and times of meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.
Official Viewer Status
- Official Viewer: 2025.04 – 7.1.14.15192634334, issued May 25, promoted May 28 – No Change.
- Second Life Project glTF Mesh Import, version 7.1.14.15976006598 July 2 – No Change.
- This is an early Alpha release with some of the rough edges and already resolved many bugs and crashes, although more are to be found, together with general feedback from the community. Please read the release notes if you intend to test this viewer.
- Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 – No Change.
glTF Mesh Uploader
[Video: 1:41-3:03 – and as noted below]
- This project is moving into beta testing, and the updated viewer for beta testing is currently with QA, and should appear on the Alternate Viewers page “pretty soon”.
- Again, as a reminder this project is providing the overall functionality available for uploading COLLADA .DAE files to the upload of glTF mesh files. As such all current constraints will continue to exist within this work.
- Enhancements will be coming (and Feature Requests have been received for things like increased tri counts and vertex limits), but are regarded as a separate tranche of work.
- [Video 4:50-6:00] A request was made for enhancements to the convex physic hull limits (e.g. number and complexity). This would require simulator-side changes, as some of the constraints are enforced server-side, and are “fundamental” to how Second Life works.
Lighting Discussion
- [Video 6:05-7:40] Light and particle exclusion volumes – the question was asked that as SL now has water exclusions “volumes”, how hard would it be to do the same for lighting and particles (e.g. to prevent lighting in one room bleeding into another).
- In actual fact, SL does not currently support water exclusion volumes – it only supports water exclusion surfaces, which operate more-or-less in 2 dimensions to “hide” water”, rather than excluding it from a volume area.
- Geenz noted that water exclusion and light / particle exclusions are “very different” in nature, with water exclusions surfaces being handled by a dedicated rendering pipe, and both light and particles requiring their own specific solutions.
- He further noted that for lighting, other engines typically support linking a light source to a volume, constraining the light to it. SL does not have that capability, and while it would not be impossible to enable it, the work would be non-trivial, and is not something being looked at. His preferred approach would be to get shadows working more efficiently and at a larger scale.
- [Video: 10:39-11:25] Related to the above, it was noted that non-shadow punctual lighting could help with lighting / darkness / shadow issues. These had been something Runitai Linden had started to look at prior to departing the Lab; in Geenz’s view, a means to determine which lights should / should not cast shadows might offer a partial solution.
- [Video: 12:17-13:43] Geenz also noted there are been several requests on Canny for lighting improvements, and he would like to get some work on lighting prioritised. However, there is a large amount of work already identified for the viewer, and so prioritising and further work has the be done “carefully”.
- He also noted issues with point lights were noted (fall-off being incorrect; the light radius tends to exceed the value set; point light penetrate objects far too much, etc), and suggested they could potentially benefit from a revisit at some point.
- [Video: 24:36-25:30] Would it be possible to create a reflection probe-like if volume and assign an EEP setting to it?
Viewer-side Havok Sub-Library and Pathfinding
- Pathfinding’s future is still up in the air, with no final decision taken as yet. Currently all that is being looked at is the removal of the Havok sub-library from the viewer, which impacts Pathfinding.
- This sub-library is used for two purposes:
- For convex decomposition in mesh uploads.
- Visualising / managing the Pathfinding Navmesh.
- In terms of mesh uploads, there are alternative open-source libraries which could be used in place of Havok. Some of these alternatives are already being used by TPVs in preference to having to obtain a Havok sub-library licence from LL, and Geenz noted that a Pull Request from any viewer using such an alternative would be “welcome”.
- Using Havok in the viewer purely for visualising the Navmesh is seen as overkill, again considering there are potential alternatives which could be used.
- Philip Linden noted the need to reduce the amount of technical debt in the codebase, and removing Havok from the viewer would assist in this.
- As far as Pathfinding as a whole is concerned, Geenz reiterated that currently, the Lab is not looking to completely deprecate it (both within the viewer and on the server-side); all that is being discussed at present is the need to remove Havok from the viewer.
- An ancillary question asked by Rider linden was how many people at the meeting actually used Pathfinding characters, as opposed to NPCs using llGetStaticPath (which appears more popular, given the 15LI penalty and overall complexity of build Pathfinding characters).
In Brief
Please refer to the video as well.
- [Video: 3:14-4:10] There is some work going into “beefing up some frame time metrics” – this will mean the viewer’s Statistics Floater (CTRL-SHIFT-1) will be updated with “a lot more” statistics going forward.
- Some of this work will be surfaced in the next update to the glTF Mesh Upload RC viewer.
- How many of the new stats are to be tracked in real-time is still TBD within the Lab.
- [Video: 8:05-8:40] In terms of water exclusion volumes, this work has not yet bee prioritised and would required co-ordination between the simulator and viewer teams as it would require the passing of new object flags in order to work properly.
- [Video: 20:41-24:08] General Linden Water update:
- Improvements to Screen Space Reflections (SSR) on water are currently on hold pending the work on gathering better frame time metrics to be sent to the logs (how often is a user’s frame rate significantly dipping, for example), rather than just logging a user’s frame rate at the time they log-off.
- The work that has been done on water SSR also still needs some further polish.
- Overall the aim is to offer real-time reflections on any surface without it being a “gigantic frame rate killer”.
- Other things that Geenz would like to bring back include shoreline fading, which had to be disabled due to alpha rendering issues – but this kind of work may have to wait for expanded EEP settings for water.
- [Video: 33:40-36:02] PBR texture stretches when “stretch textures” is unchecked was raised over a year ago, and is marked as “complete”. It is not clear if a fix was actually deployed (and it does keep occurring), so Geenz and Atlas linden are going to take this back for a further review.
- [Video: 37:04-48:24] A discussion on “lag”, and the (still common) assumption that most of it is simulator-side, and thus LL’s problem, rather than the viewer becoming overloaded thanks to people’s proclivity to jam-pack their avatar with complex meshes, multiple attachments, high-resolution textures, etc., thus impacting their own system’s performance (and potentially that of the people around them).
- Geenz acknowledged that there is more LL could do to allow people to better quantify the impact they are having on themselves and others, vis à vis their avatar outside of the (inaccurate) avatar complexity system.
- A problem here is that whether provided via options in the viewer, documentation, etc., people will ignore recommendations, warnings, reminders, etc.
- Potential approaches to helping people understand the impact of the avatar include: indicating how much of their VRAM their Avatar is absorbing; having a meter display over their avatar’s head indicating the level of impact on general performance their avatar is having (both of which would only be visible to the user viewing them – and not to everyone else).
- Technical solutions which might also help and under potential consideration for future implementation include texture streaming.
- This discussion also encompassed the deficiencies with the ARC (Avatar Render Cost calculations & figures, and regulating the tension between people dressing their avatars so that they are resource-intensive to render, then going to a club or social venue and then dragging down the performance experienced by other users vs. allowing the venue owners to have the ability to set an “upper limit” on how resource-intensive avatars entering their club can be in order to preserve an experience that can be enjoyed by everyone.
- The first 10 minutes of the meeting included a largely text-based discussion on the physics engine and viewer freezes. In short, there are no planes to change the physics engine, and the kind of viewer freezes experienced by SL as physics calculations are carried out are not uncommon within platforms using user-generated content (UGC), so trying to replace the current Havok engine (or even updating it) would not necessarily solve these issues.
- A discussion between a user and Geenz concerning an EEP setting setting and use of an RGB cloud map, and whether this is supported. No definitive answer, other than Geenz would need to investigate.
- The end of the meeting touched on SL Mobile issues and Project Zero – these are covered in other user group meetings.
Next Meeting
- 13:00 SLT, Thursday, August 7th, 2025, at the Hippotropolis Campsite.
Inara Pey: Living in a Modemworld 