Gavin Hird

👍 Just to elaborate on that, afaik the difference is that on Linux, wine and crossover allows direct access to the GPU, so you get reasonably good OpenGL performance. On macOS it don't. It probably falls back to the Apple OpenGL CPU renderer.

I don't use it simply because it is a complete mess on macOS, and it is very difficult to get anything to run on it. I have had reports that Linux users have successfully run my opensim Windows version viewer in Crossover or Wine.

It probably wont, unless the Rosetta2 emulated OpenGL can take advantage of all the GPU-cores.

Run on what? – Apple Silicon? Generally Mac users respond very poorly to the suggestion of running Windows apps on their Macs. So that is not a solution, if that is what you ask. To the extent it actually runs, it will still be dependent on Rosetta2. In theory a Windows version of the viewer could run in Windows 11 ARM version with x86 emulation in VMware Fusion for Apple Silicon, but Microsoft has so far said they will not support that in any way. Add to that, VMWare has said it will not take on the task of writing their own Intel emulation on Apple Silicon. (which for all practical purposes would require deep support from Apple).

The TPV viewers would not exist unless LL open sourced the viewer code, so that is correct. You do, however significantly overestimate the influence of the TPVs on the survivability of SL. In many respects they have both hampered and slowed down the development of SL. Additionally, during the development of Sansar, LL added significantly new functionality and support to the viewer code, which was done largely outside TPV influence at all. When it comes to a native ARM viewer, there are two significant issues, of which one affects all ARM builds regardless of who made the hardware: Many of the libraries used by the current viewer are significantly outdated and don't compile on ARM without up to significant effort. In the case of Apple, there is also the issue of OpenGL, which simply don't exist, and Apple has no interest in developing and maintaining. The rewrite to Metal is complicated both because the OpenGL code is interwoven in the current viewer code in such a manner that it is hard to entangle. In addition the entire UI is rendered in OpenGL, and not only the 3D view. While most of the current viewer is written in C++, to take advantage of that for a Metal version, you have to enable Objective-C++, which is currently not possible given the current state of the code base. The reason for this is that the Metal libraries can only be used with Objective-C or Swift. Using Objective-C++ is the shortest route, as a Swift rewrite is exactly that – a rewrite, and from the ground up. Unless LL has a secret viewer project for the Mac, I see no trace of coding activity that is required to support future Macs (or i-devices) once Apple turns off the switch on OpenGL. As a Mac user in SL and opensim since 2007 and 2008 respectively, it is painful to watch. (I also develop a viewer for opensim on the same codebase with opensim modifications + Mac specific code for the macOS version).

Actually the current 0.9.2 dev branch is better than it ever was, but Microsoft is creating issues wanting everyone over to .NET5 or higher, and opensim server is written for .NET 4.6 right now, and needs a rather big rewrite to run on .NET5. In addition mono (for the same reasons) have not been updated for a year because MS also want those users over to .NET5. So that is obviously an issue for running opensim on Linux/macOS servers. (MS took over the mono project). As an example, it is not possible to compile opensim server on debian 11 unless you coerce it to use old mono builds. 64-bit ARM builds you can just forget.

It will not continue after Apple only ships Apple Silicon Macs. The current OpenGL implementation runs in Rosetta2 emulation, and the only thing they have done is to write a HAL to the (new) AS GPUs in the same manner as they previously did on the A-processors for the OpenGL ES when it was supported on the i-devices. There is no native OpenGL implementation at all on Apple Silicon, and there never will be.

The development of the Mac viewer is to a large extent done in Xcode, and every version of the viewer is compiled from an Xcode project that is generated by cmake via LL's autobuild py scripts. You obviously have no clue what you are talking about. Just look to opensim and see what happens when you leave it all to open source and the free ***** Linux user community unwilling to pay for anything (throw in a bunch of Windows users in that bunch too).

By my estimation, the minute Apple pull their last Intel machines from marketing (and at the same time zaps OpenGL). LL will announce no support for the Mac viewer. This should happen by this time next year latest. So, yeah...

Exactly. So you have to pick your target from what is your profit (or other) motive. Mac, iPad and iOS users are usually both willing and able to pay. At the other end of the scale is the whiny Linux base who don't want to pay for anything but the graphics card and CPU, but otherwise don't want to pay for anything in-world. Allegedly 25% of the creators in SL are Mac users.

No, you would widen your potential user base by about 1 billion users. If you get 1 million of those being active, you have doubled the current user community.

The Xcode tools makes it possible to write the same application that runs both on macOS, iPadOS and iOS with relatively small variations in the UI code. Your opinion of this is significantly outdated.

The motivation for re-writing for Metal is not the 5% (actually 15% according to LL) Mac users, but to address the very large i-device market. Remember, the M1 processor is essentially the same as the A14 that sits in the latest iPhones and iPads - devices which are perfectly capable of running a viewer both when it comes to processor, memory and screen. Obviously the UI must be updated for touch or at least controller.

There is no Apple Silicon native OpenGL, so the viewer will not compile at all. In addition, there is a dependency of a lot of rather old libraries, many of which most likely will not compile on Apple Silicon without significant updates.

Running great on the Mac Pro with 3.5 Ghz 6-core Intel Xeon E5, 64 GB memory, AMD Firepro D500 3GB and macOS 11.5.2 (Big Sur). The iMac tested above runs macOS 10.15.7 (Catalina) Struggling a bit more on the M1 Mac mini with the same settings as on the two machines above, but that is to be expected given it is running on macOS 12.0 beta 5 (Monterey) which is full of debugging code. It also runs under Rosetta2 emulation, and the GPU - while being a significant improvement over previous Mac minis, is not exactly stellar. Macbook Pro 2012 with macOS 10.15.7 (Catalina) and 2.3 Ghz Quad-Core Intel i7, 16 GB memory and NVIDIA Geforce GT 650M 512 MB was struggling more but that is to be expected given the rather weak GPU. The texture memory was also as default set to 512 MB. Lowering this to 384 MB improved frame rates a bit, but only became useable with shadows turned off. Since this machine don't have a Retina display, turning off HDPT improved framerates a bit more. All the above was tested with a viewer window size of 1680 x 1050. Mesh objects quality set to lowest High setting and Shadows turned on. I'd say this is overall a GREAT start!

I gave it a quick whirl on an iMac 2017 with Radeon Pro 575 4 GB, 24 GB memory and 3,5 GHz Quad-Core Intel Core i5, and it felt as responsive as, if not faster, than most of the Mac viewers out there, so a very good start. Noticeably it rezzed the scene within seconds compared to other viewers (including the SL one) which can take minutes to drag down enough textures to make the avatar decloud and the scene to shift from grey to textured. One thing was that it did not seem to retrieve inventory till you clicked on each inventory folder, which would pause/hesitate a bit before the number of items in each folder was displayed. I see from the Info.plist that the deployment target is macOS 10.9, which also the SL viewer is compiled to, but that is just crazy old, and you will get sub-optimal performance because of that. At a minimum you should set target to 10.12 and even that is getting old as minimum supported system version from Apple now is 10.14, which will change to 10.15 in a few weeks time. Setting the target higher will produce more deprecation messages during build, but that is just the reality of things to come. I'll test it on a 2012 MacBook Pro, a 2013 Mac PRO and a 2020 Mac mini M1 and see how it performs.

There is no prims, but while attached meshes are loading, it can display some really weird artifacts till the mesh is fully rendered. This is particularly evident if the viewer is on a slow connection or the asset server is slow to deliver a mesh (you can often see this in some opensim installations). Some builds may also use prims for physics, and those could show while the mesh is loading. Obviously they will be embedded in the mesh as they are never meant to be visible.

Not sure what you mean by companion prims? All the original prims are low poly meshes which can be morphed into many shapes. They are also quite efficient as building blocks for many purposes as they have flexible texturing and you don't need to add physics. Removing them would break a large amount of builds and content. The absolute worst are sculpt, which they simply should get rid of. A full 128x128 sculpt map will create a mesh of 16834 vertices. Many sculpted panel plants still used throughout are made from 32x32 sculpt maps which are 1024 vertices, but often the creator have used a bigger map. A similar panel plant can be made from 12 vertices with an uploaded mesh, and is infinitely more efficient for the renderer. What makes sculpt even worse is that a large number of the vertices are often hidden, imposing an extra burden on the renderer in the pass that calculates transparency.

The prims don't go anywhere. The renderer (the most important part of the viewer) which paints what you see in world to the screen has a pass per frame where it calculates what is obscured by other objects. So if the prims are obscured by an overlying mesh, it simply drops painting the prims into the 2D frame that is sent to your screen. The result is they appear to be hidden. Transparency can also influence what is obscured, so the renderer also has a pass to apply transparency to objects before it finally paints out what shall be visible or not in a frame. From a performance standpoint, remove all prims you might wear from the outfit if these prims will be obscured by the meshes you wear. The more you pile on, the harder the renderer must work to figure out what shall and shall not be visible, resulting in lower frame rates.

In my experience many ISPs inserts Cloudflare between you and the CDN, so that is another hurdle for your content to load. I could very well be that Cloudflare actually throttles. Usually, when I arrive in SL after having been absent for some days, it takes minutes for a region to even start loading textures on objects, and I suspect a combination of the CDN has discarded the content from cache and has to dig deep in the storage to fetch it, or even replicate from another peer, in addition to Cloudflare starting to fill its caches en route.

There is absolutely no need to calibrate the on screen display at all. It would only make it worse. An external display connected to the system can possibly need a calibration unless the system auto-detects a profile for it. Then it is probably better left as is.

Are you running the machine in the evening with nightshift on? That will change the warmth of the colors. Also remember that this machine has a 10-bit per color dynamic range, and a different color gamut than the viewer is developed for, so it will in most situations look better. Windows will look washed out in comparison. It also use True Tone which further change how colors look on the screen. https://www.pocket-lint.com/tablets/news/apple/137264-what-is-apple-true-tone-display

Apple has deprecated OpenGL and it will most likely be zapped completely from macOS the day they ship their latest Intel based Macs. From then on it is Metal only both on Intel and Apple Silicon. They have said the transition from Intel will be max 2 years, but if could be faster. We are soon 6 months into the transition period. The consequence of that is that the Mac viewer must be rewritten from scratch because the Metal libraries ONLY work with Objective-C or Swift, and 99.99% of the viewer code is C++. In addition to OpenGL that is used both to generate the entire user interface and render the world. This is a monumental undertaking. Unfortunately I don't see any project to move the Mac viewer forward and give it a future.

As long as the virtual reality is operated by live humans sitting behind their screens with a virtual representation of themselves it would be concidered a real world activity, for which your local police could arrest you if you broke local law. SL is not automata or a programmed game.

Your country will hold you responsible for your actions sitting behind your computer. LL can be held responsible for facilitating your actions and not blocking them, and that can be extended to AWS.