#bakesonmesh — Public Fediverse posts

@OpenSim

I know it's tempting to disallow avatar scripts on your sims. I know that it can greatly improve the performance by killing off the heavy-weight scripts that some people wear on their avatars for whatever reasons of flashiness.

But keep in mind that the following things don't work anymore with avatar scripts off:

• Attached AOs. This may be one reason to disallow scripts because typical #SecondLife #ZHAO AOs use up tremendous amounts of server resources, and hardly any #OpenSimulator user has ever heard of #khAOs. But many #OpenSim users depend on attached AOs. They either don't know how to put an AO into their viewer, or they can't be bothered because attaching one is sooo much more convenient, and it gives you a HUD.
  
• Adjusting the foot position on most female mesh bodies from #SecondLife. Unless you've got your feet on "high" permanently, you can neither take your high heels off nor put them on.
  
• Switching the alpha mode on #Ruth2 v4 and #Roth2 v2. If it's forced to "off" when you teleport in, and your alpha masks stop working, you can't use your HUD to turn it back on, and you have to edit the body manually.¹
  
• The alpha HUD on pretty much all other mesh bodies. You can only change clothes if you don't need alpha-ing.
  
• Bento HUDs. You can't even correct your hands if your fingers are stretched into all directions.
  
• Sex, at least not if it involves at least one male avatar. Guys can't switch their boners on. Turning avatar scripts off on a sex-oriented sim is amongst the top five stupidest things you can possibly do as a sim owner.

¹By the way, yes, #BakesOnMesh supports alpha masks. If your mesh bodies don't, doesn't mean BoM as a whole doesn't.

#Metaverse #VirtualWorlds

@OpenSim

I know it's tempting to disallow avatar scripts on your sims. I know that it can greatly improve the performance by killing off the heavy-weight scripts that some people wear on their avatars for whatever reasons of flashiness.

But keep in mind that the following things don't work anymore with avatar scripts off:

• Attached AOs. This may be one reason to disallow scripts because typical #SecondLife #ZHAO AOs use up tremendous amounts of server resources, and hardly any #OpenSimulator user has ever heard of #khAOs. But many #OpenSim users depend on attached AOs. They either don't know how to put an AO into their viewer, or they can't be bothered because attaching one is sooo much more convenient, and it gives you a HUD.
  
• Adjusting the foot position on most female mesh bodies from #SecondLife. Unless you've got your feet on "high" permanently, you can neither take your high heels off nor put them on.
  
• Switching the alpha mode on #Ruth2 v4 and #Roth2 v2. If it's forced to "off" when you teleport in, and your alpha masks stop working, you can't use your HUD to turn it back on, and you have to edit the body manually.¹
  
• The alpha HUD on pretty much all other mesh bodies. You can only change clothes if you don't need alpha-ing.
  
• Bento HUDs. You can't even correct your hands if your fingers are stretched into all directions.
  
• Sex, at least not if it involves at least one male avatar. Guys can't switch their boners on. Turning avatar scripts off on a sex-oriented sim is amongst the top five stupidest things you can possibly do as a sim owner.

¹By the way, yes, #BakesOnMesh supports alpha masks. If your mesh bodies don't, doesn't mean BoM as a whole doesn't.

#Metaverse #VirtualWorlds

@OpenSim

I know it's tempting to disallow avatar scripts on your sims. I know that it can greatly improve the performance by killing off the heavy-weight scripts that some people wear on their avatars for whatever reasons of flashiness.

But keep in mind that the following things don't work anymore with avatar scripts off:

• Attached AOs. This may be one reason to disallow scripts because typical #SecondLife #ZHAO AOs use up tremendous amounts of server resources, and hardly any #OpenSimulator user has ever heard of #khAOs. But many #OpenSim users depend on attached AOs. They either don't know how to put an AO into their viewer, or they can't be bothered because attaching one is sooo much more convenient, and it gives you a HUD.
  
• Adjusting the foot position on most female mesh bodies from #SecondLife. Unless you've got your feet on "high" permanently, you can neither take your high heels off nor put them on.
  
• Switching the alpha mode on #Ruth2 v4 and #Roth2 v2. If it's forced to "off" when you teleport in, and your alpha masks stop working, you can't use your HUD to turn it back on, and you have to edit the body manually.¹
  
• The alpha HUD on pretty much all other mesh bodies. You can only change clothes if you don't need alpha-ing.
  
• Bento HUDs. You can't even correct your hands if your fingers are stretched into all directions.
  
• Sex, at least not if it involves at least one male avatar. Guys can't switch their boners on. Turning avatar scripts off on a sex-oriented sim is amongst the top five stupidest things you can possibly do as a sim owner.

¹By the way, yes, #BakesOnMesh supports alpha masks. If your mesh bodies don't, doesn't mean BoM as a whole doesn't.

#Metaverse #VirtualWorlds

@OpenSim

I know it's tempting to disallow avatar scripts on your sims. I know that it can greatly improve the performance by killing off the heavy-weight scripts that some people wear on their avatars for whatever reasons of flashiness.

But keep in mind that the following things don't work anymore with avatar scripts off:

• Attached AOs. This may be one reason to disallow scripts because typical #SecondLife #ZHAO AOs use up tremendous amounts of server resources, and hardly any #OpenSimulator user has ever heard of #khAOs. But many #OpenSim users depend on attached AOs. They either don't know how to put an AO into their viewer, or they can't be bothered because attaching one is sooo much more convenient, and it gives you a HUD.
  
• Adjusting the foot position on most female mesh bodies from #SecondLife. Unless you've got your feet on "high" permanently, you can neither take your high heels off nor put them on.
  
• Switching the alpha mode on #Ruth2 v4 and #Roth2 v2. If it's forced to "off" when you teleport in, and your alpha masks stop working, you can't use your HUD to turn it back on, and you have to edit the body manually.¹
  
• The alpha HUD on pretty much all other mesh bodies. You can only change clothes if you don't need alpha-ing.
  
• Bento HUDs. You can't even correct your hands if your fingers are stretched into all directions.
  
• Sex, at least not if it involves at least one male avatar. Guys can't switch their boners on. Turning avatar scripts off on a sex-oriented sim is amongst the top five stupidest things you can possibly do as a sim owner.

¹By the way, yes, #BakesOnMesh supports alpha masks. If your mesh bodies don't, doesn't mean BoM as a whole doesn't.

#Metaverse #VirtualWorlds

@OpenSim

I know it's tempting to disallow avatar scripts on your sims. I know that it can greatly improve the performance by killing off the heavy-weight scripts that some people wear on their avatars for whatever reasons of flashiness.

But keep in mind that the following things don't work anymore with avatar scripts off:

• Attached AOs. This may be one reason to disallow scripts because typical #SecondLife #ZHAO AOs use up tremendous amounts of server resources, and hardly any #OpenSimulator user has ever heard of #khAOs. But many #OpenSim users depend on attached AOs. They either don't know how to put an AO into their viewer, or they can't be bothered because attaching one is sooo much more convenient, and it gives you a HUD.
  
• Adjusting the foot position on most female mesh bodies from #SecondLife. Unless you've got your feet on "high" permanently, you can neither take your high heels off nor put them on.
  
• Switching the alpha mode on #Ruth2 v4 and #Roth2 v2. If it's forced to "off" when you teleport in, and your alpha masks stop working, you can't use your HUD to turn it back on, and you have to edit the body manually.¹
  
• The alpha HUD on pretty much all other mesh bodies. You can only change clothes if you don't need alpha-ing.
  
• Bento HUDs. You can't even correct your hands if your fingers are stretched into all directions.
  
• Sex, at least not if it involves at least one male avatar. Guys can't switch their boners on. Turning avatar scripts off on a sex-oriented sim is amongst the top five stupidest things you can possibly do as a sim owner.

¹By the way, yes, #BakesOnMesh supports alpha masks. If your mesh bodies don't, doesn't mean BoM as a whole doesn't.

#Metaverse #VirtualWorlds

@OpenSim

So #SecondLife is working on introducing #PBR, also called #PeanutButter. And the #FirestormViewer is working on keeping up with it. There's a PBR-enabled alpha version now. This gives me to think.



One, there's that talk about higher hardware requirements. Now, Firestorm is actually still available in a 32-bit Windows version. Look back into the past. What were the last machines sold with pre-installed 32-bit Windows, and when was that?

That must have been in the late 2000s. And those machines were entry-level consumer laptops with on-board graphics. In other words, these computers were under-powered already when they were new. But there are actually people who visit #VirtualWorlds using 15-year-old or even older potato computers that run 32-bit Windows. That was all they could afford when they bought them, and they've never again been able to afford any computer. Maybe it's a German thing that the second-hand market is chock-full of used business laptops that are comparably cheap because there are so many of them.

Of course, in this use-case, toaster users have to turn down the graphics settings to a minimum. Advanced lighting is completely out of question, in fact, the shaders have to stay off entirely. The reason why so many Second Life buildings have shadows and gloss and all that painted onto their textures is so that they look pleasant to toaster users.

Now, the Firestorm devs say that when Firestorm introduces PBR support, it will probably remove the advanced lighting switch. Not only the shaders will have to be permanently on, but so will advanced lighting.

This doesn't necessarily mean that you'll have to replace your 32-bit, single-core Celeron M that can only use 3 of 4GB of installed RAM with a brand-new i9 and your on-board GMA 900 graphics with a GeForce RTX 4090 Ti. I mean, I've been able to use advanced lighting with a low-intermediate Radeon HD 7770 from 2012 until it died a week and a half ago. But your old clunker won't cut it anymore.



Two, chances are that some more third-party viewers will wither away because their development can't keep up with that in Second Life. Remember when the #SingularityViewer was one of the hottest viewers? Well, the last new stable version introduced #BakesOnMesh and #Animesh, and that was in 2020 already, while some other third-party viewers still don't support either at all. The last nightly was over two years old, too, before nightly downloads were recently removed. Its user base is reduced to #OpenSimulator users who are at home on grids that still run #OpenSim versions with #Windlight.



Speaking of which, three, this will once again show an advantage of Second Life's centralised structure over decentralised OpenSim: If you've only got one instance, you've also only got one server-side software version to worry about. Second Life introduced PBR all over in one go.

In OpenSim, you can't expect all hundreds of grids and attached sims to upgrade to the newest version all at once, even if an OpenSim version with PBR should come out. Sure, most places run on 0.9.2.2 nowadays which even counts as a stable release while others are trying out 0.9.2.3.

But there are still places that run older versions, even on the #Hypergrid. 0.9.2.1, 0.9.2.0, 0.9.1.1, all still with Windlight instead of #EEP, sometimes even older and without BoM scripting support. I think some are still stuck at 0.8.2.1. And here and there, I think, there are even a few with even older versions and no BoM support whatsoever.

Some grid owners live by that typical Windows user credo: install once, never upgrade. And they extend it to their grid. It doesn't help that OpenSim is cross-platform, and the vast majority of at least private grids is running on desktop Windows.

Others are fairly conservative. There are grids that seem like they've spent the past ten years under a rock. They've still got mesh disabled. As far as I know, that very switch has been removed from OpenSim quite a while ago, just like the one in viewers. Naturally, these grids run very old versions because the grid owner doesn't see any benefits in upgrading if new versions only introduce stuff they don't care for anyway or even remove something they've come to love. I wouldn't be too surprised if there were grids that still run OpenSim 0.7.3 while being connected to the Hypergrid.

Forks come on top of that. Some grids still run on forks from 0.7.x days. Not only are these forks no longer maintained, but they weren't really soft forks to begin with. The maintainers only took over from vanilla what they deemed useful or necessary, leaving ArribaSim which used to be popular in German-speaking countries with flaky BoM support, probably because parts of BoM collided with the performance optimisations which Arriba was famous for.

NextGen is even worse. It never had any support for BoM built in, not even any kind of fallback. I still know one grid that runs NextGen in spite of its gaping and actually exploited security holes. The reason is NextGen's killer feature, namely a nifty point-and-click Web interface. And your typical NextGen grid admin depends on this very point-and-click interface to be able to run a grid. Such grids can only be saved by either grafting NextGen's Web interface onto vanilla OpenSim or adding another admin who can administer OpenSim on the command line, and who'll effectively take all power away from the current admin. Until that happens, such grids are partially stuck at 0.8.0.0 at best.

So this means that Second Life-only viewers can be developed against exactly one Second Life version. As soon as they want to support OpenSim, they'll have to cover some five years worth of releases or more.

At least we're in the lucky situation of having a fairly new official stable release. For there haven't been any stable releases between 0.8.2.1 which introduced BoM basics and 0.9.2.1 which was the last version with Windlight. Before 0.9.2.1, the Hypergrid was split into a few grids that played it safe and stuck with the stable release and lots of grids that preferred development versions over hopelessly outdated versions. This is also why the "0.8.2.1" versions of #Ruth2 v4 and #Roth2 v2 exist.

OpenSim will introduce PBR, this one is certain. It will have to in order to stay compatible with Firestorm, its most important viewer (sorry, #CoolVLViewer fans). But there will be a long period in which lots of grids will not have PBR. And even when a stable release of OpenSim with PBR is out, and #DreamGrid has made the switch to a PBR version, there will remain lots of places without PBR.

Viewers that are compatible with OpenSim will have to remain compatible with non-PBR places in some way. If the Firestorm devs say that it's impossible to keep supporting non-PBR, just like they said it's impossible to support both Windlight and EEP, that'd create a rift through the Hypergrid. Users on PBR grids could no longer visit non-PBR places and vice versa. They'd need two viewers, one with PBR, one without. And even that is impossible because you can't rez your avatar somewhere on the Hypergrid while logging in. Unless you have sims on your home grid that run on a different OpenSim version, you're stuck in your half of the Hypergrid.

The Windlight/EEP issue was solved acceptably: At least Firestorm versions with EEP have a fallback mode that uses EEP to emulate Windlight, and it looks like OpenSim versions with EEP have their own fallback for older viewers. If PBR means a similarly hard cut, I hope that there will be a similar compatibility solution.

#Metaverse

@OpenSim

So #SecondLife is working on introducing #PBR, also called #PeanutButter. And the #FirestormViewer is working on keeping up with it. There's a PBR-enabled alpha version now. This gives me to think.



One, there's that talk about higher hardware requirements. Now, Firestorm is actually still available in a 32-bit Windows version. Look back into the past. What were the last machines sold with pre-installed 32-bit Windows, and when was that?

That must have been in the late 2000s. And those machines were entry-level consumer laptops with on-board graphics. In other words, these computers were under-powered already when they were new. But there are actually people who visit #VirtualWorlds using 15-year-old or even older potato computers that run 32-bit Windows. That was all they could afford when they bought them, and they've never again been able to afford any computer. Maybe it's a German thing that the second-hand market is chock-full of used business laptops that are comparably cheap because there are so many of them.

Of course, in this use-case, toaster users have to turn down the graphics settings to a minimum. Advanced lighting is completely out of question, in fact, the shaders have to stay off entirely. The reason why so many Second Life buildings have shadows and gloss and all that painted onto their textures is so that they look pleasant to toaster users.

Now, the Firestorm devs say that when Firestorm introduces PBR support, it will probably remove the advanced lighting switch. Not only the shaders will have to be permanently on, but so will advanced lighting.

This doesn't necessarily mean that you'll have to replace your 32-bit, single-core Celeron M that can only use 3 of 4GB of installed RAM with a brand-new i9 and your on-board GMA 900 graphics with a GeForce RTX 4090 Ti. I mean, I've been able to use advanced lighting with a low-intermediate Radeon HD 7770 from 2012 until it died a week and a half ago. But your old clunker won't cut it anymore.



Two, chances are that some more third-party viewers will wither away because their development can't keep up with that in Second Life. Remember when the #SingularityViewer was one of the hottest viewers? Well, the last new stable version introduced #BakesOnMesh and #Animesh, and that was in 2020 already, while some other third-party viewers still don't support either at all. The last nightly was over two years old, too, before nightly downloads were recently removed. Its user base is reduced to #OpenSimulator users who are at home on grids that still run #OpenSim versions with #Windlight.



Speaking of which, three, this will once again show an advantage of Second Life's centralised structure over decentralised OpenSim: If you've only got one instance, you've also only got one server-side software version to worry about. Second Life introduced PBR all over in one go.

In OpenSim, you can't expect all hundreds of grids and attached sims to upgrade to the newest version all at once, even if an OpenSim version with PBR should come out. Sure, most places run on 0.9.2.2 nowadays which even counts as a stable release while others are trying out 0.9.2.3.

But there are still places that run older versions, even on the #Hypergrid. 0.9.2.1, 0.9.2.0, 0.9.1.1, all still with Windlight instead of #EEP, sometimes even older and without BoM scripting support. I think some are still stuck at 0.8.2.1. And here and there, I think, there are even a few with even older versions and no BoM support whatsoever.

Some grid owners live by that typical Windows user credo: install once, never upgrade. And they extend it to their grid. It doesn't help that OpenSim is cross-platform, and the vast majority of at least private grids is running on desktop Windows.

Others are fairly conservative. There are grids that seem like they've spent the past ten years under a rock. They've still got mesh disabled. As far as I know, that very switch has been removed from OpenSim quite a while ago, just like the one in viewers. Naturally, these grids run very old versions because the grid owner doesn't see any benefits in upgrading if new versions only introduce stuff they don't care for anyway or even remove something they've come to love. I wouldn't be too surprised if there were grids that still run OpenSim 0.7.3 while being connected to the Hypergrid.

Forks come on top of that. Some grids still run on forks from 0.7.x days. Not only are these forks no longer maintained, but they weren't really soft forks to begin with. The maintainers only took over from vanilla what they deemed useful or necessary, leaving ArribaSim which used to be popular in German-speaking countries with flaky BoM support, probably because parts of BoM collided with the performance optimisations which Arriba was famous for.

NextGen is even worse. It never had any support for BoM built in, not even any kind of fallback. I still know one grid that runs NextGen in spite of its gaping and actually exploited security holes. The reason is NextGen's killer feature, namely a nifty point-and-click Web interface. And your typical NextGen grid admin depends on this very point-and-click interface to be able to run a grid. Such grids can only be saved by either grafting NextGen's Web interface onto vanilla OpenSim or adding another admin who can administer OpenSim on the command line, and who'll effectively take all power away from the current admin. Until that happens, such grids are partially stuck at 0.8.0.0 at best.

So this means that Second Life-only viewers can be developed against exactly one Second Life version. As soon as they want to support OpenSim, they'll have to cover some five years worth of releases or more.

At least we're in the lucky situation of having a fairly new official stable release. For there haven't been any stable releases between 0.8.2.1 which introduced BoM basics and 0.9.2.1 which was the last version with Windlight. Before 0.9.2.1, the Hypergrid was split into a few grids that played it safe and stuck with the stable release and lots of grids that preferred development versions over hopelessly outdated versions. This is also why the "0.8.2.1" versions of #Ruth2 v4 and #Roth2 v2 exist.

OpenSim will introduce PBR, this one is certain. It will have to in order to stay compatible with Firestorm, its most important viewer (sorry, #CoolVLViewer fans). But there will be a long period in which lots of grids will not have PBR. And even when a stable release of OpenSim with PBR is out, and #DreamGrid has made the switch to a PBR version, there will remain lots of places without PBR.

Viewers that are compatible with OpenSim will have to remain compatible with non-PBR places in some way. If the Firestorm devs say that it's impossible to keep supporting non-PBR, just like they said it's impossible to support both Windlight and EEP, that'd create a rift through the Hypergrid. Users on PBR grids could no longer visit non-PBR places and vice versa. They'd need two viewers, one with PBR, one without. And even that is impossible because you can't rez your avatar somewhere on the Hypergrid while logging in. Unless you have sims on your home grid that run on a different OpenSim version, you're stuck in your half of the Hypergrid.

The Windlight/EEP issue was solved acceptably: At least Firestorm versions with EEP have a fallback mode that uses EEP to emulate Windlight, and it looks like OpenSim versions with EEP have their own fallback for older viewers. If PBR means a similarly hard cut, I hope that there will be a similar compatibility solution.

#Metaverse

@OpenSim

So #SecondLife is working on introducing #PBR, also called #PeanutButter. And the #FirestormViewer is working on keeping up with it. There's a PBR-enabled alpha version now. This gives me to think.



One, there's that talk about higher hardware requirements. Now, Firestorm is actually still available in a 32-bit Windows version. Look back into the past. What were the last machines sold with pre-installed 32-bit Windows, and when was that?

That must have been in the late 2000s. And those machines were entry-level consumer laptops with on-board graphics. In other words, these computers were under-powered already when they were new. But there are actually people who visit #VirtualWorlds using 15-year-old or even older potato computers that run 32-bit Windows. That was all they could afford when they bought them, and they've never again been able to afford any computer. Maybe it's a German thing that the second-hand market is chock-full of used business laptops that are comparably cheap because there are so many of them.

Of course, in this use-case, toaster users have to turn down the graphics settings to a minimum. Advanced lighting is completely out of question, in fact, the shaders have to stay off entirely. The reason why so many Second Life buildings have shadows and gloss and all that painted onto their textures is so that they look pleasant to toaster users.

Now, the Firestorm devs say that when Firestorm introduces PBR support, it will probably remove the advanced lighting switch. Not only the shaders will have to be permanently on, but so will advanced lighting.

This doesn't necessarily mean that you'll have to replace your 32-bit, single-core Celeron M that can only use 3 of 4GB of installed RAM with a brand-new i9 and your on-board GMA 900 graphics with a GeForce RTX 4090 Ti. I mean, I've been able to use advanced lighting with a low-intermediate Radeon HD 7770 from 2012 until it died a week and a half ago. But your old clunker won't cut it anymore.



Two, chances are that some more third-party viewers will wither away because their development can't keep up with that in Second Life. Remember when the #SingularityViewer was one of the hottest viewers? Well, the last new stable version introduced #BakesOnMesh and #Animesh, and that was in 2020 already, while some other third-party viewers still don't support either at all. The last nightly was over two years old, too, before nightly downloads were recently removed. Its user base is reduced to #OpenSimulator users who are at home on grids that still run #OpenSim versions with #Windlight.



Speaking of which, three, this will once again show an advantage of Second Life's centralised structure over decentralised OpenSim: If you've only got one instance, you've also only got one server-side software version to worry about. Second Life introduced PBR all over in one go.

In OpenSim, you can't expect all hundreds of grids and attached sims to upgrade to the newest version all at once, even if an OpenSim version with PBR should come out. Sure, most places run on 0.9.2.2 nowadays which even counts as a stable release while others are trying out 0.9.2.3.

But there are still places that run older versions, even on the #Hypergrid. 0.9.2.1, 0.9.2.0, 0.9.1.1, all still with Windlight instead of #EEP, sometimes even older and without BoM scripting support. I think some are still stuck at 0.8.2.1. And here and there, I think, there are even a few with even older versions and no BoM support whatsoever.

Some grid owners live by that typical Windows user credo: install once, never upgrade. And they extend it to their grid. It doesn't help that OpenSim is cross-platform, and the vast majority of at least private grids is running on desktop Windows.

Others are fairly conservative. There are grids that seem like they've spent the past ten years under a rock. They've still got mesh disabled. As far as I know, that very switch has been removed from OpenSim quite a while ago, just like the one in viewers. Naturally, these grids run very old versions because the grid owner doesn't see any benefits in upgrading if new versions only introduce stuff they don't care for anyway or even remove something they've come to love. I wouldn't be too surprised if there were grids that still run OpenSim 0.7.3 while being connected to the Hypergrid.

Forks come on top of that. Some grids still run on forks from 0.7.x days. Not only are these forks no longer maintained, but they weren't really soft forks to begin with. The maintainers only took over from vanilla what they deemed useful or necessary, leaving ArribaSim which used to be popular in German-speaking countries with flaky BoM support, probably because parts of BoM collided with the performance optimisations which Arriba was famous for.

NextGen is even worse. It never had any support for BoM built in, not even any kind of fallback. I still know one grid that runs NextGen in spite of its gaping and actually exploited security holes. The reason is NextGen's killer feature, namely a nifty point-and-click Web interface. And your typical NextGen grid admin depends on this very point-and-click interface to be able to run a grid. Such grids can only be saved by either grafting NextGen's Web interface onto vanilla OpenSim or adding another admin who can administer OpenSim on the command line, and who'll effectively take all power away from the current admin. Until that happens, such grids are partially stuck at 0.8.0.0 at best.

So this means that Second Life-only viewers can be developed against exactly one Second Life version. As soon as they want to support OpenSim, they'll have to cover some five years worth of releases or more.

At least we're in the lucky situation of having a fairly new official stable release. For there haven't been any stable releases between 0.8.2.1 which introduced BoM basics and 0.9.2.1 which was the last version with Windlight. Before 0.9.2.1, the Hypergrid was split into a few grids that played it safe and stuck with the stable release and lots of grids that preferred development versions over hopelessly outdated versions. This is also why the "0.8.2.1" versions of #Ruth2 v4 and #Roth2 v2 exist.

OpenSim will introduce PBR, this one is certain. It will have to in order to stay compatible with Firestorm, its most important viewer (sorry, #CoolVLViewer fans). But there will be a long period in which lots of grids will not have PBR. And even when a stable release of OpenSim with PBR is out, and #DreamGrid has made the switch to a PBR version, there will remain lots of places without PBR.

Viewers that are compatible with OpenSim will have to remain compatible with non-PBR places in some way. If the Firestorm devs say that it's impossible to keep supporting non-PBR, just like they said it's impossible to support both Windlight and EEP, that'd create a rift through the Hypergrid. Users on PBR grids could no longer visit non-PBR places and vice versa. They'd need two viewers, one with PBR, one without. And even that is impossible because you can't rez your avatar somewhere on the Hypergrid while logging in. Unless you have sims on your home grid that run on a different OpenSim version, you're stuck in your half of the Hypergrid.

The Windlight/EEP issue was solved acceptably: At least Firestorm versions with EEP have a fallback mode that uses EEP to emulate Windlight, and it looks like OpenSim versions with EEP have their own fallback for older viewers. If PBR means a similarly hard cut, I hope that there will be a similar compatibility solution.

#Metaverse

@OpenSim

So #SecondLife is working on introducing #PBR, also called #PeanutButter. And the #FirestormViewer is working on keeping up with it. There's a PBR-enabled alpha version now. This gives me to think.



One, there's that talk about higher hardware requirements. Now, Firestorm is actually still available in a 32-bit Windows version. Look back into the past. What were the last machines sold with pre-installed 32-bit Windows, and when was that?

That must have been in the late 2000s. And those machines were entry-level consumer laptops with on-board graphics. In other words, these computers were under-powered already when they were new. But there are actually people who visit #VirtualWorlds using 15-year-old or even older potato computers that run 32-bit Windows. That was all they could afford when they bought them, and they've never again been able to afford any computer. Maybe it's a German thing that the second-hand market is chock-full of used business laptops that are comparably cheap because there are so many of them.

Of course, in this use-case, toaster users have to turn down the graphics settings to a minimum. Advanced lighting is completely out of question, in fact, the shaders have to stay off entirely. The reason why so many Second Life buildings have shadows and gloss and all that painted onto their textures is so that they look pleasant to toaster users.

Now, the Firestorm devs say that when Firestorm introduces PBR support, it will probably remove the advanced lighting switch. Not only the shaders will have to be permanently on, but so will advanced lighting.

This doesn't necessarily mean that you'll have to replace your 32-bit, single-core Celeron M that can only use 3 of 4GB of installed RAM with a brand-new i9 and your on-board GMA 900 graphics with a GeForce RTX 4090 Ti. I mean, I've been able to use advanced lighting with a low-intermediate Radeon HD 7770 from 2012 until it died a week and a half ago. But your old clunker won't cut it anymore.



Two, chances are that some more third-party viewers will wither away because their development can't keep up with that in Second Life. Remember when the #SingularityViewer was one of the hottest viewers? Well, the last new stable version introduced #BakesOnMesh and #Animesh, and that was in 2020 already, while some other third-party viewers still don't support either at all. The last nightly was over two years old, too, before nightly downloads were recently removed. Its user base is reduced to #OpenSimulator users who are at home on grids that still run #OpenSim versions with #Windlight.



Speaking of which, three, this will once again show an advantage of Second Life's centralised structure over decentralised OpenSim: If you've only got one instance, you've also only got one server-side software version to worry about. Second Life introduced PBR all over in one go.

In OpenSim, you can't expect all hundreds of grids and attached sims to upgrade to the newest version all at once, even if an OpenSim version with PBR should come out. Sure, most places run on 0.9.2.2 nowadays which even counts as a stable release while others are trying out 0.9.2.3.

But there are still places that run older versions, even on the #Hypergrid. 0.9.2.1, 0.9.2.0, 0.9.1.1, all still with Windlight instead of #EEP, sometimes even older and without BoM scripting support. I think some are still stuck at 0.8.2.1. And here and there, I think, there are even a few with even older versions and no BoM support whatsoever.

Some grid owners live by that typical Windows user credo: install once, never upgrade. And they extend it to their grid. It doesn't help that OpenSim is cross-platform, and the vast majority of at least private grids is running on desktop Windows.

Others are fairly conservative. There are grids that seem like they've spent the past ten years under a rock. They've still got mesh disabled. As far as I know, that very switch has been removed from OpenSim quite a while ago, just like the one in viewers. Naturally, these grids run very old versions because the grid owner doesn't see any benefits in upgrading if new versions only introduce stuff they don't care for anyway or even remove something they've come to love. I wouldn't be too surprised if there were grids that still run OpenSim 0.7.3 while being connected to the Hypergrid.

Forks come on top of that. Some grids still run on forks from 0.7.x days. Not only are these forks no longer maintained, but they weren't really soft forks to begin with. The maintainers only took over from vanilla what they deemed useful or necessary, leaving ArribaSim which used to be popular in German-speaking countries with flaky BoM support, probably because parts of BoM collided with the performance optimisations which Arriba was famous for.

NextGen is even worse. It never had any support for BoM built in, not even any kind of fallback. I still know one grid that runs NextGen in spite of its gaping and actually exploited security holes. The reason is NextGen's killer feature, namely a nifty point-and-click Web interface. And your typical NextGen grid admin depends on this very point-and-click interface to be able to run a grid. Such grids can only be saved by either grafting NextGen's Web interface onto vanilla OpenSim or adding another admin who can administer OpenSim on the command line, and who'll effectively take all power away from the current admin. Until that happens, such grids are partially stuck at 0.8.0.0 at best.

So this means that Second Life-only viewers can be developed against exactly one Second Life version. As soon as they want to support OpenSim, they'll have to cover some five years worth of releases or more.

At least we're in the lucky situation of having a fairly new official stable release. For there haven't been any stable releases between 0.8.2.1 which introduced BoM basics and 0.9.2.1 which was the last version with Windlight. Before 0.9.2.1, the Hypergrid was split into a few grids that played it safe and stuck with the stable release and lots of grids that preferred development versions over hopelessly outdated versions. This is also why the "0.8.2.1" versions of #Ruth2 v4 and #Roth2 v2 exist.

OpenSim will introduce PBR, this one is certain. It will have to in order to stay compatible with Firestorm, its most important viewer (sorry, #CoolVLViewer fans). But there will be a long period in which lots of grids will not have PBR. And even when a stable release of OpenSim with PBR is out, and #DreamGrid has made the switch to a PBR version, there will remain lots of places without PBR.

Viewers that are compatible with OpenSim will have to remain compatible with non-PBR places in some way. If the Firestorm devs say that it's impossible to keep supporting non-PBR, just like they said it's impossible to support both Windlight and EEP, that'd create a rift through the Hypergrid. Users on PBR grids could no longer visit non-PBR places and vice versa. They'd need two viewers, one with PBR, one without. And even that is impossible because you can't rez your avatar somewhere on the Hypergrid while logging in. Unless you have sims on your home grid that run on a different OpenSim version, you're stuck in your half of the Hypergrid.

The Windlight/EEP issue was solved acceptably: At least Firestorm versions with EEP have a fallback mode that uses EEP to emulate Windlight, and it looks like OpenSim versions with EEP have their own fallback for older viewers. If PBR means a similarly hard cut, I hope that there will be a similar compatibility solution.

#Metaverse

@OpenSim

So #SecondLife is working on introducing #PBR, also called #PeanutButter. And the #FirestormViewer is working on keeping up with it. There's a PBR-enabled alpha version now. This gives me to think.



One, there's that talk about higher hardware requirements. Now, Firestorm is actually still available in a 32-bit Windows version. Look back into the past. What were the last machines sold with pre-installed 32-bit Windows, and when was that?

That must have been in the late 2000s. And those machines were entry-level consumer laptops with on-board graphics. In other words, these computers were under-powered already when they were new. But there are actually people who visit #VirtualWorlds using 15-year-old or even older potato computers that run 32-bit Windows. That was all they could afford when they bought them, and they've never again been able to afford any computer. Maybe it's a German thing that the second-hand market is chock-full of used business laptops that are comparably cheap because there are so many of them.

Of course, in this use-case, toaster users have to turn down the graphics settings to a minimum. Advanced lighting is completely out of question, in fact, the shaders have to stay off entirely. The reason why so many Second Life buildings have shadows and gloss and all that painted onto their textures is so that they look pleasant to toaster users.

Now, the Firestorm devs say that when Firestorm introduces PBR support, it will probably remove the advanced lighting switch. Not only the shaders will have to be permanently on, but so will advanced lighting.

This doesn't necessarily mean that you'll have to replace your 32-bit, single-core Celeron M that can only use 3 of 4GB of installed RAM with a brand-new i9 and your on-board GMA 900 graphics with a GeForce RTX 4090 Ti. I mean, I've been able to use advanced lighting with a low-intermediate Radeon HD 7770 from 2012 until it died a week and a half ago. But your old clunker won't cut it anymore.



Two, chances are that some more third-party viewers will wither away because their development can't keep up with that in Second Life. Remember when the #SingularityViewer was one of the hottest viewers? Well, the last new stable version introduced #BakesOnMesh and #Animesh, and that was in 2020 already, while some other third-party viewers still don't support either at all. The last nightly was over two years old, too, before nightly downloads were recently removed. Its user base is reduced to #OpenSimulator users who are at home on grids that still run #OpenSim versions with #Windlight.



Speaking of which, three, this will once again show an advantage of Second Life's centralised structure over decentralised OpenSim: If you've only got one instance, you've also only got one server-side software version to worry about. Second Life introduced PBR all over in one go.

In OpenSim, you can't expect all hundreds of grids and attached sims to upgrade to the newest version all at once, even if an OpenSim version with PBR should come out. Sure, most places run on 0.9.2.2 nowadays which even counts as a stable release while others are trying out 0.9.2.3.

But there are still places that run older versions, even on the #Hypergrid. 0.9.2.1, 0.9.2.0, 0.9.1.1, all still with Windlight instead of #EEP, sometimes even older and without BoM scripting support. I think some are still stuck at 0.8.2.1. And here and there, I think, there are even a few with even older versions and no BoM support whatsoever.

Some grid owners live by that typical Windows user credo: install once, never upgrade. And they extend it to their grid. It doesn't help that OpenSim is cross-platform, and the vast majority of at least private grids is running on desktop Windows.

Others are fairly conservative. There are grids that seem like they've spent the past ten years under a rock. They've still got mesh disabled. As far as I know, that very switch has been removed from OpenSim quite a while ago, just like the one in viewers. Naturally, these grids run very old versions because the grid owner doesn't see any benefits in upgrading if new versions only introduce stuff they don't care for anyway or even remove something they've come to love. I wouldn't be too surprised if there were grids that still run OpenSim 0.7.3 while being connected to the Hypergrid.

Forks come on top of that. Some grids still run on forks from 0.7.x days. Not only are these forks no longer maintained, but they weren't really soft forks to begin with. The maintainers only took over from vanilla what they deemed useful or necessary, leaving ArribaSim which used to be popular in German-speaking countries with flaky BoM support, probably because parts of BoM collided with the performance optimisations which Arriba was famous for.

NextGen is even worse. It never had any support for BoM built in, not even any kind of fallback. I still know one grid that runs NextGen in spite of its gaping and actually exploited security holes. The reason is NextGen's killer feature, namely a nifty point-and-click Web interface. And your typical NextGen grid admin depends on this very point-and-click interface to be able to run a grid. Such grids can only be saved by either grafting NextGen's Web interface onto vanilla OpenSim or adding another admin who can administer OpenSim on the command line, and who'll effectively take all power away from the current admin. Until that happens, such grids are partially stuck at 0.8.0.0 at best.

So this means that Second Life-only viewers can be developed against exactly one Second Life version. As soon as they want to support OpenSim, they'll have to cover some five years worth of releases or more.

At least we're in the lucky situation of having a fairly new official stable release. For there haven't been any stable releases between 0.8.2.1 which introduced BoM basics and 0.9.2.1 which was the last version with Windlight. Before 0.9.2.1, the Hypergrid was split into a few grids that played it safe and stuck with the stable release and lots of grids that preferred development versions over hopelessly outdated versions. This is also why the "0.8.2.1" versions of #Ruth2 v4 and #Roth2 v2 exist.

OpenSim will introduce PBR, this one is certain. It will have to in order to stay compatible with Firestorm, its most important viewer (sorry, #CoolVLViewer fans). But there will be a long period in which lots of grids will not have PBR. And even when a stable release of OpenSim with PBR is out, and #DreamGrid has made the switch to a PBR version, there will remain lots of places without PBR.

Viewers that are compatible with OpenSim will have to remain compatible with non-PBR places in some way. If the Firestorm devs say that it's impossible to keep supporting non-PBR, just like they said it's impossible to support both Windlight and EEP, that'd create a rift through the Hypergrid. Users on PBR grids could no longer visit non-PBR places and vice versa. They'd need two viewers, one with PBR, one without. And even that is impossible because you can't rez your avatar somewhere on the Hypergrid while logging in. Unless you have sims on your home grid that run on a different OpenSim version, you're stuck in your half of the Hypergrid.

The Windlight/EEP issue was solved acceptably: At least Firestorm versions with EEP have a fallback mode that uses EEP to emulate Windlight, and it looks like OpenSim versions with EEP have their own fallback for older viewers. If PBR means a similarly hard cut, I hope that there will be a similar compatibility solution.

#Metaverse