Beq Janus

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.

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

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?

Aha! it is also on the developer menu. Developer->Show Info->Show Time.

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

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.