
The following notes were taken from:
|
Table of Contents |
Note that this is not intended as a full transcript of either meeting, but rather a summary of those topics discussed in terms of project LL have in progress feedback given to ideas / questions comments.
Meetings 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.
- For both meetings: 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 Viewers Status
- Release viewer: version 7.1.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
- Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
- WebRTC Voice RC, version 7.1.9.10084807842, July 26.
- Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9981869229, July 22.
- Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
- Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
Upcoming Releases
- The WebRTC RC viewer remains first in line for promotion to de facto release status.
- It will most likely be followed by the Atlasaurus RC, although this currently has a higher then expected crash rate at present.
CCUG – Graphics / glTF
PBR Terrain Painting – Cosmic Linden
Summary
- An in-development project. Current intent:
- Provide a means to support the four PBR materials currently used in SL for “terrain painting”.
- Will allow materials to be defined in their X,Y co-ordinates within a region by using a paint map, rather than having them defined by elevation defined in a height map. This will allow where grass or rock or stones or dirt, etc., appear within the region. providing much more flexibility in how terrain appears / changes.
- Terrain painting will use the same permissions as terrain texturing (so if you have terraforming permissions, then tertian paining is possible; if you have the appropriate region permissions, you can define the PBR materials for the region.
- Other points of note:
- LL prefer to limit terrain painting to the four available slots at region revel, rather than allowing fully customisable swatches / slots at parcel level, as the latter presents “non-trivial issues” for terrain texture handling /loading.
- Terrain painting will require a new entity to be introduced. Exactly what form this will take is still being discussed internally; it is unlikely to be a new asset type.
- Much longer term options being considered for this capability might be to:
- Allow prims to act as part of the terrain, inheriting the materials of the terrain, whilst still allowing the prim to be sized and shaped.
- Perhaps allow the terrain within a region to be replaced by “something” else created externally to SL and then imported.
- Neither of these ideas are currently being pursued beyond possible ideas / options.
Status
- Cosmic has been carrying out some early internal testing on how terrain painting looks using the paint map and how it works in practice in terms of bandwidth and performance.
- The initial results of these tests is described as “promising”.
Punctual Lights and Transmission / IOR – Geenz Linden
- Punctual lights:
- This a glTF extension that has recently been folded into the main specification, defining the use of lighting sources (house light, table lamps, street lights, etc.), including the potential for shadow casting from such light sources.
- Geenz is working to implement punctual lights, but they will be tied to the node hierarchy for glTF scene imports.
- The first iteration of the work will not include shadow casting, and will focus on point and spot lighting as defined in the glTF specification.
- Transmission and Index of Reflection (IOR) will provide:
- Both refraction and “blurry” refraction suitable for things like frosted glass surfaces.
- Dispersion, allowing chromatic aberration, allowing the RGB channels to “separate out” based on a certain factor.
- Volume, allowing an object surface to be tinted at different surface thicknesses .
- Geenz believes there is one significant bug left to resolve, relating to the scaling of the effect.
General Discussion
- A request has been made for a “glTF FAQ” to be put together, based on the Lua FAQ that has been made available, and which is seen as extremely useful.
- The request was specifically made for a glTF Scene Import FAQ, as this capability has the potential to have the biggest impact on SL in terms of content creation, as glTF scenes have the potential to cover multiple areas (e.g. object import, sounds, animations, node hierarchies, lighting, etc.).
- However, such a FAQ / series of FAQs could allow creators to more fully understand what is being proposed / has been considered / might be excluded, etc., thus offering them the opportunity to make more informed suggestions / requests to hep move glTF projects forward.
- This was seen by LL as something which should “definitely” be on the road map, but may take time to surface as much of what might be covered is still only being discussed / prototyped internally to see what is feasible, and so subject to change.
- In the interim a set of questions posted to the Content Creation discord channel was suggested as a means to get the ball rolling in providing ideas as to what a FAQ / FAQs might address.
- PBR individual material UUIDs accessible via llGetPrimitiveParams on non-full permission objects has been raised and is subject to being tracked and investigated.
TPVD – WebRTC Voice Update
Summary
- Replacing the use of Vivox for Voice in SL with WebRTC communications protocol (RTC=”real-time communication”).
- Benefits:
- Move to a “defacto standard” for voice services, with features such as automatic echo cancellation, better noise cancellation and automatic gain control, etc., and offers much improved audio sampling rates for improved audio quality
- WebRTC can be supplied within the viewer using a library and wrapper, ending the need for any additional third-party plug-in for Voice like SLvoice.exe, as supplied by Vivox.
- Opens the door to adding new features and capabilities to SL Voice, some of which have been long-requested.
- Care is being taking to address potential security issues (e.g. preventing eavesdropping, exposing users’ IP address (by using an internal proxy server), etc.).
- Feature requests for WebRTC made via the WebRTC board on the SL Feedback Portal are being evaluated and some are being actioned, together with issues being investigated.
- LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers.
Status
- The plan remains to try to promote the WebRTC RC viewer to release status ASAP, with the aim of having as many TPVs adopt it as possible prior to the back-end switch being thrown to move all simulators to only using WebRTC.
- The work is at a point where there is just a “handful” of issues, with fixes most of them actually being tested by QA. Some of these are transition issues related to moving between regions using Vivox and regions using WebRTC (or vice-versa).
- LL hope to release the back-end support for WebRTC peer-to-peer and Group calls, which should remove some of the limitations with testing WebRTC.
- Roxie Linden also noted some third party viewer users using Linux viewers have been having device/audio subsystem issues with WebRTC, and has offered to provide some assistance with these problems – with the caveat that she’ll need TPV developers to diagnose their issues and on the fixes.
In Brief (Both Meetings)
Combat 2.0
- The updates to the SL Combat system (SLCS), otherwise known as “Combat 2.0” are now in a deployment phase.
- After to prior attempt, the updates are now deployed to the BlueSteel simulator RC channel.
- Providing no further issues are found, the updates (as part of the Summer Fun simulator update) will be deployed to he remaining RC channels on Wednesday, August 7th; and then to the SLS Main channel on on Tuesday August 13th.
- In the meantime, those involved in Combat in SL and who wish to have their regions able to leverage the new capabilities can file a support ticket to have their region moved to a channel supporting Combat 2.0.
- With Combat 2.0 becoming available, Linden Lab has announced the Combat 2.0 Promotion Partnership Programme has been launched.
- The intention behind the Promotion Partnership Programme this is to give those actively involved in combat activities in Second Life the “opportunity to help us spread the word across the grid about Combat 2.0 in Second Life”.
- In particular, this will see some of the LL combat regions (e.g. Concord and Lexington) a facelift and use them to showcase Combat 2.0, with participants in the Programme asked to donate free-to-use combat items for use in the regions.
- In addition, participants will have their regions / communities included in a Combat section of the Destination Guide. There may be other benefits for participants as well.
- Those interested can sign-up via this Google form.
2K Texture and PBR Materials Support and Bakes on Mesh
- This is now an active project. However (and as previously indicated in these summaries), the work is more than just updating the Bake Service.
- In particular, it will mean bringing the code for the appearance service back into the viewer codebase. However, this will will yield two benefits:
- It will make the code is easier to update in future.
- Could potentially make it easier possible to add PBR materials support to Bakes on Mesh in the future (although some design work on what compositing PBR materials layers means).
- It was noted that the priority is to get “PBR BOM” in place prior to any release of glTF scene import.
Additional Items
- It has been reported that some auto-replies to Canny tickets do not always include any linked ticket.
- For example: Beta grid: water “sandboxes” was raised in Canny, but closed as already tracked, but fails to publicly list the tracked issue – in this case Github archive issue #9258 (originally Jira BUG-231883).
- It was broadly agreed that it would be useful for these replied to at least reference archived / accepted tickets from Jira – even if the tickets themselves cannot be views (e.g. as they relate to a security issue).
- Viewer release process:
- Brad Linden has been working on the new viewer Gitflow process and release branches.
- As previously noted, the focus is on moving away from having multiple release candidate cohorts based on different codebases in flight, as has been the case since around 2012, and instead focus on a core Develop branch of the viewer, from which RC versions can be built – so each RC viewer is essentially a “snapshot” of the Develop Branch code, rather than being an entirely separate viewer to anything else in flight.
- It is hoped the formal switch-over to this approach will commence with the Atlasaurus RC.
- The Lab’s Linux viewer work currently resides within the Maintenance B RC viewer branch.
- This is awaiting merging into the the main Development branch, and has encountered some issues with merging.
- Once the merge has happened, and remaining issues dealt with, then packaging Linux builds for the viewer “could start happening some time after that” (so some time after the Atlasaurus viewer release).
- The TPVD meeting included a general discussion on the future of LODs (Level of Detail):
- As a part of glTF adoption, Linden Lab is looking at adopting the Microsoft LOD extension for glTF 2.0, one outcome of which could be the removal of the RenderVolumeLODFactor (RVLF) setting from the viewer’s Debugs.
- It was noted that as manually setting RVLF has long been the means by which creators can hide issues with LODs (i.e. raise LOD and force the viewer into rendering the higher LOD instances of an object), removing the debug is going to the lead to a lot of poorly-made content being exposed, potentially leading to a lot of upset.
- However, it was also noted a more standardised approach to LOD instances of objects is required, and adoption of the Microsoft glTF extension is the means to achieve this, allowing content creators to better leverage LOD generation within tools like Blender.
Next Meetings
- CCUG: 13:00 SLT, Thursday, August 15th, 2024, at the Hippotropolis Campsite.
- TPVD: 13;00 SLT, Friday, August 30th, 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.