Gavin Hird

Based on Unity. Very limited in terms of functionality Not that Unity necessarily is bad, but I don't think it has the ability to render and handle a dynamic environment like SecondLife. Then there is the licensing issue that basically makes it out of reach for any TPV development.

Checked out the latest Firestorm on a Mac Mini M2 and it runs fine with PBR content (have not found a mirror yet, so that is untested). Machine is running macOS Ventura, so if the bad experience is on a Mac running Sonoma it might behave different because Apple have started removing support in newer drivers included in the newest system versions.

When Apple deprecates something they basically stop development of the feature and let it fade out into oblivion till the day it is completely removed. OpenGL 4.6 barely was a thing when OpenGL got deprecated (2018)

After VMware (now Broadcom) added OpenGL 4.3 support to VMware Fusion Pro for Apple Silicon (ARM) and Microsoft sort of upgraded Windows for ARM's ability to run x86_64 binaries in emulation, I tested running the latest SL viewer 7.1.1 in such a virtual machine on macOS, and lo and behold it not only started, but also logged in to SecondLife. It did not exactly run as a screamer at around 7 fps, but the VM was only given 2 CPU cores, 5 GB RAM and 768 MB of graphics memory to play with on a barebones M2 Mac mini. A more capable Mac should improve the performance. Maybe Windows on ARM, even in a virtual machine is starting to become a thing? Fusion Pro, and the accompanying Workstation Pro is now a free download from Broadcom for private users.

Why do you think OpenGL is going to be updated. Apple has explicitly deprecated OpenGL and will NOT update it ever again. It will be removed from system service the minute they stop supporting Intel based Macs (which might even happen this fall, but more likely in 2025)

The Mac viewer has never been of any priority for LL. It has merely been a tick off item to attract a certain group of creative users that can contribute to the SecondLife economy; users who will not switch to Windows. Granted, Apple's systems has historically had weak graphics performance with a lot of Apple specific idiosyncrasies, so that has not encouraged LL to do much more than minimum effort to make something running. – Which is why the codebase is at it is. 😐

OpenGL support will be removed once the OS support for the last Intel based Mac Pro is over. I'll give it 1 1/2 more years toppers. I really don't see much point in rewriting the ObjC code that exist in the current viewer in Swift. If you look at my repository I have used bridging code to get rid of autorelease pools (did this many years ago) and a few other changes. I have also converted in the order of 12500 BOOL (still ongoing). That alone makes portions of the code faster as the compiler can optimize on native bools and not on random ints.

I am sorry, no From my standpoint rewriting in Swift is pointless as it is both a (very) major undertaking, but also makes the codebase for Apple platforms totally incompatible with the Windows, Xbox or whatever other platforms LL wants to pursue. I don't see Apple dropping C++ and ObjectiveC support anytime soon. The very first objective is to clean up the C++ code base to the point you can start using Apple libraries everywhere; being getting rid of all the BOOL so the codebase effectively becomes a ObjectiveC++ base (other cleanup needed). Boost also has to go. The above means you can use a good portion of the C++ code as is, and start replacing functionality with Apple libraries for audio, video, get rid of the monstrosity that is the embedded browser and replace it with WKWebview, use native system threading and scheduling, network stack, preference management, add iCloud support, Apple SIMD, Apple compression libraries etc, etc. Separate the OpenGL view to purely render in-world, overlaid by a 2D view for the UI. Move all menus to standard Apple menus, all UI widgets to be based on standard Apple UI widgets (with necessary modifications), essentially stopping to render any UI in OpenGL. Finally rewrite the world rendering in Metal. Vulkan is a dead end on Apple platforms. If you want to be in business in Apple platforms, you cannot make your product dependent on a 3rd party for the very core functionality that will and can break at any time. Apple is never going to design for or test that Vulkan will work. I know it is a tall charge, but the reward is a viewer that can run on all Apple platforms with a, depending on how you count, 1-2 billion user base.

What? Do you mean macOS 10 in the documentation. If that is what you mean, LSMinimumSystemVersion is supported from macOS 10 till this day. I run systems from macOS Catalina through to Sonoma to test my viewer builds, so not sure what you mean. Minimum system requirement for my viewer is 10.15 (Catalina)

Info.plist in "Second Life Viewer.app/Contents/" says otherwise. The minimum system version is marked as <key>LSMinimumSystemVersion</key> <string>10.13</string> The info in the Info.plist is what tells macOS what the minimum system requirement is. If the macOS version is lower than the minimum requirement, Finder will show a special icon across the app icon that it is incompatible, and will not even attempt to launch the app. https://developer.apple.com/documentation/bundleresources/information_property_list/lsminimumsystemversion?language=objc

Try take the settings.xml file in ~/Library/Application\ Support/SecondLife/user_settings and move it to the Desktop and see if the viewer will start.

I think you are reading too much into it. RLV was used as the general understood term and not a specific implementation. Besides, isn't Marine Kelly the original creator of RLV, so one would assume she implements the reference version? Another thing is how much functionality do you need if you are going to sit locked down in one spot gagged out (no sound and speech) staring at a black screen? 🤣

RLV support in the SL Viewer anyone?

I also got the messages about not having minimum requirements on an M2, and it set all graphics to minimum. I suspect it might have to do with using SL viewer settings (I upgraded it to version 7 today) and there is also the settings.xml file in user_settings that might interfere with this viewer.

I see why it did not run because it use the SecondLife folder in ~Library/Application Support, which is an exceptional bad idea for a viewer. There was tons on log spew and crashdumps where it tried to use SL Viewer Settings files in addition to the SL Viewer caches. So my initial suggestion to you is to get that sorted, so you don't overwrite SL viewer settings and make sure you have full control of your own including the caches.