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.

Unknown's avatar

Published by Inara Pey

Eclectic virtual world blogger with a focus on Second Life, VR, virtual environments and technology.