Prims, Prim Equivalent, Land Impact... a too-long guide

 by Jenni Darkwatch 

from the Second Life forums


Because there's a ton of misinformation and even more woe-to-me, here's a bit of a guide - in laymans terms. For everyone who's interested in the details please do feel free to look over at the mesh forum.
Disclaimer: This information represents my own opinion on how things work, and is largely the result of experimentation and reading various posts from people way more talented than myself. Especially Drongle McMahon, Gaia Clary and Chosen Few.

There's a good question: Why would anyone besides creators even care? Because with mesh and with the new accounting system that comes with it, the following scenario is quite possible. I built a simple house, it's 11 prims as you can see in the build floater:
A few things to note: The house was built using regular box prims and a cylinder. It's not exactly well-built either. After all there's no door and no windows :smileyhappy:
More important to note and not immediately obvious is that the build floater doesn't list "Prims" but "Land Impact". For old objects that distinction is irrelevant. But creators are now increasingly using mesh items and/or items which contaim partial mesh content. Mesh accounting, i.e. Land Impact, is vastly different from the good old prim based accounting.
Here is the same house, but using Land Impact (mesh-type) accounting:
It's the exact same building, but it only has a land impact of 6. In old terms, it means that even though I used 11 prims to build this house, the simulator only subtracts 6 from my parcel allowance.
For consumers this can quickly become difficult to understand, because they might buy this house and the ad might say "11 prims, 6 Land Impact" or more common on the marketplace "11 prims, 6 Prim Equivalent".

We all know the good old region prim count. It's used everywhere. If your region has a maximum capability of 1000 prims, then 1000 prims is what you can rez. Regardless of whether the prim is a regular prim or a sculpted prim, and regardless of their size.

With mesh, there's now a new accounting system: Land Impact (LI). It calculates three values for any prim: Download Weight, Physics Weight and Server Weight. It also calculates a fourth value, Display Weight, but that one is not used for Land Impact (LI) calculations.
Unfortunately, old viewers can not properly display Land Impact, and that's a problem. Because if a customer would buy that house from the first paragraph, old viewers would show both houses as using 11 prims, even though the second one only subtracts 6 from your parcel allowance. Old viewers cannot distinguish the two houses.

It gets a bit technical here by necessity, but bear with me please. LI is calculated for each and every prim in an object, regardless of whether it's a simple prim, a sculpt or mesh. By default, only mesh is forced to use the new LI system. This is where one misconception stems from: That mesh is less efficient.
In the newer viewers, Land Impact for objects can be examined in the build floater. Here's what it looks like for the good old 0.5m cube:
Sorry for the low contrast. The advanced floater appears when clicking on the "More info" link in the build floater. LL changed the terminology across the board. No longer does land have a prim allowance, it has a LI allowance. The distinction is significant.
In the advanced floater there is a section called "WEIGHTS OF SELECTED", listing four values: Download, Physics, Server and Display. These terms are not explained very well in any LL reference that I could find, so here's what they mean based on Linden comments and resident research:
Download: It literally is a measure of how much any prim impacts the network side. More complex objects have higher download weights. The download weight corresponds to the size of most (but not all) prim types. The bigger a prim, the higher the download weight. Box prims stay the same at all sizes. Torii don't. As Drongle has kindly pointed out, the download weight is kind of in-between server and viewer, as it relates to bandwidth use.
Physics: A server side measurement. This relates to the complexity of the physical appearance of a prim, which is not the same as the visual appearance. More on that below in the physics types section.
Server: This seems to be largely script weight, again server side. Unscripted prims seem to have a server weight of 0.5 regardless of shape or type.
Display: This is the only value that is not relevant for LI. It's meant as a measure of render engine impact and as such is clientside. Because this value is highly subjective it's not used for LI impact calculations.
The LI value of any object is always the highest of the three values Download, Physics or Server, and it always gets rounded up.
You will notice that the simple box has a highest value of 0.5. That gets rounded up to an LI of 1. What happens if we link two boxes together?
As we all know, it counts as two prims as seen in the build floater. But the highest weight of the two boxes is 1.0. That is because by default, non-mesh prims use the old accounting system of just adding the number of prims to a prim count total.
That's where it gets interesting. It is possible to opt-in to the new LI accounting system, like I have done here:
Et voila, the land impact dropped to one. In other words, these two boxes only count as one single prim against a regions old-style prim allowance. And that's why LL has removed reference to prim count in most places including land/parcel info floaters. It's now all called LI. How to opt in to the new system? Change the physics shape of ANY object or prim in a linkset to anything other than prim. If even one prim in a linkset is opted in to the new accounting, the whole linkset automatically gets opted in. Also, if a linkset contains even just one mesh, the whole linkset opts-in to the new LI accounting.

There always has been a problem in SL. A prim isn't a prim. For servers, a torus is a horrible thing. It's physical shape is complicated, and it's relatively complex to describe the shape of a torus. Boxes are simple.
Most simple objects would benefit from the new LI accounting system. But some would not. Let's opt-in a pair of tori to the new accounting system:
I admit up-front I cheated. I only opted the root prim into the new accounting by changing its physics shape to Convex Hull. More on these physics shapes later. As you see, this can be a real "Oh damn!" moment. These two prims have a LI of 37! Or in old terms, they count the same as an object made out of 37 prims.
That's why we currently have two accounting systems. The old "a prim is a prim" system and the new LI system. If LL had forced the new system in, a lot of people would have had a lot of their things returned to inventory. When experimenting with the new accounting system it's a good idea to either be in a sandbox or on a parcel with plenty available LI/prims. In a sense, the new LI accounting exposed just how inefficient prim-style building can be in some cases.
Keep in mind, old viewers will not see LI. They only see prims.

Physics shapes are what make SL useable for avatars. Without them we could not walk into houses, over bridges and so on. Physics are not free, they have to be calculated. The servers handle that. Many objects in SL really would not need to have any physical shape, or could at least use a very simple shape. Next to script memory use, physics are one area where we as residents have direct influence on sim performance now.
We currently have three distinct physics shapes: Prim, Convex Hull and None. Meshes can have their own physics shapes, I'll ignore them for simplicity and just use a torus for explanation.
Physics shape type: PRIM
I've upscaled the torus enough so I can stand inside. On the right I enabled showing the physics shape of the torus (in Develop->Render Metadata->Physics Shapes). You see that the physical shape matches the visual appearance of the torus quite nicely.
The example torus above is using the default physics shape type for old-style prims, aptly named Prim. Lets switch to Convex Hull and see what that does. To illustrate, I turned the torus so the opening is on top.
Physics shape type: CONVEX HULL
You see that my avatar stands on the hollow part, it does not fall in. Again enabling display of the physics shape shows why. When switching to Convex Hull, the physical shape ignores the hole and closes it. Convex Hull can be thought of as a gift-wrap shape. It just follows the outline and ignores any holes. Here's a side-by-side of the two physics shapes:
PEvsLI_005.jpg PEvsLI_007.jpg
You can clearly see the difference when looking at the triangles. Also, Convex Hull does not conform nearly as precise to the actual prim shape. It's a lot easier on the physics simulation though.
Physics shape type: NONE
The last new shape doesn't require an image, as there would be nothing to see. Physics shape type "None" removes any physics shape from a prim. It effectively turns the prim phantom. This can be used in linksets to have individual prims phantom, removing the need to either script objects for that or have a separate linkset for all phantom prims.
Linksets can have a mix of all physics shape types. I'd expect that the better creators use that new ability to optimize builds for low server impact. But I'm not holding my breath for every creator doing it. Most don't give a damn anyway, it's easier to blame LL for lag.
I'd like to warn again: Be careful when experimenting with this - it's quite possible to blow LI through the roof especially with complex builds. Go experiment in a sandbox if you're low on free prims.

The new accounting system gives us yet again a new tool in our arsenal to make SL a pleasant place and cut down on lag. I'm sure many here are familiar with the statistics floater (in Advanced->Performance Tools->Statistics Bar). It gives, among other things, a snapshot of the sims health:
PEvsLI_010.jpgSpecifically the time display is of interest, as it tells us where the sim is using its processing time.
The three weights that make up LI are more or less directly tied to three of the time values in this display:
Download Weight affects (vaguely) Net Time.
Physics Weight directly affects Physics Time.
Server Weight (at this point in time) mostly affects Script Time.
This is overly simplified of course, but it illustrates just why we, as residents, should care. Not every performance problem can be attributed to poorly created content of course, that would be unfair to creators who put a lot of time and effort in to making quality products. A lot of content is badly built regardless, partly because we didn't have the tools to effectively measure the impact of our creations on SL.
Now we, creators and residents, have better tools at hand. As residents it allows us to make more educated choices when buying things in SL.


The new LI accounting system has a number of flaws, as near as I can tell.
An object thats set Phantom still gets the full physics penalty, even though at that point it should not affect the physics engine at all.
Since the new system is opt-in unless you use mesh, it does somewhat encourage "cheating" by setting all objects that benefit from it to the new LI system and leaving all objects that do not benefit out of the LI system. Personally I don't see that as much of a problem, but it definitely is a problem.
The new system also places A LOT of weight on scripting. Scripts kill any objects LI quite fast. No idea what the reasoning behind that is.
Last but not least: The new system is not explained very well anywhere. There's no central information hub on it. The documentation that does exist is often outdated, incomplete or both.
Especially for creators the new system is problematic. People with older viewers cannot see it. People with newer viewers may not know about it. The marketplace doesn't support any information on it.

Anyway... if you read this far, my apologies for the lengthy pamphlet. I hope it'll help understand what's going on.

No comments:

Post a Comment