Tag: Content Creation 2023

2023 week #49: SL CCUG meeting summary: PBR status; Game Controllers

Posted on by Inara Pey
The Middle of Nowhere, November 2023 – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, December 7th, 2023.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden, in accordance with the dates and times given in the the SL Public Calendar, which also includes the location for the meetings.
    • Conducted in a mix of voice and text.
    • Open to all with an interest in content creation.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript.

Official Viewers Status

The Maintenance X RC viewer (usability improvements) updated to version 7.1.1.7088410646, on December 7.The rest of the official viewer stand as:

  • Release viewer: version 7.0.1.6894459864, the glTF / PBR Materials viewer, issued November 17, promoted November 28.
  • Release channel cohorts:
    • Maintenance-W RC viewer, version 7.1.1.7088402585, December 5 – bug and crash fixes.
    • Maintenance V(ersatility) RC viewer, version 7.1.1.7039128750, December 1 – displaying user-customized keybindings in chat.
    • Maintenance Y, version 6.6.17.6935642049, issued November 21 – My Outfits folder improvements; ability to remove entries from landmark history.
    • Emoji RC viewer, version 6.6.15.581551, August 31.
  • Project viewers:

General Notes

  • It is unclear which viewer is liable to be promoted (if any) to end-of-year de facto release status. Currently both the Maintenance V RC and the Emoji viewer are seen as possible candidates – although the latter has yet to be updated to Github Actions / merged with the PBR release viewer code base.

PBR Materials

  • Maintenance work on the initial release is well in progress.
  • This work includes updates to environmental haze, per my previous CCUG summary (e.g. making local lights and glow be subject to haze  / fog such that those further away appear dimmer / are blotted by the haze / fog, rather than poking through it; fixing BUG-234235 “[PBR] alpha blend on water is acting a bit like invisiprim” + correcting the fact that Linden Water is currently drawn twice in a rendered scene, when visible).
  • There have been some reported permissions issues with PBR / glTF, and these are being worked on.
  • A fix (courtesy of Ansariel Hiller) for BUG-234706 “[GLTF] [PBR] Performance unstable / massive performance loss compared to default release” has also been pulled into the maintenance update.
  • BUG-234728 “[PBR] Masked alpha gradient textures change with viewing angle” has been accepted by the Lab, but is proving difficult to consistently reproduce, slowing the investigation.

PBR Terrain Work

Materials applied to Second Life terrains. Credit: Linden Lab
  • Per past meeting notes, Cosmic Linden is prototyping the application of PBR materials on terrain (see this blog post for more).
  • Important notes with this work:
    • It is not terrain painting. It is the application of PBR materials – terrain painting is described as “something that’s on the radar” at LL.
    • The work does not include support for displacement maps.
    • The work is currently only viewer-side, with no corresponding server-side support, the idea here being to prototype what might be achieved and testing approaches / results.

Current Status

  • With PBR Materials now having shipped, cosmic Linden is turning her attention back to this work.
  • The first order of business she sees is to get a project viewer supporting PBR terrain made available for users to try.
  • Cosmic is also working on refining the PBR swatch / picker in the viewer’s UI.
  • There is an issue with how PBR normal appear when used within terrain which needed to be corrected.

Game Controller Support

Project Summary

  • The work is being led by Leviathan Linden, to provide game controller support at the scripting level (e.g. for handling things like vehicle movement, scripted objects etc.).
  • It is not currently related to matters of avatar locomotion / camera movement, which is covered by the Preferences → Move and View → Other Devices (/Joystick) options, and considered out-of-scope for the work at present.
  • Official documentation on the server-side support can be found on the Game Control page of the SL Wiki. Note this is based on the Simple Direct Media Layer (SDL) library for the button naming conventions, with some additional buttons added by the Lab to provide support for up to 32 buttons, rather than the 21 offered by SDL.
  • At the time of writing, the Gingerbread maintenance branch with the prototype Game_Control feature is available on Aditi (the Beta grid) on the following regions: Aegis Island, Blake Sea – Turnbuckle, Cloud Sandbox 1, Cloud Sandbox 2, Firestorm Aerodrome, Gothlauth, Hona Lee Puff, Jigglypuff, Laefeon, LR151, LR 152, Mauve, Moonberry, Morris, SG2, and Smithereens.
  • The current methodology for the Game_Control event is for whatever button is pressed on a games controller, an overall state is sent to the viewer, comprising:
    • The number of buttons available, presented in bitmask form to any controlling script.
    • A range of six axes in the range -1 to 1, given as floats), which the event then presents to an LSL script, which can then parse them.
    • The Game_Event function then passes this information to a controlling LSL script for parsing.
    • Notes:
      • The above points should not be considered tablets-of-stone, Leviathan is open to taking feedback from vehicle builders, etc., – such as including things like mouse input within the axes data.
      • Event_Control does not include a means for handling force feedback in its current form, but something like this might be added in a future iteration.
  • Note that discussions on the project are also held within the Simulator User Group meetings (summaries here).

Current Status

  • Consideration is being given to the fact that when the data on a games controller is sent to a script, it will have to be sent in sequence – so does this mean the inputs received by the Game_Control event should be given more meaningful names prior to being parsed by an LSL script?
  • Also, what does the LSL script need to know? Is it what button is being pressed or what action is being performed? Three lines of thought emerged in discussions:
    • One for keeping button options as “standardised” as possible, rather than allowing actions to be arbitrarily mapping to buttons (with the result that every creator using the capability will do so differently), possibly backed-up with a “best practices guide”. A concern with this approach was that it would require a degree of proscription (“button x can do  this, this or this” – which do you require?”), which might not meet all use-cases.
    • Allowing for a more arbitrary button / action assignment, sending the button names as bindable options to the viewer, and providing users with a UI element (accessed via an on-screen button) so they can freely map buttons to vehicle / object actions based on personal preference.
    • Something of a half-way house: providing a “standard” set of buttons that can be used by a controller, then providing a scripted means  / UI option to map vehicle / object actions to that set of buttons.
  • A further suggestion was made to have a core “glossary” of typical game controller inputs / actions (e.g. up, down, strafe left, strafe right, etc), but have the ability for script to identify the actions they require in controlling a vehicle / object, and allow the creator (/user, if a UI options for re-binding is provided), to map additional options to buttons /re-map preferences.
  • Discussions around these ideas set to continue.

In Brief

  • Not purely Content Creation related, but a Jira (BUG-234653 – “Feature Request: Invisible / Utility Login”) has been submitted requesting the ability for users to be able to completely hide their on-line status prior to logging-in. This is being considered for implementation.
  • The question of the status of the Puppetry Project was again raised. In short:
    • The overall project remains on “hold” for a variety of reasons (including both complexities and also limitations within SL which require separate addressing).
    • Some of the work originally sitting within the Puppetry banner – such as animation import – is either being considered as a separate project, or being folded into other work – such as glTF scene import (which encompasses items such a node hierarchies which are required for IK systems etc.).
    • This lead to a broader discussion of the potential with glTF (perhaps best left until the project relating to scene import becomes more public) and a history of the Puppetry Project, mush of which is summarised in my Puppetry Project meeting summaries).

Next Meeting

† 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.

2023 week #46: SL CCUG meeting summary: PBR status & current release plan

Posted on by Inara Pey
Le’eaf Forest Retreat, September 2023 – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, November 16th, 2023.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden, in accordance with the dates and times given in the the SL Public Calendar, which also includes the location for the meetings.
    • Conducted in a mix of voice and text..
    • Open to all with an interest in content creation.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript.

Official Viewers Status

No updates for the latter part of the week, with the current crop of official viewers being:

  • Github Actions (GHA) RC viewer, version 6.6.16.6566955269, issued October 20 (with major CEF update and number version numbering) and promoted on October 25.
  • Release channel cohorts:
    • Maintenance X RC, version 6855926535, issued November 14 – usability improvements.
    • Maintenance Y, version 6.6.17.6855930358, issued November 14 – My Outfits folder improvements; ability to remove entries from landmark history.
    • glTF / PBR Materials viewer, version 7.0.1.6750600769, November 11.
    • Maintenance-W RC viewer, version 6.6.17.6709258523, November 9.
    • Maintenance V(ersatility) RC viewer, version 6.6.16.582201, October 16.
    • Emoji RC viewer, version 6.6.15.581551, August 31.
  • Project viewers:

General Notes

  • The PBR viewer now appears to be the no 1 on the runway for promotion to release status – see the notes below for more.
  • The next viewer LL is hoping to promote after PBR is the Emoji RC viewer.
  • As there are now four Maintenance RC viewer in the pipeline (V, W, X, and Y), it is likely some of them will be merged together to reduce the load on the release schedule.

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal for glTF as a whole is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

Grid-Wide Deployment and Viewer Release

  • Following a meeting this week, the current plan from the Lab is to deploy PBR Materials grid-wide on the simhosts during the first week after US Thanksgiving (so week commencing Monday, November 27th, 2023).
  • Currently, all RC simhost have been updated to the PBR simulator code which leaves only the SLS Main channel to go.
  • The plan is also to promote the PBR RC viewer to de facto release status that same week.
  • Note that these plans are subject to late-breaking issues or other requirements not getting in the way of things.

Recent Work

  • Fixes are progress for what are seen as to remaining notable issues:
    • One to correct the issue with normal maps uploaded via the glTF uploader always coming out square post-upload  and with lossy compression.
    • One to correct the issue of not being able to revert an Alpha mode from blend or mask to opaque without having to save the material back to inventory after making the change in order for it to apply properly.
  • There are some additional bugs within the system, some of which do have fixes in the works, but these aren’t seen as having significant impact, and will be subject to release with the first maintenance update to PBR Materials.
  • That said, there some issues which have been identified, but will not be addressed until the first PBR maintenance viewer is issued. These include:
    • A “slim minority” of users with very, very large inventories and Friends lists may find some objects in a scene do not render when logging-in. Currently, the steps for correcting this are to a) re-log, and if that fails to resolve the problem, b) clear cache.
    • Some users on Macbooks and / or Apple Silicon systems may experience poor performance on the PBR viewer.
  • For those interested – this is the list of currently open issues for PBR.

General PBR Discussion

  • BUG-234235 “[PBR] alpha blend on water is acting a bit like invisiprim” – this is being worked on, and is seen as somewhat related to another change under consideration: environmental haze.
    • Currently, local lights are not affected by environmental haze. Runitai Linden is working on a change that will make local lights responsive to haze (e.g. if you are in a foggy environment, lights at an increasing distance from your camera position will appear fainter and fainter due to the influence of the fog).
    • This work will likely be surfaced in the first PBR viewer maintenance release.
    • The reason this is related to BUG-234235 is that it will also require an adjustment to water haze as well, and this should resolve the issue reported in the bug (haze will essentially get its own render pass, with a single shader being used for both atmospheric and water haze, rather than them requiring separate render passes).
  • Future work on glTF will allow for more greater control of lighting sources, such as lamps, etc., and provide for luminosity to be defined in terms such as lumens. However, this work will depend on glTF scene import, which will be worked on in the next tranche of work, together with HDRI import / export (which is not as yet on the glTF implementation roadmap).
  • A Materials folder is to be added to the system library and available through the Library section of inventory.

In Brief

  • A Feature Request has been filed to allow system-generated sounds to be overridden by Experiences to provide more immersive sounds (e.g. on entering a door and being teleported, the sound heard might be the creaking of the door opening, rather than the ding-sing-whoosh of the default teleport sound – which can only currently be disabled on a per viewer basis by the user). See (and Watch) BUG-234682 “Override UI sounds within the scope of experience keys” for more.

Next Meeting

† 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.

2023 week #44: SL CCUG meeting summary: PBR

Posted on by Inara Pey
Shades of Autumn, September 2023 – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, November 2nd, 2023.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden, in accordance with the dates and times given in the the SL Public Calendar, which also includes the location for the meetings.
    • Conducted in a mix of voice and text..
    • Open to all with an interest in content creation.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript.

Viewer Updates

The glTF / PBR RC viewer updated to version 7.0.1.6658224456 on November 2nd, bringing it into parity with the current release viewer and built via Github Actions.

The rest of the official viewers in the pipeline remain as:

  • Release viewer, version 6.6.16.6566955269, promoted October 25 (formerly the GHA RC viewer).
  • Release channel cohorts:
  • Project viewers:

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal for glTF as a whole is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

Status Update

Server-side deployment

  • The simulator code supporting PBR Materials was deployed to the BlueSteel and LeTigre simulator RC channels, making it “live” across some 3,000 simulators.
  • This has seen a number of additional bug reports filed, but currently nothing which has been seen as constituting a major blocker to further deployment.
  • At the time of the meeting, it was hoped that the PBR code could be deployed to all of the RC channels simhosts on Wednesday, November 8th, 2023. This is seen as the best way to test for additional cases of non-PBR content suffering breakage which may have thus far slipped through the net.
  • If things continue as planned, the aim is to have PBR support on the simhosts fully deployed “by Thanksgiving”.

Viewer Updates

  • The PBR viewer has been updated to build via the new Github Action process, marking it as up-to-date with the current release viewer (version 6.6.16.6566955269, October 25th, at the time of writing).
  • It is possible that one of the Maintenance RC viewers may be pushed to de facto release ahead of the PBR viewer in order to correct a statistics reporting issue.
    • At the time of the meeting, a final decision on this has yet to be made. However, if this proves to be the case, and if LL decide to maintain the 2-week minimum period between viewer promotions, this could mean the PBR viewer might not be released until after the simulator code is grid-wide.
  • The PBR viewer release is also dependent upon whether or not any remaining reported / open issues are considered serious enough to require fixing ahead of any promotion.
    • Currently, there is one blocker which is under investigation: if the PBR viewer is used, and then a swap is made to using a non-PBR viewer, then it is possible some objects may not show-up on logging in, and will never show up until object cache is cleared.
  • For those interested – this is the list of currently open issues for PBR.
  • The current PBR RC viewer replaces the term “Materials” in the Build / Edit floater Texture tab with Blinn-Phong. Whilst this is the technically correct term for the current implementation of materials support in SL and was seen as a means of differentiating between the current materials support and PBR, the switch to the term has been raised as potentially confusing to users not deeply versed in graphics  / rendering but who are familiar with using and applying current materials maps. As such, the use of an alternate term has been requested.

Tone Mapping and Full Bright Issues

  • A recently-reported issue is with tone mapping not applying correctly to Full Bright objects, resulting in darker colours / blacks being crushed and white highlights being blown out.
  • This has been highlighted in BUG-234506 and this forum thread, where it is reported as an issue facing content creators trying to produce advertising images for their products for use on in-world vendor boards, etc. However, the issue has the potential to affect SL photography in general, where snapshots are taken to be uploaded for display in-world as textures (e.g. as art, “family” snapshots, etc.).
  • The problem is the result of tone mapping being applied to such textures twice:
    • The first time as a result of tone mapping being enabled (and captured) when the snapshot is taken.
    • The second time as a result of the uploaded texture being rendered with tone mapping active in the viewer.
  • This is seen as “expected behaviour”, and the lighting model will not be changed for dealing with Full Bright (e.g. by making it a straight pixel pass-through).
  • This means the current work-around is to use the No Post Build menu option, thus:
    • Edit the object using Full Bright to open the Build  / Edit floater.
    • Go to menu bar → Build → Options and enable No Post – this will try off tone mapping and exposure, and will remain active as long as the Build / Edit floater is open.
    • Take the snapshot.
    • Close the Build / Edit floater.
  • As this workaround is seen as heavy-handed (and also not helpful to those taking photos who may need to disable tone mapping at times, but who are unfamiliar with the Build / Edit floater and Build menu), it has been requested to incorporate a toggle checkbox for No Post directly into the snapshot floater.
  • Runitai Linden has also proposed the addition of a HDRI export to the 360º Snapshot floater.

General Notes

  • The viewer performance issue on older versions of MacOS has been addressed, but it is not clear if the fixes work with Apple silicon SoC, pending further tests.
  • It is acknowledged that there will be a learning curve among all users where PBR is concerned due to the level of changes involved in the lighting model (e.g. objects with a specular map – even indoors – having a blue sheen to them, due to reflecting the ambient environment; an issue which can be fixed through the correct placement of reflection probes indoors).
    • Efforts are being made to ensure cases like this are being covered in the PBR documentation being put together by LL.
  • It was re-iterated that there will be follow-on glTF work following PBR materials (see the general roadmap, below), with it being noted that some would allow the implementation of hierarchical structures which could allow for options such as arbitrary pivot points in meshes, whilst adoption of the glTF specifications for animations could result expanded animation capabilities, etc.
  • A number of requests for new features (e.g. the ability to be able to simulate Linden water on surfaces via materials). These were noted as all having pre-requisites and potential limiters on them, so while they are not refused, mention of them here will be held over until LL have determined if and how they (and their pre-requisites) might fit into the overall roadmap.
  • Whilst concerns remain about Apple simply ceasing to support OpenGL, thus driving a potential need to switch the viewer away from using OpenGL to using Vulkan / MoltenVK, this is not seen as an immediate priority compared to moving ahead with further glTF work. Which is not to say LL won’t move the viewer to alternate graphics API as the glTF work progresses beyond scene import work (see below).

Likely Roadmap for glTF

  • Complete and deploy the current PBR materials work.
  • Resume work on real-time mirrors and terrain support for glTF materials. In brief, these comprise:
    • Mirrors: providing the means to have mirrors within scenes to reflect their immediate surroundings. These will leverage a “hero” reflection probe concept (512×512 resolution), with one such probe per scene being active for any given avatar, based on the avatar / camera distance from the mirror.
    • Terrain support: providing the means to apply glTF materials to terrain as a viewer-side effect to improve the appearance of the SL terrain. Note that this is not PBR terrain painting.
  • Alongside the mirrors / terrain work will be a period of PBR Materials maintenance work to fix reported bugs / those issues still open at the time of release.
  • Also start to develop a prototype for glTF scene import – with no overall time frame for the latter being indicated.
  • Once there is an initial prototype for glTF scene import, he Lab will proceed in much the same was as for PBR materials: an iterative development cycle which fully engages the user community / content creators.

Next Meeting

† 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.

2023 week #42: SL CCUG meeting summary: PBR

Posted on by Inara Pey
Meditation Mountain, August 2023 – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, October 19th, 2023. Unfortunately, my recording software glitched (I tend to be afk when the meeting is in progress), so only the first 18 minutes of the meeting were actually recorded to disk, as represented here.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden.
    • Conducted in a mix of voice and text.
    • Held at 13:00 SLT on their respective days.
    • Are subject to the schedule set within the SL Public Calendar, which includes the location for the meetings.
    • Open to all with an interest in content creation.
  • The notes herein are drawn from a mix of my own chat log and audio recording of the meeting, and are not intended to be a full transcript.

Viewer Updates

Friday, October 20th saw the release of the Github Actions (GHA) viewer, version 6.6.16.6566955269. This is the first official viewer to be built via Github Actions rather than TeamCity.

  • Outside of a major version update to CEF (Chromium Embedded Framework) which includes several performance updates and security fixes, this viewer contains no user-observable differences to the current release viewer…
  • .. Other than having even more crunchy digits in the version number for us all to chew on.
  • Release viewer, version 6.6.15.581961, promoted October 2 (formerly the Inventory Extensions Viewer).
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Project viewers:

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal for glTF as a whole is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

General Status

  • The back-end communications / bandwidth fix has been deployed to all PBR test regions, per this blog post from the Lab.
  • The push is now on to get glTF PBR to a point where the simulator side code can be more broadly deployed to an RC channel. This may result in some regressions being noted, but this will be subject to point releases to correct, should they occur.
  • On the viewer side, there will be a focus on getting the Mac version up to match the performance seen with the windows PBR RC viewer.
  • Because of the above, and as the viewer moves forward, the recommendation for those testing PBR is to read the available documentation – particularly the viewer release notes.
  • The general word to those testing PBR is that if they do come across anything that could be a major issue, to be sure to Jira it ASAP and in as much details as possible, and if active in the content Creation Discord Channel (which, for those who ask, I have been specifically asked by LL not to provide links to in these pages), to speak up.
  • This focus on trying to get PBR Materials out means that the work on real-time mirrors and on glTF terrain has been put on a temporary hold to maximise the resources available for Materials work.

Mirrors

  • Mirrors are a part of the glTF / PBR materials project, but something of a separate tranche of work.
  • The idea is provide the means to have via high resolution reflections (i.e. mirrors) within a scene.
  • Initially only one active mirror surface per scene will be active for any viewer.
  • The process will use the PBR reflection probes mechanism, combined with a automated “Hero Probe” mechanism which with generate high resolution (512×512) “reflections” for the mirror.
  • The system will operate on the basis of avatar / camera proximity to a mirror surface triggering the closest reflection probe to become a “Hero Probe” for that avatar / camera. This means that if there are multiple mirrors placed within an environment, only the one closest to a given avatar / camera will be active and display the “reflections” generated by the reflection probe.
  • Depending on testing and performance, the number of mirrors might be expanded to two – one for mirror surfaces and one for Linden Water to generate high resolution water reflections where appropriate.

Status

  • As noted above, work temporarily on hold to focus resources on PBR Materials.

In Brief

  • There was a general discussion on how best to change an preserve overrides on materials when allowing for the likes of colour changes when making changes via LSL (and how best to batch similar changes). This was seen as something that could be better handled outside of LSL directly (thus avoiding multiple calls to set / preserve specific changes), but is something to be looked at after the initial release.
  • At this point the recording flatlined 😦 .

Next Meeting

† 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.

2023 week #40: SL CCUG meeting summary: PBR and combat / gaming

Posted on by Inara Pey
Sonder, August 2023 – blog post

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, October 6th, 2023.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden.
    • Conducted in a mix of voice and text.
    • Held at 13:00 SLT on their respective days.
    • Are subject to the schedule set within the SL Public Calendar, which includes the location for the meetings.
    • Open to all with an interest in content creation.
  • The notes herein are drawn from a mix of my own chat log and audio recording of the meeting, and are not intended to be a full transcript.

Viewer Updates

The Maintenance W RC viewer updated to version 6.6.16.582075 on October 5th. The rest of the current official viewers in the pipelines remain as:

  • Release viewer, version 6.6.15.581961, promoted October 2 (formerly the Inventory Extensions Viewer).
  • Release channel cohorts:
    • glTF / PBR Materials viewer, version 7.0.0.581684, September 8.
    • Emoji RC viewer, version 6.6.15.581551, August 31.
    • Maintenance V(ersatility) RC viewer, version 6.6.15.581557, August 30.
  • Project viewers:

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal for glTF as a whole is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

General Status

  • There has been a reported issue with animated textures on glTF materials which is under investigation.
  • Work is focused on clearing the backlog of niggling issues. Part of this is a glTF update which clarifies glare on transparent surfaces (e.g. things like glass and the degree of glare / sheen on it) which is helping for properly define this property (index of refraction), rather than leaving it up to artistic licence.

Mirrors

  • Mirrors are a part of the glTF / PBR materials project, but something of a separate tranche of work.
  • The idea is provide the means to have via high resolution reflections (i.e. mirrors) within a scene.
  • Initially only one active mirror surface per scene will be active for any viewer.
  • The process will use the PBR reflection probes mechanism, combined with a automated “Hero Probe” mechanism which with generate high resolution (512×512) “reflections” for the mirror.
  • The system will operate on the basis of avatar / camera proximity to a mirror surface triggering the closest reflection probe to become a “Hero Probe” for that avatar / camera. This means that if there are multiple mirrors placed within an environment, only the one closest to a given avatar / camera will be active and display the “reflections” generated by the reflection probe.
  • Depending on testing and performance, the number of mirrors might be expanded to two – one for mirror surfaces and one for Linden Water to generate high resolution water reflections where appropriate.

Status

  • Geenz Linden is working on performance improvements within the viewer. There is a target than an active real-time mirror should not exceed cutting a viewer’s frame rate by more than 50% at the highest impact.
  • Culling has been updated so that objects that are physically behind a mirror are no longer reflected by the mirror.
  • Shader work is in progress to get mirror reflections generally looking better visually.

Combat and Gameplay

  • Rider Linden confirmed he is adding a new function and event to llRezObject per the discussion in this forum thread about features for combat gameplay.
  • He also referenced his idea for moving Second Life damage from being a function of a script o being a function of the object, per his comments at the Simulator User Group meeting, and if possible this will include “negative damage” (or health recovery, if you prefer!).
  • A request was made to have a means to cap or better manage damage in some way, in order to prevent scenarios where it is possible to have a single bullet strike a object on which (say) five avatars are seated and have them all be killed (100% damage each), wherein in reality the bullet would only kill one and (maybe) wound another (so instead of all of them getting 100% damage, it is capped to each of them only getting X%). This request grew out of feature request BUG-231985, “Incoming LL Damage Cap”.

In Brief

  • BUG-234493 “Add an “until shortcut key released” option to gestures so we can do properly user-mappable keys” has been raised as a means of potentially making gestures more versatile, particularly in gameplay / combat, but also other areas, such as vehicle control options (e.g. creating a gesture to raise / lower the forks on a forklift truck and have the creator free to bind that to whatever keys / controller button(s) they like), etc.
  • A wide-raging discussion on the ability to create large-scale games in Second Life to attract a new audience, running from the technicalities involved and the need for more integrated toolsets (e.g. viewer-side scripting for HUD creation; and updated physics engine) through the ideas for a type of Second Life Endowment for the Arts (SLEA) but focused on content creation specifically targeted at encouraging people in to SL, to various ideas for new specialist simulator / region types, such as on demand regions and “game / event / entertainment” region types that can be instanced on the basis of demand.
    • The majority of this discussion was among users, the Lindens at the meeting not being in a position to comment on policy or revenue matters.

Next Meeting

† 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.

2023 week #38: SL CCUG meeting summary: PBR and Puppetry

Posted on by Inara Pey
Moksha, July 2023 – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, September 21st, 2023.

  • 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 viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden.
    • Conducted in a mix of voice and text.
    • Held at 13:00 SLT on their respective days.
    • Are subject to the schedule set within the SL Public Calendar, which includes the location for the meetings.
    • Open to all with an interest in content creation.
  • The notes herein are drawn from a mix of my own chat log and audio recording of the meeting, and are not intended to be a full transcript.

Viewer Updates

The Inventory Extensions RC viewer updated to version on Thursday, September 21st. The rest of the current list of official viewers remains as:

  • Release viewer, version 6.6.14.581101, promoted August 23.
  • Release channel cohorts:
  • Project viewers:

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal for glTF as a whole is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

General Status

  • A update is coming up for deployment which should fix the protocol issue which has been a issue for the last several weeks (and noted in these summaries). Once deployed:
    • It will require those testing PBR materials to make sure they are using the latest RC viewer, or they will not be able to see edits to materials in-world.
    • Any scripts which have been created for handling PBR materials will need to be re-compiled as a result of a fix to prevent a conflict with one of the LSL constant values.
  • Concern has been raised about lighting using reflection probes, specifically where probes do not fit with a specific structure, leading to the indirect lighting from the probe “leaking through walls, floors, ceilings. This is seen as something to address once Vulkan support has been implemented, as this will open the door to the use of things like shadow atlases.

Ambient Lighting / Sky Brightness

  • A “big change” is being implemented in how environment ambience interacts with reflection probe ambience in an attempt to overcome the issue of “non-PBR” EEP enlivenments looking overly dark on the glTF/PBR viewer code.
  • Essentially, this will mean that environment ambience should be pretty much unchanged, unless one or more reflection probes with an ambience setting greater than zero but less than 1 are used within a scene.
    • If the probe’s ambience is set above 0 but below 1.0, then the probe’s ambience will be mixed with the environment (sky) ambience.
    • If the probe’s ambience is set to greater than 1.0, then the environment ambience will be completely ignored in favour of the probe’s indirect lighting ambience within the probe’s sphere of influence.
  • This should allow for a better balance, in that interior scenes can be set to utilise probe ambience, allowing for darkened room / cave, etc., interiors, without making the environment outside the influence of the probe(s) unduly dark / darker that it should be.
  • In addition, the tone mapping in the PBR renderer is being adjusted to prevent the viewer crushing colour values below 22 (i.e. towards their darker tones). This will better align the HDR colour mapping to SRGB without over-saturating blacks.
  • Longer-term, LL is considering a tone map / texture look-up people can plug-in to for sky settings, but for now the drive is to just drive home the idea that with PBR, tone mapping is now a part of the render pipe, and creators should not bake their preferred tone mapper into their content.

Mirrors

  • Mirrors are a part of the glTF / PBR materials project, but something of a separate tranche of work.
  • The idea is provide the means to have via high resolution reflections (i.e. mirrors) within a scene.
  • Initially only one active mirror surface per scene will be active for any viewer.
  • The process will use the PBR reflection probes mechanism, combined with a automated “Hero Probe” mechanism which with generate high resolution (512×512) “reflections” for the mirror.
  • The system will operate on the basis of avatar / camera proximity to a mirror surface triggering the closest reflection probe to become a “Hero Probe” for that avatar / camera. This means that if there are multiple mirrors placed within an environment, only the one closest to a given avatar / camera will be active and display the “reflections” generated by the reflection probe.
  • Depending on testing and performance, the number of mirrors might be expanded to two – one for mirror surfaces and one for Linden Water to generate high resolution water reflections where appropriate.

Status

  • An issue with the mirror code eating up all available VRAM has been addressed.
  • A viewer build is being queued-up in preparation to be made available via the Content Creators Discord channel.
  • Remaining work is seen as ensuring there is only one placement mode for Hero probes for mirrors, which should work on most objects and on ensuring culling works correctly (e.g. ensuring nothing behind the mirror surface gets rendered ad a reflection in the mirror.
  • There may also be some data modelling changes and shader tweaks along the way.

Puppetry Project

Summary

  • Previously referred to as “avatar expressiveness”, Puppetry is intended to provide a means by which avatars can mimic physical world actions by their owners (e.g. head, hand, arm movements) through tools such as a webcam and using technologies like inverse kinematics (IK) and the  LLSD Event API Plug-in (LEAP) system.
    • Note that facial expressions and finger movements are not currently enabled.
    • Most movement is in the 2D plain (e.g., hand movements from side-to-side but not forward / back), due to limitations with things like depth of field tracking through a webcam, which has yet to be addressed.
  • The back-end support for the capability is only available on Aditi (the Beta grid) and within the following regions: Bunraku, Marionette, and Castelet.
  • Puppetry requires the use of a dedicated viewer, the Project Puppetry viewer, available through the official Second Life Alternate Viewers page.

Status

  • This project grew in scope following initial inception, with various additional elements of work / projects being identified through Puppetry User Group meetings. As a result, meetings were suspended on July 13th, 2023, and have remained dormant since.
  • Currently, work related to scripted means of puppetry is blocked pending the IK work moving forward, and given that the IK work had expanded through the early part of the Puppetry work to become its own sub-project, both it and the scripted element of Puppetry have been placed on the back burner.
  • A further consideration with Puppetry is that “glTF phase two” will likely implement a node hierarchy, which will have significant implications for animations and puppetry. As such, putting the core of the work on hold for the time being is seen as sensible. However, that the work is on hold should not be taken to mean Puppetry has been abandoned.
  • Work is progressing on another spin-off piece of work: broadening SL’s animation import capabilities. As of July 2023, this work was leaning towards using Assimp (github: https://github.com/assimp/assimp), which supports some 30-40 animation formats (including the likes of .FBX and glTF), converting them to its own format for ease of import to multiple platforms, potentially including SL. However, no-one engaged in that work was available at the meeting to give an update on overall progress and current status.

In Brief

  • Physics engine: the Havoc physics engine for SL has not been updated since 2012. There “is an awareness” within LL that work needs to be put into making the simulator’s physics system more up-to-date, however, exactly what path this may take (e.g. updating Havoc or switching to a new engine or simply exposing more of what the physics engine can do) has not as yet been determined.
  • LL has noted the Unity situation regarding it new Install Policy due to be introduced from January 1st, 2024, given the SL Mobile application is built on the Unity Engine. Announced on Tuesday, September 19th, the announcement has generated considerable backlash from Unity developers and the situation is in a state of flux. As such, LL is watching developments in this area to see what direction Unity might ultimately take.
  • Much of the meeting was taken up with discussions on tier and (particularly) with the idea of LL developing their own alternative to Flickr as a potential new revenue stream. This is something that may become the subject of a separate blog post.

Next Meeting

† 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.