One metric is not enough

[Tapple Gao]

Inspired by Psistorm's post, I thought that having an accounting system that honestly measures resources sounds like a gread idea. I don't really like the current prim equivilance system. It feels like a magic number that can change unpredictably at any time, with no way to predict what will happen to existing builds when the formula changes.

I'd prefer an accounting system where the cost of something was fixed, but the limits were tweaked, so that it would actually be possible to predict how proposed changes would affect existing content. So I propose abandoning any single-metric system, and thinking about some fairly universal units in computing

I'd really like to know all of the following about a given build:

• How many prims is it? (a prim is a pretty well understood bundle of position, orientation, size, and a few dozen shape numbers and texture and mesh uuid's)
• How many unique textures is it using?
• How many unique meshes is it using?
• What is the total download size (in megabytes, killobytes, etc) of all the textures and meshes counted above?
• How much script memory is it using (in killobytes)?
• How much script time is it using(in milliseconds per frame, seconds per real hour, or something)?
• How much is it costing the physics engine? (in number of convex shapes, collision checks per frame, or something)

If resources could be accounted in simple units like the above, the tweaking could stop fiddling with what the costs are and shift to working on what practical limits are. This would make it much easier for us to prodict the effect of any new limits the Lindens choose to set.

So purchasing a parcel gives you (or your group) the right to use up to (as an example):

• 100 prims
• 10 mb of streamed data (textures, mesh, maybe sounds)
• 1000 convex shapes in the physics engine
• 1 mb script memory
• 1 script minute per hour

This would rather help us understand how we are actually using the linden's servers, and be let us better know what to simplify in order to reduce lag. Such numbers also leave no room for misunderstanding and drama, since their meaning is well understood and not subject to change. And also, it's mostly backward compatable with the old accounting system (only count prims) and the script limit system (I don't know what the status of it is). 

Some other benifits I see to this system:

• It rewards reusing meshes and textures in builds in a very straightforward way
• It penalizes texture-heavy builds in a backward compatible way, which is, in my opinion, what REALLY causes server lag, not prims, and which mesh may do best at replacing.
• Prims and meshes are penalized equally for scripts, since scripts take the same amount of resources no matter what prim they are put in
• In the future, could lead to better lag control by sim owners; if a combat sim would rather have more physics capacity and less streaming capacity, he could request that and his sim would be preferably allocated on a server with lighter physics load and heavier streaming load

Issues:

• As stated, it would penalize making good LOD's for mesh, since they increase the raw storage size. Perhaps the metric should instead be streaming size * area of visibility, (in MB * m^2), or put a weighting factor of 1/4th or something on the  high LOD's (magic number alert)
• I have no idea what physics costs actually are like, as I've never used a physics engine

[Poenald Palen]

Script Time? Physics? Aren't they making/have made the scripting stuff and physics stuff all flexible based on sim demands? So, some sims get more 'attention' than others, based on usage happening at the time avatars are there?

[Vivienne Schell]

Limiting anything in existance, prims and scripts, might be a good idea basically, but it´s not practicable. Imagine what will happen when all the thousands of objects and linksets which will not apply to these new restrictions will be returned to their owners? If people who paid real dollars for scripted attachments and real dollars to Our Lordships for a license to kill cannot wear these attachments anymore and nobody knows which inventory items can be rezzed and which not anymore?

As far as i understood it, Linden Lab only tries to limit the impact of mesh imports on the system *somehow*, which is a wise decision. While i agree with you that the recent mesh import restrictions and the math ping pong are an insufficient joke and won´t solve any problem.

[Psistorm Voxel]

The concern is clearly valid, but to avoid this, a transition period would have to be introduced. A period where the viewer gets the necessary updates, but they are simply "for show" for maybe 3 months or something. This would mean residents could see how much resources they are using under the new metric, and address potential issues that arise. Only at the end of the transition would these metrics actually take effect and stuff be returned that was over the limitations.

 

That said, the idea of a more spread-out metric is interesting, and would certainly allow for a fine balance of how many resources of a kind LL wants to run on a sim. On the other hand, it will be a challenge to divvy up those ratios responsibly, so that, say, textures dont get too much or too little space assigned, or mesh, etc.

The benefit with the single-metric system of mine is taht it is adaptive. It could be either a low-prim, texture intense build, or a high detail, but lower texture build. But this, on the downside, is putting server load somewhat on the same level for all asset types, unless their costs are balanced to match. Which they should be, mind you.

As the person who opened the single metric post, I´m favoring mine, but I´m biased, obviously. But I will say that the OP´s, given a good, easy to understand implementation, certainly has a lot of merit and is as good a solution as my own, thinking about it.

I think we can agree that a new metric is needed for all this though, rather than trying to obscurely define mesh costs via PEwts, which are hard to understand for new residents. That, and the case of "the whole is 32.000 times greater than the sum of its parts" needs to be dealt with desperately.

[Vivienne Schell]

I doubt that a transition period would be acceptable. It only would give people three months to be forced to spend more real dollars on replacements and more real dollars for renting some server space which tey cannot use as advertised. That´s not a fair deal. It would be one if they were compensated for the loss in full scale. Which will never happen.

Linden Lab should adress the real trouble with mesh imports instead spreading confusion and spur arbitrary ideas among the potential uploaders. For example: Why should an imported mesh be scalable and scriptable and linkable at all? Given the fact that these functions add a lot of bandwidth, physics and usabilty trouble. Allow fixed sizes, no mod, and done. Easy, fast, fun.

[DanielRavenNest Noe]

---

Vivienne Schell wrote:. Allow fixed sizes, no mod, and done. Easy, fast, fun.

---

So now you want to break the permissions and build system?  What happens when such a no-mod mesh is linked to non-mesh items?  Does the whole thing become no-mod?  You are just exchanging one kind of worthless (it costs too many prims) for another kind of worthless (Even the original creator cannot edit the item)

[Drongle McMahon]

"Why should an imported mesh be scalable and scriptable and linkable at all? Given the fact that these functions add a lot of bandwidth, physics and usabilty trouble. Allow fixed sizes, no mod, and done."

That's an interesting proposition. Where did you find that scaling uses up bandwidth? Are you suggesting a whole new mesh has to be downloaded each time? That would be ridicuolous indeed. Obviously, since the streaming format uses normalised vertex positions and a scaling vextor, all that is needed is for the editing viewer to send three numbers and for the server to pass those on to any other observing clients, just as with other kinds of object. Do you have any information confirminf that it's not done that way?

For the visual mesh in the client and the physics shape on the server, isn't it just a matter of applying a transformation matrix, exactly the same as rotating or scaling any other object, except, of course, that meshes use fewer vertices for the same shape and so can be transformed faster.

As for scripting and linking,  why exactly should those consume any different bandwidth than doing the same things with other objects? In fact, since you can put many prims-worth of structure in a single mesh, woulndn't any linking overhead there is going to be reduced?

 

[Vivienne Schell]

Obviously LL penalizes scaling up, scripting and linking meshes at least in some way. I conclude that there is a valid reason for this. Logic tells me that one can either penalize or simply avoid penalizing by removing the reason for penalizing. No reason, no trouble.

There still are many workarounds for making "pure" meshes interactive, one must only want to work around. And i see no sense in adding additional burden to an already aching engine.

[Vivienne Schell]

"Even the original creator cannot edit the item"

Right, but you have a desktop app you can edit as long and as much as you want before you upload your mesh. And if done correctly, i see no need for further inworld editing. I cannot edit my photoshop graphics in SL, so what´s the problem?

[Dain Shan]

But you could edit your skyboxes ..

 

How about LL adds a save button to builds.

No even better, after  you take a build to inventory cou cant change it anymore, means no adding of textures, no altering any values or scripts.

No linking stuff to it eighter.

 

Thats what you suggest here. If you want to change something, like size or anything else, you have to start over completly.

Oh my what a fun .

 

Seriously .. i suggest you quit joking. Thats not funny anymore

[Vivienne Schell]

That´s not a joke. Mesh imports in IMVU are not editable at all. Why should they be? Simplifying a format to it´s favorable essientials (I think that the 3D creators here are mainly stressing the superior graphical quality of mesh imports) while not stressing the environment is a valid - and proven to be economically succesful - thought. It would make most of the math described above more or less obsolete, give you a simplified and much more transparent upload/calculation process and "bare" meshes still would do great as the desired visual enrichment.

Or did i miss something?

And Dain, i am penalized enough with prim count and workarounds, believe me.

[Tapple Gao]

please make your own thread to debate whether mesh should be modifiable or not. it's off topic for this one

[Vivienne Schell]

Oh, it´s off topic when i discuss the reason for this thread? Yes, yes, the hen and the egg....

[arton Rotaru]

Here is my solution for the problems. Don't login at all. Just pay for your Region(s), but don't put any prims on it. No prims, no scripts, no textures, no avatars, on the entire grid! I promise, the performance of second life will be stunning. :matte-motes-nerdy:

[Drongle McMahon]

"Obviously LL penalizes scaling up, scripting and linking meshes at least in some way. I conclude that there is a valid reason for this. Logic tells me that one can either penalize or simply avoid penalizing by removing the reason for penalizing. No reason, no trouble."

Ah. I see.I'm not sure your conclusion follows, as it naks rather generous assuptions. However, in this case they do have reasons. The same reasons apply to normal prims and especially to sculpties. I think that would mean exetnding your logic to say that those should not be be scaled, scripted or linked.Oh what a dull world.

The penelty for scaling mesh is simply because the larger the size, the larger is the area around your camera where the highest LOD has to be downloaded and rendered, and that is more data and more triangles. This is because of the simplistic LOD switxh logic based solely on object size. You have no control mover where the levels of detail switch, which works plausibly for prims, but is very ill suited to mesh which really need adjustable LOD distances.

 

[Vivienne Schell]

Yes, very dull. Right, prims and sculpts are not penalized. But mesh is. Logic tells me that there cannot be the same problems as with mesh imports then. The conclusion is, that at the current state, Linden Lab tries to reduce some impact by penalizing the format. Which is not exactly the most efficient way to introduce an additional format to the environment. Importing problems and trying to reduce - not avoid - the problems by some wishiwashi penalty math, oh uh.

Every other conclusion is illogic. So is yours.And you do not adress my simple suggestion at all. Very dull world, indeed.