Beq Janus

Render time is exactly what it says it is. How much that "object" is costing to draw right here, right now. That is the entire point. This is why in the scene optimisation I have the option to imposter by distance. Visible face count (which at present equates one to one with drawcalls on the GPU) is the dominant factor right now. Even on laptops with integrated graphics this has proven so in my tests. I am hoping that changes in the future as drawcall batching will help a bit. The triangle count at the moment has very little impact on FPS performance because of how bad the face count issue is. As I have mentioned many times in this thread, when we get past this hurdle then the wheel will turn and the triangle count will become an issue. This is because triangle count has (surprisingly) little impact on the CPU but is a major problem in the GPU resulting in what is call overdraw. Move to a place where the CPU bottleneck is reduced and the GPU bottleneck becomes important. Low poly, low face count is the direction to go for efficiency but right now poly count is dwarfed by an order of magnitude by face count. In those snapshots we see Belleza at 120 face and Kupra at 18, as a rough estimate, Belleza will take about 5 times as long to render. Any body hair or other object that allows the overall face count to be reduced is going in the right direction. However, unless all the users are aware and use this it is a moot point. ARC calcs are pointless and as discussed at length elsewhere in this thread are shown to make it clear how utterly broken and pointless they are. In the next update I am thinking of having a camera toggle option in the "Your avatar" panel, this will then allow you to see the worst case, which is probably useful. We are literally banned from updating ARC calculations. But as I have stated elsewhere any related calculation becomes out of date as the current one has. changes in the pipeline and our hardware make the current render time the best tool for tuning. As you said the render time is only one metric. It is the one that directly correlates to how long it takes to draw Object X right now, right here, with these settings on this machine. It makes no other claims

Swap is not what you might think. The footnote here was an initial attempt to explain it. You may have come across the term "double buffering" in technical things. It is commonly used when we have a resource that needs to be used by one thread or program, whilst being updated by another. The screen is the classic case of this. when we are drawing the scene we do so to the "back buffer" the buffer not on display. When we are done the buffer is flipped, the back buffer now on show and the old buffer now ready for us to overwrite. "Swap" is the time spent waiting for the drivers to switch buffers. This takes longer the more "stuff" that is queued there. It is not as cut and dried as to be "too many textures" or "too many triangles" though those do have an impact. Swap will also reflect wait time in the driver. If you are using Vsync to control your frame rate then the driver will have to wait for the next sync before the swap can occur and the driver literally blocks until that is done. It is relatively unusual on current viewers (aside from the vsync special case) to see a machine running SL that is limited by swap, though it is certainly possible, your empty region being such a situation the CPU has little to do and is able to quite happily able to keep pace with your GPU and you are effectively waiting for it (maybe you have vsync enabled too). If you were to throw a couple of avatars into the mix, then the CPU gets bogged down and the amount of "swap time" that is really "wait time" will reduced. At the moment, we are typically CPU bound in any scene of moderate complexity; when we see the performance tuning come to FS we will likely see an increase in the Swap numbers and the whirring of GPU fans. Fingers crossed.

Based on that image, your body alone is 60% of your avatar's render time. So any changes you are making elsewhere are only tweaking the remaining 40% even if you removed you entire head, you'd only save a further 14% so with that context there's not a lot you can do. The earrings and heels seem perhaps the main candidates. Best hope at the moment is wait and hope that Maitreya release a low cut option, then you have options where the old body with older outfits and the new one with newer outfits that have alpha layers (or old ones that don't need alpha) that's the ideal world. Also fingers crossed that the next round of viewer updates will help us all.

In theory, it removes a headache for them but it really depends on their workflow as to how viable it is. When you make the bodies, they are modelled then sliced, but of course we're talking about existing assets so there is effort in recombining, and unless their workflow happens to involve starting from the uncut and applying the cuts with each tweak/update then they'd need to go the extra step and combine. I suspect that the amount of work that'd involve varies from creator to creator. The cuts are a real pain in other ways too, we all know about the issues that mesh has at high altitudes, jumping through hoops to ensure that the distortion is minimised etc. It is definitely possible where there is the will, Siddean Munro of SLink released the Redux models which were compatible with the pre-BOM sliced versions. At present, I am stuck because my beloved SLink Redux has dwindling creator support and much as I admire the work and the efficiency of the Kupra bodies, the aesthetic is not one that works for me. I'd love to see an efficient petite body with good clothing support. I'm also hoping that the future performance viewer updates will make it less of an issue in general.

It is included in part because that is what the Lab were propsing to show, and the very reason I developed this feature was to illustrate quite clearly how fundementally misleading those numbers now are. People have been saying "yes we know complexity is wrong but it is better than nothing" for a number of years now, and frankly, that is a lot of BS and I am calling out that BS with hard data. The complexity number gets used by region owner to shame/ban people based on spurious information. The promotion of it as a valid stat is detrimental. I know of a number of people who have looked at their ARC, freaked out and removed their old unrigged hair and replaed it with a similar rigged mesh hair. The ARC plummets because the rules by which it is calculated are flawed, however the render cost actually gets worse. As a TPV, we are expressly forbidden from changing the ARC formula. One viewer chose to go against that rule but if FS were to do the same the Lab would fall on us like a tonne of bricks. You can see, quite clearly on this display, that the ARC and the render time do not correlate. My goggles are apparently the worst part of my outfit. In reality, they are a small contributor, certainly not eleven times worse than my hair, which by comparison, allegedly, has a very low complexity. If I were worried about my complexity in order to get into an event, or just to be a good citizen, I would likely remove my goggles, when in fact the better change to make in this case would be my earrings. Using myself as an example is not always a good idea, my render time is low as I wear simple things. However, If I wear a different body and hair, you will see how the ARC numbers have very little correlation to reality The hair that I added, a 2017 Red Mint hair, is one of my all time favourites; and "wow ONLY 2K complexity" but wait... uh oh..it is a disaster for my render time. The legacy body likewise shows as 8 complexity less than that of my collar, but nope, it is by far the worst item I am wearing in rendering terms. (notice my collar is invisible, no render cost hardly, yet complexity 9(k) ). I don't like to keep knocking the body makers, for while they have chosen to retain these cuts it is in no small part "our fault" because "we" as customers (and "we" as clothing creators) were dismissive of BOM and alpha layers initially. SLink went down the right path performance-wise, but lost commercial ground in part because of this. What I'd love to see is for the big body makers to provide a low cut version of their bodies. Alpha layers are common place now because of Slink and Inithium and of course people could still opt to wear their older bodies with older outfits. I live in hope. Sadly I think red mint has closed 😞 so I can't hope for a performance-tuned version of my favourite style. There is a place for an ARC-like number, and the Lab have been talking this (as an aspect of "project ARCTan" for about four years now) no real progress has been made. One reason why is that it is a hard, maybe impossible nut to crack. The reasons that the existing number is wrong will apply equally to most attempts to update it to another arbitrary number, which is primarily because we all have different hardware and that hardware evolves over time. What is slow for you might not be slow for me, or vice versa, and what is slow for us today may not be slow for us next time we buy a new PC/GPU. Any new number needs to somehow take this problem into account. I tried various optoins and in the end decided that the best solution was direct measurement. So why am I showing the old number? To highlight how badly misleading it really is in 2022.

That's easy to answer. It is a proper BOM implementation with very limited cuts in it. The bodies with Alpha HUDs are sliced into little mesh pieces and every one of these has a large overhead to draw it making those bodies far slower and less efficient. Contrary to what many believe, at the present time the number of triangles makes very little difference because the alpha cuts are so very bad that it makes the triangle overhead pale into insignificance. For SLink, the hands are 1 extra mesh (possibly two but I think 1 as left and right are the same object). The feet too, because only one pose is visible at any time, you only pay for that single mesh. In addition, Slink bodies have a butt panel and a boobs panel, that allows you to wear the petite chest and the alternate bums. Finally they have the left arm as a separate mesh to allow for independent tattoos. This means that in total, a SLink body has a tiny fraction of the meshes that the cut bodies have; as a result when the viewer has to draw a slink body it has to draw around 30 meshes. By contrast, when drawing a Lara or Legacy body it has to draw a lot more, about 8x and 11x more respectively. PS - This is why Avatar Complexity/ARC or whatever name you give that fixed number is completely irrelevant as a measure. It does not take into account any of the actual complexity of rendering on a modern CPU/GPU.

it was indeed. I had never dug into server costs like that, though you and @arton Rotaruwere clearly aware of it. 🙂

I visited Gweha. After some puzzlement I found the answer and learned something new. win/win. Her linkset is made up of a number of parts a floor, a ring of "hooks" that curves overhead and then a series of particle target prims that are needed for some chains. The final ingredient is a very script heavy box in which she has all her normal animations etc. that go into her furniture. The script box has a server weight of 1.0 the other parts are all 0.5 however, when linked together all the individual links (prims or mesh) act as if they have a server weight of 1.0 each Thus when she links all the parts together before the box. we have 9*0.5, total server cost of 4.5, and that being lower than the other costs the LI is 7 because of the download weight. So far so good, everything as expected. Now we link the green box. we expect it to add 1 as the server weight is shown as 1.0 The LI magically becomes 10 as she stated, which suspiciously, matches the number of links in the linkset. hmmm I tested it with a few prims and sure enough , linking the box of scripts forces the server cost to be set to the number off links in the linkset. I had thought that the server cost was dark art and we didn't have any good information on it, but google proved me wrong and I found this. https://wiki.secondlife.com/wiki/Mesh/Mesh_Server_Weight Specifically the note in yellow and that completely explains the behaviour. So if you have more than two times the number of scripts to the number of links in the linkset, then you'll hit the lower cap "num_prims". In Gweh'a case 0.5*10 + 0.25 * LOTS > 10 so the server cost gets set to 10. The confusion arises because we have no indication of "potential server cost" in the "more info" display. when that box of scripts was standalone the content were still <big number> LI worth but it was capped at 1, by linking it the cap lifts to the size of the linkset. I literally had no idea that was a thing. Thank you @gweha and hopefully we both learned. @Monty Linden we have a number of anti-builder mines scattered around the place. This was a new one on me (and no doubt everyone else will be going duh Beq, 'course it does 🙂 ) "More info" typically warns you of the true underlying costs that the LI algorithm hides, It would be good to be able to reflect the true "potential" server cost in a way that helps builders navigate through the minefields.

For those watching this thread. There appears to be a new workaround that might help in the interim This was contributed by D0nthate, via the Mac Monterey voice Jira If you try this and it works let me know here and I can make this the default workaround that our support teams will give.

aha! yes, that will hapopen if you have fps limited. I'm going to explore that a little more, but effectively at the moment (as the top right text (if you can read between the Beq derp layout) states, if you have an fps liimit or are tabbed out looking at other things, then I suspend collection. this is because I can't really rely on frame time that is mostly made up of deliberate sleeps. That said, the reality is the attachments and avatars still take the same time so I should probably be a little more accomodating and let those through and just keep the summary stats blanked/greyed or something.

Mostly cos silly Beq had a non-default UI scaling when she laid it out and realised just too late and the builds were already on their way to QA. Sorry. In your screen it looks more cramped than ever which is likely a font thing on your setup. That will hopefully get fixed if I can make the UI behave and support resizing As for the overhead of capturing that info, it is pretty low (lower than all the fast timers that have always been in the viewer) and most importantly almost all of the work is done off of the main rendering thread.

The numbers are showing you the actual impact on your viewer FPS, it is not intended first and foremost as a comparison tool. Even with HUDs off your avatar will take more time there is just more overhead in the viewer when dealing with your avatar than the rest. As for keeping the HUDs on, as noted by other alt-shift-H is a great option. The other thing I use a lot is the favourite wearables. All the HUDs I use semi-frequently, got added to the favourites and when I need them they are just two clicks away. As mentioned elsewhere, I worked on making it resizable but the UI would not play nice. It'll be revisited, though how I will approach that I do no know yet. You can currently get to it from Wordl menu, and Advanced->performance tools. There is a tool bar button which yo can add to any of the tool bars. All shadows? Can you reproduce that if so please throw me a Jira? I think what you probably saw avatar shadows being removed, that is expected. The environment settings do not autotune shadows at all at present because that triggers are far more disruptive change in the viewer shaders, whereas the avatar shadow removal is less invasive. The problem I struggled with is that the range of numbers is very large. On some systems a single avatar can take a many milliseconds, on another a few hundred microseconds. Using a units suffix like K might help. I am certainly open to ideas.

You may have an RLV restriction that is preventing you from hiding HUDs. That's the only reason I know of for the hide HUDs to be unavailable

Nothing has changed in that regard. Set your settings, whether that is through general prefs / phototools or whatever. and save a preset. You can save and load presets form the perf floater so, you are at liberty to load "Photp settings OMG Slow" preset, take your shots then either click autotune or load "My normal settings" and move around again.

Are all the items mesh? If one or more is a prim/sculpt then linking it into a linkset, may cause the legacy prim cap to be lifted if any of the other items in thelinkset have materials or alpha mask enabled.

Niran, is welcome to borrow and adapt my code (or turn his nose up at it 🙂 ) and I am expecting to contribute this feature back to the Lab in some form that is mutually acceptable. So it will in due course flow downstream in any case. Niran has been gnashing his teeth at bad assets for a long time, BD has its own twist on ARC that he feels better matches reality, for exactly that reason. We are pulling in the same direction. The updates that are coming from the Lab are pretty impressive. and they may arrive sooner rather than later. Though as we did with EEP, we'll release when we think it is stable enough as large scale reworking of the render pipeline like this will have a number of sharp edges I am sure. The water issues have been addressed, big win for everyone. But what surprised me and makes me really excited is that they have implemented "batching for rigged mesh" "I know all you heard then was blah blah blah...but what this means to you and me is that even those horrible laggy bodies that I am dissing will be faster than today. In my tests of the current "work in progress" the multisegment bodies remain slower than the non segmented bodies, BUT everything is significantly faster. There is a gotcha of course. For those who managed to read my technical blogs on the mesh body problem, there was a note that whilst drawcalls are the "probleme du jour", if we can move the bottleneck away from the CPU and over to the GPU then suddenly mesh density (the number of triangles) becomes the new problem due largely to a thing called overdraw. So we are moving one problem into another, but frankly given where we are today, that will be a far nicer problem to have (though even harder to measure). So to put it mildly, I am really excited about the next few releases. I don't care what viewer you run, so long as it is maintained and up to date, it should be getting a decent boost.

Perfect example. They blew your complexity (ARC) high. But did they actually have a signifcant cost? It depends, if they were prim jewelery then compared to the multipart mesh hair or multipart mesh body they would be nothing. It would be an interesting test case.

Possibly true, I can't answer that, but if you are certain that's the problem I can relay it. The problem of code signing generally is not the cost but the constraints around who can and cannot do the builds etc. we wasted heaps of time and money of codesigning releases in years gone by on the promise that it would stop the AV companies flagging every single new release as "omg paranoid this is new it might be nasty", it never worked, and required us to jump through burning hoops backwards carrying a goat playing the ukulele. I don't know the Mac world at all being apple-phobic I doubt it is much different, but it's probably an alpaca and a lute. Apologies to Mac Monterey users because sadly, the release has gone out without a concrete fix. We do however have a workaround that appears to have been succesful for most Monterey users during our test phase. This can be found on the voice wiki page https://wiki.firestormviewer.org/fs_voice#tab-mac If you happen to know a Mac developer who can build the viewer (typically that's the first hurdle) and would like to help us improve our Mac support please put them in touch.

I think only one does that. and it is not FS Not entirely true, people get jelly dolled and ARC shamed for incorrect reasons, making them make poor decisions on what they should and should not wear/buy. We saw this immediately when the LL perf floater appeared and people were swapping out prim hair for mesh hair cos the complexity was shown to them. A decision that in many cases would have made their avatar slower to render. Yep, I've said a number of times in a number of places now, these numbers are personal to you, they cannot be compared machine to machine, that is not their intention. the question is "why is my FPS currently X", this tries to give you the answer in a way that can be deconstructed into actions. The render time slider is akin to the max complexity slider, but now instead of making you suffer ugly grey blobs on your screen for their vanity, we try hard to reduce their impact without resorting to grey blobs. My personal favourite though is using the attachment view to measure how good or bad a new hairstyle/head/body is. Self-awareness is a good thing. One of the good things that has come out of this process is that my initial research into how damning the drawcall overhead of mesh bodies really is did highlight the issue to the Lindens and in the performance viewer we have seen a concerted effort to reduce this through drawcall batching of rigged mesh. the differences are still there, but the magnitude is dramatically reduced and all of SL will win once those viewer changes hit the street.

Can we trust the numbers. That depends on what you mean. The numbers are the amount of time (averaged over the last few frames to stop it being super jittery) that that avatar took to render. It is an accurate reflection of the CPU cost on your machine. So in that sense it is a far more reliable stat than the utter nonsense of ARC, However, do not take my word for it, you have the tools now to do a little home science experiment. go to a busy place and look at this screen, you'll find some people are super high cost and others are not. if you derender a high cost individual then that amount of time will be removed from the total frame time and your FPS will increase by the same proportion. If you lookdown the list you'll probably find a High ARC person with a low render time (now this may simply be that they are out of view, but it is not necessarily so) ideally find a high ARC, low render time person in full view. derender them. Did your FPS zoom up in line with the ARC or inch up as suggested by render time? A lot of this hinges around the high impact of alpha cut mesh bodies. My blogs such as https://beqsother.blogspot.com/2021/12/upgraders-of-lost-arc.html show the issue, with some of the earlier ones going a lot deeper into the technical issues. It is indeed. I tried to make it resize nicely and the UI system bit my arse and puked up all over my homework. I tried, honest. I did not actually do the ARC truncation. This floater revived the short-lived performance floater that LL released last June. It was the fact it centred on the misinformation of ARC that riled me up enough to do this. That floater truncated the numbers. as for usecs..yeah I pondered long and hard about this. Ultimately I cannot convert it to a more practical unit that makes it sensible. In disclosing the actual numbers I am hopefully giving those who are interested a new tool. This changes nothing in terms of "shaming", it at least stops pointing the finger at the wrong people like ARC does. As Wulfie says, it doesn;t really matter what we do, someone will use it for reasons other than self improvement. I had that, however, due to the way that SL works it is not possible to retrieve the another avatars attachments by name without selecting them (this is how the "inspect" works) doing this would be highly disruptive and counter to what we are trying to do so I had a choice of leaving the attachments as UUIDs and thus pretty meaningless or simply removing them and focussing on our own. I chose the latter. You can use it to work out relative performance, but do make sure that you have the avatar in view, it is measuring the direct rendering cost, so be careful about that. Indeed so. As noted above, you can test for yourself, but render time is quite literally "how long did it cost my CPU to draw this bundle of meshes". ARC is uhm someone waving a finger in the air and estimating based on metrics that are 15 years out of date.

The Collada files that you have provided do not contain matching sets of models. In particular, it appears that 'Model Cirlcle.02' and 'Model Circle.01' are present in the Medium, and Low LOD collada files but have not been exported in the High LOD file. Every model in a lower LOD must have a corresponding High LOD (parent), hence the error you are seeing.

It has indeed been a lot longer than we would have normally liked since the last release, many reasons contribute to this, many of which are the perils of managing a large complex software product with a small team of volunteers. RL happens, things don't go to plan, an upstream release or update, may break some critical dependency or feature and we have to scurry to fix them. Firestorm is a world of moving parts and co-mingled personal time commitments that uncannily conspire to thwart our plans. Thank you for your patience. However, as those in our QA team and the early adopters in our preview group know there is a new update imminent (barring any last minute shockers being uncovered by the aforementioned guinea pigs). The update will bring us broadly up to the current release status of LL releases, cutting off just before the most recent Maintenance release which arrived in the midst of our QA program and introduced enough new bugs that it would have been irresponsible to try to slip that update in at the last minute. That means all the preceding bugfixes and updates, and features such as the 360 panoramic photos capability will be include, along with our own fixes and enhancements. For my part, the "imminent" update will also introduce my experimental view to help people identify the major influences form the current scene over their FPS, and in particular with regard to avatars (and thus most useful in crowds) will offer additional options such as conditionally disabling shadows for very costly avatars. This is coupled with an Auto-tune capability that I hope people will find useful but, given that it makes choices for you, changing certain settings towards a singular aim of increasing FPS that you may not always agree with, I fully expect to cause some people consternation (it is entirely optional to use it of course). in getting it into your hands now I hope to see what people love and hate about it and so improve it for the future. All I will ask is try it, be sensible about what you ask it to do, and let us know what works or does not work for you and perhaps how you'd like to see the feature evolve. My recent blog posts details both the motivation and objectives of the feature. You can get an overview of the feature in "Upgraders of the lost ARC" with the preceding post a more pointed and personal account of why some avatars and more specifically mesh bodies are poisonous to current viewers. The performance viewer that LL are still hammering away at (and @Odaks referred to) is a significant (positive) change to the viewer performance but is not ready for release just yet. . When it does arrive it would be safe to anticipate that changes of this magnitude across the whole of the graphical infrastructure of the viewer will have rough edges and as such we will take our time to assess, evaluate and address things before rushing into a further update. We are very keen however to get the benefits that are coming from the hard work that the lab have put in to the optimisations, into the hands of our users, so I think we're all hoping for a much shorter wait for the next release than there has been for this one.

As @Henri Beauchampnotes it's not really a crash as the viewer is perfectly ready to do its part of the bargain, but the universe has flipped it the bird. It is a flaw in the wider system though. What typically happens is that the handover protocol fails. The protocol is overly optimistic, the region you leave forgets about you before the one you are going to is fully onboard with accepting you and thus you get orphaned. Ever squeezed your car into a tight parking space only to find that when you want to leave you can't work out how the hell you ever managed to get in? That's the viewer in mid TP fail.

Mr Carlsons Lab? Great channel.

Most TPVs allow you additional control (arguably to the point where you can break yourself if you try hard enough.) If you want that on the Lab's viewer then the first place to start is by raising a JIRA for a new feature request, they can then consider it and perhaps ask one of us TPVs to contribute their code. I expect there are any number of people who have requested this in the past so take a look for existing tickets and add your own comments to one of them. Ultimately though, the configuration is a hint and making it higher won't force thing to change, it is the OpenGL drivers that will dictate how much VRAM you get to use. Applications do not allocate resources on the card directly, but instead grab buffers which the drivers decide where to place (VRAM or system RAM), as such you will frequently find that at least as much system RAM is used to mirror the VRAM pools.