non prim based limit

okay this one is going to get me shot down but according to my little researches not all the prims are erqual in client resource drain, to reflect this here is what i would suggest

basically each pri "weight" more or less depending of it's type:

cube = 1
prism= 1
cylinder = 3
ring = 6
tube = 7
sphere = 11
torus = 24

so putting down 24 cubes would cost as much as putting down one torus, it is just an example more fune tuning would be needed, but it would learn passively to builders that some prims drain more resources than others

Well, I guess I didn't wait long did I. You're right, different types of prims do have different levels of drain on a client and Toruses are the biggest hogs and it would seem to make sense to base an allocation on actual system and client resources used, however there are a couple of difficulties with using that as an allocation structure.

1. The actual resource drain on an area in terms of bandwith is more heavily determined by number of scripts running, whether or not there are active physical objects, size and complexity of textures in an area, presence of particles, presence of sounds, and whether or not there's an avatar standing there trying to run a series of maxed out animations with million prim hair, high-res custom body texturing, bling on every attachment point, and sound effects going (you know who you are). All in all, the greatest drain on the resources of that list would be the avatar, you could theoretically create a plot limit for number of avatars in an area, but that would cause difficulty for the people that hold events with large number of ppl (tringo parlors, boxing arenas, etc).

2. Preferencing different types of prims would also limit creativity and encourage even more 10mX10m box construction than we have now.

3. The closest solution that I can think of that would accuratly reflect the amount of resources a plot is capable of holding would be to put a maximum memory size, however then users have to be continuously checking to see how much memory their scripts, textures, and such are taking on the server, and even that's flawed since a 2K script can create much more or much less resource drain than a 500K texture.

well the idea IS to privilegize the use of low polygon prims, sure it might do bad, but the overall experience will be waay better and this would mainly improve the client fps, who know maybe we might get something acceptable in the game industry?

Had to comment about the concept that "scripts are what lag a sim".


From what I understand, Linden Lab has allocated a maximum time slot to scripts. So no matter whether you have 5 scripts or 5000 scripts, that script maximum is supposed to remain the same and is not supposed to increase (or were we misinformed?).

There are so many things that lag SL: moving prims (rotators), toruses, moving textures (lag client side), number of prims, size of prims etc etc etc.

What lags far worse than anything are avatars themselves. Since a 512m plot is limited to 117 prims but constantly moving avatars have no such limitations, it's not anything unusual to see an av with 200-400 prims attached lagging a sim significantly.

A person can spend all day long trying to prim-cut, texture-cut, script-cut, and have all that effort totally negated by two or three heavily-laden avatars. Any more, we can't get more than 10 avs on a sim without it lagging considerably.

I believe the major contributor to lag is not client-side or user content, but SL programming, bad data structure, bandwidth problems and far more users than their system is capable of handling under the current platform.

I've also come to realize that nothing I do is going to stop that common experience of everything working just fine, no problems, and suddenly the whole sim dropping to Time Dilation of .3 and FPS of 0 and everyone lagging to a standstill. People try to move and wind up flying off uncontrollably into limbo, then either crashing or suddenly being snapped back to sim edge. That happens every day, day after day, and there is nothing the users can do to correct that problem. Until LL corrects it, severe lag is going to remain a problem. And once they do manage to correct it (IF they do), then it will be much more difficult for customers to cause severe lag. It will be unlikely to result from standard building or scripting.

On ElvenGlen we have 13,500 prims of all types. We have over 3,000 scripts. There are times when we run just peachy, no problems, no lag, no difficulties-- and ElvenGlen is a very content-rich sim. Right next to it we have ElvenMyst, with half the prims and far less scripts. It too operates with no difficulties at times. this indicates that there is a wide variety of sim situations that can run just fine, with no discernable lag. But both sims regularly hit that "molasses" point where no one can move. They are on different servers. So that tells me there is something deep-core that is to blame, not user content. If it were user content, neither sim would ever run well. The fact that they are capable of running well indicates the problem is on LL's end, not ours. That's been pointed out before, numerous times, especially in a post called "The Lag Monster Myths", which was about as goofy a troll war and denial of simple facts as I've seen on these forums. Bottom line fact: SECOND LIFE LAGS... and that lag is getting worse all the time. That's why users now default to 96m view instead of 128m as they used to. That's why they're culling prims and we can see .5m prims only at 20m or less instead of 30m as we once did. SL has gone from 25,000 users to 200,000+ in the past year. I believe LL is cutting corners to compensate.

So I've for the most part stopped fighting the lag game. I pay my bills for 15,000 prims and however I want to set up my sim. Beyond that, it falls to Linden Lab to deliver what the contract specifies. If they don't, well, eventually there will be competitors.

Empirical observations indicate otherwise. I have a script that is dependent on repeated timely computations. It performs fantastic under low lag and horrid under extreme lag.

can you tell me in what is it related to the "price" of each prim being in proportion with the client side polygon drain

And along comes the virtual server and makes the whole lag point moot as thus:
A computer runs a stripped down server, which runs an OS that runs 6 servers that runs the sims. Virtual Servers.
Now, how does this help?
Virtual servers can be traded among each of the server machines so that if there are 15 sims that have no activity, dump them all on one machine: any lag in those sims would not be noticed as no one is there. If one sim ends up seeing high loads, transfer it to a dedicated machine that runs JUST that sim. It quiets down again and another sim is sent to that machine to take advantage of the available system resources.

Now, this doesn't help client-end lag, but it will take care of server-side lag. It is also very scalable and actually would REDUCE the number of machines that LL has to maintain.
Another bonus:
Hardware upgrades would not affect grid status! As well as possibly allowing the grid to *gasp* be left online durring server and client updates!
1) Virtual server load is frozen (no more sim-swaps)
2) One machine (or a group) at a time is taken offline ("You have 1 minute to teleport"
3) That/those machines get their server update
4) Sims are brought back online, anyone attempting to TP or log in into that region is given a dialog saying that a client update is required
5) After all sims have been updated (and thus all active clients), sim-swapping cna be turned back on and the grid opperates as normal.

Downside to reconfiguring LL server farm:
The grid would be down for probably a week as LL reconfigures everything and installs new operating systems to handle virtual servers.

It'd be worth it though. Check out Dungeons & Dragons Online, you'll never see lag there, no matter how many people are in an area because each area is instanced to balance the server load (virtual servers are created and destroyed dynamically to correspond to demand). Even though SL isn't instanced, if each sim opperated as a "permenent instance" and was moved from machine to machine seamlessly to take advantage of system resorces lag would probably be cut in half.

I don't know the exact tech figures, but I can say this: no matter how much one "trims"... the lag is still going to be there because it is server/programming based, not client based.

Yes, extremely bad client building/scripting can lag a sim. But when you have a sim that full of rich content, and another sim that is only half-filled with content (and script-controlled) and both sims lag equally, that has nothing to do with what the customers are doing. That is server-side issues. And when the full sim runs just peachy fine at times, that indicates server-side issues, because if content were the problem, the sim would always lag. Simple boolean logic.

Further, when you scrimp and save and try to make your sim function to a tee, only to have that totally blown away by some visiting avatar wearing a hairdo with 200 floppy prims, it all gets down to the "absolutely a waste of time to worry about it" catagory.

So for myself, I've pretty much stopped worrying about "lag" issues on my end, because Second Life is going to lag like a fiend no matter what I do. I pretty much build what I want to and how I want to these days. There's very little I could do in normal building that would lag the system any worse than it's lagging already.

There's also another issue: when Linden Lab knows that the system is lagging like a fiend and still decides to bring out floppy prims and specialty lighting (both heavy-lag issues) that tells me they don't give a flop about lag effects on their customers. They obviously care more for special effects than system usability.

off topic again i talk about the poor CLIENT SIDE fps we get usually due to the tendencie of a lot of avatars and builders to try to put as puch details as they can, avatars being the worst as they have no hard prim limit like land do, my idea was to make each prim have a different cost, that would reflect theyr actual price in triangles on the client rendering engine, pushing the builders to use low cost prims rather than the high cost one (so even if they don't knos anything about realtime build optimisation they would still be tempted to use less costly shapes)

this has nothing to do with server lag
this has nothing to do with physics
this has nothing to do with scripts

Hmm, would this be for avatars though? I think that usually the problem isn't a build, complicated buildings are covered fairly well by LOD and occlusion culling since they don't move about, and the limits on prims are fairly good as they are (enough to work with a few optimisations, but not crazy). It's the avatars that cause big problems since people wear things like armour made up of individual pieces, or jewelry that is so tiny you can't even make out the individual prims used to make it.
I've seen avatars that have hundreds upon hundreds of prims attached, and since they move they often trigger the LOD spikes that are worse than most lag since it seems to freeze SL while it recalculates the detail of each prim.

However, as you say, an avatar wearing a ton of cubes would actually be much simpler than one wearing the same number of spheres, resulting in less of a hit on LOD.

Read again post #7. You can charge clients all you want in "prim" points... you're still not going to eliminate lag. What you're trying to do in effect is solve the world's starvation problem by having people eat less. When Ethiopians were dying of hunger, food was rotting on the docks because the government refused to spend the funds to get it to them. The way to solve the starvation problem is to get the governments to distribute food better.

Same here: the way to stop the lag problem is not to try and force the clients to build in a certain manner. Although I do see some merit in say, a torus shape or floppy prim or lighting prim costing 2 "prim points" rather than one... that will do no good at all, because the lag will still be there.

When lag is primarily server-side, there is nothing you as a client can do. You have to get Linden Lab to do something.

But you know what I think is hilarious about all this? (well, not really hilarious, because it's a pain)...


Linden Lab brings out occlusion culling in order to reduce rendering of non-visible prims. Maybe a good idea (although how long does it take the system to figure out that prim is not visible at this particular moment? Who knows.)

But at the exact same time, they add floppy prims and specialty lighting to the system, both of which were known ahead of time to be huge lag-hounds. Further, "hoochie hair" has been known for ages to be one of the worst lag factors on SL So now LL gives people the ability to increase that problem ten fold?

One has to wonder.

I dont wanna play in legoland. I'll take the FPS hit to avoid it, thanks.

Plus, I can turn a cube into something worse for your system than an off-the-shelf tori. And trust me, I would be, too, if this happened.

I for one actually notice very little difference in FPS when switching lighting and/or flexiprims on/off, they're not actually big of a lag factor. In the morris test area there must have been hundreds of visible flexi-prims at almost every point, that DID lag but mainly because it forced occlusion updates all the time. Flexi-prims actually scale surprisingly well with quantity and lights are really very well implemented.

I'm also not sure that server-side lag is the issue either, as the prims don't really matter all that much to the server, especially if they're attached to an avatar as they're just there, not really much else to it. It's the scripts an avatar can have that the server is more worried about.
However, the prim problem often is client side with ridiculous avatars. The systems in place (occlusion culling and level of detail) often seem to cause more lag than they solve when it comes to groups of avatars. OC makes it more bearable as avatars you can't see just wink out of existence, but an avatar coming a little closer to you can force a LOD update which can be costly sometimes, especially if lots of avatars are moving and causing it to constantly recalculate.

I agree some prims take more resources. But you also have to take into account hollow, cut and most importantly twist. Twist increases the poly count of a cube alot. But it's way be too late to switch now, so many people would suddenly be over limit.

Likewise people wont like this comment either
But if they added a DirectX 10 render path that would be great. Of course DX10 hardware is'nt even out yet, etc. But its advantage over all previous versions of DX and maybe Open GL too, is that the software layer between the card-driver-windows-app is much more efficent then it used to be. And I also think even bounds checks may be on hardware too(like is something needs clamped to 0.0-1.0). And.. Just an idea, But the geometry shader in DX 10 may be able to build the prims on the card. That would be amazing. You send it code, then push it the prim info, and the card renders it all, no polygons(except AV's) sent. Mmmm.. Of course in RL it would never happen, and even if it did.. I cant afford to updgrade for a while anyway, lol.

Yes, far as I know you're accurate in all this. Prim rezzing (from what I understand) is primarily client side (although I imagine servers have something to do with prim updates, just as they do with particle updates). But the thing is... client side is already over-taxed. So why add anything more to tax further?

The server-side issues I'm talking about are the kind of issues where everyone is standing around, doing just fine, no problems, then suddenly everything becomes syrup. Everyone confirms the lag, which immediately indicates it's not client side-- it's likely a server issue (either that, or something that just caused all clients to lag at the same time... and that's not usually likely). When we check Time Dilation and SIM FPS and they're all over the scale... it's obvious something is not working right somewhere.

I do have to wonder how often sims but heads over shared resources. They're currently running four sims on every box, which means those four sims are sharing hard drive, bus and net resources (that was confirmed at a Town Hall meeting). I also think they may have a cache buildup or something somewhere, because our sims work just peachy fine if we reset them, then the more hours that pass, the slower and slower they go, until Time Dilation just goes nuts and we have to reset it again. That tells me something is not being done right somewhere.

Time dilation or whatever usually is the fault of a script though, or a physical item. Maybe it's physical objects that should be counted as double? As the calculations for physical objects (collisions etc) can be quite costly and WILL cause everyone to lag. Same with scripts that are moving things around a lot, though the script time control is pretty good with that as far as I can tell.

I think the main issue with server lag as far as avatars go is that it has to send information to all of them, and keep updating them, again is a physical issue because avatars are controlled by the physics engine so if they're all moving around it can cause issues. And of course the various pieces of content they need streamed to them.
You'll notice in other games, for example Unreal Tournament that servers there can struggle with more than 12 players, even though all of their content is available to you BEFORE you actually play. Some handle up to 32 players fairly well, but you often get insane lag and so-on.

So maybe part of the issue is communications then? And what has to be done with these communications (physics). Hrm, I know I'm rambling about all sorts of stuff, but I'm trying to identify the main issue. I'd probably be in favour of some way of limiting the over-use of physical objects though, as these are quite costly, more so than a torus which is really just a rendering issue. For example, my FPS is relatively consistent in complex areas as simple ones in terms of the polygons, but complex scripts, physics or avatars can kill me.

Such can be caused by a bad script or a physical item. But "usually"? It's pretty apparent that time dilation and sim FPS problems appear out of nowhere and then disappear just as suddenly. And they get worse the longer a sim is online without being reset. It's not limited just to one sim either; it's grid-wide. We have 5 sims on 5 different servers and we have the same problems with every sim.


Yes... but that's what the system is supposed to do. Excusing the system is like buying an expensive new car and then saying, "It's having trouble getting down the road because there are people sitting inside."
Again, I point out that quite often the sims will work just fine. No discernable lag. No problems. And then suddenly wham, out of nowhere, with nothing on the sim changing, severe lag. I was on the system at 2am other day, the ONLY avatar on the sim, and suddenly, wham! Time dilation drops to .13 and sim FPS even lower. Now there are all kinds of things that can cause such... internet problems for example. But when 5 people are standing around and suddenly every one of them lags to syrup... that pretty much indicates server issues. This is a repetitive thing that has gone on month after month after month.


I've played Unreal for ages. The only time I have ever experienced lag was during Invasion when a dozen or so avs are fighting 50 or so monsters with extremely high firepower. I mean, there's enough going on there that would make the entire SL grid crash. ; ) But even then the lag was only moderate. I have never seen the game lag to a standstill or even close to it. Really though, comparing apples and oranges.


Join the club . People have been trying to figure this one out for ages. Thing is, my deep gut instinct tells me 2 things: either LL really doesn't know where the lag is (ie, it's deep core and they just haven't ferreted it out yet) or they know exactly where it is, and they're not fessing up.

However all prims are equal as far as the server is concerned, a prim is a prim is a prim and no matter how you add them up, the server only supports a fixed number.

This is trying to solve a problem by looking down the wrong end of the telescope, bottom line SL needs a better 3D engine.

You don't need virtual servers to do that. Sims are already transferred between machines this way.

Virtual servers are almost always a hack to deal with horrible application or operating system limitations. If the applications and operating systems are competantly designed (which rules out Windows and Windows-sourced applications, of course) you don't ever need them. Seriously.

Except they're not.

Really.

Even on my Mac mini's Radeon 9200 (which is as sad a processor and GPU as anyone sane woudl expect to run SL on these days) there's absolutely zero difference in performance turning these features on and off. There wasn't any problem with them in Preview, and there hasn't been any since.

What caused the big problems in 1.10 was the new shader code, and that wasn't necessary for the new features... up through the 1.9.1.13 preview they were still using the old shaders and it was actually faster even with prims flexing all over the place!