Tag: PBR

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.

2023 week #36: SL CCUG meeting summary: glTF PBR

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

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday,  September 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.
    • 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.

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

  • An update for the PBR viewer – version 7.0.0.581684 was issued following the meeting, on Friday, September 8th.
  • Work is continuing on the communications bloat issue. This will utilise a new message type – GenericStreamingMessage.
  • Bug fixing continues.

Ambient Lighting / Sky Brightness

  • Also noted in previous summaries, there are some issues around ambient lighting where the PBR viewer is concerned. In particular, it tends to render a lot of EEP settings darker than users are used to (in part because the ambient environment lighting in SL has tended to always be over-saturated and bright), and the PBR viewer effectively reverses this to render environments more realistically.
  • This has been an area of work for some time, with none of the results particularly satisfactory, so there is going to be a further round of changes. with the aim of making existing EEP sky settings render more closely to how the author may have intended, rather than remaining overly dark.
  • In addition, the tone mapper in the PBR renderer is going to be adjusted to help reduce undue darkening of older EEP settings.
  • These changes will not impact EEP settings which are created specifically using the PBR settings and capabilities.
  • This work will mean there will likely be a couple more viewer passes as things are tested and adjusted.

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

  • The promised initial build of a PBR viewer supporting mirrors should be made available in week #37. Caveats for this build include:
    • It is not functionally complete and will not render as fully as LL would like.
    • It is not intended for primary use will likely look like it is breaking things.
    • There are already some known crash issues for Mac OS X which will not be fixed when the viewer is initially made available, but will be fixed in due course.
  • The viewer will be made available via the CCUG Discord Channel, and an LSL script will be provided to allow for easy toggling through mirror options.

In Brief

  • Senra:
    • Requests continue to be made to surface the new web-bases avatar creation / customisation tool through the viewer – even it is is just hooking it to the internal browser and providing an easy and obvious means of accessing it. The major reason this is being requested is to to help new users who may have become “lost” or confused in trying to customise their avatar view the viewer – which is clearly a very different experience to the web capability – to get back to something they understand and can readily re-use.
    • It was pointed out that Senra has yet to be featured in the Choose Your Avatar option in the viewer.
    • It was also pointed out that unlike the older “starter avatars” Sentra does not inherently have any form of outfit structure, so if items are worn directly from the Library, anything worn will be copied to the item type folder (shoes to shoes, hair to hair, etc.), rather than being placed within any form of “outfit folder”, making it harder for new users to understand what is happening with their avatar + the items they are using from the Library may end up getting copied multiple times into various folders in their inventory – potentially leasing to more confusion / frustration down the line.
    • This lead to a lengthy discourse through the greater part of the meeting, further demonstrating the need for a New User Experience User Group (or similar) where those actually responsible for projects like Senra could actually engage with users, address questions, etc., rather than cherry-picking if / what they want to respond to via the forums.
  • The above spun-out into a broader discussion on the development of a Sansar-esque dressing room element in the local viewer of outfit / appearance changes (leaving an “untouched” version of the avatar within a region until the change / update is complete) and the complications of doing so (attachments require simulator rezzing, for example), and an general discussion on outfit changes, etc., without firm conclusions drawn.
  • The question was asked about SL supporting vertex animation textures (VAT). This is seen by the Lab as something that might be investigated further down the glTF implementation road, alongside the likes of blend shapes.

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 #35: SL CCUG meeting summary: glTF PBR

Posted on by Inara Pey
Reality Escape – Books, Coffee & Chairs – Oh My! – blog post †

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, August 31st, 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.

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

  • Cosmic Linden has been working on some permissions updates to make permissions meaningful when being addressed via LSL. This means that is a materials surface in set to No Modify, a script will not be able to change its tint, for example.
    • Support for this is currently on the glTF / PBR servers on Aditi, where it is being tested (same region names as above, just on Aditi).
    • Changes to reflect these updates will also be made to the viewer so things like the build floater correctly reflect the permissions status.
  • Runitai Linden is continuing to work on the communications bloat issue. This will utilise a new message type – GenericStreamingMessage. This will both make messages passing between the simulator and viewer more compact and also less frequent in order to reduce the load.
  • To help improve people’s awareness / avoid confusion with the updated Build floater, a new pop-up is being implemented that will be displayed and give information on the change when the floater is first opened and used with a PBR material, complete with a link to the PBR wiki page.

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.

Summary

  • Geenz Linden hopes to start working on a version of the PBR viewer which supports mirrors very shortly.
  • The final data model for mirrors will not be available on the server end in time for the initial version of a Mirrors viewer, but will be coming later, as it is dependent on dialling-in the parameters required for the mirrors functionality based on testing.
  • Overall, the approach now taken means that mirrors will now not just be limited to planar (flat) surfaces.

Lighting / Ambient Lighting

  • Concerns continue to be raised over colour saturation / ambient colour / light within the PBR viewer within non-PBR regions. People appear to be reporting particular issues with over-saturation and with black surfaces (particularly clothing) looking “flat” or minus any clear definition.
  • It was pointed out that some of the issue may well be down to a combination of running the PBR viewer within regions that do not have the proper PBR environment adjustments, thus leading  – to some degree at least – to tone mapping being overly biased for darker colours + the adjustments made within the PBR viewer to compensate for the lack of reflection probes in non-PBR regions still requiring further tweaking + the PBR viewer generally not rendering the excess ambient light common to existing ambient lighting in non-PBR regions.
  • A lot of this is known to be an issue, and something Runitai Linden has been looking to address, as per my pervious CCUG summaries such as this one.

In Brief

  • Rider Linden noted the following updates will be available in the near future via simulator RC releases:
    • “Dog Days” update, due to go to one or more simulator RC channels during week #36 (commencing Monday, September 4th):
      • The unbinding of the Experience KVP database read / write functions from land (users will still require an Experience to access the KVP database).
      • A scripted ability to set CLICK_ACTION_IGNORE, allowing an object to be clicked-through to reach an object behind it – a flag supporting this is included in the current release viewer.
    • The still in development “Fall Colours” update, which will include:
      • llIsFriend – essentially “Is the avatar touching this object a friend of the object’s owner?”, and then act accordingly.
      • llGetInventoyDesc(ription) – a function to return a list of the contents within an rezzed object.
  • User Animats has been experimenting with a new open-source convex hull algorithm for making physics models, which he describes as probably “not suitable” for the SL mesh uploader, but which “might be useful” when working in Blender. There is a forum thread on this line of investigation got those interested.
  • A suggestion was made that as LL gather stats on the hardware users are employing to access SL, that some measure of this data is made public-facing so that creators might have a better idea of the “typical” hardware environment they need to consider, rather than assuming everyone is either running high-end or low-end systems.
    • This was put in terms of something like a list of the 10 or so most commonly used CPU / GPUs (either individually or in combination); most common RAM amounts used (8GB, 16GB, etc.), with the information made available via a web page or similar.
    • It was pointed out that some of the information might be difficult to put together as it might not be possible to accurately extrapolate or consolidate in a meaningful way.
    • However, Vir Linden thought the idea is worth poking at to see what, if anything might be done towards achieving it.
  • An animated discussion on the permissions system and No Mod objects including:
    • Why people use No Mod (such as the mistaken belief that it “prevents copybotting” + the misunderstanding users might have that while a scripted item may way have No Mod scripts, the item itself can still be modified, etc).
    • A idea for the “reset to defaults” override button for Modify object so that if a user royally messes up an object, they can click the button and restore the original look / texturing, etc., of the object (potentially very hand for Mod / No Copy objects).
    • The addition of a new attribute “Demo” which can be used to both lock an object into No Mod and add some form of “demo” indicator to it for when the user is wearing / examining it.
    • The problem with any changes with the permissions system is that it is a) already extremely complicated in its implementation; b) would require considerable care; c) is liable to be a lengthy, far-reaching project. As such, there may not be the appetite within LL to take on such work.

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.