At the start of October 2025 I noted that I would be taking something of a break from SL and blogging in order to address a health issue which had been developing since earlier that year. At the time I did not go into specifics – nor do I intend to here. Rather, I wanted to let people know that circumstances were such that a break was required, and its exact length might well be indeterminate.
As it turned out, things initially appeared to go better than planned: the surgery proved to be less complicated than had originally described, and the immediate cause for concerned fully excised. As a result, my immediate recovery proved to be faster than anticipated, notably in terms of the time I was actually in hospital, such that by the latter third of October I was hoping I’d be returning to SL and blogging pretty much “full time” as it were.
Unfortunately, by mid-November it became apparent that despite these positives, the underlying cause of my problem had not been completely eliminated, and I would therefore require a more sustained period of treatment in order for it to hopefully be dealt with. As a result, my focus on SL and blogging has continued to be reduced and noticeably haphazard throughout the end of 2025 and into 2026 – and will most likely continue to be the case for at least the immediate future.
I mention all of this not to illicit thoughts and messages of sympathy and / or support, but because I’m aware that during the latter part of November and through December I received a lot of personal requests to attend a range of events (art, charity, music, etc.) and / or to ask for my help in promoting specific activities, the openings of public regions, etc., the majority of which went unanswered. As such I genuinely believe an apology for such a lack of response is warranted; the fact that my ramblings and this blog are viewed with regard by many is something I never wish to take for granted – it has and remains something for which I am ever grateful. Thus, I hope readers will take this post in the manner it which it is offered, and continue to bear with the unpredictable nature of my blogging until things again start to settle down for me.
In the meantime, my thanks to everyone for continuing to read this blog, and especially to those who have asked after my health through IMs, DMs, and the like; it really has helped lift my spirits.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates from the week through to Sunday, January 2nd, 2026
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.
Outside of the Official viewer, and as a rule, alpha / beta / nightly or release candidate viewer builds are not included; although on occasions, exceptions might be made.
Official LL Viewers
Default viewer 2025.08 – 7.2.3.19375695301 – maintenance update with bug fixes and quality of life improvements – December 2 – No Change.
Notable addition: new VHACD-based convex decomposition library for mesh uploads.
Second Life Project Lua Editor Alpha viewer 7.2.3.19911032641, December 5 – No Change.
Second Life Project Voice Moderation viewer 26.1.0.20139269477, December 12 – No Change.
Introduces the ability to moderate spatial voice chat in regions configured to use webRTC voice.
Second Life Project One Click Install viewer 26.1.0.21295806042, January 26, 2026 – one-click viewer installation – NEW.
A European Space Agency Automated Transfer Vehicle (ATV) burns-up in the upper atmosphere following its departure from the International Space Station (ISS). Debris from this type of re-entry burn-up is now of growing concern due it its potential impact on the atmosphere and climate change. Credit: ESA
However, there is another aspect of the increasing frequency of space launches and the number of satellites and debris re-entering the atmosphere: pollution and an increase in global warming. This is something I covered in brief back in October 2024, and it is becoming a matter of growing concern.
Currently, there are 14,300 active satellites orbiting Earth (January 2026), compared to just 871 20 years ago. Some 64.3% of these satellites belong to one company: SpaceX, in the form of Starlink satellites. Launches of these commenced in 2019, with each satellite intended to operate between 5 and 7 years. However, because of their relative cheapness, combined with advances in technology and the need for greater capabilities means than since August 2025, SpaceX has been “divesting” itself of initial generations of their Starlink satellites within their anticipated lifespan at a rate to match the continued use of newer satellites, freeing up orbital “slots” for the newer satellites.
As a result, SpaceX is now responsible for over 40% of satellite re-entries into the atmosphere, equating to a net of over half a tonne of pollutants – notably much of it aluminium oxide and carbonates – being dumped into the upper atmosphere a day, all of which contributes to the greenhouse effect within the upper atmosphere.
These particulates drift down into the stratosphere where monitoring is showing they are having some disturbing interactions with everything from the ozone layer through to weather patterns.
We’re really changing the composition of the stratosphere into a state that we’ve never seen before, much of it negative. We really don’t understand many of the impacts that can result from this. The rush to space risks disrupting the global climate system and further depleting the ozone layer, which shields all living things from DNA-destroying ultraviolet radiation.
– John Dykema, applied physicist at the School of Engineering and Applied Sciences, Harvard
A 2023 axonometric view of Earth showing the space debris situation in different kinds of orbits around Earth. Credit: Pablo Carlos Budassi
In a degree of fairness to SpaceX – who will continue to dominate the issue of re-entry pollutants if their request to deploy a further 15,000 Starlink units is approved – they are not the only contributor. One Web, Amazon, Blue Origin and China via their Qianfan constellation, all stand to add to the problem – if on something of a smaller scale (Amazon and Blue Origin, for example, only plan to operate a total of 8,400 satellites, total). Further, NASA itself is a contributor: the solid rocket boosters used by the space shuttle and now the Space Launch System have been and are major depositors of aluminium and aluminium oxides in the upper atmosphere.
Nor does it end there. The vehicles used to launch these satellites are a contributing factor, whether semi-reusable or expendable. They add exhaust gases – often heavy in carbonates – into the atmosphere, as well as continuing to the dispersion of pollutants in the upper reaches of the atmosphere as upper stages re-enter and burn up.
Carbonates and things like aluminium oxides are of particular concern because of their known impact on both greenhouse gas trapping and in the destruction of the ozone layer. A further factor here is that research suggests that interactions between aluminium oxide and solar radiation in the upper atmosphere can result in the production of chlorine in a highly reactive form, potentially further increasing ozone loss in the atmosphere.
We’re not only putting thermal energy into the Earth’s climate system, but we’re putting it in new places. We don’t really understand the implications of changing stratospheric circulation. It could cause storm tracks to move. Maybe it could shift climate zones, or possibly be a new source of droughts and floods. Chlorine is one of the key actors in the ozone hole. If you add a new surface that converts existing chlorine into reactive and free radical forms, that will also promote ozone loss. Not yet enough to create a new ozone hole, but it can slow the recovery that began after the 1987 Montreal Protocol phased out chlorofluorocarbons.
– John Dykema, applied physicist at the School of Engineering and Applied Sciences, Harvard
There is something of a complex balance in all of this. We need the capabilities an orbital infrastructure can provide – communications, monitoring, Earth and weather observation, etc., – but we also need to be aware of the potential for debilitating the natural protections we need from our atmosphere together with the potential for pollutants to further accelerate human-driven climate change beyond the ability of the planet to correct.
This is further complicated by the inevitable friction between commercial / corporate need – and much of modern space development is squarely in the corporate domain, where income and revenue are the dominant forces – and governmental oversight / policy making and enforcement. As such, how and when policy makers might act is also subject to some complexity, although many in the scientific community are becoming increasingly of the opinion that action is required sooner rather than later, and preferably on a united front.
Changes to stratospheric circulation may ultimately prove more consequential than the additional ozone loss, because the outcomes are so uncertain and potentially far-reaching. For the moment, many questions are not really amenable to straightforward, linear analysis. The ozone loss is significant, and we’re putting so much stuff up there that it could grow in ways that are not proportional to what has thus far been seen. The question is whether policymakers will act on those concerns before the invisible wake of our spacefaring ambitions becomes impossible to ignore.
– John Dykema, applied physicist at the School of Engineering and Applied Sciences, Harvard
Brief Updates
Artemis 2 Launch targets February 8th As Earliest Opportunity
NASA has announced a new earliest launch target date for Artemis 2: Sunday, February 8th, 2026, some two days later than the initial earliest launch date target.
The decision to push the target date back was taken after the planned wet dress rehearsal (WDR) for the launch – which sees all aspects of a vehicle launch tested right up to the point of engine ignition – was postponed due to extremely cold weather moving in over the Kennedy Space Centre which could have impacted accurate data gathering on the 49-hour test, which had been slated to commence on January 29th, 2026.
The Artemis 2 Space Launch System rocket on the pad at Launch Complex 39B at Kennedy Space Centre, January 31st, 2026. Credit: NASA/Joel Kowsky.
The WDR was instead reset for the period of February 1st through 3rd, 2026, with the countdown clock to the start of testing resuming at 01:13 UTC on February 1st. It will run through to the opening of a simulated launch window for 02:00 UTC on February 2nd. This latter part of the test will see the propellant loading system – which exhibited issues during preparations for the 2022 Artemis 1 launch – put through its paces to confirm it is ready for an actual launch.
As a thorough testing of all ground and vehicle systems, and a full rehearsal for all teams involved in a launch, the WDR is the last major step in clearing the SLS and Artemis 2 for it mission around the Moon. It will officially terminate as the simulated launch window opens, some 10 seconds before engine ignition – but data gathering will continue through until February 3rd as the rocket is de-tanked of propellants and made safe. Then will come a data analysis and test review.
The actual crew of Artemis 2 are not participating in the test, but will be observing / monitoring elements of the WDR as it progresses. NASA has a livestream of the pad as the WDR progresses, and a separate stream will be opened during the propellant loading phases of the test.
The Artemis 2 crew: Canadian Space Agency astronaut Jeremy Hansen, and NASA astronauts Victor Glover (vehicle pilot), Reid Wiseman (mission Commander) and Christine Koch. Credit: NASA
The push back to February 8th, means that NASA effectively has a 3-day opportunity through until February 11th (inclusive) in which to launch the mission before the current window closes. After that, the mission will have to wait for the March launch window to open.
NASA / SpaceX Crew 12 Looks to February 11th Launch
As NASA primarily focuses on Artemis 2, a second crewed launch is being lined up on the taxiway (so to speak) ready to follow the SLS into space – or possibly launch ahead of it.
NASA and SpaceX have confirmed they are looking at February 11th, 2026 as a potential launch date for the Crew 12 mission to the International Space Station (ISS). The mission will lift-off from Kennedy Space Centre’s launch Complex 39A (LC-39A), just a few kilometres away from the SLS at LC-39B, carrying NASA astronauts Jessica Meir and Jack Hathaway, together with ESA astronaut Sophie Adenot, and Roscosmos cosmonaut Andrey Fedyaev aboard the SpaceX Crew Dragon Freedom.
The Expedition 74/75 / SpaceX Crew 12 personnel, l to r: Roscosmos cosmonaut Andrei Fedyaev, NASA astronauts Jack Hathaway (vehicle pilot) and Jessica Meir (crew commander), and ESA astronaut Sophie Adenot. Image credit: SpaceX.
Officially classified as NASA Crew Expedition 74/75, the four will bring the ISS back up to it nominal crew numbers following the medical evacuation which saw the Crew 11 astronauts make an early return to Earth, as I’ve covered in recent Space Sunday articles.
The preparations for Crew 12’s launch means that in the coming days there will be two rockets on the pads at Kennedy’s Launch Complex 39, each proceeding along its own route to launch. As to which goes first, this depends primarily on how the Artemis 2 / SLS launch preparations go. If it leaves the pad between February 8th and February 10th as planned, then there is nothing hindering Crew 12 lifting-off atop their Falcon 9 booster. However, any push-back to February 11th would likely see Crew 12 delayed until February 12th at the earliest. Conversely, if Artemis 2 is delayed until the March launch opportunity, this immediately clears the way for Crew 12 to proceed towards a February 11th lift-off, with both February 12th and 13th also available.
Habitability of Europa Takes Another Blow
In my previous Space Sunday article, I covered recent studies relating to the potential for Jupiter’s icy moon Europa to harbour life (see: Space Sunday: examining Europa and “The Eye of Sauron”). The studies in question were mixed: one contending that conditions on Europa might lean towards life being present within its deep water ocean, the other being more sceptical about the sea floor conditions required to support life (e.g. the presence of hydrothermal vents).
Now a further study has been published, and it also suggests the chances of life existing in Europa’s ocean are at best thin.
One of the core issues with Europa has been knowing just how thick its ice shell actually is. Some have suggested it could be as little as 2 kilometres thick, whilst others have stated it could be as deep as 30km.
Understanding the thickness of the moon’s ice crust is crucial, as it helps define whether or not processes seen to be at work on the Moon are sufficient enough to have an impact on what might be happening within any liquid water oceans under the ice.
If the ice crust is thin – say a handful of kilometres or less – then activities like subduction within the ice sheets have a good chance of carrying minerals and nutrients created by the interaction between brines in Europa’s surface ice down into the ocean below, where they might help support life processes. similarly, transport mechanisms within the ice could carry oxygen generated as a result of surface interactions down through the ice and into the waters below. If the ice is too thick, then there is a good chance such processes grind to a halt long before they break through the ice crust into the waters below, thus starving them of nutrients, chemicals and gases.
An analysis of data gathered by NASA’s Juno mission as it loops its way around Jupiter and making periodic fly-bys of Europa now suggests that the primary ice crust of Europa is potentially some 28-29 kilometres thick. That’s not good news for the moon’s potential habitability because, as noted it would severely hamper any movement of minerals and nutrients down through the moon’s ice and into the waters below. However, the researchers do note that this doesn’t mean such elements could not reach the waters below, but rather they would take a lot longer to do so, but rather their ability to support any life processes within Europa’s waters would be greatly diminished.
A study of data gathered by NASA’s Juno mission spacecraft suggests the thickness of Europa’s ice crust might be enough – 28-20 km – to severely limit the ability of transport mechanisms and “crustal delamination” (see: Space Sunday: examining Europa and “The Eye of Sauron”) to transfer nutrients, chemicals, gases and minerals formed on the moon’s surface down to the liquid water ocean where they might help life processes in the water. Image credit: NASA
An unknown complication here is he state of the ice towards the bottom of the crust. Is it solid all the way through, or does it become more slush-like as it nears the water boundary layer, warmed by the heat of Europa’s mantle as it radiates outward through the ocean? If it is more slush-like, even if only for around 5 kilometres, this might aid transport mechanisms carrying nutrients, minerals, chemicals and oxygen down into the ocean. Conversely, if the ice is solid and there is a further 3-5 km thick layer of icy slush forming the boundary between it and liquid water, then it will act as a further impediment to these transport mechanisms being able to transfer material to the liquid water ocean.
As a result of this study, and the two noted in my previous Space Sunday article, eyes are now definitely turning towards NASA’s Europa Clipper, due to arrive in orbit around Jupiter in 2030, and ESA’s Juice mission, due to arrive in 2031, in the hope that they will be able to provide more detailed answers to conditions on and under Europa’s ice.
Please note that this is not a full transcript of either meeting but a summary of key topics.
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 generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meetings. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
Default viewer 2025.08 – 7.2.3.19375695301 – maintenance update with bug fixes and quality of life improvements – December 2 – No Change.
Notable addition: new VHACD-based convex decomposition library for mesh uploads.
Second Life Project Lua Editor Alpha version 7.2.3.19911032641, December 5 – No Change.
Second Life Project Voice Moderation viewer 26.1.0.20139269477, December 12 – No Change.
Introduces the ability to moderate spatial voice chat in regions configured to use WebRTC voice.
Second Life Project One Click Install viewer 26.1.0.21295806042, January 26, 2026 – one-click viewer installation.
Upcoming Viewers
Viewer 2026.01 – One-click Installer / Updater
Now available as an alpha viewer (above).
As the name suggests, triggers a one-click install / viewer update process.
Is still being worked on, with a focus on ironing out some kinks in the one click install, including an uninstaller for old non-velopack viewers that can be triggered when required, the usual registry stuff for Windows, and so on.
Also includes improved monitoring / logging of viewer freezes and crashes, etc.
Viewer 2026.02 – “Flat” UI, Font Changes
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2
This viewer is to be part of the Lab’s “first impressions” push to make SL resonate more with incoming new users and hopefully encourage them to keep logging in.
Will include a new “flat” UI (as seen in the Project Zero (viewer in a browser) version) which comprises things like a font change, a colour scheme change, and generally giving the viewer a more “modern” look and feel. This is not a major UI overhaul in terms of overall look and feel, more an aesthetic one.
Font changes within this viewer are currently described as “experimental”.
Also looking like it will include a log-in landing refresh.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2
General Viewer Notes
Work on clearing viewer bugs and implementing smaller feature requests into the viewer is continuing, so users can expect more of this, allowing for other priorities in viewer work.
On the viewer development side:
There should be some vcpkg movement in the near future. A Pull Request for this work via a third-party developer is apparently in progress, but will not be shipped immediately on approval. Rather, it will be allowed “soak time” so other developers can assess impact on their build pipelines downstream and the like.
There will also be some CMake project changes, although these appear to be more of a “modernization” push, to bring CMake in the viewer into line current CMake project norms.
LL is contemplating bringing back viewer maintenance releases to try to encourage some TPVs to pick-up bug fixes and incorporate them faster into their viewers (rather than waiting for a major viewer update which includes bug fixes to get to release status and then merging them).
If this is done, the maintenance releases will be “much smaller in scope” than past maintenance updates (so a kind of taking bug fixes that are flowing into upcoming major viewer releases, cherry picking them and then QA’ing and releasing them as a small update to the viewer.
Those TPVs at the meeting indicated this could either add to their workload or that they would not alter their existing workflow due to overheads, but instead will continue to cherry-pick upstream fixes as a part of their own release cycles.
In response to questions on whether Kitty Barnett’s RLVa code contributions will be included in the official viewer (and which are currently pending fixes she has submitted for RLVa avatar appearance fixes anyway), Geenz Linden stated:
If we did, it’d likely be a very progressive and targeted thing that we do. And hopefully not in a way that significantly makes downstream more difficult to maintain. It’s a longer discussion that needs to be had basically.
This led to concerns that LL could end up implementing a variant of RLVa that is at odds with the current RLV/RLVa API, and effectively end up being ignored for being incompatible. In response, Geenz further noted:
I’d prefer one that everyone can participate in if we do go that route so we can be more targeted with others helping to guide that. Last thing we want to do is make it take 7 months to ship a TPV just because we made a change to RLVa. We also have to consider overall content compatibility and such.
Also as per the last meeting, official Linux support is aligned with the in-progress SLua viewer .
“First Impressions” Context
This work is focused on trying to ease that first experience for a lot of new residents to try and drive up retention numbers.
The work is seen more-or-less as experimentation at this point in time, but the goal is to drive up first day engagement among incoming new users to encourage them to continue to log-in to SL.
Work on this is on multiple fronts, and more will be shared on it in due course.
Grid-Wide WebRTC Deployment
The Lab is currently looking at a March deployment of WebRTC voice across the grid, but this is subject to possible change.
The last major server crash has been fixed, and there have been none since that fix went in.
There is an upcoming fix – see Pull Request #5322 (included in viewer 2026.01) – to address some of the issues with voice dropping. The recommendation is for TPVs to get this into their viewers for a good user experience.
An upcoming server-side update will hopefully address some of the issues with WebRTC spatialisation (e.g. voice volume varying greatly with even small camera position movements on the part of a listener).
Additional connection tweaks for WebRTC have been made to the 2026.01 viewer to help improve voice performance (e.g. to improve auto-reconnect).
Feedback on people’s experiences with WebRTC is still being sought (notably via the beta testing).
SLua Update
An update to the SLua project viewer is forthcoming.
As noted above, this will bring with it support for Linux
Still no confirmation as to when SLua will go live across SL
General Discussion
OSD Meeting
SSR and PBR water real time reflections and shadows: Geenz indicated that work is progressing on this and that when available, it will be given “a proper” alpha/beta/Release Candidate process.
The was noted that whilst improvements on SSR and PBR water reflections are being made, they will never 100% match pre-PBR views without a lot of work being put into optimisation, what would likely still result in mixed feedback without any significant win.
This led to a general discussion on addressing water reflections and shadows.
CCUG Meeting
PBR lighting: still on the list of potential updates, but requires “quite a few” server-side changes in order for it to happen.
The existing SL lighting system has a range of constraints dating back 20+ years, and so would require significant modification in order to enable PBR lighting support.
As such, this is currently viewed as being on the back burner for the foreseeable future, while other things are worked on.
A question was asked on whether it would be possible for an Animesh using only ten bones in total to have a lower Land Impact / rendering cost than one rigged to 10 out of the 110 bones of the default skeleton. Short answer: no, not without custom rigs.
Custom rigs themselves are acknowledged as something SL should have, but the work involved in enabling them is extensive and touches on multiple areas (e.g. re-targeting bones for clothing fits; re-targeting animations – and even a couple overhaul of the animation system -, etc.). There is also work to be carried out elsewhere that would yield benefits for things like quality of life which are of a higher priority. As such, custom rigs are not something currently on the roadmap.
In-world mesh creation tools: unlikely to be a thing, as the implementation would be costly in time and effort, and likely would not measure up to the capabilities of external tools like Blender.
It was asked if the import route for rigged meshes could be “streamlined” without the need for AvatarStar / MayaStar. Neither of these tool are actually a requirement for rigged mesh import / export, rather they are tools that can help with the process of rigging from within SL. Meshes that have been correctly rigged and weighted using external tools should import correctly through the current import mechanisms (COLLADA or glTF).
Overhauling the mesh import file format / process through the support of something like OpenUSD is an idea that is being mulled over within the Lab. However, a) this is not something that is likely to be prioritised in the next 12 months; b) it is something that would require a lot more in the way of discussion before moving towards it; c) there is still work to be done in improving the import / export of currently supported formats before trying to add to them / replace them.
Materials import for meshes: this is something the Lab wanted to implement for glTF mesh import (rather than having to import materials separately).
However, due to the way in which asset uploads to SL work, it proved to be more a complex issue than first thought.
The hope is that the work can be returned to in the future, possibly using a new import flow that is more in line with other platforms and tools, but this is not something on the current roadmap.
PBR specular support: this is still something Geenz would personally like to get done, but it is currently sitting behind various other items which need to be completed / implemented in order to clear time for working on it. Also, this work does have impacts on things like the glTF upload validator, scripting, simulator support, managing glTF overrides (which are currently not well handled) etc., all of which would have to be factored into the work and which are outside of Geenz’s immediate responsibilities.
In terms of extending glTF support in general (PBR specular, IoR, etc.), the preference at the moment is to fix more of the existing issues / bugs within the existing PBR capabilities before adding further options.
The meeting was somewhat sidetracked by talk on the use of bots, ToS bot violations, Tiny Empires, etc., the majority of which are more of a Governance issue.
Fans of the Avatar franchise may recognise the term, given it is one of two “common names” (so to speak) by which Ewya, the globally distributed consciousness of Pandora is known; the other being the All-Mother. As such, it should come as no surprise that this is something of a personal homage to the Avatar movies whilst also being entirely unique as a setting in its own right; a place of infinite beauty; one that is utterly immersive.
Dive into the deep primordial forest, an ongoing passion project for Benny Vortex. Discover a lush, bioluminescent dreamscape of sights and sounds nestled below breath-taking floating islands under the silent gaze of a gas giant. May the spirits guide you.
– The Great Mother’s Destination Guide description
The Great Mother, January 2026
Occupying a Full region called – appropriately enough – Eywa, the setting captivates from the start. But before getting into specifics, there are some recommendations for enjoying a visit:
Preferably, visit using a PBR-enabled viewer.
Make sure you enable the local music stream to enjoy a soundtrack fully in keeping with the setting.
Use the shared region environment settings.
The Great Mother, January 2026
Also, make sure you have local sounds enabled – this is an absolute must, as Benny has created an immersive soundscape, covering everything from the deep, echoing sounds of Pandora’s forests and creatures through to the sound of your own footsteps rustling the moss and grass. That said, don’t expect to encounter any of Pandora’s beasts – or ioang – whilst you may hear them in the distance, this is a place of sanctuary and spiritual awakening. However, if you opt to visit in a Na’vi avatar, that would be both appropriate and welcome.
Finally, do be aware that The Great Mother is very much a work in progress: whilst now open at the ground level, Benny has plans for vertical expansion and more. In fact, the Landing Point itself is in the air and presents the first of the setting’s unique elements.
The Great Mother, January 2026
Forming a small island, the landing Point is marked by a number of rope slides. Each of these bares a symbol scratched into its wooden frame, indicating the area of the biome below in which you will arrive. Pick the one you fancy and ride it down to a smaller floating island, where a dive mat awaits.
Sit on the dive mat, select your preferred dive (and style, if offered), and take the leap! Whichever area of the biome you selected, you will land in water. As you do so, a dialogue box will be displayed with a couple of options – one being a return to the diving mat and going again, if you wish.
The Great Mother, January 2026
However, to explore, ignore the dialogue – but do not stand up. You are still running an animation tied to the dive mat, and you can use it to swim through the water and / or to shore, where upon the animation will release you and allow you to walk.
Whichever rope slide you take, it likely won’t be the last, within the forest and waterways below are ropes to climb and rope traverses pass through the higher boughs, and trails over land and across water to be explored, together with discoveries to be made. Keep an eye out for seeds marking potential points of interest as you explore. Overhead, further off-region islands hang in the night sky whilst a massive Jupiter-like gas giant watches over the comings and goings of this living world.
The Great Mother, January 2026
Extensive use is made of Elicio Ember’s fabulous plants, their bioluminescent fronds and petals well suited to representing Pandora’s own rich mixture of plant life, and this further brings the setting to life. As with the ideals of Eywa as well, there is a balance of lands and water throughout the region, with water channels as much as dry land trails offering routes of exploration – indeed, as Benny noted to me, the entire region is navigable by canoe.
As to what drew him to create such an environment, ad his future plans for expansion, Benny had this to say:
I really love the concept of the film and as a biologist/mycologist RL I can’t get enough of bioluminescent organisms. The next mission will be above 1000m with floating islands and waterfalls, and as I’ve also put a deep channel running through the region, I will eventually make it mer-friendly, and such.
– Benny Vortex on developing The Great Mother
The Great Mother, January 2026
Merfolk per se might not be a formal part of the Pandora ecosystem – although the Na’vi clearly have a relationship with the seas of their world – providing such a merfolk environment within The Great Mother does, to me, fit, and further extends the inclusiveness of the setting as a whole.
While I could write far more on the region, the truth is, it doesn’t need explanation – it deserves exploration and time spent with in it. As such, I’m going to wrap this up with a thank you to Benny for the invitation and the chance to explore for myself, and to strongly urge all Second Life explorers to visit Eywa and The Great Mother.
Campwich Forest grounds: location for the Monthly Mobile User Group (MMUG)
The following notes were taken from the Thursday, January 29th 2026 Monthly Mobile User Group (MMUG) meeting. These notes should not be taken as a full transcript of the meeting, which was largely held in Voice, but rather a summary of the key topics discussed.
The meeting was recorded by Pantera, and her video is embedded at the end of this summary – my thanks, as always to her in providing it.
The Mobile User Group provides a platform to share insights on recent mobile updates and upcoming features, and to receive feedback directly from users.
These meetings are conducted (as a rule):
The last Thursday of every month at 12:00 noon SLT.
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.
SL Mobile is seeing new users signing-up and joining SL, this led to the creation of a series of New Start Locations for those coming in via Mobile to be able to easily reach, and which have been put together by the location creators specifically to be Mobile-friendly.
SL Mobile New Starter Experiences front-and-centre.
The range of available experiences is being expanded, with the latest being a Brazilian-based experience – the Brazilian Beach Hangout – offering Voice in both English and Portuguese.
As many are aware (and a part of ), there is an invite-only SL Mobile Alpha group providing early access to users to help test upcoming Mobile features and updates prior to them being made publicly available through the main Beta programme on Android and iOS.
The app for this programme is entirely separate to the app available via the Apple and Google stores.
The most recent releases to Alpha include Bubble Chat and single-taps.
Bubble Chat
This is is response to complaints about having to switch views / trying to remain in contact with the in-world scene when using chat.
Allows chat and incoming IM’s to be viewed over the in-world scene, and allow tap-to-reply.
In the initial iteration, tapping a message to reply will still take a user back to the menu to show the keyboard.
However, as the feature is expanded, it is hoped that it will enable the keyboard overlay to be displayed over the in-world scene to allow for faster responses without having to switch away.
Bubble Chat is also seen as a means of encouraging greater use of Mobile rather than just a quick “checking in” tool.
Interactions with SL Mobile can be “tedious” in terms of the number of taps, etc., required to initiate an action – such as chatting, finding a person’s name / profiles, etc., and even interacting with objects.
Single Tap to Interact replaces the current long press required to garner a response from objects in the world view (display the context menu). When tapping on an item, Single Tap will display the top items in the context menu as an overlay to the in-world view. So for example:
Tapping on an avatar will display the options to send an IM or Friend request or expand the menu to see more options – such as their Profile.
Tapping on an in-world object will similarly display the most common options in the context menu (e.g. “sit” if it is chair / seat), with an option to display the rest of the context menu.
Like Bubble Chat, Single Tap is seen as a means to increase on-going use of SL Mobile beyond being an adjunct to using the viewer, and allow greater opportunity for users to be active in SL when using Mobile.
Bubble Chat is seen as relatively “easy” to implement, outside of one or two quirks in how Unity handles uniformity of presentation of things like overlays, which does require a little additional work to solve.
Single Tap to Interact is a more complex subject, as it not only involves changes to the underlying touch functionality, it is also attempting to more accurately map on-screen taps to ensure the right focus and the the resultant correct menu is displayed.
On-screen interactions – touch, tap, etc., – can be seen as collisions, which require a degree of physics calculations. Generally in SL the vast majority of physics interactions and collisions are managed by the server – the viewer is essentially “dumb” to them.
With Mobile, this can lead to inaccuracies arising between where the screen is touched and where the simulator thinks it has been touched, simply because of the network latency involved in back-and-forth communications and calculations, resulting in the noted frustrations with long-touch, etc.
So as a part of the implementation of Single Tap, it was decided to incorporate some of the physics-related calculations into the app itself.
Incorporating physics calculations into the app has involved building a “mini physics simulator”, capable of loading all of the physics colliders into the app’s already constrained memory limits (so effectively pre-caching them), and providing a means for the colliders and calculations to be recognised by, and accurately passed between, two different physics engines – Havok on the simulator, Unity’s own in the app.
Whilst complex, this has resulted in a significant reduction in latency between touch and response and in ensuring the relevant menu appears, and with little to no added latency resulting from the device hardware having to do all the pre-caching and calculations. the only appreciable impact is on networking bandwidth during the pre-caching process.
A further help here is that the Unity physics engine can be switched off excepted for when actually required, thus removing a continuous overhead for the app.
This work will also help with other physics-related interactions down the road.
Stability: the Lab uses both their own internal metrics and those from the app stores to monitor SL Mobile’s overall stability.
There has been a steady decrease in Android crash rates, and a further fix is coming in the next production beta release of Mobile.
New work being initiated (no due dates / target release dates at present):
Persistent chat (i.e. chat histories persisting between Mobile and viewer, rather than being broken by using one or the other).
Chat logging.
More work on language localisation for Mobile.
Map and Search:
Search: Web search is already Mobile responsive, but hard to use. To overcome this, this preferred route at present is to take Web Search and put it into Mobile as an embedded view. This requires a certain amount of work, which is in progress in terms of how to best present Web Search within the app and ensure its performance, prior to actually embedding it into the the app.
Map support: starting to be looked at as a facet of Search, with the hope that the two will be fairly well integrated with each other in the future and where relevant (e.g. toggling between Search and the Map when searching for places). Once this is in place, the Mobile team will look to build further viewer World Map functionality into the Mobile Map.
General Q&A
What is SL Mobile’s maximum Draw Distance?
Up to 250 metres can be selected (but not recommended), but the app currently defaults to 40-50 metres to reduce the memory load.
As a rule of thumb, every additional 10 metres of draw distance can result in 30%+ of the app’s memory allocation (determined by the OS / hardware) to rendering alone.
Higher distances can be set at the user’s discretion via settings, but these can impact performance., and many of the higher settings (100m+) are not recommended for general use, as noted here and in the app.
A danger with exceeding memory limits in an app is that the OS will simply drop it without warning.
Concern was expressed about content being suitable for Mobile consumption – LODs, Land Impact, etc., – and on the need to encourage content creators to think Mobile in their work.
The Mobile app does actually carry out a degree of object culling to lighten the load – small objects, for example, aren’t rendered unless directly focused upon.
There have been internal discussions at the Lab about Land impact and how it relates to Mobile, but no firm decisions have been taken.
The matter of LODs and content creation tools vis-à-vis Mobile has also been discussed, but again, no firm decisions have as yet been made. LOD models are a part of a wider discussion overall for SL, given they also impact lower-specification hardware running the viewer, and there are on-going talks (e.g. through the Content Creation User Group) on LODs, automatic LOD generation, decomposition tools, etc.
PBR, Shadows and EEP support:
PBR – not yet.
Shadows – yes, supported, but is device-dependent, as shadow rendering is expensive (e.g. can as much as triple the rendering complexity for a scene).
EEP – limited support, with two passes of integration carried out so far. More work is required on this (e.g. average scene lighting to bring Unity’s lighting more into line with how scenes appear on the viewer), but it is not an easy task in terms of future maintenance.
Will SL Mobile support:
In-scene dialogue menus (i.e. the blue menus displayed when touching scripted object in the viewer)? – Yes, possibly in the next couple of months.
A walk / run / fly toggle on the movement joystick? – This is something that LL would like to support down the road.
Alpha Texture support: there are two primary issues in managing alphas on Mobile:
Formats: the viewer uses JPEG2000 for textures, Mobile uses a variety of formats which are hardware-dependent, and so additional work such as switching out texture formats is required – which itself can be problematic (e.g. can invalidate texture caches and cause issues such as slow loading, etc.). However, Adam Sinewave (Mobile Lead Developer) does have a potential fix for this in the works.
Tiled-based GPUs: these are common on mobile hardware and do not like overdraw (rendering the same texture multiple times, required for alphas).
Both of these mean that Mobile uses a mix of dithered alpha rendering and temporal anti-aliasing to achieve the desired result. This actually simplifies alpha rendering on Mobile, but does produce unwanted artefacts on transparency, some of which will be hopefully resolved, others of which might continue to result in differences in how alphas appear on Mobile compared to the viewer.
Will SL Mobile be made available through other mechanisms than Google Play Store? Possibly, the idea of providing Android Package Kits (APKs) has been discussed, but brings with it a distribution problem. Also, the idea of using Google’s update mechanism for apps has also been discussed, which would bind SL Mobile more to the Google Play Store.
Minimum requirements for Mobile: these are somewhat hardware constrained (CPU / GPU pairing). As a broad rule of thumb, SL Mobile requires a device with at least 4Gb of RAM, and preferably a more recently SoC combination of CPU/GPU.
Isola Sirena, January 2026 – click any image for full size
I came across Isola Sirena whilst perusing the Destination Guide. Comprising a pair of Full private regions, each leveraging the Land Capacity bonus offered by Linden Lab for such regions, it is an expansive, multi-faceted, multi-level setting with a lot to see and do throughout.
The work of Angel Kavanagh-Taylor (AngelWaldencork) and SL partner Kina Finest-Taylor-Kavanagh (Kina Amour), the setting also possesses several secrets worth discovering. The main starting point for explorations is located in the more westward of the two region, Isola Sirena – Sunkissed Cove Beach.
A sun-drenched Mediterranean-inspired sim offering sweeping coastal views and dreamy escapes. Explore a hilltop restaurant, mini golf in the clouds, a charming winery and farmers market, and a stunning beach, with beautiful beachside and villa rentals.
– Isola Sirena About Land description.
Isola Sirena, January 2026
It is here, perched on a high mesa, is a complex of Landing and Information point, offering teleport boards to reach the majority of the setting’s major locations, several of which are located within the complex itself: the Game Room, La Vetta d’Oro, Mixology Bar, and outside, via the terrace, the Summit Infinity Pool and the Plaza. However, the best way to explore and discover most of the locations is on foot (with one exception!).
On the south side of the mesa lies a small village reached by one of two routes from the Landing Point complex. This, like the mesa’s summit, offers clear views out to the off-region surrounds which give the impression both regions are part of a broader Mediterranean location. However, to fully appreciate the extent of this, Draw Distance will likely have to be raised.
Isola Sirena, January 2026
Parts of the village appear to be for rent as businesses or homes. How extensive these rentals might be wasn’t clear to me: many were empty; and without rental boxes, others were furnished as homes and include rental boxes. The village and its footpaths step down toward the region’s beach, passing by way of La Tavola di Eleanora Café, which can also be reached via the main teleporter boards, as can the beach below.
The beach itself offers a mix of public spaces and rental beach cabins, together with the hackney carriage ride, a jet ski rezzer, a swim assist board and the beach bar. At the south-western end of the beach can be found the Meditation Point and Beach Club, both reached via the Teleporter boards, and the former also by the Beach boardwalk.
Isola Sirena, January 2026
A covered bridge provides access to the setting’s mid-point island, home to the stables and farmer’s market, and which also provides bridge access to an eat-point tongue of land extending out from the base of the mesa to connect with the second region of the setting. The appears to be largely given over to villas available for rent. However, it is also home to one of the setting’s secrets: the bathing cavern.
This is quite exquisitely done, the entrance offering something of a backstory to the cavern’s discovery. Offering, as its name suggests, a place to bathe in warm waters offering places to sit and cuddle around the edges of the pool all set within a location suggestive of great age. The main pool surrounded by tall statues, some of whom hold shells from which water falls to replenish the pool below. It is a place suggestive of a relaxed, hedonistic beauty.
Isola Sirena, January 2026
Set to one side of the main pool is a blank cave entrance, a sign indicating it is the way up to the sun-based caverns.
These are equally magical in their design, and also entirely otherworldly. The path through them is well signed, and there are places here to pass the time alone or in company. Exploring them is an absolute must, whether via the bathing cavern (recommended) or the main teleporter boards. Nor are these the only caves to be found within the setting – but all let you find the others, accessible as they are from the ground and (again) the Teleport boards.
Isola Sirena, January 2026
Eastwards, past the villa the land flows into Isola Sirena – Winery and Countryside. This again appears to be given over to villas available for rent, together with the Vetta Oro Vinicola wine bar and the Winery itself. The latter has its own secret located on the shoulder of the hill to one side of it. Guarded by a stone carving of a young (weeping?) woman, lies a stairway leading down to the wine cellar.
And there is still more to be found – from bumper boats to picnic areas and seating – and of course, the pair of small islands held aloft by balloons and home to mini golf, as mentioned in the setting’s description and which gives it a little twist of the surreal.
Isola Sirena, January 2026
I will confess to having some small niggles with Isola Sirena. The main caverns are at altitude, and so are ideal for their own dedicated EEP setting. Similarly, the cavern baths also look as if they could be placed in a parcel with its own EEP. This would avoid the need for sign posts asking people to change their setting locally, and make the experience of exploring more immersive with seamless transitions.
Another minor niggle is with the wine cellar – the stairs down / up could benefit with rotation. As it is, they are placed in such a position that the camera is placed of the wrong side f the walls surrounding it, which can make for difficult navigation when climbing. A final small point is that raising Draw Distance to view both regions can lead to texture discards – the first time I’ve encountered this since LL worked on refining texture provisioning and loading; but there is a lot going on in both regions , texture-wise.
Isola Sirena, January 2026
These niggles don’t spoil the overall impact of the regions or the setting as a whole. And it has to be said, that taken individually or together in a single visit, the regions of Isola Sirena make for an engaging visit, one worth eschewing the Teleporter boards in favour of exploration on foot.
Inara Pey: Living in a Modemworld 