limit avatars to 1000 prims

The SL cache isn't what I'm talking about here - it's not the same thing.

And prims reloading to the video card are not the same thing either.

Then what are you talking about and how isn't that the same? More info, please.

SL's "cache" is just storing data on the hard drive. I'm talking moving data between the hard drive and memory.

Thats exactly our design ethic and mentality... We know that we will have a large number of avatars and so to allow for that we use a very *VERY* small set of textures (roughly 8, all 512x512 not 1024) for almost all of our building. we also use relatively simple geometry for our area. Again, we are designing a social space, and therefore the people are the focus, and we really minimize our actual area's impact on the clients to a large degree so that we can actually have 20 people hanging out and still have workable framerates.

The analogy you made to the 'boss' monster being in a simple area to support more complex creature geometry is very very apt.

If you are designing this beautiful area but you are investing tremendous resources to simply render the area, yes, you will be annoyed at 'complex' avatars that add just enough more latency in to 'overdo' it and lag your sim/location...

At the same time though keep in mind that there are many other areas and social spaces that are designed with a *different* overall ethic entirely, and can support multiple rather sophisticated avatars without causing general 'client' lag. They have been made to support built in headroom for that sort of thing...

saying just because YOUR particular area is not very supportive of it that NO ONE IN SL should be able to... which is what a hard line limit does.. is not only a rather self-centered, its down right immoral and masoginisic, you are claiming that because you want thing X, everyone else, all 500,000 others, have to suffer consequent Y... even if they will never in a million years actually see you or the thing you are trying to 'accomplish'...

There is a 'finite' pool of client resources, on a given machine

every machine will be different, every machine will have a 'different' pool... some will be deeper, some will be wider, depending on their various ratios of cpu to memory to graphics power... some people will have huge problems rendering alpha textures, some people will have no problems with alpha at all, but will not be able to render that many polygons, other people will have no problems with alpha or polygons, but will be very limited on texture memory... etc..

there is no 'one size fits all' pool, there is no single 'thing' that will fix sl for everyone, and any one thing attempted, on a HARD LIMIT basis, will do more harm to more people, than it will ever do good. What may make your area run *great* (say, arbitrarily, banning ALL ALPHA TEXTURES FROM THE GAME), may 'additionally' ruin SL for hundreds of thoussands of other people (who depend on alpha textures for myriad aspects of their avatars/areas/goods/etc)...

its a shame he has me on ignore so he won't see this... but thats the point...

i don't know how many people in sl spend their time 'standing around chatting'... but that is *NOT* a small number... and just because thats not what *he* wants to do, he is perfectly willing to ruin the SL experience for anyone else, because no one else's experience obviously has any importance to him

I don't really see the point there. Either way is a data transfer... and either way, you're moving either prim data or texture data. That's why graphics cards have 256megs or 512megs of their own RAM... to handle such graphics. So once such is loaded... it should pretty much be fine. And if it's not loaded... massive prim data or massive texture data... it's still going to take graphics time, either way. More info still required.

Uh, first of all, if your talking about non-top-end systems, which you folks apparently are, many graphics cards do NOT have 256 megs of memory, cards that run SL just fine otherwise.

And no, evidently you don't see the point. Maybe someone else can simplify how this works better, I'm not a good person to teach this stuff.

Maybe I can put it this way:
(Note, following the converstaion is a little hard and I am a little up in the air about the actual point, but I'll try my best.)

ALL the data a prim could possibly hold is proably a kilobyte or three (unless it has every single possible prim attribute such as SetText appied to it (max data), and even then that probably be 10 kb max).
A 513x512 jpg picture is probably 300 kilobytes.

All this gets downloaded to your local client's cache on your harddrive.

Render times: Objects take next to 0 time to render, textures ON objects take "forever" (i.e. significantly more time).

Rendering is all done in the video card, with its puny special processor and small amount of RAM (these days most people have 64 or 128 MB)--EVERYTHING visable is shoved into that RAM, every texture, every vertex of every prim. Textures take up more space than prims, so the textures are blurred and reduced in size so that the renderer can actually render everything.

Wanting a texture to load all the way means that if it isn't in your local cache--which it probably isn't if it got blurred, as the new version was saved--it has to be downloaded from the server again, then shoved into an already full video RAM and rendered.

The point is that you wrote "prims cause lag" therefore, you say, there should be a prim limit, and adde "it's that simple".

It's not that simple. You have to get more complex because a "it's that simple" prim limit can lead to behaviours that cause more lag. For example, to save prims, people start using complex alpha textures and highly complex cut and sliced prims. The result of that is more rendering inconsistencies from alpha masking, more unique textures on a sim so more time waiting for textures to download, and more actual sim load because the physics engine has a harder time with concave prims.

So it would have been better if the original "prim cost" in a sim was scaled by the complexity of the prim.

It's too late for that now, but it's not too late for any "avatar prim quota" to be better designed.
That can be addressed by apportioning sim time to scripts differently. Perhaps having a maximum quota of script time per parcel, which would limit avatars (sincethey are always in the same parcel) more than builds.

There's two big problems with this statement.

First, it implies that the only options are a simple prim limit enforced at the server, or nothing. That's a false dichotomy... there are lots of options, and we should explore them.

Second, to do the wrong thing now because you want to do something now can be a big mistake. One reason we don't have havok 2 or 3 now is because they prematurely implemented joints and they can't get the havok upgrade without backing the joint code out and breaking all jointed objects (which they are doing, I hasten to add, but in stages). One reason we have lag from complex prims in builds is because complex prims are just as cheap as simple ones. Even if it wasn't a false dichotomy, it still may be better to do nothing right now.

I have already come up with (and implemented, but not distributed) a mechanism for getting the effect of push on no-push land. I've found similar products on SLexchange. There are technical solutions for these devices as well, and for cages, and for pure kinetic weapons, and for particle bombs. But every time you trim the game down to limit griefers you limit legitimate builders as well.
It may not be out job, but it is in out interest to make sure that we try and solve it anyway. Push restrictions are a perfect example of that: there was extended discussion about how to fix the problem, with people taking extreme positions or working towards a compromise but all getting technical. And Linden Labs' final scheme was very close to the compromise position we worked out... if we hadn't done this, if we'd just said "it's not our job to solve HOW to fix push" we'd have been likely to end up with one of those horrible situations like the new snapshot that have to be, slowly and fractionally, backed out.

So I don't care whether it's our job or not, it's one we're far better off taking on. Do you want to actually take that on, or just dismiss it and hope that LL guesses right?

Actually, flexi is a background process. All that happens when there's too much flexi around is that the flexi stops flexing. The flexed shapes themslves, though, are not simple... I don't know how expensive they are but they're likely closer to toruses than cubes.

Well, um, have you actually looked at how those flexis are being used? They're being used as bent cones and bent prisms... and before flexi, the only way to get a bent cone or a bent prism was with toruses and rings.

Yep. In a skybox, with no other skyboxes in draw distance.

Er, yes, I think that was my point. It's the kind of prims FAR more than the avatar.

I'm talking about having the client application automatically reduce the quality but only for the avatars wearing too many too complex prims. So the avatars that "look bad" will be the ones that would be causing the lag in the first place. The punishment (hey, stupid, where's your hair?) falls upon the person causing the problem.

It's more effective to say "you can wear a 2000 prim av, but it's going to make you look like a clown... do you really want to do that?"

Sure. I'd love to be able to upload a custom avatar mesh. I've seen avatar designers plead for that ability. Linden Labs sayeth naught.