BriannaLovey

One thing that would definitely be impacted is your graphics settings. Since the last 2 versions of Firestorm use different rendering engines, the settings will be completely different One viewer will have settings that the other doesn't have, and vice versa. I am not sure how Firestorm handles this internally. If you want to back them up, you can back up the user_settings folder in your Firestorm AppData directory.

The viewer's speed isn't going to be influenced as much by the install location as much as it will be influenced by the cache location. The cache is where most reading and writing happens during viewer runtime, so it is best to keep your cache on a SSD. Since your C:\ drive is a SSD, you don't need to change anything.

Oh my goodness, I didn't even see that part. Maybe scripting Firestorm-like UI widgets for your viewer is a better investment of my time than forking Firestorm.

LL is chasing whales again. Of course they want 13 year olds to sign up. Given existing trends, I would expect younger generations to spend more on microtransactions than older ones. https://www.businessofapps.com/news/gen-z-install-the-most-games-and-make-the-most-frequent-in-app-purchases/

All bets are off if this happens.

ohh heehee jokes go over my head a lot :c

Wine is a translation layer that lets Windows programs be run on Linux. It isn't an operating system unto itself.

If anyone does want help, feel free to send me a notecard inworld.

lol your hyperbole is so funny. Your knowledge on the subject is a bit outdated, though, by at least 5 years if not more.

Thanks! I will keep this in mind. lol I don't know why I typed spectral, maybe I am too sleepy. Thanks for the info, I will not combine the maps then. I don't want to make things any more inconsistent than they already would be.

I don't expect any official TPVs other than Henri's and the one I am working on myself to use a feature like this. I am forking firestorm, because a lot of the people I recommended Henri's viewer to ended up having baby duck syndrome about the interface. As for the difficulty, who knows. The absolute worst case scenario is that I have to learn GL Shader Language in order to implement compute shaders for efficient conversion to textures. I have done a bit of OpenCL before though, so it shouldn't be all that bad. I don't expect I will have to do that though, since it will be only a few addition or multiplication operations, and the tradeoff of sending stuff to the (i)GPU and back will favor CPU-based PBR->texture conversion.

There is a way to convert to normal or spectral maps, but I am not really focused on that for now since those who can run ALM can generally run PBR viewers. Think of it this way: Right now, terrain uses textures. Mesh uses textures. Prims use textures. Profiles use textures. In nearly every instance, the textures are loaded the exact same way. In the future, when any of them use PBR, the process I described above can be used. If computational overhead for the PBR->texture conversion process is a concern, of course a caching system could be created for the converted stuff. If storage is a concern, the downloaded PBR materials could be discarded since they wouldn't be needed after this conversion takes place.

From what I understand, the process looks like this, simplified (correct me if I am wrong): Viewer downloads PBR material -> PBR material's color map is extracted and converted to a texture locally -> resulting texture is rendered. Whereas the process for a texture is: Viewer downloads texture -> texture is rendered. This works the exact same way for every texture that has to be downloaded in SL, regardless of what it is applied to. Fundamentally, PBR materials and textures are very similar; both are just structured lists of pixels. PBR materials just have more channels for the other fancy stuff.

Sorry, maybe I wasn't clear. I am talking about a viewer feature here. Henri's viewer already does this to some degree, but does not make use of the other maps to add to the approximation. The same exact thing can be done for terrain. It isn't complicated once you look at the basic components involved.

I have gone into detail in other replies about why this will not be as big of a problem as people say. TL;DR: there are ways to convert PBR materials into diffuse textures in order to approximate their appearance. I will be experimenting with them very shortly after I get basic changes implemented in my Firestorm 6.6.17 fork.

If you don't want to deal with Windows Recall spyware when you do personal stuff on your computer, then it will be very beneficial.

If TPVs were not permitted in SL, I would completely agree with you. But that is simply not the case at all. I don't believe LL will walk this back either, but I do believe that creating/modifying viewers of our own will greatly help the situation. So will spreading the word about existing viewers that can help, like [henri please don't stab me for this] viewer

Dual-booting is also an option; keep your linux and windows installs on the same computer, and switch between the two as needed 😄

Pay for an operating system? lmao

I find that responding to that guy at all is just not worth my time. It is better to focus on helping people who will be affected by this than arguing with those who don't care about them, but that is just my opinion.

Demanding that people who have no obligation to appease you do so is never a rational thing to do, yes. And for the most part, all these other things are pretty good to add. It is just the performance requirement that I am actively pushing back against.

If they made their items with modify permissions then they would have less of a workload, to be fair.

No different than...

The only way to realistically force people to do that is to outlaw third-party viewers entirely. If that happens...oh gosh. The easiest way for stuff you create to be seen correctly is to put a diffuse texture on it and nothing else. PBR isn't going to solve anything unless LL bans third-party viewers.

What a strange thing to potentially put your platform in jeopardy over, then.