2024 SL SUG meetings week #48 summary

Les Bean at the Salty C, September 2024 – blog post

The following notes were taken from the Tuesday, November 26th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from the chat log and Pantera’s video of the meeting, which is embedded at the end – my thanks to her for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, November 26th, 2024, the simulators on the Main SLS channel were restarted without no updates.
  • On Wednesday, November 27th:
    • An updated version of the Barbecue simulator update should be deployed to the BlueSteel RC. This includes: support for “alpha-gamma” which will allow an object owner to adjust some of the PBR alpha values that were impacting legacy things like hair; llSetAgentRot; a new warning on receiving direct IMs from Scripted Agents (“registered” bots). Rider describes this as “Bot confessions”: with IM sessions with bots there will be a warning sent to the receiver that they are having a conversation with a bot. Also, for viewer developers, there will be a bit of metadata attached to the IM_NOTHING_SPECIAL that indicates the sender is a bot.
    • The remaining RC channels will be restarted.

Apple Cobbler Update

Currently in testing on Aditi ( regions of Mauve and Jigglypuff for those wishing to test), and includes:

  • llTransferOwnership which enables a prim give itself to a new user (subject to owner permissions already set).
  • An extended llGiveInventory to allow for a destination folder (system folders + RLV/a) to be specified as well (+ the use of a parameter list, so further options can be added in the future).
  • llMapBeacon – like llMapDestination, but a) does not necessarily open the map window; b) can optionally open the map, with or without focus. This will also require a viewer update.
  • A new function for detecting attachments. If it is running with an experience it will be able to detect HUDs that also have scripts with the same experience (e.g. to ensure the correct HUDs are being used – this will not allow anyone to script to find out all the HUDs someone is using).

SL Viewer Updates

No updates with the current official viewers:

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11750364439, November 12.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

In Brief

Please refer to the video below for the following:

  • There appear to still be issues around the llTransferOwnership function, which is available for testing on Aditi. See: llTransferOwnership() returns -6 when flag 0x4 is used inside a full-perm-for-owner object.
  • A request to fix the long-standing (18 years!) to fix the issue of Modify becoming No Modify on being taken back to inventory if they have a things like No Mod script in their contents (the script should maintain its no Mod permissions, and the object should retain its Modify permission and not inherit No Mod from the script, etc.) as part of the work in tweaking permissions for llTransferOwnership() was seen as “out of scope” for this work.
  • A discussion relating to sitting height and a possible change in behaviour resulting from the fix for the recent “hovering on logging-in” issue affecting system shoe height adjustments (and whether the mentioned sitting issue is  / is no a bug) – see Sitting height is now affected by system shoes.
  • A further discussion on region crossing and attachments and potential issues.
  • Further discussion around people being able to opt-out of the extended llGiveAgentInventory() capabilities so as to avoid things being dropped “anywhere” in their inventory.
    • This saw a re-hash of the idea that all items – whether received via the Marketplace, of in-world transfer, should go to a single, dedicated system folder clearly named, and then to sub-folders within it (e.g. “From Marketplace” and “In world”).
    • The above would help prevent a lot of confusion for newer users, as everything then receive goes into *one* system folder and they can find it). I would also allow users to retain better control over their inventories in terms of where items received finish up. However, it risks breaking functionality such as #RLV (which is in the process of being adopted by LL for their viewer).
    • The discussion also included a request that users be given an override to llGiveAgentInventory(), so that they can set the destination folder on being offered the item(s).

 

† 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 rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

Sitting on a Frost Peak in Second Life

Frost Peak, November 2024 – click any image for full size
Update January 2025: Frost Peak has closed.

Winter is the quietest and most peaceful time of the year. Nature lies beneath a soft, white blanket, sleeping in gentle stillness. Snowflakes dance through the air like tiny, sparkling stars, quietly settling on the ground. Forget your worries for a moment and enjoy a warming mulled wine at the festively decorated Christmas market or an exciting train ride through the snowy landscape.

– Frost Peak About Land

Occupying a Homestead region, Frost Peak offers exactly what its About Land deception states:   a winter’s setting rich in snow and opportunities to forget worries, relax and take photos, wander a little market or ride a train through the surrounding woods.

Frost Peak, November 2024

Designed by Yoyo Collas with the help of AmyDenise, the region near seamlessly blends itself with the outlying surrounds to present a place nestled within high mountains. The Landing Point sits towards the eastern end of the landscape (itself laid-out roughly east-to-west), where steps lead up to an arched entranceway passing under a grand festive tree.

At the foot of these steps is the first opportunity for photography – a horse-drawn sleigh with sitting for individuals or couples. A further place to pose can be found just across the track from the sleigh, in the form of a little glass-canopied bench and where a white stag watches over a small herd of deer.

Frost Peak, November 2024

Stand close the tracks long enough, and an open-topped train will clatter past, hauling a line of open-topped little carriages. Mindful somewhat of Stevenson’s Rocket (albeit with a cow-catcher on the front!), the little train huffs and puffs itself around an oval of track passing through the outer sides of the region at a speed that makes hopping on and off very easy.

The train is a good way to see the outlying woodlands of the region and the wildlife therein – bears, fawns, deer – and pass by the cosy home at the western extent of the land (and which appears open to the public if you fancy popping inside and warming yourself up). The tracks will also take visitors past a bridge and a deck which both provide access to the ice-skating track area.

Frost Peak, November 2024

Broad enough for ice dance around the little island in its midst, and close to the deck and below the slope leading up to the house, this frozen part of the setting throws two smooth arms around the middle of the landscape, possibly allowing a race or two around it, the route carrying skaters under the Landing Point’s huge tree in the process.

Passing through the tunnel under this tree from the Landing Point brings visitors to the Christmas / Winter market set within the innermost oval of the land, walls around most of it lifting it above the ice skating, other than at its western end where the snow-covered ground slopes gently down to the ice, a road also curling tail-like around it it from the market or offer a path from one to the other.

Frost Peak, November 2024

The market is home to a range of stalls and little shops, together with fairground rides, places to sit and plenty of life. One of the rides is a novel carousel in which the riders’ seating and mounts remain still, and the rest of the carousel itself  slowly revolves around them! A curio it might be, but it also fits within the setting.

The life and liveliness comes in the form of static NPCs who are set as if wandering the stalls, seated in conversation, bartering over snacks, taking phots, and so on. They are joined  by a couple of cats who look to be about to have a disagreement, and the local Elf and welfare team taking a break from sweeping the snow from the cobbles, before they make their way gnome (sorry! 😀 ), while pigeons and stags round-out the animal representative and snowmen keep their eyes on things.

Frost Peak, November 2024

The NPCs in the market aren’t the only ones to be found here, as those who ride / follow the train tracks will discover – folk are out for a walk around the tracks as well, while those looking for little places to sit and pass the time might want to seek out the old cable car cabin as it sits out on the ice or perhaps the cosy little forest shed across the ice from it, and watched over by a friendly owl.

Rich in details, easy on the eye, Frosty Peak is well put together to make a nicely relaxing visit.

2024 SL viewer release summaries week #47

Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates from the week through to Sunday, November 24th, 2024

This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
  • Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.

Official LL Viewers

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC, dated September 11, promoted September 17 – NO CHANGE.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11750364439, November 12 – New.

LL Viewer Resources

Third-party Viewers

V7-style

  • Black Dragon for Windows updated to version 5.2.1 (PBR), November 25 – release notes.

V1-style

  • Cool VL Viewer Stable: 1.32.2.25, November 23 – release notes.

Mobile / Other Clients

  • No updates.

Additional TPV Resources

Related Links

Space Sunday: big rockets and (possible) ISS troubles

A shot from the “flap cam” on Starship, showing the Super Heavy immediately after separation during IFT6. Note the residual gases burning within the hot staging ring. Credit: SpaceX

The sixth integrated flight test (IFT-6) of the SpaceX Starship / Super Heavy behemoth took place on Tuesday, November 19th, 2024, and proved to be perhaps the most successful test yet of the system, even though the core aspect of the first part of the flight didn’t occur.

The vehicle lifted-off from the SpaceX Starbase facility at Boca Chica, Texas at 22:00 UTC. All 33 Raptor-2 engines on the Super Heavy booster ignited, and the massive vehicle lifted-off smoothly. All continued to run, and the initial phases of the flight passed without incident: the vehicle passed through Max-Q, reached Most Engines Cut-Off (MECO) at 2 minutes 35 seconds, leaving it with just three motors running.  Seven second later, hot staging occurred, Starship firing all 6 of its engines and then separating from the booster.

Starship IFT6 rising from the launch facilities, November 19th, 2024. Credit: Redline Helicopter Tours

This was followed by the booster flipping itself onto a divergent trajectory to Starship and re-igniting the ring of 10 inner fixed motors to commence its “boost back”: gradually killing it ascent velocity and bringing it to a point where it could commence a controlled fall back to Earth, and then a powered final descent into being caught b the Mechazilla system on the launch tower, as seen during the October flight.

However, during the boost-back, the call was made to abort the attempt at capture, and to instead direct the booster to splashdown in the Gulf of Mexico. The booster then went through a nominal descent, dropping engines first (and causing them to glow red-hot during the compression of air inside their nozzles, despite the fact none were firing).

Booster in the water: seconds after splashdown, a single motor still running, the Super Heavy booster sits in the Gulf of Mexico. Credit: SpaceX

At just over 1 km altitude, the 13 inner motors did right, all of them firing for some 7 seconds and reducing the rocket’s descent from 1,278 km/h to just 205 km/h. At this point nine of the ten motors on the inner fixed ring shut down, with one appearing to run a second or so longer. When it shut down, there was a belch of flame of the base of the booster, which might indicate an issue.

Nevertheless, the three central motors continued to operate, gimballing to bring the booster to a vertical position and a brief hover right above the water before cutting off and allowing the rocket to drop end-first into the sea. Remaining upright for a moment, the booster then started to topple over. However, as the live stream cut away at that point, it was down to other camera to capture the subsequent explosion due to water ingress around the super-hot engines, etc., which destroyed the rocket.

“There’s the kaboom!” Shots from onlookers demonstrating that 13 super-heated engines and their plumbing and residual gases in propellant tanks don’t play nice with cold sea water, as the Super Heavy booster explodes

The Starship vehicle, meanwhile, made it to orbit and continued on over the Atlantic and Africa to  the Indian Ocean, where it went through its de-orbit manoeuvres.

Whilst in the coast phase of the flight, the vehicle had been due to re-ignite one of its vacuum engines to demonstrate this could be done in space. This occurred at 37 minutes 46 seconds into the flight, the motor running for about 4 seconds. Although brief, the re-light was a milestone – Starship will need the capability while on orbit in the future.

A camera in Starship’s engine bay captures the steady firing of one of its vacuum Raptor-2 motors during the flight’s orbital coast phase. Credit: SpaceX

The Starship’s return to Earth was anticipated as being potentially “whackadoodle”, and subject to possible vehicle loss. This was because SpaceX had removed elements of the thermal protection system designed to protect the vehicle from burning-up during atmospheric re-entry.

The purpose in removing tiles from the vehicle was to expose parts of the hull where, if Starship is also to be “caught” by the Mechazilla system on its return to Earth, it will need exposed elements on the side bearing the brunt of the heat generated by re-entry into the atmosphere, and SpaceX wanted data on how the metal of the vehicle held-up to being exposed to plasma heat, particularly given the previous two flights had seen plasma burn-through of at least one of the exposes hinges on the vehicle’s aerodynamic flaps.

The leading edge of a flap show clear signs of impending burn-through during re-entry – but the damage is a lot less than previous flights. Credit: SpaceX

As it turned out, the vehicle managed very well during re-entry; there was a significant amount of very visible over-heating on the leading edge of a flap, but even this was less than seen in IFT4 and IFT 5. It’s not clear as to how much damage the exposed areas of the vehicle suffered were TPS tiles had been removed, but given the vehicle survived, any damage caused was clearly not sufficient to compromise its overall integrity.

The drop through the atmosphere was visually impressive, the flight so accurate that as the vehicle flips itself upright at less than 1 km above the ocean, the landing zone camera buoy anchored ready to record the splashdown can clearly be seen. Immediately after entering the water, the Starship toppled, bursting into flame – but this time not immediately exploding.

After fling half-way around the world, the Starship vehicle is about to splashdown just a handful of metres from the camera buoy (arrowed, top right)at the landing zone. Credit: SpaceX

Whilst a booster catch might not have been achieved, IFT6 can be classified a success. All criteria but the catch of the booster was achieved, and even though the later was lost as a result of a forced splashdown, the successful diversion of the booster to do so demonstrates an ability for SpaceX to divert a vehicle away from a landing tower in the event of an issues with the tower – providing said issues are spotted earl enough.

The flip side of this is that it exposes an inherent weakness in the system; the reason for the abort was that the actual launch of the vehicle had caused damage to the launch tower and its communications systems, calling into question its ability to make the catch. Tower / launch stand damage has been a recurring theme with Super Heavy launches, although the degree of damage caused has been dramatically reduced.

The moment before splashdown, as seen from the Starship flap cam (l) and the remote camera buoy (r). Credit: SpaceX

Even so, the fact that comms systems could be KO’d reveals how vulnerable the system is to a potential loss of vehicle (and the knock-on impact in terms of “rapid reusability”), particularly if there is no close-at-hand and available launch / catch tower available to take over the role. And while this abort was called when the vehicle was still 87 km altitude, with lots of time to bring it safely into a splashdown, can the same be said if an issue occurs when the vehicle is just 13 km above ground? Or ten? Or two? Or if the malfunction occurs in the final engine burn?

ISS Reports “Toxic Smell” and Atmosphere Scrubbed

Update: Several hours after this article was published, NASA issued a statement on the event described below.

Reports are surfacing of possible toxic contamination board a resupply vehicle at the International Space Station (ISS). Initial news on the situation was broken by the highly-reliable Russian Space Web, operated by respected space journalist and author, Anatoly Zak, but that the time of writing this piece, western outlets had not reported the story, which is still breaking.

On November 21st Russia launched the automated Progress MS-29 resupply vehicle to the International Space Station (ISS), carrying some 2.487 tonnes of supplies, including 1.155 tonnes of pressurised supplies, 869 Kg of propellants; 420 kg of water and 43 kg of nitrogen gas.

Cosmonauts Ivan Vagner and Alexei Ovchinin monitor the automated approach and docking of Progress MS-29 at the Poisk module of the Russian section of the ISS. The majority of Progress dockings are automated, but members of the crew are on hand to manually intervene if required. Credit: Roscosmos / NASA

After being placed in an initial parking orbit, the vehicle rendezvoused with the ISS on November 23rd, manoeuvring to dock with the zenith port of the Poisk module (mini research module – MSM 2), attached to the Zvezda main module of the Russian section of the station. Following docking, the vehicle was secured and the pressure between the module and Progress vehicle pressurised to allow the hatches between the two to be opened.

However, the hatch to the Progress has to be immediately closed due to a “toxic smell” and a potential contamination hazard in the form of free-floating droplets. Following the securing of the hatches, NASA’s flight controllers apparently ordered the activation of the Trace Contaminant Control Sub-assembly (TCCS) in the International section of the ISS, a system designed to remove traces of potential airborne contaminants, effectively scrubbing the atmosphere in the ISS, with the Russian crew activating a similar system within the Russian section for around 30 minutes, with the cosmonauts themselves donning protective equipment (as reported last week, the main hatch between the two sections of the station is now kept shut due to a continuous leak of air through the Russian Zvezda module).

Progress MS-29 approaching the ISS, November 23rd, 2024. Credit: Roscosmos

The cause of the smell and the overall status of the MS-29 vehicle have yet to be determined; this is a developing story.

New Glenn Gets Ready

Blue Origin is approaching a readiness to launch their new heavy lift launch vehicle (HLLV), the New Glen rocket.

Earlier in November I reported on the new rocket’s first stage being rolled from the Blue Origin manufacturing facilities at Kennedy Space Centre to the launch preparation facilities at Space Launch Complex 36 (SLC-36), Cape Canaveral Space Force Station. These facilities already held the rocket’s upper stage, which had undergone a series of static fire tests of its motors whilst on a test stand at the pad earlier in the year.

Integrating the first and upper stages of the first New Glenn rocket to fly. Credit: Blue Origin

Since the arrival of the 57.5 metre long first stage at the integration facility at SLC-36, Blue Origin engineers have been preparing the vehicle for launch. By November 14th, the first and second stages of the rocket has been integrated with each other, and worked moved to integrating the payload and its protective fairings to the rocket.

Originally, the inaugural flight for the massive rocket – capable of lifting up to 45 tonnes to low Earth orbit (LEO) – was to have been the NASA EscaPADE mission to Mars. However, due to complications, the flight will now be the first of two planned launches designed to certify the system for the United States Space Force’s National Security Space Launch (NSSL) programme. The payload for the flight will be a prototype of Blue Origin’s Blue Ring satellite platform, a vehicle capable of delivering satellites to orbit, moving them to different orbits and refuelling them.

The fully assemble rocket, two stages plus the payload and its protective fairings, backs towards launch pad SLC-36, Cape Canaveral Space Force Station, November 21st, 2024. Credit: Blue Origin

On November 21st, the completed rocket – over 80 metres in length – rolled out of the integration facility and delivered to SLC-36, where it was raised to a vertical position, mounted on the 476-tonne launch table designed to support it and keep it clamped to the pad.

The actual launch date for the mission has yet to be confirmed, but it will see the company both launch the rocket and attempt to recover the reusable first stage, called So You Think There’s a Chance? Following separation from  the upper stage of the rocket, the first stage will attempted to make and controlled / power decent to and landing on the Blue Origin’s Landing Platform Vessel 1 (LPV-1) Jacklyn.

The New Glenn rocket mounted on its 476-tonne launch table at SLC-26, November 21st, 2024. Credit: Blue Origin

Artemis 2 Vehicle Progress

Even as NASA’s Space Launch System (SLS) continues to face a potentially uncertain future due to its per-launch cost, the second fully flight-ready vehicle continues to come together at NASA’s Kenned Space Centre in readiness for the Artemis II mission.

The mission, which is targeting a launch in late 2025, is due to carry a crew of four – Reid Wiseman (Commander); Victor Glover Pilot; Christina Koch, flight engineer and Jeremy Hansen (Canada), mission specialist – on an extended flight of up to 21 days, commencing with the crew aboard their Orion Multi-Purpose Crew Vehicle (MPCV), being placed in low Earth orbit, prior to transiting to a high Earth orbit with a period of 24 hours.

The Artemis II mission profile – click for full size, if required. Credit: NASA

Once there, they will carry out a series of system checks on the Orion and its European Service Module (ESM), as well as performing rendezvous and proximity flight tests with the rocket’s Interim Cryogenic Propulsion Stage (ICPS), simulating the kind of rendezvous operations future crews will have to do in order to dock with the vehicles that will actually carry them down to the surface of the Moon and back. After this, the crew will make a trip out and around the Moon and back to Earth.

The Orion capsule for the mission is nearing completion, with core assembly completed and the internal fixtures, fittings and systems on-going. Earlier in November 2024, and sans its outer protection shell and heat shield, it was subjected to a series of pressure tests to simulate both the upper atmosphere and space to ensure it had no structural integrity issues.

The core stage of the Artemis II SLS rocket, complete with its four main engines, inside NASA’s gigantic Vehicle Assembly Building (VAB). One of the base segments of a solid rocket booster (SRB) can be seen in the background. Credit: NASA

Meanwhile, the SLS vehicle itself has commenced stacking. The core stage, with is massive propellant tanks and four RS-25 “shuttle” engines, arrived at the Vehicle Assembly Building (VAB), Kennedy Space Centre, in July 2024, and since this has been undergoing much work whilst still lying on its side.

More recently, work on stacking the two solid rocket boosters (SRBs) developed from those used with the space shuttle, that will help power it up through the atmosphere has also commenced.

A crane inside the VAB prepares to lift one of the SRB motor sections and its assembly gantry, ready to place it on the back of a transport vehicle. November 13th, 2024. Credit: NASA

The SRBs comprise 5 individual segments which need to be manufactured and then bolted together, prior to being filled with their wet cement-like solid propellant mix. The base segments of these boosters include the rocket motor and guidance controls, and on November 13th, these were rolled into the Vehicle Assembly Building on special transport / stacking gantries. Over the next several months, the two SRBs will be assembled vertically in one of the bays within the VAB, and then loaded with their propellant and capped off.

Once the SRBs are ready and their avionics, etc., checked out, the core stage of the SLS will be hoisted up into one of the VAB’s high bays, moving to a vertical orientation as it does so. It will then be lowered between the two SRBs so that they can all be joined together. After this the ICPS will be moved up into position and mated to the top of the core stage of the rocket, and then work can commence stacking the Orion and its ESM and their launch fairings.

The SRB motor and its mounting gantry on the transporter, ready to be moved to the VAB bay where stacking can commence, November 13th, 2024. Credit: NASA

Whether or not Artemis II makes its planned late 2025 launch (no earlier than September) is open to question; currently, NASA has yet to fully complete the work on ensuring the already manufactured heat shield for the mission’s Orion vehicle is fit for purpose, per my previous report on heat shield issues.

2024 week #47: SL CCUG & TPV meeting summaries

Silent Melody, September 2024 – blog post
The following notes were taken from:

  • My chat log & the live stream video (embedded below) of the Content Creation User Group (CCUG) meeting of Thursday, November 21st, 2024.
  • My chat log and Pantera’s video (embedded towards the end of this article) of the Third Party Viewer Developer’s Meeting (TPVD) of Friday, November 22nd, 2024.
Table of Contents

Please note that:

  • This is not a full transcript, but a summary of key topics.
  • “[Video]” time stamps refers to the CCUG meeting livestream recording;  “[Pantera]” refers to the TPVD meeting video provided by Pantera.

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
  • The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
  • Dates and times of both meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.

Official Viewer Status

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11750364439, November 12.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

Mobile Notes – CCUG Meeting

[Video: 45:24-47:42]

  • Adding PBR support to SL Mobile is on the roadmap, with ah hoped-for target of some time in Q1 2025 (Jan-March).
  • SL Mobile voice support is experimental, and utilises WebRTC.

CCUG Meeting

Graphics Team Work – General Recap

[Video 0:28-5:31 and 25:04-32:33]

  • Core focus remains on performance work and will remain so until “everyone is happily on PBR-enabled viewers.”
  • Hope is still to have ExtraFPS promoted to release status by the end of 2024.
    • This viewer should see some “significant [performance] improvement” on certain types of hardware – e.g. the Intel HD4000 series (launched May 2012), which is “remarkably popular” among SL users.
    • This work is focused on developing a “classic” mode (also known as a “potato mode” which will see various rendering options disabled (e.g. HDR, Tone Mapping, Reflection Probes, the Emissive channel) to render SL more in keeping with its pre-PBR appearance when running with ALM enabled (aka Deferred Rendering).
    • To achieve this and ensure decent frame rates, comparative benchmarking is being carried out:
      • If an older GPU runs a non-PBR viewer at a higher FPS with ALM enabled than with it disabled – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer. Or;
      • If an older GPU runs a non-PBR viewer at a higher FPS with ALM disabled (thus using the old Forward Renderer)  – – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer, but with ALM-like graphics fidelity.
    • A major element of this work is to get older harder performance back up without creating a rendering schism through the re-introduction of something like Froward Rendering.
  • This work is being carried out alongside “various end of year this and kick-off the next year things.”
[We’re] doing our level best to ensure everybody who can use Second Life on Firestorm 6.6.17 can upgrade to some version of 7.x [PBR] without suffering negative consequences. That’s what we’re doing; we’re chasing all the crashes that we can and all the performance issues that we can. 

– Runitai Linden.

  • [Video 33:28-35:10] A reiteration that a lot of the issues impacted older / lower spec systems are not PBR-related per se (they just happen to have been surfaced within PBR-enabled viewers). Rather, they are the result of things like running out of VRAM due to the updates made to the texture streaming system.
    • Where issues have been due to PBR (e.g. exceptionally heavy PBR in-world builds) there are additional optimisations that are being done.
    • A point to remember here is that PBR is a part of the glTF 2.0+ specification which LL are adopting – and glTF is designed to support a very wide range of hardware, including mobile ‘phone upwards, and so is not itself particularly resource-intensive.
  • Until now, issues with the quality of water reflections on PBR viewers has not been seen as a priority to fix, as it is not performance related and has thus been “taking a back seat” in the queue of fixes. However, if it is seen as a significant issue that prevents users from moving to a PBR viewer, this might be reviewed.

Texture Blurring and downscaling

[Video: 6:54-14:25]

  • In response to comments about texture blurring, Runitai Linden noted that the viewer will start down-scaling textures as it detects a system is running low on available VRAM.
  • This can result in some scene textures close to the camera remaining blurred until focused / zoomed-in upon.
  • Runitai believes there is more work that could be done as to how the fall-off curve for this works to reduce the need to zoom “right in” on textures doing this in order for them to render properly.
  • He further noted that the old behaviour of just using mouseover on a texture to get it to load is no longer applicable, as that actually caused most of the textures in a scene to load at full resolution, causing a performance hit.
  • In addition, there are still some bugs which can result in the viewer getting the wrong answer as to how much VRAM is available on a system (and start downscaling textures when it may not need to). To check if this might be the case:
    • Open the viewer’s texture console (Develop(er) → Consoles →  Texture Console / CTRL-SHIFT-3).
    • Check Est. Free (top line of the Console display) and compare the number with something like GPU-Z or Task Manager (via GPU option).
    • If the two are very different, then there is likely a bug. Please file a bug report with hardware details (Help → About → Copy to Clipboard and paste info into report).
    • Note that on integrated graphics system, the amount of VRAM usually gets reported as the amount of system RAM, and this is referenced by the Sys Free number in the viewer’s Texture Console. Sys Free also reports based on the fact that the viewer tries to minimise its total memory footprint to under 16 Gb.
  • There is no set “minimum” or “maximum for VRAM with SL; LL are committed to enabling SL to run on GPUs with as little as 2 Gb of VRAM, and it is felt that systems with a minimum of 4 Gb and a Draw Distance of 128 metres should be able to manage most scenes – but this is a very broad rule of thumb; the viewer will continue to use VRAM until it runs out, if necessary – there is no upper limit, although some TPVs do allow caps to be set.
  • When downscaling occurs, it should be a) because VRAM has been used; b) commence with textures in the background / off-camera before moving to those in-view.
  • Note that textures will also be off-loaded from VRAM when SL is minimised  / put in the background, to allow other applications access to VRAM. This can also cause blurring as textures are reloaded when SL is brought back to the foreground and resumes using all available VRAM as best it can.

In Brief

  • [Video: 18:32-21:02] WebRTC: LL are still awaiting more users to move to viewers with WebRTC support prior to disabling Vivox.
  • [Video: 23:31-24:40] Older EEP (e.g. Windlight, they’re that old – such as CalWL) settings can look blown-out on PBR views.
    • LL have been attempted to auto-adjust them, but this has proven subjective in terms of results.
    • Therefore, going forward, work will be limited to trying to make them look like they used to, which is acknowledged as not being great for PBR content, but is the “least bad” in terms of keeping EEP settings people like looking the way people like to see them.
    • Hopefully, this work will be finished in time to be included in ExtraFPS; however, if it misses ExtraFPS, it may be issued as a viewer hotfix.
  • [Video: 39:15-40:10] A note of two long-term risks, graphically speaking, that have to be addressed within SL at some point:
    • COLLADA support: support for COLLADA is waning world-side, and so SL needs an interchange file format that is not dependent on COLLADA. Again, glTF is seen as the best solution here.
    • Similarly, OpenGL support is waning, so SL requires a rendering engine that does not rely on OpenGL [and this has been an on-going discussion for the last couple of years or so].
  • [Video: 40:12-45:10] Land Impact: it has long been acknowledged that the Land Impact calculation needs to be revised; there is both a lack of real incentive within it for creators to optimise their builds, and  it misses some key adjustments for things like large builds. The question here is more when it will be revised – although doing so may not eliminate all the ways in which some people game the system to produce lower LI items, as this is something of a separate issue.
  • A general discussion on glTF and mesh imports (incl. scenes) via glTF. In short, no-one working on things at present, given the focus on the performance issues. The local preview remains available in those viewers with the code – by Runitai reminded people that the preview does not use texture streaming; everything gets pulled in at full resolution – and so VRAM can easily be gobbled up.

TPVD Meeting

Much of the TPVD covered ground already walked during the CCUG meeting. Therefore, the following is thus a summary of additional points discussed. Time stamps reference Pantera’s video, below.

Note the meeting formally ended at around 29 minutes, although the video runs through until just shy of 41 minutes, covering a more generic conversation.

  • A recap of the “classic”  / “potato” mode work (get PBR viewers running on lower-spec machines running at the same or better FPS than the hardware can run a non-PBR viewer).
  • Debunking the PBR myths:
    • It is not necessary to run the viewer on Ultra quality in order to view PBR content.
    • LL are not removing support for Blinn-Phong (or “classic” or “legacy”, however you want to call them) materials. PBR is an extension to materials support in SL, not a replacement.
  • A general conversation on Blinn-Phong and PBR Materials, notably in terms of providing the former as “fallbacks” to the latter to accommodate people on non-PBR viewers and prevent them seeing grey / white / plywood surfaces  / features.
  • [Pantera: 9:42-10:42] Some people may experience issues with PBR not just because of computer hardware limitations, but also because of network / router issues (e.g. instead of a single diffuse map, PBR calls multiple maps, resulting in multiple HTTP requests which can cause some routers to choke).
    • To counter this, the “classic / potato” mode LL is developing already doesn’t use the emissive map; if this is shown to work and push up performance, then LL will likely go through as see what other maps might be ignored without compromising the overall visual look of “classic” mode, and hopefully further lift performance in these cases.
  • [Pantera: 15:11-16:45] A reiteration that LL are continuing to work on trying to resolve performance issues, and that anyone experiencing such issues should file a feedback report with as much detail as possible (including hardware information (Viewer Help and use the Copy to Clipboard button and paste info into the report).
    • Specifics are important, as there is only so much info LL can pull from their stats. This is particularly true when terms such as “performance craters” are used, as these are so broad-ranging as to be meaningless.
  • [Pantera: 16:50-20:00] SL viewer’s use of CPU cores and threads: thread usage is variable depending on the number of CPU cores.
    • Those with a specific interest in this, the Steam Hardware Survey is “pretty close” to SL, although SL’s install base tracks “a little closer” to the lower end of hardware, so reduce what is reported in the Steam Hardware Survey 10-20%, and that’s fairly representative of SL.
    • Overall with SL, the main processing loop is single-threaded; texture rezzing and some audio processing occurs on background threads.
    • Runitai Linden has been experimenting with adding threads – such as a dedicated idle thread – and these are showing a “lot of promise”, particularly when Vsync is used.
    • As most GL processes are multi-threaded, hints are sent to things like Nvidia drivers to put themselves into multi-threaded mode.
  • [Pantera: 20:38-25:35] Frame limiters / Vsync: some TPVs use frame limiters to assist with performance, and LL would be interested in receiving a code contribution for one of these.
    • However, it is felt that if trying to limit frame rate to screen refresh, then Vsync remains the better option; whilst a frame limiter is more suited to use in other situations. But, and  depending on the frame rate, Vsync can cause more screen jitter than a frame limiter.
    • In this discussion it was noted that a fix from Apple at the OS level means Vsync with work at 100/120 Hz.
    • It was noted that Firestorm are now defaulting to 60fps with their frame limiter.

Next Meetings

 

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

Simurg’s Winter Valley in Second Life

Simurg + Winter Valley, November 2024 – click any image for full size

It has been but a month since my last visit to Lintu’s (KorppiLintu) always-engaging Simurg, so this might seem a rapid-fire return. However, being the time of year that it is, the parcel has been redressed from its autumn / Halloween design to a winter / seasonal setting – and Lintu was kind enough to drop me a personal invitation to come and take a look.

Added to the above is the fact that Simurg is a parcel rather than a full region, and Lintu is adept at demonstration just what can be done to present richly engaging settings in Second Life without the need to go all-out on an entire region. This is something I have always admired when designers do so (and have tried to achieve myself within the parcels I’ve held / hold, even if I’m too selfish to share them!); thus visiting Simurg is always a personal pleasure for me.

Simurg + Winter Valley, November 2024

Simurg + Winter Valley sees the setting region to something of its “split level” design, with Lintu again using elevation to give a sense of space and quite literal depth to the location, whilst also allowing for the inclusion of another “hidden space” within it to further enchant visitors.

Visits commence on the elevated aspect of the setting and to its western side. Here, within a wooden gazebo visitors can purchase Simurg products via a wooden Christmas tree and look out over a snowy environment whilst deciding if they are suitably dressed for the winter. I most certainly wasn’t, my qipao dress being way to summery – so I fixed that by adding pair of elbow gloves 😀 .

Simurg + Winter Valley, November 2024

From the Landing Point, a path points  eastwards, bracketed to one side by a decidedly warm looking log cabin (one of Cory Edo’s excellent designs), with a large covered veranda complete with fireplace and blankets on the sofas to keep folk warm.

On the other side of the path, and close enough to the cliff edge to provide a view out over the valley below, is a boarded look-out point with warming braziers and wooden seats located behind a heavy rope set out along posts to prevent folk stepping too close to the edge and possible slipping over it.

Simurg + Winter Valley, November 2024

Also facing the cabin from across the main path is another, single-room cabin, reached by a shallow set of stone steps. With glazed walls and an open space before it again looking out over the valley, it is set far enough back so as not to be rudely staring into the dormer windows of the house directly below it. The main path passes behind this little cabin, skirting under a backdrop of rocky cliff faces and then descending gently down towards the valley below.

In descending the slope, the path passes by Lintu’s workshop (open to the public) and links to the end of another path leading down from the front of the little cabin. It then ducks under a lynch-gate before dipping again and curving around to meet the carriage track passing up along the valley from its very south-eastern corner. A stage coach guards the track here as it blends with the off-region landscaping (as does a fence to stop people colliding with the region’s edge).

Simurg + Winter Valley, November 2024

The track runs alongside a broad pond through which a local stream passes – although both are now frozen. The fact that they are means the pond can be used for ice skating – just touch the hearts floating over the ice. The track follows the edge of the pond to where it narrows into the neck of the stream. Here it is crossed by a little hump-backed bridge and the little village square on the far side, with its Christmas tree, little stalls, coffee shop and tailor’s shop.

Beyond the bridge, the frozen surface of the stream offers a way into the Fairy Cave, where more magic awaits other who venture inside, with two romantic little settings to be enjoyed.

Simurg + Winter Valley, November 2024

Throughout all of this are little touches and details that mark Lintu’s care and eye for creativity. Cats roam and play inside her workshop, the cabins and house are all furnished, places to sit can be found throughout, deer and wolves can be seen among the woodlands in the off-region landscaping (and within the region in a few places!) while white horses wait to greet you in the cave. And all the while the chimes of a music box playing When You Wish Upon a Star might be heard, landing another layer of romance to the setting.

All in all, Simurg + Winter Valley presents another photogenic and enjoyable setting form Lintu, and I recommend it for a wintertime visit!

Simurg + Winter Valley, November 2024

SLurl Details