Firestorm 6.4.13 release

37 thoughts on “Firestorm 6.4.13 release”

1. It’s a shame about there not being performance improvements. Right now I’m stuck on 6.3.9 because the sim I generally hang out on is complex enough to have places where 15-20fps isn’t abnormal on that, 6.4.12 reduced that to around 7fps, which is unusable.

   I just hope the Firestorm team either fix it before the 3 version rule kills 6.3.9 or else suspends the rule until the performance issues are fixed.

   LikeLike

   1. “Performance issues” can be a somewhat subjective term due to external influences. For example: you’re seeing a degradation in viewer-side fps since 6.4.12. However, I’ve found little to no difference between 6.3.9, 6.4.12 and 6.4.13 outside of the more general issues people are reporting and which are not confined to Firestorm – such as slower texture / mesh loading when entering uncached regions. This tends to make it hard to determine what might be going on and where without more information being passed to support teams on what is being experienced together with when & and where.

      As such, and assuming you haven’t already, all I can do is suggest you file bug reports with Firestorm specific to your experiences (such as side-by-side comparisons taken at the same location with the same settings, etc), as doing so might help pinpoint particular problems.

      LikeLike

      1. It’s really odd, because this basically the #1 complaint about Firestorm at the moment. A sizable proportion of the people who use the sim I hang out in are refusing to upgrade, others are switching to Kokua, which used to be slower than Firestorm and is now roughly equal, it’s all over every commenting thread about Firestorm, and yet… no official acknowledgement and no pressure from journalists. And that scares me because it suggests nothing is going to happen.

         I… don’t know what to say about you not seeing any difference at all between 6.3.9 and 6.4.12. Even the Firestorm defenders I know in the groups I’m in are acknowledging FPS drops have happened, they’re just saying that it’s still usable to them because of their specific hardware.

         Do I want to submit a Jira ticket? Urgh. This means finding a sim that shows the problems at worst (easily done), going to it when it’s empty (harder, I mean, it is often, but not for extended periods of time), then wiping Firestorm, installing a clean 6.3.9, log in, waiting 5-10 minutes to ensure textures are loaded, snapshot, quit, wipe Firestorm, install clean 6.4.12, wait 5-10 minutes, snap shot, quit, wipe Firestorm, install clean 6.4.13, snapshot, quit, then repeat the same process on my Ubuntu machine which has the exact same problem that apparently doesn’t exist.

         And then what’s the result likely to be? I don’t want to sound mean and maybe Firestorm’s developers are better than average but my personal experience of filing Jira tickets is you immediately get a DUPLICATE against a vaguely related bug that isn’t actually the same, or a WONTFIX because people are blaming hardware or something else. Even if that’s not true, you can probably guess why most of us get a lump in our chests about the mere idea of putting in the work to do a full bug report.

         So… I’m not saying I won’t, but right now it’s not on the top of my list. I’m just concerned that this isn’t an issue being taken seriously. If it’s not fixed, and if they ban 6.3.9… well, I won’t be going to the latest version, I’ll tell you that. Perhaps someone else will step in, or perhaps our communities will rebuild themselves somewhere else.

         LikeLike

         1. Broadly speaking, I’ve always found FS produces lower FPS than other 6.x TPVs & the official viewer, so I’m not surprised people switching find they generally get higher fps. Similarly, in terms of Linux vs Windows, Linux has always tended to run the viewer at higher local fps.

            My own experience is based on visiting multiple regions for the purposes of photography every week and with each iteration of FS. I generally find my fps ranges from the mid-teens through mid-to-high 20’s with Shadows enabled, and low 20s through high 30s / mid-40s with shadows disabled. The only real exceptions I find to these rates are regions that have high concentrations of mesh coupled with a lot of unique textures, where fps can drop to single digits with Shadows enabled.

            Texture and mesh loading do seem to be slower in general – but on first time loads, that could be the result of increased interaction times between the viewer, the simulator and the CDN delivery service as a result of the AWS move (and I should stress I have no empirical evidence this is the case, I’m just spitballing). I’ve also tended to find texture loads seem to be slower even when cached (and which can affect initial fps when arriving in a location I have cached – such as our home island), but both of these are different to pure FPS drops.

            LikeLike

      2. For what it’s worth, just did the tests above under Windows. Of course, some people were logging in or moving around, but I waited 5 minutes each time and looked for the fastest frame rate (which was also a consistent rate, the fastest wasn’t unusual.) Each was a clean re-install, uninstalled old version, deleted files in AppData/*/Firestorm*, installed, ran, loaded back up settings, restarted, ran, entered SL, sat on same tire on same tree and hit ESC to reset the view, opened the same windows (People, Chat), and waited five minutes to ensure textures were loaded and confirmed Firestorm wasn’t complaining that it was still loading textures by clicking on the lag status thingie in the top right.

         The choice of location was decided by the fact I know it isn’t terribly fast but is an area I hang out in.

         Results?

         6.4.13 11.8fps max
         6.4.12 11.3fps max
         6.3.9 19.8fps max

         How on Earth has nobody close to the Firestorm team not noticed this?

         Oh and apparently in order to log this under Jira I need to now need to get permission from someone in SL. Great. So I will log it, I will submit the ticket, I’m just feeling depressed and like nothing will happen if I do. But at least someone will have logged the issue.

         LikeLike

         1. If you contact Willow Wilder or Anastasia Horngold as per this web page, they should get you set-up fairly rapidly. If you need help with filing a bug report – although the firestorm format is slightly different to LL’s, I have a tutorial (for the LL system) here. However, the main thing to do is provide as much info as possible, and if you can include Help > About info from your viewer, so much the better.

            I know it’s easy to feel that nothing will be done (and again, bearing in mind outside influences, some things can be really hard to diagnose even when they appear straightforward) – but the key thing is, if an issue isn’t logged, then no-one is going to look at it; if it gets logged, then at least you know it will end up under someone’s nose.

            LikeLike

            1. Thanks, I’ve submitted a bug, I may see if I can add more tests using Firestorm on Ubuntu so they can at least rule out that it’s a weird bug confined to my PC.

               LikeLike

               1. Alas as I feared it was a waste of my time. Only two people in the team responded. One criticized me for my choice of benchmarking location because apparently locations of that type are slow (and that relates to Firestorm getting slower in the same sim HOW exactly?), as well as making a ton of other unrelated observations. The other asked questions that were answered in the damned bug report.

                  I wasted several hours in total getting benchmarks of Firestorm 6.3.9 vs 6.4.12 and 6.4.13 proving there was a problem, and then more comparing SecondLife 6.3.7 to 6.4.13 to confirm it was unrelated to anything LL had done (surprised me, but EEP apparently has nothing directly to do with the slow down.)

                  And then silence. A ton of benchmarks proving there’s a problem, no change to ticket, no independent tests, nothing, nada, zilch, after a ton of unhelpful and patronizing comments that I struggled to make a polite response to.

                  This is why people don’t report bugs via the “official channels.”

                  LikeLike

      3. The performance issues are real and aren’t limited to Firestorm. It’s connected to LL’s implementation of EEP and has been a recurring theme of complaints since it was released as beta. It’s not uncommon for people to complain of 50+% drops in frame rates. I personally see 20%-50% drops in frame rates between 6.3.9 and 6.4.12/13 depending on the region I’m in on the same hardware. Hardware that is only a single generation old, and has no trouble with 70+ FPS on the average sim without EEP. It reads to me like LL only tested their changes on narrow ranges of hardware and have ignored the community feedback on wider ranges of hardware. This is not an uncommon occurrence in the gaming industry. Many games ship with excellent support for Nvidia OR AMD but if you have the other vendor, your experience is awful and usually remains so. If and when 6.3.9 becomes nonviable as a client, I’m moving to Henri’s Cool VL which has a dual lighting pipeline and I can optionally turn on EEP should I ever become that masochistic.

         Filling FS’s Jira with bug reports for a Linden problem isn’t going to help, and LL isn’t listening to the bug reports they’re getting about EEP’s performance impacts. Workarounds like Henri’s are the only solution.

         LikeLike

         1. Yes, there are issues around performance in general, some of which are related to EEP, others to the manner in which the water plane is rendered (and which are not restricted purely to Firestorm). However, those aside, Firestorm has generally tended to offer a lower FPS for many when compared to other viewers quite independently of these issues.

            As far as the performance drops some have seen WRT Firestorm + EEP, these are not common to everyone – I see around a 5-8% difference between FS 6.3.9 and 6.4.12, for example, which is not that far %age-wise, from the degree of difference I saw between the official viewer with and without EEP. But again, I’m on a mature mid-range system which doesn’t seem to suffer as much as some with more recent hardware appear to experience (which has actually caused me to hesitate around upgrading my PC, as I don’t want to spend ££s and find it’s only giving me a slight poke upwards in performance).

            “Filling FS’s Jira with bug reports for a Linden problem isn’t going to help, and LL isn’t listening to the bug reports they’re getting about EEP’s performance impacts”

            – Actually not entirely accurate. Bugs identified by FS users and seen to be related to the core LL code tend to ralyed to LL as dedicated reports via members of the FS team – hence why certain “FS bugs” share a LL BUG number. Also, LL have actually been addressing EEP bugs – hence why both the love Me Render 4 and 5 viewers from the Lab include EEP fixes. It’s just that LL no longer see EEP as an “independent” rendering project.

            LikeLike

         2. Obviously more testing is needed, but I repeated the same tests I sent to Firestorm’s JIRA (https://jira.firestormviewer.org/browse/FIRE-30842) with the LL client, and LL actually got a little faster after the EEP update. Kokua hasn’t shown any signs of a slow down either (a large number of friends have switched to Kokua because they believe it’s now a little faster than Firestorm) So my guess is this has nothing directly to do with EEP. It may be indirectly connected – for all I know Firestorm’s pre-EEP code that they replaced may have been hand optimized by the Firestorm crew, but it’s not LL’s fault if the Firestorm developers haven’t done the same optimizations for the new EEP versions.

            LikeLike

2. I have a suggestion to FS team: make a kind of “Light version” of FS viewer,focused more in performance for regular users( keeping the complete version named as “Pro version”). I bet most of FS users are not interested in the zillions of features this viewer has…These features and options obviously made this viewer pretty heavy and slow.Let’s be honest, how many people you know are used to the complex tools FS has?Ask to your friends if they don’t agree with me.But of course SL viewer it’s a shame,and a lighter version of FS could be nice ( I hope some people of FS team read my text, because I tried to put it in the FS site but it seems not publishing it).

   LikeLike

   1. There are already multiple “lighter” viewers with better performance available, and each with their own particular aims: Kokua (with the highest cadence of updates allowing to to keep pace with the official viewer & with the approach of pulling-in popular / beneficial changes/additions from FS and others), Catzip, Kirsten’s Viewer, Restrained Love, and Alchemy all sitting in the same camp of v6.x viewers with Firestorm. All have their own pros and cons (Alchemy is particularly lagging behind the official viewer code at the moment, for example), and their own emphasis (Catznip offers a mix of additional capabilities + under-the-hood improvements; Alchemy and Kirsten’s perhaps lean more towards performance / rendering improvements; Restrained Love keeps pretty close to the core official viewer code but with RLV integration).

      And of course, there is a “hybrid” Black Dragon, and for v1.x fans, Cool VL and Singularity, all again with their own emphasis and pros/cons (although Singu again lags in terms of “full” releases), and the SL viewer itself – which cannot be discounted: it offers generally better performance than FS and with the lab’s code contribution policy, actually includes a reasonable range of options.

      Thus, with all of these options available, why should the FS team create a headache for themselves in trying to work out what a “FS lite” viewer should include, what audience it should address (new users? builders? shoppers? photographers?, etc)., then trying to manage two different viewer code sets through update, QA, testing and release cycles whilst also dealing with inevitable demands / complaints from users due to the “lite” version not offering the functionality they feel it should?

      LikeLike

      1. The problem I have with the LL viewer is unacceptable amounts of texture thrashing. I believe it’s because LL has stuck with their small limit of 512 MB of texture memory, despite the fact that many of us have video cards with multiple gigabytes of RAM. Most TPVs have increased the limit.

         LikeLike

         1. Texture VRAM can only be increased where the system / GPU has the memory available. Many SL users are actually on systems with lower-end GPUs (with a total of perhaps only 1 GB of VRAM) or on systems with shared memory for graphics which is capped; as such LL have felt obliged to stick with settings that suit the published minimum specs for accessing SL (which arguably could themselves do with a more realistic overhaul), hence the 512 MB cap.

            That said, there has been discussions of late at various CCUG and TPVD meetings about LL potentially making the amount of VRAM an adjustable setting so as to cater for more up-to-date systems with those multiple GBs of VRAM, so we may at some point see a change.

            LikeLike

            1. It is true that Texture VRAM is (sorta) based upon what the GPU has available with AMD and Nvidia cards, but I’ve noticed, and confirmed by checking the source, that the viewer is hardcoded to use a maximum of half a gig for Intel integrated graphics, despite the latter being expandable to pretty much whatever you want. It may be hard for Firestorm (and LL, because I think this originates in LL’s code) to determine how much RAM is available for Intel GPUs, but realistically they need to find a way to let the user override the 512M default, even if it’s setting an environment variable ensuring it’s only users who know what they’re doing who increase it.

               LikeLike

               1. I tried to go back to the SL viewer after many, many, many years on Firestorm, but still none of the, even most rudimentary, features that I love FS for. You would think. It was FAST, but not faster enough to be worth it (like, really, NO Area Search? No wonder some friends still use ancient 3rd party search tools). But, it only read my Intel integrated graphics and not my Nvidia graphics card with 2GB VRAM, so stuck at unbearable 512 texture memory. Not just sim textures, but many objects wouldn’t rez. So no deal…looking into other viewers so I don’t have to endure an even slower FS, but I have a feeling the “slow” might be a fine tradeoff.

                  I did notice that the SL viewer set my bandwidth at 3,000kb, which seemed very high per the old calculation, so I set FS to that (from 1800, with a warning) and it really helped. I also changed a few Nvidia settings and FS graphics and it’s faster now.

                  LikeLike

3. I know it’s much easier said then done, and probably would need of remade viewer from scratch, but making Firestrom to use all of available CPU cores and not just 2 of them would really boost FPS. cause now none of the viewers utilities a lot of high end CPU and GPU power that your pc got.

   LikeLike

   1. The lack of multi-threading in the viewer code has been the subject of much discussion at assorted discussions with the lab. As you note, it is a lot easier said than done, and would likely require a massive overhaul of the viewer code, something potentially based handled by the Lab were it to be tackled at all.

      LikeLike

      1. And the result of those many discussions with the Lab apparently is that the Lab is satisfied with general performance of their viewer / graphic engine and the quality of life of their subscribers.

         LikeLike

         1. Not entirely accurate. Even without a total overhaul of the viewer, the Lab actually is working a range of performance / rendering improvements. Right now, for example, despite being relatively static from frame to frame the viewer re-draws the entire visible UI alongside of the world scene each and every frame, which is obviously an intensive process. So Euclid Linden is currently working to separate out the UI so it can be re-drawn in its own thread and at a more suitable frequency that every single frame. While it may occasionally have a small impact on UI responsiveness in some instances, it should result is a general improvement in rendering per frame.
            Similarly, LL are actively engaged in overhauling aspects of viewer caching to improvement general performance. Admittedly, the first deployment of this work – the Simple Cache viewer – didn’t go as planned, but this doesn’t mean the work has stopped. Also on the horizon is a shift away from using OpenGL as the rendering API and to something more recent for both Windows and Mac. However, a significant issue here is that a fairly substantial number of SL users (estimated from stats gathered to be around 20-25% of all Windows users) are accessing SL on systems actually incapable of running a more recent API such as Vulkan. like it or not, this is something LL simply cannot ignore, and thus are trying to have to work around.

            So saying they are “satisfied … with the quality of life of their subscribers” doesn’t really reflect the fact that in some respects, they are hamstrung by the choices of their subscribers in terms of client hardware and expectations around it.

            Part of the problem

            LikeLike

            1. Oh that’s some interesting information,Thank you. Was that information available to general public? cause i don’t think I’ve seen it before

               LikeLike

               1. Currently, the best way to follow updates – when available – is to either attend the bi-monthly Content Creation UG meetings, or read the summaries I post in this blog (Under SL > Users Groups & Viewer > User Group Meetings in the menu). The latter refer to all of the Lab’s acknowledged projects as and when they provide info / an update.

                  LikeLike

4. I would like “51” but it crashes for me quite reliably (every time) as it closes. (EXC_BAD_ACCESS (SIGSEGV)) Fixed it finally by uninstalling it. I have to skip about every 4th Mac update.

   LikeLike

   1. Other Mac users have reported a similar experience via channels such as Twitter. I’ve no idea if a bug report has been raised or not. If you could do so, even if a duplicate, it could be helpful.

      LikeLike

      1. I did file a Jira. They must not be doing much Mac beta, I have tried this on three Macs with identical results, but I not been able to hunt down the solution.

         LikeLike

         1. Thanks for filing the bug report – hopefully it will prompt further investigation.

            LikeLike

         2. There can only be as much Mac beta testing as there are Mac beta testers willing to do so. Last Mac preview version was downloaded 24 times – less than the Linux version. Feel free to join the beta testers if you want to help to improve the result.

            LikeLike

            1. Will do — if I can figure out how to join. But your comment explains a lot, beta testing on 24 random Macs is clearly not a formula for success. My Mac uses external video, relatively rare, but unlikely the issue, but one never knows.

               LikeLike

5. I’m chiming in here following Connie’s comments – I agree with her assessment. I tested the 6.4.12 on two different pc with similar outcome. Constant crashes. I had to roll back the upgrade to the older version of 6.3.9 because I kept crashing while in the middle of a Madpea hunt that required me teleporting from sim to sim in rapid successions. And one of my pc is a fairly powerful gaming computer. Firestorm chat-help kept asking me to do correctives that did not solve the problem. However when I opted to do roll back to the previous version – everything fixed itself. In keeping with Connie’s comments – I was hopeful that this new version would have addressed the problem. Since no mention of this issue is in the release notes, I’ll skip this new upgrade and wait for the next installment. As stated, I am usually teleporting in rapid succession doing hunts from sim to sim, this may cause an overload on the fps.

   LikeLike

   1. Just an FYI – there is currently a reported issue with rapid teleporting causing crashes (or disconnects), and also a reported problem for some where teleporting back to a region previously visited can also result in a disconnect. The report on the latter issue is BUG-229871. Either may have exacerbated your problems.

      LikeLike

      1. that bug report appears to be closed although the teleport issue persists.

         LikeLike

         1. Yes, BUG reports are for reference purposes – they do get closed as issues appear to be resolved; however, a closed report does not necessarily indicate that all root causes of a related group of issues have been resolved; there may be additional issues that can cause similar problems. With the likes of Teleport issues, group chat, etc., where the resolution lies with the Lab, the best way to see how core issues are resolved / outstanding is to monitor the SL jira to see if specific issues you’ve encountered is reported there (Firestorm generally manually clone such issues from their Jira to the official jira) and check to see what else has been reported by way of similar issues.

            There’s also my weekly SUG meeting updates, which will report on issues where and when they are raised at those meetings, and so tend to be more up-to-date.

            LikeLike

6. The photo tools and depth of field updates look exciting!
   Unfortunately will have to wait on this version since I can no longer select my joystick. It shows up in the newly formatted dropdown list (Move & View > Movement > Joystick Configuration) but it is impossible to select any joystick other than “none”. Previous version it worked as a checkbox – not as elegant, but it did work. Using Linux (like Ubuntu) – not sure if the same issue would occur in the Windows version.

   LikeLike

   1. No idea. My SpaceNav is detected OK and works as previously – but I am on Windows. Your best course of action is to contact Firestorm support.

      LikeLike

7. The worst thing about the new version is that you reduced the amount of windlight settings available in the viewer. There were a lot of interesting settings that we have lost. Shame!

   LikeLike

   1. There are over 200 EEP settings available for use in the viewer – all viewers in fact – as imported from windlight for Linden Lab by Firestorm’s Whirly Fizzle. You can find them in inventory > Library > Environments and can drag-and-drop them into your Settings folder as you wish, and edit / amend / use them from there.

      Similarly, if you have your own copies of Windlight .XML files, you can import them as EEP settings. For further information on both, see the following parts of my EEP tutorial:

      • EEP Library Assets
      • Importing Windlight Settings as EEP Assets

      LikeLike

Comments are closed.