2026 week #23: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, June 4th, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

Viewer Notes

  • Viewer 26.3.0 (performance improvements) remains the priority for issue and later promotion. This viewer will include async inventory loading, which should further help with loading very large inventories; together with new texture streaming updates which should help those on SL minimum specification computers with constrained VRAM.
  • Beyond this, there are on-going discussions within the Lab as to priorities for the viewer train going forward.
    • This might see the Lua Editor and the Linux updates for the viewer get merged into the Develop branch. However, if this does happen, it should not be taken to mean Lua is on the cusp of being formally released; rather it will will mean that the viewer side gets released within a viewer ahead of the back-0end support going grid wide (the latter loosely seen as being in the late summer at the earliest).
    • Setting feature flags within the viewer to gatekeep upcoming features and functionality until such time as it is generally available (as would be with the Lua code mentioned above) is also being discussed.
  • The Graphics Care Package Viewer (GCP) is effectively “on hold” for the present. However, it might see some additions made to it, such as the glTF transmission work (which will depend on the overall performance impact).
  • Maintenance releases are also in development. As has been indicated in past CCUG and Open Source meetings, these will be much smaller updates to the viewer, aimed at offering a more limited number of fixes  (e.g. the top 5 or 10 issues / viewer crashers) than has been the case with past maintenance viewer updates. The first of these is probably going to be viewer 26.3.1 (i.e. following 26.3).

General Discussions

  • Kyle Linden confirmed the Second life Creation portal (/Getting Started with Scripting) has seen a lack of outward communications from LL, but the Lab definitely wants to proceed with building it out and does want to receive contributions. To this end he will be contacting those known to have produced documentation on things like Lua, and this work will be progressing in the near future.
  • It was requested that the upcoming rendering updates within the GCP viewer all have options to disable them if people do not wish to use them.
    • Geenz pointed out that rather than options to disable, all of the items with could impact performance (such as glTF transmission) will have drop-down options within Preferences, allowing their quality, to be lowered, limiting any performance impact. However, some capabilities (e.g. glTF metallic) will remain enabled at all times, as they are viewed as essential to content.
  • A general conversation about possibly reintroducing texture sampling / supporting glTF texture filtering, plus looking beyond OpenGL together with upscaling resolution via the likes of AMD’s FSR, Nvidia’s DLSS, Intel’s XeSS, etc. See here for more), with Geenz noting the with the deprecation of OpenGL, LL is getting increasingly constrained as to what they can do, although FSR is a “maybe”, as there has been some backporting of support to OpenGL.
    • The above being said, LL is currently still looking at API options (e.g. Vulkan / Metal /  WGPU (the latter being seen as  suiting a wider mixed of older hardware can address multiple APIs)), although the focus at the moment is on finding a good inflection point to determine the direction which should be taken (such as Apple finally finally ending their support of OpenGL, rather than deprecating it but still supporting in through Mac Os 14 Sonoma).
  • Conversations not directly related to content creation included Nvidia’s new CPU/GPU ARM chips and how they may affect hardware (and Windows support) in the future; availability of Second Life OpenSpace regions; whether Second Life can have regions larger than 256×256 sq m (not on the horizon).

Next Meeting

2026 week #21: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, May 21st, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

Viewer Notes

  • 26.2.0 is now release, per the above. The code has also been merged into all viewers currently in development (such as the Lua Editor) with the exception of the Graphics Care Package (GCP) viewer.
  • Viewer 26.3.0 is the performance improvements viewer, intended to be the next release viewer and which is currently awaiting being issued as an alpha or RC viewer. This viewer:
    • Includes async inventory loading, which should further help with loading very large inventories; together with new texture streaming updates which should help those on SL minimum specification computers with constrained VRAM.
    • Is viewer is reported as providing good performance across a range of systems and scenarios.
  • As a part of the texture streaming updates mentioned above:
    • The viewer will not have: “a proper” texture quality setting (Low to Ultra) or the current LOD resolution drop-down.
    • The viewer will have a new texture resolution drop-down, which is more aggressive on its Low setting to optimise the use of VRAM on low-specification client systems; a Medium setting also doing more lower-resolution loading for textures at a distance from the camera (but high resolutions for those close-up); a High setting with resolutions slightly below their current levels; and an “Ultra” option that pretty much matches the current setting.
    • The viewer will also have a new (around 5 metre) “camera bubble” that follows the camera round and tries to load high resolution textures as best the client computer can manage
  • Lua Editor viewer:
    • There are “a lot of asterisks around” this viewer, both in terms of client-side work and server-side work.
    • This viewer may end up with numerous flags within it which can be toggled on / off depending on the status of server-side Lua support.
    • The availability of an official Linux remains tied to this viewer.
  • The Graphics Care Package Viewer (GCP) is effectively “on hold” as work continues on other viewers. However, when it does surface, it will likely include (but not necessarily be limited to) the following:
    • EEP post-processing settings, easing the work of setting-up EEP environments.
    • PBR specular support.
    • Updated and more performant Screen Space Reflections (SSR), including the ability to adjust SSR rendering to better suit the capabilities of the client computer (e.g. cranked right up on a very capable modern computer & GPU, or dialled down so it doesn’t choke older hardware).

General Discussions

  • It was asked if PBR (glTF) lighting is coming soon. Geenz noted that this requires server-side work, notably around the messaging service between the simulator and the viewer. Such work would need to be implemented before LL can fully commit to having largely glTF-compliant lighting. So, not in the immediate future.
  • A question was asked about artefacts occurring in varying levels when a gradient (slope) is applied in the construction of metallic materials, and whether anything was being done to correct this.
    • The question was related to gradients in normal maps, but was not total clear (i.e. was the gradient part of the normal map, or something added latter?). As such a canny report was requested on it.
    • There is a known issue with gradients on the diffuse map, and this is being addressed with the GCP viewer.
  • A request was made for PBR emissive map textures to load as the colour #000000 (up the receipt of the first discard level), as the current value – colour #808080 -, which  causes objects that use emissive to glow while they load – see this issue / Github).
    • Geenz Linden noted this could be so modified, but it would then cut across some of the texture loading work that has been going into the upcoming performance improvements viewer (26.3)
    • As such any change is unlikely to be implemented as a part of that viewer.
  • With the BonnieBots data collection system now banned from SL, a request was made for clarity on what is / is not permissible in gathering data from the grid, as there are a number of valid projects that require the use of specific data gathered from the grid via bots (e.g. in obtaining terrain heightmap data for use in producing 3D terrain maps). Geenz indicated:
    • He would try to get some clarity on this from senior management.
    • That including things like heightmap data into the map system is something the Lab is looking at, so as to make requesting this kind of data easier for those using it.
    • That additionally, LL is considering the use of things like object imposters and mesh proxies where applicable – but there is nothing solid to report on any of this at the moment.
  • It was asked if there are any further updates being planned for the avatar skeleton / avatar bones / blend shapes. Short answer: no; any work on the avatar / avatar skeleton would need to be relatively in-depth due to the risks of content breakage, etc., and so is something LL do not want to take on at present.
  • A question was asked about LL’s strategy for on-boarding and retaining new users. As previously noted in these summaries (and others), LL is not pursuing any single goal for this; there are several inter-related strategies (such as the one-click install on the viewer – making it easier to obtain; & the upcoming graphics improvements – which should make running SL a smoother, more predictable experience).
  • The subject of VR support was raised. The feedback from Geenz was that VR poses significant issues for SL, particularly in the area of being compelling enough to people already using VR headsets. For example:
    • Implementing a means by which people can simply put on a VR headset and look around SL or even move around with their avatar is not technically that complex. However, neither of these approaches would necessarily be compelling to people coming into SL who are familiar with using VR on other platforms.
    • By contrast, making SL interactive in a manner that is compelling to existing users of VR – e.g. being able to engage with, move, etc., in-world objects through hand  arm / body movements and to have things like full facial tracking and representation and having all of that packaged and streamed to everyone else in a region – is a considerably more complex task, potentially touching on multiple areas of the platform. As such it is not actually something LL is directly focused on.
  • The above led to a broader discussion at the end of the meeting on the Lab’s discontinued Puppetry project, its application in a possible VR project, together with alternate approaches, matters of IK, etc., all of which came down (again) to the view that providing a “good” and scalable VR solution in SL requires working on multiple moving parts / would have lengthy lead-times, and so is not something LL  wishes to commit to in the near-term  .

Next Meeting

2026 week #19: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, May 7th, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

 

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer  – One-Click Installer = 26.1.1.23806384790 – April 10 – No change.
  • Second Life Release Candidate (RC) viewer: Flat UI – 26.2.0.25021396775, April 29 -“flat” UI and font update.
  • Second Life Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

Viewer 2026.02

  • 26.02 is enjoying low crash rates, confirming its status as the next viewer in line for promotion to release status.
  • There will likely be another RC update to this viewer prior to its promotion, which will include some “small, small” changes and fixes (e.g. making bold text easier to see, correcting some text overruns in some floaters, and correcting an extended CEF load time on the viewer splash screen).

Viewer 2026.03

  • This viewer is now described as “following hot on the heels of 26.02”, although it has yet to appear as either an alpha/project viewer or a beta/RC viewer.

Graphics Care Package vs. Lua Support Viewer

  • No firm decision as to which of these viewers is liable to progress to release status first.
    • The Lua viewer would appear to have the advantage given it is currently going through alpha/project viewer evolutions to move towards a beta/RC version, whereas the GCP viewer has yet for officially see the light of day.
    • However, the Lua viewer is dependent on the development of Lua back-end support and simulator updates, plus it is also the viewer being used to re-introduce Linux into the mix of official viewers (with limited support), and both of these might slow the viewer’s promotion to RC and then release status.

WebRTC Update

  • The May 5th grid-wide deployment of WebRTC went ahead as planned, so Vivox is no longer the Voice service across SL. WebRTC is.
  • The deployment apparently went well and there have been few reports of issues.
  • Moving forward, the focus will now be on fixes and updates (e.g. open chat voice attenuation) and general clean-up and the removal of unwanted code.
  • Once this work has been completed, attention will be turned more towards adding new features the WebRTC.
    • Voice-to-text transcription has been requested as one of these new features (and has been experimented with inside the La, including with multiple languages), however, no decision has yet been made as to WebRTC new features or their scheduling.
    • It was also requested to have the moderation tools for Voice made accessible to scripts per this feature request.

General Discussions

  • There are reports of what might be a bug which is causing some avatars to appear to have a 1,000,000 complexity number, when they are far below this. At the time of writing these nots it is unclear if a Canny bug report has been filed on this or not, or how widespread the issue might be.
  • A request was made for expanding SL material assets so they can be used to *completely* set an object’s material? So a BP tab in the material as well (e.g. the ability to drag and drop Blinn-Phong materials into a PBR asset alongside of the PBR materials, so have a complete package with the BP materials available for fallback purposes).
    • There are no specific plans for this. However, as Geenz linden has previously mentioned in recent meetings, there are plans in hand to add specular materials to PBR.
  • Will the terrain painting project be revived? Unlikely at this point is time; performance issues are the current priority and after that, there is more general PBR work to be completed. As such, the terrain painting work remains frozen.

Next Meeting

2026 week #17: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, April 23rd, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

 

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer  – One-Click Installer = 26.1.1.23806384790 – April 10 – No change.
  • Second Life Release Candidate (RC) viewer: Flat UI – 26.2.0.24254827122, April 15 -“flat” UI and font update.
  • Second Life Lua Editor Alpha viewer 26.1.0.21525310258, February 12.

Viewer Notes

Viewer 2026.02

  • 2026.02 remains the current Release Candidate viewer (next in line for promotion to release status).
  • This viewer will likely have a further RC update prior to any promotion. This update should result in much sharper text rendering within the UI.

Viewer 2026.03

  • LL are working on implementing “whatever performance wins that we can”.
  • This includes “batching” changes – that is, taking multiple objects within a scene and rendering them in a single pass, rather than multiple passes.
    • This work was initially undertaken for what is called the “simple draw pool”, which had batching logic added some time ago, but the work was never extended to the Blinn-Phong or PBR draw pools, and this is now being done.
    • The hope is that this change should help lower specification computers render scenes more comfortably. 

General Viewer Notes

  • Work is currently stalled on the Graphics Care Package (GCP) viewer given the focus on performance improvements for 2026.03. However, work should resume on the graphic improvements and updates for this viewer soon.
  • Given the above, it is still anticipated that the Lua Editor viewer (which is currently available as a project viewer) will go to RC status and then release ahead of the GCP viewer.

WebRTC Deployment

  • The current deployment of WebRTC has hit a few bumps, but the Lab is hopefully the deployment will be completed in “the next two weeks”, and certainly before SL23B.
  • The lack of voice attenuation over distances less than 60 metres (allowing personal conversations to be heard over a large distance) will likely not be addressed prior to WebRTC deployment is complete, and will be looked at afterwards – although it was also noted that attenuation under WebRTC will be different to Vivox.

General Discussions

  • Question: will there will be further updates to Animesh, particularly with regards to having to click on them without having to put a transparent prim around them for interactions?
    • Short answer: the need to click is intentional, and currently, there is no work on Animesh any time soon.
  • Question: will the one-click installer process also be applied to alpha and beta/release candidate viewers, or will these have their own install options?
    • LL is looking at “future options to make opting-in to alphas and betas have a lot less friction”, but discussions a re ongoing and not ready to be announced.
    • Alpha and beta/release candidate viewers will retain their own cohorts within github, allowing people who opt to use them from the Alternate Viewers page to continue to be opted-in to updates to those viewers as they are made available.
    • The ability to select and download a viewer from the Alternate Viewers page will continue.
  • Aside from general text chat on matters such as Animesh (between users) and on Fantasy Faire, this was a quiet meeting, and as such was brought to a close after some 30 minutes.

Next Meeting

2026 week #13: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, March 26th, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

 

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer  – Legacy search; WebRTC improvements; QoL improvements – 26.1.0.22641522367 – March 12.
  • Second Life Project Viewers:
    • Second Life Project Flat UI – 26.2.0.22829286351, March 20 -“flat” UI and font updates.
    • Second Life Lua Editor Alpha viewer 26.1.0.21525310258, February 12.
    • Second Life One Click Install viewer 26.1.0.21295806042, January 26 – one-click viewer installation.
    • Second Life Voice Moderation viewer 26.1.0.20139269477, December 12, 2025 – Introduces the ability to moderate spatial voice chat in regions configured to use webRTC voice.

Viewer Notes

Viewer 2026.01.o1

  • The next viewer targeting promotion to default status, currently awaiting update to beta / RC status.
  • Comprises the one-click installer / updater to improve the viewer install / update processes.
  • Has already seen a “not insignificant” increase in the retention of users logging-in for the first time during closed testing.

Viewer 2026.02

  • 2026.02 remains on track for the “Flat” UI and font updates + plus a possible refresh of the log-in splash screen.
  • Currently awaiting an update to include the updated viewer log-in splash screen.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2

Viewer 2026.03

  • It has now been decided that 2026.03 will be the maintenance and performance improvements viewer.
  • This means the SLua and Visual Polish viewers will continue along their own tracks for release.
    • The SLua viewer is due a further update.
    • The Visual Polish viewer will be taking a longer road to release, as the Lab want to give it a “good long” soak time in alpha and beat (RC) to gather as much feedback as possible once it surfaces for general use.
  • 2026.03 will be pulling some elements of the Visual Polish viewer related to performance, such as the texture streaming work to reduce the load where creators insist on using very high resolution textures, normal maps and (particularly) specular maps, etc., on every face, regardless of size (specular resolution in particular can be reduced without loss of detail.
  • Most of the performance work will be focused on trying to provide a smooth experience for those running SL on lower specification machines and with graphics set to Low to Mid quality / speed.
    • So a focus more on improving frame rates in the viewer, rather than trying to address features known to have a high impact on performance such as Shadows (which require higher quality / speed settings than most lower-spec systems can handle).
    • In this regards, the Lab has a lot of metrics (including things like hardware specifications as more specialised metrics) upon which they can draw in order to be able to drill down into general performance bottlenecks.
  • A further aspect of this work is to reduce VRAM usage, as mentioned in recent previous CCUG summaries.
  • Also being considered for lower spec systems is the ability to “turn off” or automatically disable normal and specular maps on low specification systems.
  • This viewer will also includes as many maintenance fixes as can be included as well. 

General Viewer Notes

  • It is currently a toss-up between which gains priority between the SLua viewer and the Visual Polish viewer.
  • The official Linux flavour of the viewer will still be included in the SLua release.,

General Discussions

  • A feature request to Zoom in notecards, script and image views has been raised and is currently tracked, but as per usual, no estimation as to when it might actually be worked on / implemented.
    • Given the internal discussions that are on-going related to the viewer UI framework (XUI), Geenz Linden indicated he doesn’t anticipate the request being worked on “any time soon”.
    • Exactly what these discussions might be was not open for comments at the meeting.
  • New convex hull tool for mesh uploads:
    • The VHACD  convex hull tool has been available on Apple OS (notably Apple Silicon) fora good while, and Geenz is keen to see this added to the Windows and Linux flavours of the viewer.
    • Again, the primary aim of this move is to allow LL to remove the Havok physics sub-licence requirement from the viewer.
  • A discussion on Linden Water and its appearance – with some wanting water to have more than one layer, to have physical waves, etc.; others wanting a “water asset” that could be applied to mesh / prim surfaces in a similar manner to textures / materials – although this latter is actually much harder to achieve and couple be considered a “multiple feature request” (e.g. fogging, a glTF-like transmission layer, etc.).
  • A further discussion on performance  – texture LODs and the associated drop-down in the uploader (which has nothing to do with mesh LODs), etc., – but for the general user, the most salient points are hopefully included under the 2026.03 viewer notes, above.
  • The end of the meeting comprised a theoretical discussion on the requirements to develop a new avatar system for use with SL.

Next Meeting

2026 week #11: SL CCUG meeting summary

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, March 12th, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

 

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 and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer  – Legacy search; WebRTC improvements; QoL improvements – 26.1.0.22641522367 – March 12 – NEW
  • Second Life Project Viewers:
    • Second Life Lua Editor Alpha viewer 26.1.0.21525310258, February 12.
    • Second Life Voice Moderation viewer 26.1.0.20139269477, December 12.
      • Introduces the ability to moderate spatial voice chat in regions configured to use webRTC voice.
    • Second Life One Click Install viewer 26.1.0.21295806042, January 26, 2026 – one-click viewer installation.

Viewer Notes

Viewer 2026.01

  • Promoted to default release ahead of the meeting – see above.

Viewer 2026.01.o1

  • The next viewer targeting promotion to default status.
  • Comprises the one-click installer / updater.
  • It is hoped promotion of this viewer is “weeks away” rather than “months”.

Viewer 2026.02

  • 2026.02 remains on track for the “Flat” UI and font updates + plus a possible refresh of the log-in splash screen.
  • It now also includes the WebRTC voice moderation capabilities (as seen in the project viewer) to help align viewer-side WebRTC updates more with the hoped-for server-side deployment.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2

Viewer 2026.03

  • Some changes on this – originally defined as the SLVP – Second Life Visual Polish viewer, the status has changed such that 2026.03 is liable to one of the following:
    • The SLUA viewer update, or
    • The Visual Polish viewer, including the long awaited SSR improvements. PBR specular for residents who are more familiar with the old Blinn-Phong work flow + HDR controls in EEP so residents can decide how bright or dark things should be, or
    • A new performance improvements viewer option.
  • It is possible that further water improvements might find their way to this SLVP viewer, and also that as some of the updates require sever-side changes, the promotion of SLVP might be subject to delay once available, to allow time for the server changes to be slotted into the simulator release schedule.
  • It is also possible some of the above might be combined into a single viewer release under the 2026.03 banner.
  • The potential for making monthly promotions to get all the current inflight viewers up to release status is also being discussed at the Lab. 

Viewer Performance Discussion

  • Better performance is obviously always a benefit to using SL, and currently there is an internal discussion at the Lab overtrying to make some further performance improvements ahead of any release of the SLVP viewer, to enable the latter to better leverage them (e.g. by “shaving off” some VRAM usage).
  • VRAM is particularly problematic for performance as many SL creates will try to crank the texture resolution for every single material slot to the maximum, whether it is visually beneficial to do so or not. The 2K white emissive texture is an example of this.
  •  Geenz Linden has been making changes to introduce “texture channels”. That is, to more intelligently stream specific maps  – diffuse, normal, emissive,, specular, etc., at different resolutions to more intelligently manage VRAM usage with little reduction by way of a scene’s visual fidelity, particularly in scenes with a lot of high resolution textures for every material / material slot.
  • It has been noted that for this to work, there must be a means for users to make adjustments to suit their visual needs. These might take the form of a texture quality drop-down in the viewer’s Graphics settings.
  • The texture discussion led to musings on how best to identify texture size / resolution, and the complexities involved (e.g. the asset system doesn’t know – or need to know the specific resolution of a texture, it doesn’t entirely make sense for the logical to determine a texture’s resolution and how to manage it o sit within the server, which leaves the viewer – which requires the texture to be downloaded anyway – and such controls can be ignored by specific viewers simply by not adopting the code, so proactively handling texture resolutions is complicated.
  • Other work on performance might see changes to the avatar render cost calculations because, ironically, these appear to impact performance.

General Discussions

  • SLua:
    • There is a “breaking change” coming to SLua “in the next couple of weeks” which is apparently not deemed worthy of a blog post, so notification will be via Discord and social media – because “communications”.
    • It will require every current SLua script to be recompiled and restarted.
  • A discussion on using GPU texture compression to help with performance – something that would require work on LL’s part, but not out of the question for consideration.
  • HDRI support for environments – again, not out of the question. The major question is how are they to be encoded:
    • Creating a new asset type specifically for them is not seen as “super practical”.
    • While the JPEG2000 specification supports HDRI, it is “probably not the most effective application for SL’s specific use for HDRIs.
    • There needs to be a means of encoding them that is GPU memory friendly, as HDRIs are memory heavy (whilst HDRIs are already used in the rendering pipeline,  LL uses them as sparingly as possible for this reason.
    • EEP would also require updates to fully support them.
    • None of the above is seen as particularly impossible to overcome, it does require further discussion among all the relevant stakeholders0.
  • It is hoped that tweaks to the EEP ambient sky settings will help make environments using PBR to “pop” more and will help improve the current Mainland ambient lighting issues.
  • A number of general discussions on WIBNis (“wouldn’t it be nice if….”), none of which are currently in development..

Next Meeting