Beq Janus

You are always special @Aishagain😉 However, it is unlikely, the login bugfix is the cure, as it was very obscure and triggered if the user had previously logged out with the ctrl-shift-1 statistics bar open. Moreover, people are seemingly seeing this on other versions and other viewers. Never say never though, which is why I need people affected to try on other viewers and other locations.

If you are having issues with login (esp if you are on the new Firestorm 6.6.17) please download the latest LL viewer and try that for a while. There is no obvious reason why the FS update should cause problems, so we need to understand if it is isolated to the viewer.

This is an interesting conversation. When I first encountered a relay in a group chat I was surprised and a little disconcerted at not realising there were people outside of the room listening in, but I was also rather impressed at how well it worked and at a purely technical level, enabling an extension of SL presence to Discord makes a lot of sense. Technical kudos and support convenience aside, this is almost certainly a TOS violation, as mentioned by many already, the fact that your chat is being echoed into a public forum that you may well have no access to, that you have not signed up to and that you may not even be able to trace is a breach of trust and is clearly not allowed. Someone (the OP perhaps) mentioned that a local chat relay, broadcasts when you first say something, this does not happen in the groups that I know are relayed, nor would it change the facts of the issue. Being told is not the same as being asked and getting your permission. Personally, I have no problem whatsoever with many groups to which I belong (such as BB, whom I have nothing but the highest regard for) using a chat extender to mirror my chat between Discord/Slack/whatever and SL (and to be clear, if the option to opt-in to that was available for those groups I would enable it); however, I almost certainly do have an issue with some other groups that I am part of doing the same as I consider my membership of those groups less public (and by the same measure would choose to opt-out or leave those groups were I made aware/given the choice). The fact that I have no control or visibility of this is troubling. Of course, anyone can do this at any time, if someone wants to copy/paste chunks of what I am saying into another forum then they will TOS or no TOS and as such I should be careful of what I say and do, we all have a responsibility in this regard, but as @Henri Beauchamp pointed out, there is a difference between having a rumour of a conversation overheard in a pub, where the audience was limited, and a full recording of that same conversation taken without permission and echoed to the masses. When we chat in a group we have an "expectation of privacy" and assess the risk of that privacy being broken based upon those present etc. Once we accept that actually any group may be extended to an unknown/unseen audience we have given up any illusion of privacy. The big issue here is not so much the siphoning of chat to another service, but the fact that we are not being given any warning or opt-out. There are clearly big gains in terms of customer support from using a rich communication platform such as Discord, it would be useful (as is demonstrated by the mostly well-intentioned and increasingly widespread use of relays) to have proper tools to deal with bots and relays inside a group chat.

TL;DR: Firestorm should remain unaffected. Due to our three-release policy, when Win7 no longer installs the latest FS, you will have two prior releases available that will continue to work, allowing you time to choose how you resolve this. With regards to Firestorm. Our position re:Win 7 is the same as the lab's and the same rule we apply to other aspects such as 32-bit, Linux distribution and Mac version. Unsupported platforms work by chance alone, and no action is taken to fix them when that luck runs out. We will not kill Win7 support deliberately; it might well fail at any point due to a build dependency or other change that we make, and when that happens, we will choose not to resuscitate the patient. Now, with the specific case here, I cannot test this to be certain, but Firestorm should remain unaffected for the end user for now. Firestorm has been built using GitHub Actions for over a year now. As with the LL builds that have newly migrated to GitHub, this enforces a higher degree of security and support awareness as GitHub retire older OS build machines (know as runners) on a well-defined basis. For example, this has seen a recent update of our Mac builds from 10.X to 11 and our Linux builds from Ubuntu LTS 18 to 20. We have been building on Windows 11 (essentially, Windows Server 2022) for a while now. In our build system, we are using (and have been using) Python 3.11 for a few releases, and given that you are only now seeing this issue, that adds a little weight to my belief that we are, for now, unaffected. The bottom line is that Firestorm does not require Python to be installed on the end user's machine, as we do not use the LL mechanism to manage the viewer updates. FS allows you to update manually and provides three supported versions; when we do reach a point (probably sooner rather than later) where Win7 can no longer support the viewer, then those users will, in theory, have a period of up to 3 viewer releases during which they can choose how to address the issue. This should be ample time for most. I cannot, of course, guarantee this. It is always possible that a problem occurs, such as a security flaw which requires us to block all older viewers. There is no precedent for it that I know of, though. As an aside, if and when FS does not work, you might still find that some other TPVs, those that are based on the older viewer 1.X heritage such as @Henri Beauchamp's CoolVl Viewer would still work for you. My expectation is that (in the same way as 32-bit is affected) the death of Win7 will not be due directly to the Viewer itself but a requirement of one of the libraries that we depend upon. For those interested: The supported Github runners are always found here. These dictate the platforms we can build on, but not necessarily what you can run on. https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

Keep in mind that complexity is at best a guide and rarely an accurate measure of actual render cost. There are many many items that are perfectly normal, have little impact on your frame rate and yet have a "high" complexity, the number is very poor predictor these days, it was never very good and many too things have changed since it was first defined. Compare that to your typical rigged mesh hair which will frequently show low complexity but can easily be the slowest rendering part. People who insist on jelly dolling at anything under 200K are probably punishing the wrong people a lot of the time. The sooner LL discontinue/fix this crappy misleading number the better we will all be.

It's a known issue with the latest viewer. It is on my todo list. https://jira.firestormviewer.org/browse/FIRE-33157

I understand only in the sense that it is a problem that some people get; there's not always a simple answer as all of us have different hardware and network setups, and so it is very hard to do more than give a list of steps to follow and hope that the affected person is able to follow them well enough to resolve their issue. The people best equipped for this in general are the wonderful people on our support teams. They deal with more varieties of these types of issues than any other group in SL and are almost certainly the best place to ask. ( @Toshi Exodus you can join the Firestorm Support English group and explain your issues there and one of the team will do their best to help you.) You might want to point them to this thread as well so that they can see what you have put here. The first thing I would expect them to suggest, though is that you work through each and every step in this page (even if a step seems irrelevant, you've got nothing to lose from following it) https://wiki.firestormviewer.org/fs_media That is our primary troubleshooting guide for media issues. There is a nuance here, which is that you have no voice either. The troubleshooting guide for voice is arguably even more extensive as there are more varieties of failure. You can find that page here https://wiki.firestormviewer.org/fs_voice. Again I would advise following through step by step. Finally, I would note that in the lovely and not at all overly complex and convoluted world of anti virus that there is Whitelisting and there is excluding from scans, which depending on the maker of your choice of AV and in some cases even which version, may be called many different things. What you want to ensure is two things. 1) Virus scanning of network connections is disabled. This messes with all manner of things and will kill performance by effectively disabling a number of HTTP streaming capabilities. Disabling this may occur when you whitelist the folders and executables, you may have to explicitly exclude it depending on your setup. 2) Virus scanning of folders and files that the viewer is frequently updating. The cache and settings and logs being chief amongst those. The definitive guide is https://wiki.firestormviewer.org/antivirus_whitelisting In general, items like this are far more "user specific issues" as opposed to "bugs" so as a developer I am not equipped as well as the support team to diagnose it as they see far more of these than I, but I hope this might help a little and I strongly advise asking in support

Stepping aside from the discussions slightly. @Monty Linden I've been using sequencediagram.org (or a tool that it is based heavily upon websequencediagrams.com) for years to capture these types of charts in my RL work. Because the charts are source-driven, they are perfect for keeping in version control, but we also might want to think about refreshing some of the wiki.secondlife.com pages that haven't been updated since the days of the original AWG.

The scenario generalises for non-movement region connectivity, (such as a region coming into view because draw distance increased) I think it boils down to something like this... The solid lines are HTTP, with the narrow arrow heads inside the groups being the messages carried as the payload of the eventqueueget dashed lines are LLUDP, where the solid arrow heads are marked as reliable. The example is very simplified, it assumes only one region got added, but all that happens in the case of more regions is that the eventqueue payload has an Enable/EAC for each of the new regions. I am not showing all the other noise that may well appear.

This has been the single most common complaint in these first few days. The vast majority of users do not have an HDR monitor and everything looks contrasty/cartoonish, it is proving very unpopular for that reason alone at the moment. I am trying to find a way to summarise that feedback at the moment. This is one of the issues I have had with the attitudes expressed in the creator forums on the LL discord server. There is a general view that inworld creators and those that do not wish to use the big tool-chains have no valid claim to be creators. This is both arrogant and ignorant of a whole swathe of hobbyist/non-commercial builders in SL. These fall into a number of important categories: 1) The DIY-er. Just like in RL, there is some pride to be had in making something of your own. It might not look as slick as a "professional/commercial" product, but you made it and it has sentimental and subjective values way beyond any linden dollar price tag. There are two (arguably three if we include "TPV export as DAE") main toolchains used by creators that work inworld. Mesh Studio and Mesh Generator. While these are (obviously) limited to working with prims (incl sculpts) and not as flexible as directly working in mesh there is still a good number of people that enjoy the experience and find that the output is more than adequate for their needs. The majority are building for their own needs, be those role play props, artworks, additions to their homes or any number of personal items, there are also a few that sell their items and have a decent customer base who enjoy their products. 2) The decorator. We all like to customise things, from buying a house in the marketplace and then filling it with our choice of furnishings and lighting that fits our tastes, to building an entire region with mix and match assets from many creators, often tweaked and enhanced with "kitbashed" prims/sculpts/mesh. PBR can still support this, we can import PBR materials that can be tiled and apply them to our inworld objects. It worries me that we're seeing suggestions that homes sold by creators should have built-in probes and lighting. This goes against what many house-dressers want and I hope will backfire on those trying to force their design identity onto all of their customers. 3) The re-seller Mesh Creators have long had a sub-market for template mesh, meshes that come with a UV guide and other textures designed to allow their customers to apply custom materials and re-style and re-sell their product. I am sure there are many more, examples of people that don't want or need to leap into some external toolchain every time they need something.

Interesting (maybe, to some, at least) addendum to the history lesson. In OpenSim, client-side baking is still a thing; it actually makes sense when you consider that the server that you are connected to may be a very low-end machine and also that the layers that you are wearing may be hosted by a different grid. The downside is of course that you are then co-dependent on your fellow potato wranglers. Before we roll about laughing though consider that the SL bake service is behind the majority of your orange cloud experiences. I timed it recently, logging out standing next to my partner who was fully-rezzed, and then logging in again, a few minutes later, I get a swirly cloud. It took 183 seconds for the cloud to resolve itself (the timers are in your viewer log file). I have a perpetual TODO note to explore exactly what is happening but the majority of this is I believe down to fetching a large number of bake textures and the fact that the viewer is told not to try to render an avatar until all its bakes have arrived.

When I asked recently about "best practices" in the Creator Discord I was generally dismissed and shouted down for even suggesting that there was a transition period. One creator cheerfully declaring that they had no intention of providing a fallback, or considering a bright pink "upgrade to PBR" texture instead. This does not bode well for the mobile users or those users for whom it will take time to save for an upgraded machine and wish to remain in SL as long as possible. In reality, we won't know the facts about the adoption rate and thus the expected transition period until release.

There is a difference between functioning and giving a reasonable experience, and also to being supported. Once PBR is officially launched by LL, and once we release our first PBR viewer, then based on our normal practice there will be support provided for prior versions for 3 releases. After that support is dropped and we typically block those builds. That suggests that probably 12 months after the initial PBR release we would expect to be moving away from the non-PBR viewers. Older viewers should continue to function without issues, they would only cease to function if the underlying protocol that communicate with the SL servers change. At the moment, no such changes are expected. The question then is will you get a reasonable experience, and that is going to depend a lot on the attitude of consumers and creators. As @Flea Yatsenko notes, the PBR spec allows for a legacy texture to be applied to a PBR asset such that non-PBR viewers will see a fallback texture. However, this does require the creator to provide such a texture, if not then you will see a plain white, untextured mesh

Coincidental, though probably not massively different, we merged PBR after our main release (6.14) last week, so the PBR codebase that was merged was up to date at that point.

We've just released an Alpha build of Firestorm that integrates the Linden Lab PBR project viewer. I have to emphasise that this is Alpha, in the same sense that the LL version is too. This is not release quality but the hope is that many of our users will be keen to test this new technology out and at the same time provide ourselves and, more importantly at this stage, Linden Lab, with valuable bug reports and user experience feedback. PBR server-side support is not yet ready for mainstream and is only available in a limited number of regions on the main grid (Agni), it is also present on the beta grid (Aditi). This is a shiny, fun, bug-hunting spree. The more we find now, the less painful things are later on. For bugs, please use JIRA (if this is clearly a core graphical bug, I would suggest going straight to the LL JIRA https://jira.secondlife.com )for others then do use https://jira.firestormviewer.org For more general comments on the PBR experience then these forums have a number of PBR discussions; you can also comment here of course. Please do remember that this is not intended to be release quality; constructive feedback is appreciated. https://www.firestormviewer.org/see-the-future-of-second-life-graphics-firestorm-pbr-alpha/ The download links are available in our preview group (Phoenix-Firestorm Preview Group secondlife:///app/group/7ba4569c-9dd9-fed2-aaa7-36065d18a13c/about) this is also where inworld support is given, we cannot support this viewer in our main support channels as it is not a release build. Enjoy.

update: There is a Jira for this raised by Asher, please add you details to that. https://jira.secondlife.com/browse/BUG-234248

@Silver Selenium I would be interested to know if you have recently (or ever) changed your name. I read that another person who was having this issue had recently done so, and as this would be a uncommon but not unheard of situation I am wondering if it ties together those of you who are experiencing this problem. EDIT: I just found an existing JIRA for this. Please add your experience to that. https://jira.secondlife.com/browse/BUG-234248

@Asher Isodo out of interest (given new information on another thread here) have you changed your name recently (or ever)? I'm trying to see if there is a pattern behind these. ETA: I just saw your JIRA (thank you). https://jira.secondlife.com/browse/BUG-234248 I am directing a few others that way. Can you please updateon the JIRA if by some chance you have changed your SL name recently (or undergone any other change that comes to mind)

Not one that I am aware of, in the sense that I have only heard of it in the occasional mentions we have seen here. I have not seen anything in terms of a proper bug report.I will double check with our support team. The information here that places the failure in the context of a name change is very interesting. @Virulent Vortex could you please raise a JIRA at https://jira.secondlife.com . Based on what you have written here, this appears to be a bug in the upstream LL viewer that we have inherited, which also implies that it will affect most other TPVs that have adopted the new profiles, moreover, it may well be a server side issue related to that update mechanism used. If I understand correctly, this only happened after you changed your name, that is probably/possibly an important detail to record. The simplest way to create the JIRA is to login using the LL viewer and go to the help menu, from there select "report a problem"; that should take you directly to the JIRA system and even pre-fill some of the form for you. When you write the JIRA, be sure to specify the steps that led up to this. It would be useful to attach you viewer logs to the JIRA, though only if you go through the steps of attempting to do the update, beforehand. Looking at the code I see only limited logging in the profile code but it may be enough to suggest where the issue lies.

this is the side effect of merging in the largely retrograde profile updates that were applied when LL moved away from web profiles. We now have "free upload" profile images that you pick directly from disk and which cost nothing, and bypass the normal image upload. The downside of these is that they are then squashed to 256x256. We retrospectively restored the ability to select an inworld texture and upload normally, which leads to this rather awkward situation where you have multiple ways to "update" your profile. It's pretty ugly all round and personally, I think it was far better before the profile changes were made.

@Jackson Redstar, back on the original subject a little. I'm sure that you'll have probably looked at this already but do double-check that you have all the correct AV whitelisting in place for BD as well as FS. Assuming that BD is using a separate cache, that would be a good reason why sucking down a scene might take a lot longer. Temporarily disabling any AV might be a quick way to test that theory. Also, keep in mind that if you are running "side-by-side" comparisons, viewers will (by default) back off and go into low-usage background mode when not the active window. For many viewers (Cool VL Viewer is the exception here, I think - because I haven't yet borrowed Henri's idle/background code, and BD may be the same), the rendering frame rate and the rate at which background stuff is serviced are somewhat correlated. If your viewer is inactive (i.e., you are tabbed out), some aspects of the background workload will run at a lower framerate. Many more things run in separate threads these days than they did in the past, but several aspects of viewer operation are still coordinated from the main thread; when you tab out, and the viewer yields the CPU for other processes, this coordination happens less often, and if you are tabbing out of one viewer and into another then the active viewer will naturally appear to be a lot more snappy and faster.

Whitelisting is definitely something to look at. @Rebecca Crisp mentioned 100% RAM usage but not 100% CPU, unless I misunderstood. I would certainly take a look at the VRAM setting but be careful that if you are running multiple instances this can itself lead to increased instability. I would increase your disk cache too, the current setting at 2GB is very small if you are travelling around more than a couple of simple regions. To examine the memory usage I'd probably want to look at log files. If none of the advice here helps please raise a JIRA ticket at https://jira.firestormviewer.org and describe as fully as possible what happens, how long it takes for it to happen, and attach your log files. While it is not what is happening here. It is worth noting , that for good and ill, the viewer will increasingly be demanding more of your PC. It started with the performance updates a few releases back and will continue with PBR. In striving for better performance and higher quality the viewer is moving from something we run on the side while doing other things and not having to worry about the resources it demands and the conflicts with other tools, to being more game-like expecting the whole mahcine and wanting to use it.

Just returning here to give a public update. @BondJamesBond contacted me privately, and I've been able to look at the bug splat reports. They do (as @Kathrine Jansma suspected) suggest an OOM exception in the NVidia drivers. The next step will be to review the settings and see if we can tighten them up a bit to allow a dual operation in 4GB VRAM. I've not yet seen any preferences etc so I have no idea what settings are in use, but I thought I'd update here with what we have so far. @Henri Beauchamp I recall that you've mentioned a couple of times in forum posts in the past about "broken dynamic memory" but I've not seen any details on that. What is the broken behaviour you are alluding to? I can take a look at it if I know what I am looking for. Of course, at this stage, I don't know that we are even using dynamic VRAM here. As a general note, all viewers that are largely based on the LL viewer are increasingly able to use more of the VRAM more of the time, this is a trend that is going to continue with PBR.

While I agree that more information can do no harm; indeed, the reason I added the in-viewer LOD preview on FS was to increase the visibility of this issue and enable "look before you buy". None of these tools overcomes the basic problem of consumer indifference and creator time-to-market pressure. While as users, we may collectively curse the erratic frame rates, the FPS killers and the texture hogs. As individuals, we are all too willing to tolerate a bad item if it serves our needs. I don't think that uncosted bad assets will be halted by pretty pictures and information overload. If the server on upload were able to reject poor assets or, more realistically, if worn assets carried a proper impact cost, that would prevent entry to regions that were already at "capacity", then we'd get appropriate pressure on creators to be economical with render impact in the same way as we see with land impact for non-worn items. I have written this before here I am sure; right now the market pressures are entirely wrong. Creators are expected to produce new, unique items on a very regular basis if they are to stay at the top of the market. A 1 million poly dress is not going to sell fewer units than a 50K poly dress, but the 50K poly dress takes time, effort and some skill to retopologise properly and so there is no revenue incentive to spending that time, it is a very simple commercial choice to say "screw it, good enough, it'll sell". Many conscientious creators out there will take the extra steps, and we should celebrate those because the reward for them in doing so is higher production costs and possibly lower sales, a sacrifice made to help us keep performance higher. You also have the argument that those who do optimise lose sales because the side-by-side comparison with a ludicrously over-dense dress makes their offering look less appealing visually and looks win the day. Ultimately we need enforcement, a tangible penalty/cost that incentivises good asset creation, but we also know that this is a pretty tough nut to crack.

The derendering when you zoom in close is only slightly related to LOD, it is precisely what @Henri Beauchamp describes. I get called to investigate such things a couple of times a year on average, the common cause is sports shoes (seriously). People model every last detail on a shoe that nobody is going to look at for more than 5 seconds, and then they set out 20 of them on a stand at an event. The poor merchant in the stall next to them will frequently find that some of their own products are not showing up for some people because, as Henri noted, the cutoff is simply based on how much is stuffed into "this part of the scene", and once it passes a limit everything else is arbitrarily discarded. The issue is ancient, but sadly people are still making over complex items, and I don't expect them to stop any time soon. Edited to add: Another common cause is table decor, flowers and serving places. Possibly why you found this at a wedding. Here is an example from a few years ago where the creator themselves was confused by the behaviour (https://jira.secondlife.com/browse/BUG-225107) https://jira.secondlife.com/browse/BUG-1509 The FS default for that setting has been 64MB for as long as I can recall. Runitai notes that the LL default was 64 in 2013 so It does beg the question as to whether a larger default would be better suited in this day and age, perhaps something that scales to the RAM/VRAM available. Sadly though, we are once again making the viewer compensate for unsociable, irresponsible asset design.