Firestorm vs the LL Viewer

[Phil Deakins]

10 hours ago, Beq Janus said:

Every Second Life user is unique and likes their particular set of features and we try hard to keep as many of you happy and comfortable whilst keeping up with the progressive directions of the lab. We all hate to lose something we know and love, while at the same time look to improve and grow with the times. If Firestorm is larger than <insert name here> it is probably because that alternative viewer has made other choices and has discarded or not adopted certain feature sets. We are very lucky that the lab released the viewer as open source, it gives us the choices we have. 

With LL you get the latest SL can offer, with a commercial imperative to look after the majority of users, these days they are the drivers of innovation in Second Life overall, having the unique position of control over both server and viewer functions.

I liked most of your post, Beq, but a couple of small parts stood out.

You are not only very lucky that the Lab released the viewer as open source, but you (Emerald/Phoenix/Firestorm) owe your very existance to it. You didn't create a viewer. All you ever did was make small changes to the Lab's viewer code, not yours. The Lab releasing the code not only gives you the choices that you have, but it gives you everything you have. Without it you have nothing.

You write a though you are on a similar level with the LAB as far as viewers are concerned. You are not. You take what the Lab creates, modify it, and release it with the modifications. You are not up there with the Lab at all.

Edited October 7, 2018 by Phil Deakins

[Gabriele Graves]

On 10/6/2018 at 5:43 AM, Alyona Su said:

In your case, if you're dead-set on Firestorm (nothing wrong with that, of course) then you need to find your own cause and solution. Even if it means a new laptop because FS has out-developed past your current configuration capabilities (just a random hypothetical there). It is unlikely anyone will be able to help you. Though if LL chooses to support macOS Metal (and FS adopts it) then you'll get a major frame rate boost (and I will be jealous as a Windows user at the power boost of that for graphics).

There is an official in-world Firestorm support group that provides free support to anyone who needs it, is excellent and very responsive.  I have personally seen them tackle complicated configuration issues and managed to find the likely root cause in many cases.

Edited October 7, 2018 by Gabriele Graves
added word "official"

[Gabriele Graves]

I use firestorm almost exclusively now and find the official viewer painful to use on the odd occasion I need to check something.
The main draws for me are the additional features and the ability to configure it to the way I want.
I am also a Linux user and LL dropping Linux support was a big issue for me.  Kudos and my thanks to FS devs for keeping that alive.

Edited October 7, 2018 by Gabriele Graves
Added additional info

[Nova Convair]

Well I am using and observing viewers over many years and I don't see anything unexpected in FS memory consumption. You have 2 GB texture memory instead of 0.5 and go to a busy place. What you expect then? Even in old times the 32-bit LL viewer cranked up to about 3.5 GB before it crashed and now the situation is far worse  All the extras in FS use memory too. In the past there were versions with memory holes but atm FS and LL viewer never crash, so all good from my point of view. If you dont have the memory you need to lower features or change viewer.

For performance I barely see differences. The LL viewer seems to be slightly faster but that depends on situation too.

If you like LL give Kokua a try. It's very close to the LL viewer with a few extras and optional RLV and is kept up to date.

[Ansariel Hiller]

On 10/7/2018 at 11:28 AM, Phil Deakins said:

I liked most of your post, Beq, but a couple of small parts stood out.

You are not only very lucky that the Lab released the viewer as open source, but you (Emerald/Phoenix/Firestorm) owe your very existance to it. You didn't create a viewer. All you ever did was make small changes to the Lab's viewer code, not yours. The Lab releasing the code not only gives you the choices that you have, but it gives you everything you have. Without it you have nothing.

So are all other TPVs apart from Lumiya and Radegast - what's your point? And "small changes" made me laugh. Maybe check how much these "small changes" really are and how much time it needs to create them.

On 10/7/2018 at 11:28 AM, Phil Deakins said:

You write a though you are on a similar level with the LAB as far as viewers are concerned. You are not. You take what the Lab creates, modify it, and release it with the modifications. You are not up there with the Lab at all.

I'm pretty sure Beq was referring to feature parity. But don't let me stop your agenda...

[LittleMe Jewell]

On 10/7/2018 at 3:28 AM, Phil Deakins said:

You write a though you are on a similar level with the LAB as far as viewers are concerned. You are not. You take what the Lab creates, modify it, and release it with the modifications. You are not up there with the Lab at all.

Wow, talk about a rude slam.  Are you familiar with the viewer code base?  Have you attempted to modify it?

I've never looked at the viewer code, but I know from years of coding, including modifying code that someone else wrote, trying to add features without breaking existing stuff is incredibly difficult, often more so that the original creation itself.  It does require an extreme level of understanding of the base work.

Edited October 9, 2018 by LittleMe Jewell

[Phil Deakins]

7 hours ago, LittleMe Jewell said:

Wow, talk about a rude slam.  Are you familiar with the viewer code base?  Have you attempted to modify it?

Nope. And there was nothing rude about it. If something is true, it isn't rude to say it. I don't need to be familiar with the viewer code, or to have attempted to modify it, or even to be a programmer, to know that the Firestorm code is LL code with some modifications, and that the Emerald/Phoenix/Firestorm people didn't create it, which is what I said.

7 hours ago, LittleMe Jewell said:

I've never looked at the viewer code, but I know from years of coding, including modifying code that someone else wrote, trying to add features without breaking existing stuff is incredibly difficult, often more so that the original creation itself.  It does require an extreme level of understanding of the base work. 

It's nowhere near as difficult as you make it sound. The LL top level code (pre-compiling) was written specifically so that other people could modify it, including their own people. You don't need to understand everything about it at all. To make a modification, you only need to understand the bit you want to modify, and that's not difficult.

I know that from almost non-stop programming since the mid 80s, including writing some major programmes single-handedly.

Edited October 10, 2018 by Phil Deakins

[Drake1 Nightfire]

On 10/5/2018 at 2:23 PM, ChibiDragon007 said:

My MacBook is a late 2016 model with Touch  Bar. 

As you can see from the screenshots with Firestorm running it uses up almost all of the 8gb of memory on my system. Then there's the second image which shows how steep the drop in memory usage was after I shut Firestorm off. I'm pretty sure it's an issue related to Firestorm somewhere  because even other games I can run on my MacBook should not be using that much memory at ALL. 

FS used 3.08 of your 8 Gb of memory, thats less than half, not almost all. Maths, fairly easy when you learn the basics. 

5 hours ago, Phil Deakins said:

Nope. And there was nothing rude about it. If something is true, it isn't rude to say it. I don't need to be familiar with the viewer code, or to have attempted to modify it, or even to be a programmer, to know that the Firestorm code is LL code with some modifications, and that the Emerald/Phoenix/Firestorm people didn't create it, which is what I said.

Very much rude. Perhaps you have forgotten the massive amount of Thrd party additions to SL that would not have come about unless TPVs didn't create them FOR SL. Nearly every feature we use was created by TPV devs. They submitted them to LL and either they were approved or not. LL rarely made any features back in the day and the ones they did make sucked and no one asked for. TPVs made useful features we wanted. But hey, keep shining that pedestal you put LL on. 

[Qie Niangao]

4 hours ago, Phil Deakins said:

It's nowhere near as difficult as you make it sound. The LL top level code (pre-compiling) was written specifically so that other people could modify it, including their own people. You don't need to understand everything about it at all. To make a modification, you only need to understand the bit you want to modify, and that's not difficult.

Having managed groups responsible for maintaining large systems, I have to say: that's how we all wish it worked, but that's not how it works. In reality, a system accrues dependencies. I don't know the viewer source code, but just skimming the TPV office hour transcripts it's clear that the SL viewers are prime examples of how a system of programs can become intricately and unintentionally interdependent, despite everybody's attempts to maintain modularity and despite the help of language features and version management tools that enforce some discipline.

Eventually everything gets tangled with everything else. Then somebody decides to "refactor" the source, uncovering the more obvious dependencies, leaving a few for QA to discover, and accidentally hiding a bunch of new ones in the refactored code. This isn't bad software engineering, it's just the nature of the beast.

It's amazing software works at all.

All that said, though, the larger point is surely valid that third-party viewers are built on vast swaths of inherited code, mostly untouched from the Linden viewers. That's good, though, to streamline adoption of new LL-introduced features such as EEP and Animesh, and third-party contributions to the Lab code base.

And yet I've often lamented the lack of diversity. Lumiya, the Android viewer, is an example of an ambitious re-thinking of the whole viewer UI; I wish there were other examples.

Why, for example, is there no third-party desktop viewer with separate OS-level UI windows that we could move across displays or spread out over a 4K monitor while keeping the in-world scene uncluttered? Why not? Well, maybe because those sub-window widgets depend on each other in unwholesome ways, and maybe because new LL features come with UI components built on those OpenGL sub-windows that would take extra weeks of effort to port to first-class windows managed by the OS.

[Klytyna]

On 07 October 2018 at 10:28 AM, Phil Deakins said:

You are not up there with the Lab at all.

That would be "DOWN there with the Lab"...

There's a reason why most people who move away from the Official SL inferiority Viewer to try a TPV, never go back.

Part of that reason is the insistence on "bug of the week" builds release strategy.

Monday you get THIS weeks bug-of-the-week build, Wednesday you get the Emergency Hot Fix update to LAST weeks bug-of-the-week build, Friday you get the ACTUAL WORKING fix to LAST MONTHS bug-of-the-week build...

And then one of the dozens of "project viewers" kicks in and it's poorly conceived addition gets inserted with a digital crowbar...

Go check the latest Animesh thread, where TPV devs TOLD the Lab that they fubared the FPS, and see who's UP there, and who is DOWN there.
 

[Phil Deakins]

6 minutes ago, Drake1 Nightfire said:

Very much rude. Perhaps you have forgotten the massive amount of Thrd party additions to SL that would not have come about unless TPVs didn't create them FOR SL. Nearly every feature we use was created by TPV devs. They submitted them to LL and either they were approved or not. LL rarely made any features back in the day and the ones they did make sucked and no one asked for. TPVs made useful features we wanted. But hey, keep shining that pedestal you put LL on. 

I didn't say that TPV developers haven't been the writers of features that are now in the LL viewer. I said that TVP developers didn't write their TPVs, and they didn't. And the idea that "nearly every feature we use was created by TPV devs" is just nonsense, of course.

Lol. Me put LL on a pedestal? You have no idea, Drake. Many is the time that I've written that I think so low of LL that I wouldn't lift a finger to help the company. I've said that for years here in the forums, and I still mean it.

[Phil Deakins]

11 minutes ago, Qie Niangao said:

Having managed groups responsible for maintaining large systems, I have to say: that's how we all wish it worked, but that's not how it works. In reality, a system accrues dependencies. I don't know the viewer source code, but just skimming the TPV office hour transcripts it's clear that the SL viewers are prime examples of how a system of programs can become intricately and unintentionally interdependent, despite everybody's attempts to maintain modularity and despite the help of language features and version management tools that enforce some discipline.

Eventually everything gets tangled with everything else. Then somebody decides to "refactor" the source, uncovering the more obvious dependencies, leaving a few for QA to discover, and accidentally hiding a bunch of new ones in the refactored code. This isn't bad software engineering, it's just the nature of the beast.

Yes, things can become less and less independant as programmes get bigger and bigger, but whether or it's a problem depends on what modifications you want to make. Many of the modifications that TPVs have made have been simple rearrangements of things, such as bringing some normally buried variable or other onto the screen. FPS is an example. Some others no doubt need more involvement in the code - that's the LL viewer code.

However much involvement in the code is needed, it's LL viewer code that is being modified, and that's the point I made. It's not third party viewer code, because third parties didn't create any viewers. They merely modified LL's viewer, and I wasn't overkeen on seeing their involvement written as though they created the viewer.

Having said that, I have no doubt that there are programmers amongst them who could create a viewer from scratch if necessary, just as the OpenSim people wrote the server end from scratch.

[Ansariel Hiller]

6 hours ago, Phil Deakins said:

I didn't say that TPV developers haven't been the writers of features that are now in the LL viewer. I said that TVP developers didn't write their TPVs, and they didn't.

I'm terrible sorry most of us also have RL jobs and don't have time to build a viewer from scratch. But I hereby swear and promise I will stop sleeping at night and use the gained time to build a new viewer from scratch. Would that please you, oh Great Phil? Would that make us worthy in your eyes, Keeper of the true Faith of Viewer Development?

[Phil Deakins]

You have no need to write one from scratch, and you certainly have no need to satisfy me. I'm not dissatisfied at all

As far as I know, people do a very good job of modifying LL's viewer. Why reinvent the wheel now?

[Love Zhaoying]

6 hours ago, Phil Deakins said:

I said that TVP developers didn't write their TPVs, and they didn't.

This makes no sense. 

[Phil Deakins]

TPVs were developed from LL's viewer by modifying it. They weren't written by the TPV developers.

Edited October 10, 2018 by Phil Deakins

[Ansariel Hiller]

Just now, Phil Deakins said:

You have no need to write one from scratch, and you certainly have no need to satisfy me. I'm not dissatisfied at all

As far as I know, people do a very good job of modifying LL's viewer. Why reinvent the wheel now?

Somewhere I heard somebody complaining about those lousy TPV developers just cheaply modifying the LL in a wink adding supposedly unneeded features without making their own viewer.

[Phil Deakins]

Then perhaps that's where you should be posting

[Ipecac Burnham]

In an effort to nudge this back on track, I use Firestorm from predominantly 3 features...

 

Better mouse steering (I can control my Avatar on Firestorm exactly the same as I do on... every other game for 25 years!!).

 

Area Search.

 

'search+term' wildcard inventory searching.

 

If LL added these 3 features I'd swap back in no time (2... can lose Area search even, I can LSL that), as while FS gives me by and large better performance, I can set my VRAM and have more control over options, the LL viewer has always made things look prettier to me, maybe it's a placebo... not sure, but there's no real deciding factors that stop me from using it...

 

other than personal usability.

 

I love FS, and the team making it for making it FOR us, but I'd also love to be using the LL viewer instead so I can be 100% certain without auditing someone's code that the mesh uploader is "working as intended" for example.

 

But... each to their own, a few of my friends only use the LL viewer, some use others, some are just clinging to old UI's and refusing to relearn, and of course we're very lucky to even have the option.

Edited October 10, 2018 by Ipecac Burnham
spelling :P

[Drake1 Nightfire]

2 hours ago, ChibiDragon007 said:

Either FS needs a major update or it's my system. Likely it's a mixture of the two. I'm taking my laptop in for service on Friday, so we'll see if that was the cause or not. 

It's more likely the word i highlighted that is the cause.. SL is a system hog. Even a gaming laptop has issues with it, you just cant pack the power of a PC into a laptop.

[Nalates Urriah]

On 10/10/2018 at 10:50 AM, Phil Deakins said:

TPVs were developed from LL's viewer by modifying it. They weren't written by the TPV developers.

That is not completely true. Sections of the LL Viewer come from third-parties. Materials is the latest BIG example where it was primarily a third-party collaborating with the Lab being in more of a support position for integration than an author.

Another example is the Bento feature where third-parties primarily worked out the Appearance Slider features for the new bones.

The POSER feature and Snapshot interface of Black Dragon are being adopted for use in the LL Viewer.

While it may be technically 'precise' to say all these are modifications to the SL viewer... it is not respectfully accurate. A number of people have contributed original ideas and code to an open source project. They were not just tweaks to existing code. I suspect Oz Linden, the Linden in charge of and fan of the open source aspect of SL Viewer development, would disagree with you too. Your opinion isn't wrong, but it also is not accurately reflective of the reality.

On 10/10/2018 at 3:08 PM, Drake1 Nightfire said:

It's more likely the word i highlighted that is the cause.. SL is a system hog. Even a gaming laptop has issues with it, you just cant pack the power of a PC into a laptop.

There are Alienware laptops that would not even spin up a fan to run SL... OK, I'm exaggerating, but not a lot. But, my desktop is good, built 10/2016, yet I have a friend with same era laptop that smokes it.

You are right SL uses a ton of resources. But, what other virtual world 'game' do you know of that runs with well over 200 petabytes of data? That asset DB in like 2010/2012 was being cleaned to get it down to 200+ petabytes. I haven't heard for some time how big the DB is now. The 200PB was before mesh... 

So, if you are implying SL is a hog from inefficiency, I disagree.

[Love Zhaoying]

24 minutes ago, Nalates Urriah said:

Materials is the latest BIG example where it was primarily a third-party collaborating with the Lab being in more of a support position for integration than an author.

I used to see someone on a telegram chat who said they created materials.

Thanks for respectfully and carefully explaining all that in your response:

26 minutes ago, Nalates Urriah said:

While it may be technically 'precise' to say all these are modifications to the SL viewer... it is not respectfully accurate.

 

26 minutes ago, Nalates Urriah said:

Your opinion isn't wrong, but it also is not accurately reflective of the reality.

My gut tells me that this can’t be the end of the discussion, but your explanation is awesome!

[Ansariel Hiller]

6 hours ago, Nalates Urriah said:

You are right SL uses a ton of resources. But, what other virtual world 'game' do you know of that runs with well over 200 petabytes of data? That asset DB in like 2010/2012 was being cleaned to get it down to 200+ petabytes. I haven't heard for some time how big the DB is now. The 200PB was before mesh...

You have 200PB of data on your computer? Streamed via the Internet? Respect! ?

SL is a lag hog and slow as hell because nobody cared updating the rendering pipeline after 2006, offloading all the complex calculations involved with avatars to the GPU that has hundreds of shaders that could do that, instead of letting the CPU do all that - and that in many cases even without using SSE2 (or newer). But if they did, a small but loud group of people trying to run SL on 10 year old hardware are going to complain...

Edited October 13, 2018 by Ansariel Hiller

[Phil Deakins]

@Nalates Urriah

I didn't say that TPVs haven't contributed some additions to the viewer. I know that they have. I said that they didn't write the viewer, which they didn't, and you agreed.

Edited October 13, 2018 by Phil Deakins

[cykarushb]

6 hours ago, Ansariel Hiller said:

You have 200PB of data on your computer? Streamed via the Internet? Respect! ?

SL is a lag hog and slow as hell because nobody cared updating the rendering pipeline after 2006, offloading all the complex calculations involved with avatars to the GPU that has hundreds of shaders that could do that, instead of letting the CPU do all that - and that in many cases even without using SSE2 (or newer). But if they did, a small but loud group of people trying to run SL on 10 year old hardware are going to complain...

This, this is the point I always have to bring up when someone is concerned about performance. This game relies entirely off of old school legacy code that really likes the way old hardware worked, but with a modern demand.

This game really doesn't care what your GPU is, it wants single threaded performance and a bit of ram. Even if you have a terrible quantity of video memory it just starts using drive cache instead.

I have tested this game on literally dozens of different graphics cards and processors and ram quantities, every windows OS post XP, there's a huge problem where I get nearly the same performance out of a dual core Pentium e series and a GTX 275 that I get with any other gpu I cram in there. The only big performance jumps come with the CPU, but even that peaks eventually where my i5 4570 is performing just a tad bit below a 7700k...

 

Ive thrown everything from a GeForce4 Ti 4600 to a GTX 970 at SL and it doesn't really care as long as it has 3gb of ram to eat and a decent processor.

Side note, why did this get necrobumped so hard lel