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.

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.

why so? Taking the albedo, which is a fundamental property of the PBR model and baking it with other aspects that belong in separate maps detracts from the PBR rendering model, messes with the shading thus is muddying the whole concept. I am perfectly happy with my choice of words as I honestly think it is the correct term.

I meant removing it locally by sidestepping the PBR rendering, the job is on my TODO list and I've not looked at it yet, so I will almost certainly explore your suggested route as that is basically and existing version of what I was going to reinvent 🙂 thanks for the heads-up Henri, appreciated as always.

A short quote, but a reply that I think applies to the entire post from @Extrude Ragu. I am in general agreement. Albedo is not a valid fallback texture. The right solution is to provide the ability for creators to give a fallback texture to an item (I originally proposed that this be a feature such that even with full PBR support we can display a fall back texture in lieu of the grey mush while the other maps are being pulled down and the PBR materials assembled). The proposal to "auto fallback" using the albedo does not, to my mind, move things forward; the "non PBR" users then start to ask for diffuse and the creators bow to the pressure and bake shadows into the albedo, thus polluting the PBR for everyone else. this is the kind of mistake that was made before. By promoting "ALM off" as a first-class preference, it enabled users to turn off all the good features far too easily (when in reality, much of the time they really only needed to kill the shadows), this in turn lead to a high proportion of users complaining that they could not see normal maps and materials in general, which in turn led to the baking of light into the diffuse more than was necessary (a diffuse should only really have ambient occlusion baked in). More than this it led to the appalling habit of modelling all the fine details instead of using a normal map because "if I don't model them, half my customers can't see them", which is, of course, the bane of performance issues, leading to heavy choke points in the CPU and GPU and massively inflated overdraw behaviour.... <rant time> I was at an event yesterday (Warehouse Sale) where I had gone to specifically look at a gorgeous-looking steampunk-esque hat with flowers on it. A nice spring-time addition to my wardrobe. When I got there and found the item I zoomed in and the display vanished... This is a known issue when the render pipeline buffers "overflow" due to heavy vertex load. It was clear that the display panel was not at fault, it was simply the victim. I looked at the hat and found that it was well over 500,000 triangles. Needless to say, the hat will not be joining my wardrobe. https://gyazo.com/dcf92bdca3584c5d88e219cd1ecdab3f It is not an isolated example they are coming thick and fast and I fear that PBR is making it worse in the sense that irresponsible or ill-informed creators can produce beautifully detailed, stunning creations in an external tool, press a few buttons and import it into SL with no consequences to them, the pain becomes everyone else's. I had another case reported today where a "secondary" creator, one who does not create mesh themselves but who purchases template mesh full perm and decorates it had bought some meshes that were so complex that even in wireframe, you thought they were solid. They've paid good money for a product that is frankly not fit for purpose, from a so-called "reputable and well-known" creator. </rant time> Despite years of requests, there remains no good way for a non-technical user to determine whether an asset is well made and efficient; complexity is a broken misleading value that people still insist on citing, and of course, LI has no place for rigged mesh (even assuming LI was appropriate)

This is already a work in progress. The UI aspects were being tested before Xmas, but you also need to have the ability to see the item in "legacy render" to make it a sensible feature. We have made it clear that we will not be opening up a long-term "ALM off" type feature because of the burden it places on creators and, ultimately a cost to us all. We plan to have it remove the item being edited from PBR while editing the Blinn-Phong (did I ever mention how I hate how technobabble has polluted the build tools) so that the creator can see what the fallback looks like. Last I heard the new SL mobile client had no support for PBR, is that still the case? If so the attitude of "everyone can see PBR" seems rather misplaced. I may well be out of date on the mobile viewer status though.

For me, it is always on the login. I am not necessarily the best canary for this mine, though, as my online time is frequently spent in one place while I code. I just spent a while hopping about places. A mixture of busy venues, script-heavy shopping regions and numerous texture and asset-heavy scenic places, no issues at all.

Today, I have had repeated failures. Sometimes 2 or 3 attempts are enough; other times it might take 5 or more. Keep banging on the door, and it will eventually open. @Monty Linden these are not DNS lookup failures but timeouts in the curl request. 2023-12-19T00:38:42Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(403) LLCore::HttpPolicy::stageAfterCompletion : HTTP request 000001EEF4197E40 failed after 0 retries. Reason: Timeout was reached (Easy_28) 2023-12-19T00:38:42Z WARNING # newview/llxmlrpctransaction.cpp(266) LLXMLRPCTransaction::Handler::onCompleted : LLXMLRPCTransaction error 0000001c: Timeout was reached 2023-12-19T00:38:42Z WARNING # newview/llxmlrpctransaction.cpp(268) LLXMLRPCTransaction::Handler::onCompleted : LLXMLRPCTransaction request URI: https://login.agni.lindenlab.com/cgi-bin/login.cgi 2023-12-19T00:38:42Z INFO #LLXMLRPCListener# newview/llxmlrpclistener.cpp(344) Poller::poll : login_to_simulator result from https://login.agni.lindenlab.com/cgi-bin/login.cgi: status CURLError, errorcode OPERATION_TIMEDOUT (Despite our best efforts, something unexpected has gone wrong. Could we have an unresponsive login instance in a load balancer or somesuch? This has been dragging on for a while suggesting it is something more than transient network issues. Notably, I am seeing no issues with any other connectivity outside of SL. A DNS lookup resolves as follows: Name: a403.b.akamai.net Addresses: 62.253.3.195 62.253.3.240 Aliases: login.agni.lindenlab.com login.agni.lindenlab.com.edgesuite.net

@Monty Linden I've been asking people in FS Support to send me LMs for a while it appeared to be exclusively RC, but on such a small data set that was inconclusive and I 've just had 3 contrary indications. So no pattern so far. Meanwhile, I am not seeing the issues. Other symptoms reported by those with issues are slow responses when accessing profile data, and when opening an object, very slow retrieval of contents.

I've had muiltiple other confirmations that this is not just "the new FS" (you have no idea how much that relieves me). As @Monty Linden suggested, please reach out to LL support by raising a ticket https://lindenlab.freshdesk.com/support/home

Can you confirm the region you are trying to login to please.