Beq Janus

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.

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).

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.

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

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.

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

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.

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.

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. 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.

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.

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)

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.

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.

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.

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.