flexi-lag?

I'm looking for someone to explain to me what causes the lag in flexible objects. What I'm referreing to here is that there is apparently a "framerate" for flexis. I can be some places and my hair and skirts move fluidly. Other places, I appear to get about 1 update per second.

I can only assume that it is other flexi's doing this. Is this correct or do other things contribute such as animated textures, etc? I want to be able to dance again in my house without my skirt doing funky 1fps motions.

Your biggest enemy. Although this post should be in Resident Answers, I will give you my experience.

Just before posting this, I went to an empty sim. Without wearing one of my flexi hairpieces, I was getting 41.2 FPS. Donning my 185 prim flexi hair, the FPS dropped immeadiately to 7.2 FPS.

Take it off, volia, 43 FPS.

Try it. The hair that I normally wear is 80 prims which about 6 are flexi. It makes life much easier for me.

The sooner ppl realize what is causing most of their lag, the better.

Note:The lag is not just experienced by the person wearing the ungodly amount of prim hair, but also, anyone that has to look at it. Each client has to keep updating your hair movement and render it. 185 prim hair is low compared to some of the styles out there. I have seen much more than that.

Thanks Yrekk, but that is not exactly what I was referring to. I have an 8800GTX video card. I get about 45FPS in my house which, admittedly, is a terribly complicated environment. But even as I'm getting 45fps, the flexi-things look they are are updating at about 1 update per second... maybe 2 or 3.

I am not seeing a significant graphics frame-rate problem, it appears to be flexi/physics update rate problem

Yeah, I've noticed that the more flexis there are in one spot, the slower they update. Its probably a physics limitation. The fact that people wear 100+prim flexi hair doesn't help things.

It dynamically delegates and splits up flex processing time between all the flexible objects around you, assumably based on proximity or something.

does flex cause lag? ...................I always believed it have. But i had this CAUGH CAUGH expert explain that it doesnt. Now does flex cause lag?

Also don`t forget. Your connection if it runs in to problems proxys etc. Will also cause problems, no matter what graphic card you might have. I have a 7900 gtx extreme 675 watt. Ans at my location i can run any where between 66 fps to 100 fps. Now thats basic. Sim based well all depends on the the agents within the sim ( 40 to 45 fps most ).



Usagi

your "expert" was right... and wrong, from my understanding flexis (or rather their movement) are rendered by the client(thats you) and not the server (that's SL).... so it's not SL choking in this instance.... it's your video card...

more flexi's = more work for vid card

and I don't think there is any way to throttle flexi proccessing, like with particles... it's all pooled together, which means your framerate takes a dive usually..

but then I've NEVER had a framerate above 17... and that was in an empty sim, 500m up with only me, ruthed, and a single cube I was sitting on.... :tares at you all with envy and loathing::

Something doesn't seem quite right about this void. The reason I say that is the disparity between my framerate and my flexi update rate. I can be clocking along, as I said, at a nice 45fps and watching the flexi's updating about maybe 1 update pers second. If my video card were responsible for this, it is *almost* certain that my framerates as a whole would be suffering more.

In addition, I don't think it's my cpu that's causing my slow flexi update rate. Again, the 2 cores on my CPU will be showing something like 25% utilization each. Granted, utilization graphs are averages and might be hiding some significant details, but still, 1 or 2 updates per second is pretty bad.

Wow, and here I thought this was going tobe a simple question that some experienced builder would be able to answer off the top of his/her head.

**** EDIT ****
OK, maybe over the weekend I'm going to go do a test and remove all the flexi-plants from my property. Hands down, it is the flora on my property that has the most flexi's in it and has the least value (in other words, I care about my skirt flexing.. I don't care whether the leaves on my palm trees sway in the wind).

Yeah Brandi I was hoping the same thing re the simple question, but it seems the debate on whether flexi prims or mega-primmy hair for that matter cause lag will continue.
My 2c : I spend a fair bit of time wearing flexi gowns in laggy ballrooms. I noticed that when trying that on my older system with rubbish video card but plenty of gigs and such the lag would be horrendous. Replecating the exact same situation on a newer system with similar gigs, bandwith etc. _but_ a good video card, I experienced nowhere near the amount of lag and my gown was better behaved as well.
This leads me to say that in _my_ experience (note : my experience only) the lag is mostly caused by the video card and thus client side.
YMMV

There is no question that mega-primmy hair causes at least three types of performance issues. Let's not single out hair though. It is really just a function of prims. Each base prim must be downloaded to your computer. If you have 500 prim hair that's a fair bit of "network lag" right htere. Let's not even discuss my 2000 prim silks. Next, all those prims must be tracked by the servers. So you're introducing load on the server end which adversely impacts overall sim performance. Consider an entire SIM is capped at 15,000 prims, but if I'm in full sim-busting mode, I can easily be wearing 3500 prims just on my one single avatar. Finally, all of those prims get turned into polygons to be rendered by yoru video subsystem. There is no question that every single prim costs you and spending 500 on hair (especially if say, 40 other people have done the same), is eating into a budget that a lower-end video card just cannot afford.

There was just a discussion thread (I think in this forum) where the poster indicated that a sculpty is ~1900 polys even if it's just a simple sphere. Even a basic cube was something like 100 polys. It'd be interesting to find out how a flexi gets turned into polys.

So, there is absolutely no question that prims cause performance issues and spending them unwisely will degrade other people's experience. But that's not really what I'm trying to ask. I'm trying to get at the disparity between the overall performance in my house (fine), and the performance of the flexi's themselves (not fine).

you're right they don't seem to be directly tied, I've been told this is because most newer vid cards have a seperate chip for proccessing physics... but that depending on the card, it can kill overall performance (like my poor cut-rate card) higer end cards.... the physics might lag while the rendering doesn't.... so I'm told... It could just be a problem of metabolism ... the hamster in my pc runs faster than the gerbil, but tires more quickly if I don't feed it jolt cola.....

I say this I don`t lag. But i do see reductions in fps rates with high flex objects in a sim. So I say it does cause sim lag not system lag.

If i was a mod and i have been I never muted anyone . But since i am not a Mod why do i have to be supjected for a person that i can`t you worth ****. I would like to know why she can`t be muted.

Lag is such an overly used and un-defining term.

When you say that flexi's lag it could be taken any number of ways and so in some responses you'll get the "flexi's don't cause lag" where the OP is talking about internet communications, since a flexi's parameters are approximately equal to any other prims in terms of data bandwidth.

If however someone takes lag as being your framerate drop then in that case they could be taking it in terms of the increased number of surfaces your graphics card must render for a level 3 softness flexi over a non-flexi prim.

What seems to be described above, where the graphics card is handling the scene nicely at 45fps, might be the processing time involved in the flexible path simulation of multiple flexi's. If you think of a flexi prim as being a flexible line (from the prims -z to +z surface) with multiple parameters (i.e. softness which affects the number of intermediate points on that line, tension & stiffness which affect it's dynamic movements) and reacting to a change in position/rotation or a changing parameter (i.e. whenever the wind value changes) then your computer (as it is the one which deals with this, not the server/sim) has to calculate the new path/line. Although this may be a trivial task for the computer to do for one flexi, combining multiple into a scene together with all the other processing your computer seems to do when running second life we can see where this throttling comes into play and why the flexi's in the scene update only once a second as opposed to the 45fps framerate.

[Rambling mode off]
Hmm, wonder if any of that makes any sense. *hits the submit reply button anyway*

heard that for years............

I'm aware of what you're saying and opt for lower prim items everytime.
Sorry if I was unclear, but in my example I meant to stress a notable improvement in the flexi's performance, not the sim performance.

Just to set the record straight... newer vid cards do not have physics processing on them. There are separate physics processing cards (which second life doesn't utilize). There is also talk of leveraging the horsepower of a modern GPU to offload some of the physics processing, but there is no defined API to do that yet, it's just talk. And, even if it wasn't just talk, odds of SL using it approach zero.

Just to set the record straight... newer vid cards do not have physics processing on them. There are separate physics processing cards (which second life doesn't utilize). There is also talk of leveraging the horsepower of a modern GPU to offload some of the physics processing, but there is no defined API to do that yet, it's just talk. And, even if it wasn't just talk, odds of SL using it approach zero.

For referrence: http://www.extremetech.com/article2/0,1697,1943832,00.asp

Again, this time with references...

Flexible objects already have an LOD system built into them, so things which are further away update a lot less frequently, and are given much less priority than nearer flexible objects.
If you enable the Debug Console in the Debug menu, it currently spams the various bins ("0: " being the farthest bin and "9: " being the nearest avatar attachments) and the number of flexible objects rebuilt per frame, how many total in the bin, and the time per frame in seconds spent on that bin. So you can try to figure out what the algorithm *actually* does, as opposed to what you think it does. (Yedwab Linden, 4/15/06)

Also, if you use something like Tsearch to overwrite the flexi parameters in the viewer, you can prove to yourself that flexi's are processed client-side by setting the tension to 1000.0 and suchlike.

Well Day.. I think I'll take that as gospel. Since I find it hard to believe that SL is actually using the latest hardware assist physics processing and therefore leaning on my vid card (not even sure that this feature is out in the Nvidia drivers yet), and given that my cores aren't even remotely utilized, I'll just have to chalk this up to "CPU bound through some random wild inefficiency in the client code".

I wasn't able to see any of the bin information in the debug console, but that quote sounds pretty definitive. Now I just wish I knew what the limiting factor was. I also wish I didn't buy those copy/mod palm trees with flexi-leaves.

Brandi, I looked at the client code. You're right that flexi positions aren't recalculated every frame. Each flexi is recalculated every N frames, where N is adjusted at run-time according to an approximation of what percentage of the screen that flexi takes up.

The good news for you is that this rate is also adjusted by a factor set in the preferences. On the Graphics Detail tab, adjust the slider that is (mis-)named "Flexible Mesh Detail". If I'm reading the code right, that should adjust how often you see flexis updated. Mind you, I haven't actually tried this for myself.

that's what I get for listening to talk ... on the flip side, ATI's new crossfire tech seems to do exactly what's described, but I can't wade through the technical jargon enought to tell if the card decides what physics to process out, or if there is a related api that games could access.... either way, isn't your cpu biting the physics at it's own rate, and the 3d card rendering at it's own rate? (ok so thinking that the cpu is choking before the graphics card is a pretty silly assumption in general,)

also seeing that mesh detail code seems tied to update rate (thanks Omei) you can see where my confusion came in... sry if I spread an confusion

WOW! Thank you Omei. The final missing piece of the puzzle. So, to explain my situation, it must be somethign like this...

a) There is an algorithm in tlient which determines how mcuh time will be spent processing flexis.

b) That algorithm uses several inputs including the framerate and the "flexible mesh detail" slider.

c) Like all algorithms, it is not perfect and results in wasted CPU on my computer (hence my CPU not being pegged).

d) The more flexis you have, the less each one is going to get out of the available processing time. Ergo, reduce flexis in your draw radius to make improve the updaet frequency.

So, I am now going through my property and studiously removing flexis. I need to rebuild the palm trees I just bought because i like the dense foliage, but the leaves are all flexi. At least for me, it is much more important that my skirt, hair, and silks move fluidly than my palm fronds sway subtly in the wind.

Actually, I'm not sure this is the going to be the case for you. (But for visitors to your property whose rate is limited by their CPU, reducing flexies will help their frame rate.) The algorithm for determining how many frames to generate before re-calculating a particular flexi's geometry does not seem to be affected by the presence or absence of other flexis.

Note that I am looking at the source code for release 1.18.3. If you haven't updated to that yet, I suggest you do. There is evidence in the code that at some time in the past, flexi recalculation did depend on how many other flexis were in view. I don't know whether the change is a recent one or not.