Tag: Content Creation 2022

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, August 18th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Official Viewers Status

• Release viewer: version 6.6.2.573358 – formerly the Maintenance 2 RC viewer, dated August 1, promoted August 4 – no change.
• Release channel cohorts:
  • Profiles RC viewer updated to version 6.6.3.574158, on August 18.
  • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.3.573877 issued August 15.
  • Izarra Maintenance RC, version 6.6.3.573920, August 15.
  • Maintenance (N)omayo RC viewer, version 6.6.3.573882, August 5.
• Project viewers:
  • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.
  • Performance Floater project viewer, version 6.5.4.571296, May 10.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Copy / Paste project viewer, version 6.3.5.533365, dated December 9, 2019.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this project.

• The back-end updates are now “all there”, and the focus is now on “tightening up” the graphics., the the image-based side of things now looking “pretty good”.
• Internal testing currently involves Second Life, the new PBR / Materials viewer, the Kronos glTF 2.0 standard and Adobe Substance tools (Painter, Stager) to ensure that results displayed within Second Life are consistent with expectations when working within Substance Painter and with glTF.
• Some inconsistencies with using directional lights created in Blender have been noted and subject to further testing.
• Those with access to the Content Creation Discord server will be able to obtain an updated viewer soon. This will lack transparency support or LSL support; it will also have some “rough edges” around the UI and inventory support.
  • This is a test viewer only, and not for general consumption.
  • A more public Project viewer will be made through the Alternate Viewers channels when the work is more stable and suited for wider consumption.
• Once the initial work on PBR  Materials is released, the graphics team will likely work on some quality of life improvements (e.g. bug fixes) for the graphics system, rather than launching into a new project immediately.

Possible New Inventory Fields

Whilst not solely related to content creation, the Lab has been discussing the potential of adding new inventory fields. Ideas being considered or also put forward at the meeting comprise:

• Providing a thumbnail image of the inventory item, rather than having to rely solely on descriptive text.
• A means of “tagging” inventory items (e.g. to define what they are in terms of being an attachment or not, and whether the attachment is / is not rigged, etc.), rather than just simply leaving them as a list of orange boxes.
• Providing a formal means of “archiving” items that are not regularly used but which are not yet ready to be deleted (other than boxing things up and creating more orange boxes….).
• Splitting head shapes and body shapes to make it easier for people who use different heads with the same body (or vice-versa).

In Brief

• Requests are again surfacing for texture animation support in particles (see feature request BUG-5307). Those interested in seeing such capabilities should consider adding feedback to this Jira.
  • This led to questions on a complete overhaul of the SL particle system, which is not something currently under consideration as a possible future project at the Lab – which is not so say incremental updates are ruled out. Again, specific requests incremental updates system should be made via Jira.
  • For texture animations on particles, for example, the Lab would likely consider adopting the existing texture animation system for use with particles, rather than rebuilding the particle system to handle texture and other animations.
• There was a brief discussion of a viewer-side Animation Override (AO) system (e.g. similar in nature to the Firestorm approach). This has been raised in the past at TPV Developer meetings, where it appears to get more robust discussion.
• The question was raised of having support for user-defined custom shaders in Second Life. The short answer is “no”, as there are too many variables (a custom shader for a single scene may work – but what happens with 30 people utilise their own shaders / shaders made by others and all congregate at a single club? The rendering will not scale (also, with people all creating their own shaders, how can a consistent result be ensured? What about the risk of malicious shaders being used with content?).

Next Meeting

• Thursday September 1st, 2022.

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, July 7th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this project.

Outline of Work

• Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
  • The overall aim of this work is to provide a means to support more physically accurate reflections in SL than can be currently generated (seen as a requirement for PBR support).
  • It applies to both PBR generated content, once available, and to legacy content.
• Creating a materials type with an associated inventory asset. This will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.
• Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
• The initially supported capabilities are:
  • RGB albedo + transparency.
  • RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
  • RGB emissive.
  • RGB normal (- alpha).
  • Double-sized supported (disables backface calling before issuing the draw call).
  • Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
• In addition:
  • There will be an ability to “preview” materials on an item within your own viewer (similar in nature to Local Textures) before actually uploading them.
  • LSL support is still being defined, but should at least allow individual texture UUIDs to be replaced under script control.
  • The approach being taken is to may the system extensible so that further capabilities / plug-ins / options can be added with relative ease in the future.
  • However, Displacement maps will not initially be supported due to not being defined in the core of glTF 2.0; nor will any extensions that are not adopted into the core glTF standard (either glTF 2.0 or 3.0).

Current Progress – PBR Rendering

• Progress has been made on both the back-end and within the viewer, the latter elements being focused on hooking up EEP to work with PBR.
• There is currently an issue with Mac OSX due to the cube map being used at present, but this will be addressed.
• Given the work is still on-going, there is nothing as yet directly visible viewer-wise for users to test (on Aditi).

New Starter Avatars

There was some discussion of the new all-mesh starter avatars (see: SL19B MTL – the Moles (new starter avatars + Linden Homes)), reiterating / stating:

• This is not a re-working of the avatar system; it is aimed towards providing incoming new users with:
  • A selection of mesh avatars with which they can gain familiarity in terms of using / customising.
  • A supporting ecosystem of clothing / accessories rigged to work with the avatars / existing slider system.
  • A “stepping stone to allow them to more readily move towards more complex mesh avatar bodies / heads.
• It is hoped that as the system starts to mature, avatar clothing / accessory makers can be encouraged to support these new avatars by providing clothing / accessories of their own (and also adding to their income stream by doing so).
• There is a concern that the new avatars will be rejected by the existing community, so information will be made available to creators, etc., as the system reaches a point where reliable information can be shared.

In Brief

• llSetEnvironment (for scripted EEP changes) should start being deployed in an upcoming simulator maintenance updates.
• Currently, there are no plans to extend materials support to Bakes on Mesh; current materials or PBR.
• Additional avatar slider discussion:
  • A further request was made for a global scaling slider for the avatar. This was described as being harder to implement that might appear – although not impossible.
    • Part of the problem is the complexity involved in adding a new slider to work within the existing system, and the impact it has on other back-end systems (such as the Bake Service) which then also need to be tested / updated.
    • It is also unclear how the animation graph could be impacted / adjusted to allow for realistic, size-based strides with walking (e.g. so very large avatars don’t appear to be taking disproportionately small steps or tiny avatars are zipping along like they are jet-propelled -although given what is currently possible, it’s not clear if trying to address issues like these would be seen as a requirement by users.
    • As such, while the request has been noted (and has been subject to feature request Jira, it is described as being on the “back burner” of work LL would like to get to at some point.
  • Gender: a request was made to make the Gender slider less of a binary male / female choice. A modification to TPVs helps to provide this – for which LL now has the details – but it would be better to have official support.
• The inverse kinematics system as a whole is being looked at as a part of the avatar puppeteering (formerly avatar expressiveness) project.
• Larger prim sizes than 64m: currently not under consideration; however, LL interested in learning more about how-where they would be used, so they might better determine size ranges, etc., and in preventing Land Impact making structures created by large-scale prims becoming unaffordable.
• Non-physical region surrounds (e.g. by using environment settings to create a 360-degree panorama): still more in the discussion stage internally at the Lab rather than anything likely to be implemented in the foreseeable future.
• Mojo Linden indicated he would like to be able to give some kind of a representative low-poly bakes that would be vertex-shaded, the idea being to give a greater sense of the “vastness” of Mainland than can be gained from extending Draw Distance (which would also have a viewer performance hit in trying to render everything within DD range). These would then someone “fade away” and be replaced by the “real thing” as an avatar moves towards them, with further low-poly bakes appearing in the distance.
  • This is not an immediate project, but something Mojo would like feedback on, in terms of being something worth time in the LL considering.
  • If this were to become a project, the emphasis would be on the bakes being very low-poly, and the progress from a bake to actual objects would not be seamless.
• Terrain texture update: this has been previously discussed, but was put on hold as creators favoured PBR support. However, it is something the Lab will be getting back to in the future – with the potential for PBR support to potentially be extended to the terrain as a future PBR project, with possible PBR texture painting (grass, plants, dirt, etc.).
• There was a general discussion on land: pricing, products, instancing regions (e.g. event / experience regions) being able to spin-up / down regions when in use / not in use.
  • All of these ideas are subject to internal LL discussions, and some have their own inherent challenges (e.g. how do you account for spinning-down regions in which there are scripts running that have an expectation the region will be available 24/7, such as breedables?; how do you offer variable sized regions (e.g. 128mx128m or 1024x1024m) when the system is built around the expectation of a uniform region size (256x256m)?).
  • Beyond ideas being discussed internally and seeking feedback from users, nothing is on the current roadmap in terms of new land products.

Next Meeting

• Thursday August 4th, 2022.

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 30th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Official Viewers Update

One Wednesday, June 29th, The Maintenance M(akgeolli) RC viewer, version 6.6.1.572458 was promoted to de facto release status.

No changes to the rest of the official viewers through until Thursday, June 30th, leaving them as:

• Release channel cohorts:
  • Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
• Project viewers:
  • Performance Floater project viewer, version 6.5.4.571296, May 10.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this project.

Outline of Work

• Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
  • The overall aim of this work is to provide a means to support more physically accurate reflections in SL than can be currently generated (seen as a requirement for PBR support).
  • It applies to both PBR generated content, once available, and to legacy content.
• Creating a materials type with an associated inventory asset. This  will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.
• Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
• The initially supported capabilities are:
  • RGB albedo + transparency.
  • RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
  • RGB emissive.
  • RGB normal (- alpha).
  • Double-sized supported (disables backface calling before issuing the draw call).
  • Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
• In addition:
  • There will be an ability to “preview” materials on an item within your own viewer (similar in nature to Local Textures) before actually uploading them.
  • LSL support is still being defined, but should at least allow individual texture UUIDs to be replaced under script control.
  • The approach being taken is to may the system extensible so that further capabilities / plug-ins / options can be added with relative ease in the future.
  • However, Displacement maps will not initially be supported due to not being defined in the core of glTF 2.0; nor will any extensions that are not adopted into the core glTF standard (either glTF 2.0 or 3.0).

Materials Progress

• The focus has been on under-the-hood work to allow drag-and-drop of materials assets onto objects / object faces (download demonstration mp4 here).

• There is further work required on the back-end inventory services and asset store, and on some of the shaders in the viewer, before any of this work is ready for public testing on Aditi.

ALM Proposal / Work – Recap

At the #week #23 TPVD Developer Meeting (notes here), it was indicated that LL are “leaning” towards removal of the non-Advanced Lighting Model (ALM) (aka “forward rendering”) rendering path from the viewer, leaving just ALM rendering (aka deferred rendering”).

• Were this to be done, it would only be done if it can be shown that this does not adversely impact performance (e.g. ALM runs roughly as well as non-ALM for those using the latter) on the broad cross-section of hardware most commonly operated by SL users.
• The work will include:
  • A slider to manage the number of rendered local lights to lightening the load of rendering illumination on lower specification systems.
  • A “data saving mode” primarily intended to help those on metered connections by culling the download of additional materials / PBR maps and potentially downloading lower resolution textures mips, all of which will reduce the data passing over their connections. However, it will result in a much poorer visual experience once the PBR work has been implemented, and the hope is the mode will only be used in the minority of cases.
• Given the ongoing work to support PBR and a more rounded set of materials, moving to deferred (ALM) rendering without fallbacks to non-ALM rendering – providing, again, the caveats noted above can be met / implemented – will in general help ensure a more reliable / consistent viewing experience across a broad range of hardware.

In Brief

• The work to make full use of available video memory on a client computer is being put out to a hardware compatibility lab to help ensure the code changes are doing what they are supposed to be doing on a wide variety of hardware. These tests will also look at the impact of running the viewer with ALM active all the time across all hardware configurations.
• On Animation:
  • The Puppeteering project highlighted at Grumpity and Mojo Linden’s Meet the Lindens session came in for criticism, but it was suggested people give the system a chance to reach a more advanced stage before judging, as the video presented in the talk does not do the work justice.
  • Vir indicated that while there is an understanding at the Lab that people would like the animation system overhauled:
    • Such a project currently isn’t on the roadmap
    • However, consideration is being given to allowing an on-the-fly adjustment of animation priorities.
    • Requests for additional animation work were requested via Feature Request Jira.
  • Runitai Linden suggested that as glTF supports animations it might – in the future – be a possible option for animation improvements. However, note that moving in this direction is also not part of the current roadmap.

Next Meeting

• Thursday July 7th, 2022.

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 16th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Official Viewers Update

No changes to the list of official viewer through until Thursday, June 16th, leaving them as:

• Release viewer: version 6.6.0.571939 – formerly the Performance Improvements viewer, dated May 25th – no change.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
  • Makgeolli Maintenance RC viewer (Maintenance M) viewer, version 6.5.6.571575, May 12.
• Project viewers:
  • Performance Floater project viewer, version 6.5.4.571296, May 10.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Status

• Bugs are still being ironed-out of the release version of the Performance Improvements viewer.
• It is hoped the Legacy Profiles project viewer will start to move forwards once more.
• There’s a further dedicated graphics project viewer in the wings, which may be appearing in the near future.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this work, with notes specific to the reflection probe work available in my week #22 and week #20 meeting summaries.

Outline of Work

• Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
  • The overall aim of this work is to provide a means to support more physically accurate reflections in SL than can be currently generated (seen as a requirement for PBR support).
  • It applies to both PBR generated content, once available, and to legacy content.
• Creating a materials type with an associated inventory asset. This  will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.

Reflection Probes Progress

• Simulator-side support for reflection probes has been on test using an experimental view and simulator-side updates available on Aditi through the DRTSIM542 channel (Materials 1, Rumpus Room, Rumpus Room 2, and Materials Adult).

Materials Progress

• 

  Work is continuing on glTF materials import, and the hope is to have something that is functional within “the next week or two”. This uses the same unpacking mechanism as Unreal 4.

• Materials will be uploaded with an additional editor (shown right), which will allow some manipulation and delivery the materials as an inventory item when uploaded.
• Supported textures / capabilities:
  • RGB albedo + transparency.
  • RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
  • RGB emissive.
  • RGB normal (- alpha).
  • Double-sized supported (disables backface calling before issuing the draw call).
  • Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
• Functionality not initially supported will be the ability to change the UVU wrapping Mode (so everything will sill be repeat); no ability to change the metification / magnification filter per texture;
• The process separates the materials from the mesh, so the materials can’t know if things like tangents are present.
• Texture will initially have to be packed by a creator’s preferred toolset; once the project gets to a state of polishing, the importer should re-pack the textures itself, unless importing from a non-glTF source, in which case self-packing will still be required.
• Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
• Uploads will be L$10 per texture, so L$40 if all four used.
• Brad Linden is working on getting the import into inventory working.

ALM Proposal / Work

At the #week #23 TPVD Developer Meeting (notes here), it was indicated that LL are “leaning” towards removal of the non-Advanced Lighting Model (ALM) (aka “forward rendering”) rendering path from the viewer, leaving just ALM rendering (aka deferred rendering”).

• This was triggered as a result of a bug report which initially appeared to suggest the Performance Improvements viewer unintentionally alters the render order of object faces. While it later proved that the issue was more an edge-case in the way a piece of content had been created, efforts to try to correct it and to ensure it rendered as desired in both ALM and non-ALM rendering, raised the question as to whether it would simply be easier to remove the non-ALM path.
• Were non-ALM rendering to be removed from the viewer, it would:
  • Only be done if it can be shown that this does not adversely impact performance (e.g. ALM runs roughly as well as non-ALM for those using the latter) on the broad cross-section of hardware most commonly operated by SL users.
  • Include a slider to manage the number of rendered local lights, as these are unlimited under ALM but can cause performance issues on low-end systems; thus a slider will help those on lower spec hardware to determine how many local lights they wish to have rendered.
  • Likely include a “data saving mode” that will prevent the download of materials for those on metered connections (to reduce the amount of data crossing their connection) and / or help those who find that materials loading can impact performance. This will have a UI warning that when employed, some objects may not look the way they are supposed to look.
• In terms of the last point above and “data saving mode” the focus is currently on how many users would need it *if* the Lab goes forward with the idea. This will help determine how much the mode is needed and how best to approach it.
• Given the ongoing work to support PBR and a more rounded set of materials, moving to deferred (ALM) rendering without fallbacks to non-ALM rendering – providing, again, the caveats noted above can be met / implemented – will help ensure a more reliable / consistent viewing experience.

Rigged Attachment Render Order

In terms of render order of object faces on rigged meshes, LL are considering adding a “render order number” that can be used by creators to ensure the orderly rendering of faces for transparent rigged attachments (thus allowing pre-loading of textures on “invisible” faces, etc.).

• This would hopefully overcome issues of implicit render ordering (which may change due to other viewer dependencies), and of interpretations of the rendering order by creators that can lead to the kind of issue noted in the ALM discussion above.
• There are complications in attempting this -e.g. render order is not per object, but per mesh, and is part of an overall schema for rigged attachments (attach order, linkset order, face index order); questions around overall outfit changes, where multiple attachments are being made, etc.
• Providing such an approach does not break masses of existing content, it would allow creators to continue to use the implicit ordering (and risk odd behaviours should LL make changes in the future that affect the order), or use the ordering system to explicitly set the order, no matter what changes might occur down the line.
• None of this work should impact the attachment order, but could significantly reduce the number of avatar draw calls.

Next Meeting

• Thursday June 30th, 2022.