18 June 2018

Firestorm and OS X Mojave

At the Apple Worldwide Developer's Conference held a few weeks ago, Apple announced OS X 10.14 Mojave. In amongst all of the other things Apple announced, one announcement has made waves in the gaming world: they announced that, as of Mojave, OpenGL was deprecated and would no longer be maintained.

This is important because Firestorm, like every other graphical Second Life viewer, is based on OpenGL

I got an email from a concerned user this morning asking about the problem and urging us to convert Firestorm to Metal, Apple's new and improved 3D graphics API. Here's my reply:

***

What follows is my own personal opinion. I’m not speaking for the Firestorm team, and certainly not for Linden Lab.

I think Apple seriously shot themselves in the ass with their recent announcement. In essence, they told the gaming world to drop dead.

First, what they did and didn’t announce. What they did announce was that Mojave would deprecate OpenGL. What they did not announce was a drop-dead release beyond which OpenGL would not work. Indeed, OpenGL works in Mojave, and with a couple of fixes not related to the graphics subsystem, the Linden viewer (and, presumably, Firestorm; we haven’t tested it ourselves) runs on Mojave just fine. Those fixes will be in the next release of Firestorm, which we are moving toward.

To understand the magnitude of the problem, let me lay a couple of numbers on you. Firestorm currently consists of 25,649 files of source code, containing well over 1.2 million lines. I don’t know just how much of that is OpenGL code. What I do know is that there is no clean boundary in the viewer’s source code between the parts that use OpenGL and the parts that don’t; OpenGL is scattered throughout the entire codebase. This is true of every viewer based on the Linden Lab code, which is all of them that do graphics (with the notable exception of Lumiya, which was a ground-up implementation for Android, and a remarkable technical achievement in its own right). Some of that code is over 20 years old at this point.

Simply to factor all of that out so there’s a clean separation between the graphics code and the rest of the viewer is a monumental task. And that’s just a preliminary. Once that’s done, then a separate renderer would need to be written just for the Mac. That’s not a trivial undertaking, and to the best of my knowledge, there are exactly five people on the planet who understand the Second Life render pipeline well enough to do it: two of them work for Linden Lab, and the other three are certifiably insane. None of them are on the Firestorm team. In any event, the effort required to do this is measured in man-years.

It’s telling that Apple committed large amounts of time and money and people resources to Unity and Unreal to get their game engines ported to Metal. I’d be astounded if they did the same for Second Life. The market is simply too small.

My understanding of the Linden Lab position on this is that they’re evaluating what they are going to do going forward, and that no decisions have been made. I would hope they are at least talking with Apple to see how much time they have. They probably have contacts that let them do that. I do not, and in any case we’re dependent on what the Lab does.

While I am a faithful Mac user and have been for the last 16 years, I have not actually used a Mac as my primary Second Life system in a few years. Apple’s OpenGL implementation, not to put too fine a point on it, sucks. I usually get 30-40 FPS on one scene I spend a lot of time in, on my dual-hex MacPro 3.3 GHz/64 GB, with a Radeon R9-280X. I have actually wound up running Linux Mint natively on a second Mac Pro, this one a dual-quad 2.9 GHz/48 GB with a GTX 960. On that same scene, with the same window size, I easily turn 140 FPS or so.

Personally, I don’t see how Second Life on the Mac, at least natively on OS X, will survive the loss of OpenGL. The market’s too small and the effort’s too large to make it economical. I personally expect to find myself running Firestorm exclusively on Linux, or else under Windows in a virtual machine on OS X (which I haven’t tested at all in the past several years) at some point in the future.

Again, I must remind you that Apple has deprecated OpenGL on OS X. All that means is that they will stop supporting it at some point in the future. That point is not today, and they have not said when that point is. Until they do, Second Life, and Firestorm, will run on OS X as well as it does now.

***

Update, 22 June: At his Meet the Lindens interview with Saffia Widdershins at the SL15B celebration yesterday, Oz said that "we will find a way to keep Second Life running on the Mac." This is good news. I hope it comes to pass.

24 January 2018

Don't just turn up RenderVolumeLODFactor!

Firestorm, like all Second Life viewers, has a large number of configuration settings. One of the most widely misunderstood is named RenderVolumeLODFactor. It’s not at all uncommon for Second Life content creators to tell their users that this should be set as high as possible so their creations can be seen properly.

But what is this magic value, and what does it really do?

LOD stands for “level of detail”, which means in how fine detail the viewer will render an object. A higher LOD means that the viewer will show the object with greater detail than a lower one. A small object rendered at a lower LOD will be shown as a simpler shape; a higher LOD will be rendered more accurately.

Of course, it takes more work to render a complex object then a simpler one, and the higher the LOD required to render it correctly, the harder your computer and graphics card have to work. If there are many objects with high LOD in a scene, your computer will slow down.

The viewer manages this by determining the required LOD based, in part, on how far away you are from the object. A small, complex object 20 meters away can be rendered with a lower LOD, and you’ll never notice the difference, because it doesn’t take up enough space on your screen to show all that detail anyway. If you move yourself (or the camera) closer, the LOD will go up because the object appears larger, and the details will become visible.

RenderVolumeLODFactor controls how the viewer adjusts the LOD based on your distance from the object. It’s used in calculating the actual LOD. A higher value makes the viewer compute a higher LOD, and render objects with more detail, than a lower value would for any given object and distance.

Content creators love to set this value high, so that your viewer shows their creations with all of the details they build in. Some creators recommend numbers in the thousands. This is a very, very bad idea.

Because a higher value makes your computer work harder, raising it needlessly slows your computer down without really doing anything to make things look better. A detail that takes up a third of a pixel on your screen won’t be visible no matter ho high you set the LOD factor. Your computer will still do extra work trying to show it, though.

Not only that, but the calculation that uses the RenderVolumeLODFactor value gives a totally meaningless result for any factor above 10. It won’t crash the viewer, but it doesn’t help matters, and you’re still running the computer much too hard to no purpose.

For the past couple of years, Firestorm has enforced a limit of 8 on that value. We recommend no higher than 4, and will reset the value to 4 if it’s set higher than that. The next release will also give you a warning if you attempt to set it higher than 4.

If you’re doing high-quality photography, then you may wish to set your RenderVolumeLODFactor higher than 4. before you do so as a matter of habit, though, try it at 4 and see if it makes any visible difference. Chances are it won’t.

We hope that creators who tell their customers to use extremely high RenderVolumeLODFactor values will stop doing so. All they’re doing is showing they don’t understand how things work.