[Beq Talks About The Future Of Firestorm And PBR]

I think the "why do I need to whitelist?" question has been adequately answered already but to summarise. 

Your AV is designed to protect you from malicious files, it does this by running a scan on new files as and when they appear. It your cache folder is not whitelisted then you AV will happily burn your CPU and your disk IO continually scanning and rescanning files as they appear. Because there are so many different AVs and even within those different versions and options the impact can vary from one person to the next, The impact that I noticed (and that surprised even me) was that my textures were getting stuck on a low resolution. I was hunting for a bug that seemed to explain when I found that the AV was not whitelisted (because I'd been deliberately mesing with my cache locations). This may have been due to the cache not being whitelisted or to the realtime scanning and not having the exe listed (though I think it was).

Why don't I have to do it to other apps?

As was mentioned, other apps are almost certainly not writing and rewriting the cache files, and/or do not have a performance critical dependency on accessing them. 

Whitelisting the binaries

The executables, the code itself, have other limitations applied. Certain AVs will limit what network access and other resources a program can have access to. In addition, AV software that does realtime scanning, can inject itself in between your viewer and the internet and inspects every byte passing through, this used to cause absolute chaos as it would disable certain streaming features. I've not explored that area lately to know if it is still the case, I have no reason to think otherwise.

Signed binaries

We do not sign any binaries except for Mac (where there is no choice). Digitally signed binaries might help a little. They definitely help on the installation by not making you click the "Run anyway" prompt. We used to sign them, but it stopped shortly after I joined the team, IIRC. There were two reasons: cost and anonymity. the certificates required to sign releases are not free as a rule, but they are not super expensive (a few hundred pounds per platform per year); the bigger issue was that back then, signing required that the RL name of the specific developer who was producing the builds be public, and that was not something anyone had any interest in. It also meant that team changes required new certs and a whole heap of complexity.

I have been researching a couple of options that might allow us to sign builds now that we are in the cloud without the doxxing and without the costs. It is on the TODO list, but there are only 24 hours in a day, and FS work has to take its ration of them.

Signed binaries would not (I think) remove the need to whitelist. AV still scans the folders by default. It would increase the base level of trust that the AV software gives us and that might help a bit. Mostly it will just reduce the support pain when a new release appears.

 

 

 

[Beq Talks About The Future Of Firestorm And PBR]

11 minutes ago, JUSTUS Palianta said:

Been having rez issues for ages i have no idea how or what to whitelist why don't they just build that stuff into the viewer, so it actually goes.

This is mainly because you can't. If software could automatically whitelist itself, then all the viruses would do it, which is probably not a useful outcome.

You have to do it. It is also different for every AV program out there, which is why we maintain a page covering all the main ones.

That new feature I just showed is the best I can do; it shows the exact details your AV software will likely want. Making it easier to know if you got the right thing. If people have other ideas on how we can make it easier, please let us know. 

[Beq Talks About The Future Of Firestorm And PBR]

6 hours ago, Extrude Ragu said:

Am I the only one who is experiencing pretty severe rez failures when teleporting on fs beta?

Like, half the world just straight never appears bad.

Relog fixes it, but been a major bug bear

I know it's a massive cliché and you will roll your eyes but two things

1) check your AV whitelisting
2) do it again

Oh and don't forget I made a little helper for this.

help->whitelist adviser

I mentioned somewhere recently how I was seeing all kinds of texture and rezzing weirdness I could not explain. Then, to my embarrassment, I discovered that when I was coding and testing the recent cache changes I made, I'd managed to not have my cache excluded. Fixing that has made things so much better.

Also, don't swap back and forth if you go back to 6.X clear your cache when you come forward again. 

These might have nothing at all to do with your issues, of course, but start with those. 

 

[Beq Talks About The Future Of Firestorm And PBR]

16 hours ago, Arielle Popstar said:

My own opinion would be to dispense with the gridlist and just have a couple like Osgrid and Kitely and leave it to the residents to input their grids of choice though perhaps that's what you mean with "self managed". I'd be more then happy if that Grid list only had a couple of the bigger grids and let the rest of us put in our own manually. 

Would be nice though if FS would allow one to input a grid even if it is not online like some of the other TPV's do. Would also be nice if we had a working teleport history for hypergrid locations

This is what I mean. The grids.xml that we distribute and host will be pruned back to nothing (just the SL grids and localhost), even picking "bigger grids" suggests some favouritism and does not stand up over time.

So, on a clean install, you'll get a nearly blank list. It will respect your locally configured grids as previously. However, you will now have the new " + click to add more grids," which pops up the grid selector. The selector list is derived from Hypergrid Business' list with Maria's permission. Over time, if OpenSim gets its act together and provides a de facto live list, then it can be easily switched. 

This image shows the list partially filtered (there are about 300 grids listed). this video clip shows it in action https://gyazo.com/15ef28838964f3210172082e9eb8f829 . (This is running locally on my machine, as it is still in dev)

 

[Beq Talks About The Future Of Firestorm And PBR]

Wading my way through this. There remains a number of misconceptions. In no specific order:

2K texture and on-demand loading. 

All Viewers (those based on LL upstream, which is historically all of them) have always done this. It is know as the discard level, and is a form of mipmapping. Mipmapping is the GPU/renderer choosing to use a downsampled texture because it doesn't need all the detail and can save VRAM, the "discard level" is the same but for RAM/disk cache, we request only the discard level required. The real question is not do the viewers do it, (yes they do), but do that do it well? The answer to that is I think mixed historically and the calculation for which size texture to use has been actively tweaked by LL throughout recent developments.

Open Sim

Honestly, not been top of my agenda, PBR is available on OpenSim and PBR terrain should be supported @Ubit Umarov has asked me to provide a mechanism to allow OpenSim to support fallback textures on terrain for OpenSim, a different direction to that taken by LL, one that is required given that OpenSim does not have the same authority to force changes as LL/SL does.

There have been some recent OpenSim specific fixes, mostly contributed/collaborative with myself and non-FS devs. I am currently working on a replacement for the mindnumbingly awful gridlist. The problem of grid discovery is really not a viewer problem to solve it is something the OpenSim community needs to deal with but in the meantime I am trying out a new "self managed" gridlist. Not sure if it will be ready in time for the release. We shall see. 

Defaults and detection (and more ranting about ALM)

The defaults are specified by the "feature table" which is a file you can actually find and read in the viewer distributions.

There is a lot of "educated guesswork" goes into it, but in the end that's all you can ever really expect; we're not in console land here, everyone has a different setup and so the viewer tries to estimate where it thinks your machine sits on the performance spectrum. 

We do not typically change this. In the past FS did have a different table, and I think that was part of the problem that ALM became. ALM was being disabled at far too high level by default. If you managed to wade through my blog post you'll have read my views on the misuse of "ALM-off" and the impact that may well have had on the evolution of SL content. Big coarse-grained feature switches like ALM-off should never have been employed. If I was getting let's say 15 FPS with settings on High, and turned off ALM and got 30FPS, I might assume that this was the only way to get that result. In most cases, I'd have probably got 25+ FPS possibly even the full 30FPS just by disabling shadows. I could have kept the normal maps and other goodies. But we got used to the coarse-grained control, regularly throwing out not just the bathwater and the baby but the entire bath tub, followed by a whining complaint that "your stuff looks crap when I turn off all the rendering features, make it look better" to all the creators. 

What I would say is, don't be in the mindset of "I used to run on High-Ultra, so I should run on High-Utlra now". The table has been cleared and set out anew. Your old settings and levels are not comparable to the new ones. You will want to play around with the settings to find a "new normal" to establish what the correct balance of performance vs shinies is for you and tying yourself to old settings and assumptions is going to hold you back.

Editing PBR/BP (and its shortcomings)

Zi and I added the ability to edit both BP and PBR textures in-situ a few months back. The new editing tools provide a more concise workflow but one that is rather cramped (you can revert to the LL defaults in preferences) and also allow you to tab between the two and see what they look like. There are a few bugs in this, the tint on BP is not respected (as noted in this thread) but it also can garble the UVs. Both of these are on the todo list but are hard to get to the bottom of, I've burned more hours than it deserved already - if there are coders out there who want a challenge, feel free to have a go and send me a pull request to consider, you'll see from the change history how I injected some of the changes...). I will make it clear, though, that FS has no plans to allow a PBR viewer to disable PBR outside of edit mode. It would be a betrayal of the platform in the long-term to ease short-term pain. 

We (Firestorm) will need to keep the editing experience in mind even after SL has moved entirely on. OpenSim does not block older viewers (which is a different problem for a different day) so grid owners and opensim creators will probably spend more time on providing fallback textures (who knows in reality? time will tell)

The big thing that people are missing in all of this is that it doesn't matter one bit if the viewer does or does not support editing of (or even displaying of) fallback textures. If creators are not providing them (because producing such textures is a pain and often leaves a very unsatisfying substandard result) then the ability to show them makes no difference, all you will see is grey/white or at best base colour. For terrain, that is guaranteed, as no possible fallback option exists.

Longer term

I don't think the blog suggested I would give long-term views; if it did, then that was a mistake, as I have no particularly long-term views to share at present. That said, the pipeline of features from LL is always evolving, and we will be part of those plans. After WebRTC, you have scene uploads, changing the way that some creators will import, but moreover (as Joe mentioned), requiring a fundamental rethink of what linksets look like in SL. A proper object hierarchy opens up news challenges and opportunities for creators and scripters. There are early-stage thoughts about a complete revamp of the UI. This will be a big and scary undertaking, too, but if it goes hand in hand with the proposed client-side scripting extensions, it will undoubtedly add new layers of capability to products and change how we interact in SL. 

There were other points, but I've forgotten them by now, and as usual I've written a lot more than I intended.

 

 

 

[Trying to download Catznip]

Just had a message from Kitty to say it is fixed now

 

[Trying to download Catznip]

Kitty's website doesn't appear to have a cert so you'll need to use HTTP. Trouble is that many browsers refuse to connect to those now. I have pinged @Kitty Barnett to let her know about this thread. @Coffee Pancake can you help?

[How do I get rid of the timer?]

Aha! it is also on the developer menu.

Developer->Show Info->Show Time.

[How do I get rid of the timer?]

I think you've managed to set "DebugShowTime".

On Firestorm, it shows both an elapsed timer (since login I believe) and the FPS,  but as FPS is an FS addition, on LL default viewer, you'll see just the time.

To double check, open your debug settings and lookup debugshowtime; set it to false if it is not already.

https://gyazo.com/9962c2db19e4c1f6c90f1ed84b995dcd

 

 

[any recs for second life third party viewers?]

Sorry to hear you have issues with Firestorm, I would suggest you ask for help in our support group, Firestorm support english, most problems are generally simple to fix. 

That said, while I am clearly biased towards Firestorm 🙂 it is always a good idea to explore other viewers. TPVs are all about choice.

CoolVL Viewer offers quite a different experience as the codebase is derived from an older version and is thoroughly overhauled and maintained by @Henri Beauchamp

Catznip viewer is more aligned to the LL and FS style, but is liked by its users for some of the inventory extensions and other usability features ( @Coffee Pancake

Black Dragon is beloved by photographers and filmmakers ( @NiranV Dean)

Alchemy appeals to those wanting speed and performance. 

That's just a few look at https://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory to see more from the likes of Genesis and the newest one I have seen Megaphit which (I believe) is aiming to support platforms that the rest of us do not.

 

[Blurry textures]

It is worth noting that the Official viewer is now V7 (PBR/GLTF) whereas Firestorm Release is still 6.6.17 (pre-PBR).

Many things have been changed as part of the PBR update, lots of tuning and tweaking for performance, etc., and what you may be seeing is the side-effect of those, it would explain the fact that you see them in the official viewer but not in FS.

The texture blur/fail to load is a bug; there are numerous reports of texture-related issues with the PBR viewer. You might want to take a look at https://jira.secondlife.com and see if you can find a bug report that matches your experience and add your details to it, they may help LL to fix the problems.

This report for example cites MacOS but the user has not tested on Windows https://jira.secondlife.com/browse/BUG-234595

On the Firestorm PBR Alpha, I have seen textures get stuck in a blurry state as well, it is one of the big ticket bugs that stops us from promoting PBR at the present time. If we manage to determine the cause before LL do, then we will make our changes available to LL, if LL find it in the meantime then we will inherit those changes.

Along with items refusing to render/vanishing from view, I would say that the texture loading issues are top of our most-wanted list for bug fixes, and I am sure high on the agenda for LL too.

That's not to say there are only two bugs on that list (sadly).

 

 

[Firestorm's "Use snapshot tool"]

We cannot take the credit here; this is an LL feature (it has to be because it requires server-side support). Inventory thumbnails and the changes that went with them were the main features of the most recent FS release and correlate to LL's release of the same back in October/November, IIRC.

[Firestorm PBR Alpha viewer]

9 minutes ago, BabsNorth said:

It is good that technology moves forward, so I tried the Alpha viewer.  I have a fairly modern Desktop with 16GB Ram, video card and an i7 processor that I use mainly for work.  My internet speed is the maximun in my area of 33mbs. When running the usual FS, it is fast.  I tried the PBR Alpha and it is painfully slow to download textures and  makes movement of my avi jerky rather than the usual smooth flow.  I am just a user of software and have no clue how to adjust settings to improve the Preferences.  I hope the full FS PBR release will accommodate people like me as all my friends are saying the same thing.

If you have just downloaded and run the PBR viewer then there is a reasonably high probability that some of the issues you are seeing are due to anti virus software interfering. I would say it is probably the number 1 cause of such things (though not the only one of course)

Have a look at the following wiki page. You will probably have set all these in the past for the main viewer, but because the alpha is on a special "channel" and installs in a different place you will need to specifically exclude the alpha 

https://wiki.firestormviewer.org/antivirus_whitelisting

 

[Firestorm's "Use snapshot tool"]

It is essentially the same as the "profile" upload from disk. The image is free, it is real, it is also limited to 256x256 and downscaled if you use a larger image, which neatly stops people using this as a means to upload for free.

[Lovense viewer]

7 hours ago, Monty Linden said:

An open API for the anonymous exchange of PGP-signed biometric data.  Hmmm...

I was reading (https://nordvpn.com/blog/lovense-app-malware/) apparently their buttplug has a man-in-the-middle vulnerability.... the mind boggles.

[Lovense viewer]

5 minutes ago, Alwin Alcott said:

I would like to see those special "needs" only work when a certain fee is paid monthly ... it would contribute something to SL/LL fro the extra work.
Around 10% of the earnings would be a nice place to start.

What extra work though? The proprietary Lovense integration is funded by the additional sales that will presumably come from that. Apart from (apparently) stealing from the existing RLV community without paying any heed to the licensing, they don't seem to be adding anything more. 

Second Life has always been a platform to enable virtual life, anything that locks into a proprietary vendor product is contrary to that independent platform strategy. 

[Lovense viewer]

5 minutes ago, Coffee Pancake said:

I would like to see Lovnense hardware/API support in all viewers for all those who enjoy such content in SL.

Agreed, I think so many of us gave a little cheer at the suggestion that LL would be supporting the adult community more in the coming year, but I hope this is a coincidental thing and not part of the plan, as it seems entirely flawed as a strategy and legally compromised. Their suggestion that they'll implement a "RLV-alike" solution is the very last thing anyone needs. Who in their right minds would tie themselves to a proprietary viewer and protocol when we have decades of existing content on RLV that end users and creators have invested a lot of time and money into.

[Lovense viewer]

I have had a number of different people report this to me as a "new scam viewer", it turns out to be a pretty lame but seemingly legitimate adult-focussed viewer. In general, I am happy to see Third-Party viewers as they foster innovation and bring new ideas into our (Second) lives. This one seems to need some time to get its act together, though, ignoring the technical shortcomings; it is in breach of core TPV requirements and lacks basic provisions that would engender confidence in it. 

35 minutes ago, Quistess Alpha said:

seems this is just the standard LL viewer with a fancy lovense button. Is it possible other viewers might incorporate whatever functionality it adds?

The simple answer: "At the moment, no way". As the viewer does not comply with TPV requirements, there is no open-source posting for it, which puts it in breach of the requirements for Third-party viewers derived from the Lab Source code (https://secondlife.com/corporate/third-party-viewers). It is in direct contravention of the TPV rules on several other counts (click help->report a bug and find yourself directed to the SecondLife JIRA), but the lack of any open source release means that no other viewer could incorporate anything in the viewer at present.

It is no small wonder that people assume it is a scam viewer and consider it a high phishing risk. There are indeed grounds for concern, without digging too deep we can note that the expectation is that the "lovense" extensions allow interaction between Lovense toys. There is no obvious policy on data use, so we cannot tell how the toys are linked through the Lovense infrastructure and whether privacy is respected (we can see from the guide that it links via a QR code, but we know little beyond that). There is no way that a legitimate TPV could incorporate that kind of extension without more transparency on what is being shared, we'd be opening a can of worms for the future.

Integrating adult toys into the viewer is a niche but reasonable feature. Restricting it to their own closed-source viewer seems a rather shortsighted plan, especially as they do not have RLV, making it all but useless to many adult RP styles in SL. One would assume the main incentive is to market and promote the Lovense toys, not get into the metaverse viewer business, so an open-source extension would probably have been a wiser investment.

There have been integrations previously, but I think these were viewer-independent and used LSL to bridge a "Lovense" enabled region to the "Lovense app". This presumably has limitations that the manufacturer wanted to address, but in requiring a specific viewer to be used, I think they've misread things. Who knows, perhaps we'll see it improve and grow.

Overall, at the moment, it seems like a plausibly good plan, let down by poor research, poor execution and, even more importantly, poor marketing.

[Why I Don't Like PBR]

1 hour ago, Conifer Dada said:

I use advanced lighting (shadows etc.) most of the time and it worked OK up until the PBR viewer came along. Now, turning off advanced lighting and setting other graphics to minimum doesn't improve the slow rezzing or non-rezzing, it's just as bad as with advanced.

There appears to be some confusion here. On the PBR viewer you cannot turn off advanced lighting. You can of course set the graphics settings lower. If you have a repeatable issue then please raise a JIRA https://jira.secondlife.com to document the issues so that it can be looked into. If the problem occurs only on Firestorm or another TPV but not on the LL viewer then report the issue on that viewer's system (for Firestorm that is https://jira.firestormviewer.org). Many people who are trying the alpha viewer for Firestorm are forgetting to ensure that the binaries and other aspects of the new viewer are whitelisted in their AV. Double check that you have the correct exclusions in place for any versions that you have installed.

[Why I Don't Like PBR]

1 hour ago, Candide LeMay said:

This is still happening and is very annoying. The sim I'm demonstrating it with has multiple height layers, 500m apart. If you visit a higher layer and then come back to the lower layer, the higher layer will cast shadows, despite being out of draw distance:

An interesting issue, if you have not already done so, this should be raised as a JIRA on jira.secondlife.com (from the LL viewer you can click help->report a bug and it will fill in some parts for you)

 

[Firestorm PBR Alpha viewer]

8 hours ago, Extrude Ragu said:

I don't know when this was last updated, but I wonder if it's even possible to play SecondLife on 4gb of RAM.

No, its ridiculous and has been raised 100 times in various meetings.

To be honest ours is not much better but it is clear that you can maybe "logon and make basic interactions"

https://wiki.firestormviewer.org/fs_system_requirements

We do specific 8GB min for 64bit, and if we are strictly honest that's correct. It will get you logged in. Chances are you will crash as soon as more than one person is in the region. We should probably add a footnote to say "8GB dedicated RAM not shared with your GPU."

Of course, anyone buying a new machine and targeting the minimum spec for something that is important to their purchasing decision is probably asking for trouble.

 

[Firestorm PBR Alpha viewer]

7 minutes ago, Flea Yatsenko said:

Haswell came out in 2012. Surely the people who are complaining so much aren't on 11 to 12 year old laptops?

In Feb 22 we had about 3% of users on pre-2012 hardware. In Oct 23, it had dropped to about 2.5%.

The rate of change at the low end is high, with just less than half of those on pre-2012 machines trading up to newer machines between 2022 and 2023. (The number crunching for this is far from good statistical science as the stats we have are not very clean, but they give a fair indication I would say)

The point is that I don't think  CPU is the bottleneck now. The optimisation work has shifted the workload and made things far better in that regard. certainly for older machines the lack of threads will be a constraint but people are still buying brand new machines with 8GB of RAM and expecting them to run SL healthily. Spoiler alert: they are disappointed.

There is some pressure on us, our support team more than most, to identify the best strategies for users on limited resource machines, and help them adjust. Low defaults is only one tool in the toolbox. Once we have a good picture of the impact we can try to make things manageable but there also has to be an acceptance that there is only so much you can do, you simply cannot fit a litre of textures in a pint glass of RAM.

 

[Firestorm PBR Alpha viewer]

11 minutes ago, Flea Yatsenko said:

I can guarantee you there will be people actively seeking out fully baked homes and stuff over PBR two years from now. That's just how some of the SL residents are.

Correct, they can desire that. Same as many cling to default avatars and sculpties. The expectation is that those will be the tiny minority. It's a free world where they can wish for what they like and seek out such content; there may/will be niche creators who wish to support them, too.

I think the excellent work that LL has done in raising the frame rate through successive iterations of optimisation has brought much more breathing space to the low end and reduced that entry bar. Too much time is spent bashing LL for this or that statement here, and not enough to recognise the amazing work done. The uplift in performance over the last couple of years is nothing short of miraculous in the face of the unrelenting flood of poorly optimised content.

What I have no conclusive data for yet (and I doubt it will be available until we have PBR in the wild and a fair amount of content) is the typical long-term memory demands. I suspect that 16GB will become the minimum viable memory footprint for normal use in the near future. This will be driven partly by the overuse of 1024 maps where they are not needed, as we have seen for the last decade, but also by the increase in maps. The rationalization/de-duplication of blank maps that LL are doing on the server side is one attempt to mitigate some of this effect. 

I see a lot of out-of-memory crashes in our bug splat reports. We can sometimes put a plaster over them and carry on, but at some point, things fail. AMD graphics is particularly good at this kind of crash. Their "shared memory model" allows users to allocate/reserve portions of main RAM for GPU use. We have recently seen users with 8GB main RAM and 4GB reserved for GPU. This leaves ~4GB for the OS and the programs, and all the data. Needless to say, they crash almost immediately in the AMD drivers.

 

[Firestorm PBR Alpha viewer]

23 hours ago, Henri Beauchamp said:

I would have loudly opposed to this totally silly statement about providing two different items for PBR and legacy viewers, when all viewers can render (even if differently) a combined PBR plus ALM (or diffuse only) bearing face !

Making two separate items achieves nothing, PBR is in the eye of the beholder. If I rez a new leather sofa with lovely PBR materials, that's fine because I can see it, if my guest is on a non-PBR viewer, then I do not have the option to rez them a different item. They will see what I have, and it will be ugly without fallback support. The extension of this argument becomes "If you are building for a mixed audience, then you should only rez non-PBR", this is completely counter-productive and would kill transitional adoption dead in its tracks. We need multimode rendering during the transition, making it harder for creators to provide a fallback is in nobody's interests. 

"Why don't you just force everyone to update?"

Firstly, that's never ben the FS model, our users have always enjoyed the long-term support model that allows them to choose, within a three-release window, when to update. More than this, though, I would argue that we need the transition to allow people who have weaker hardware the time and space to decide on whether they need to upgrade, find an alternative way to interact with SL, or  (the very worst case) leave SL. While they are not the majority, by any measure, we do play host to a significant number of minority groups who use SL as a social space to interact where they are unable to do the same in RL. These groups include those living on some form of disability income, for example, and often do not have the same disposable income to make a major purchase at a moments notice. Allowing them the time and options to manage their own transition, while not burdening the majority with legacy demands and/or additional work is something I feel strongly about.

There will come a point by which people will need to have made their choices, for Firestorm users, that will be after our 3-release long-term support policy removes the final non-PBR release. For other TPVs, it will vary, as @Henri Beauchamp has stated. 

 

[Firestorm PBR Alpha viewer]

4 hours ago, Qie Niangao said:

Anybody with a PBR viewer—hence, all those for whom a PBR rendering model even exists—will never see the "pollution", right? It's only folks gazing through the dimming glass of forward rendering who'll ever encounter it… and maybe a few too stubborn or delusional to update. Yes, it will look like crap sometimes, but surely no worse than a void textured surface.

We may be talking at cross purposes. I asserted that if viewers were coerced into automatically using the albedo as a fallback diffuse, then the creators would be coerced by those not seeing PBR into providing baked light in their albedo map at the point of material upload, as such, the albedo is corrupted at source and the pollution propagates to all. It is a hypothetical use case based on the exact behaviour we have observed from creators since ALM.

Synthesising a fallback diffuse automatically would be different as the base PBR is not being corrupted in the process.