Jump to content

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

Jenni Darkwatch

You are about to reply to a thread that has been inactive for 4064 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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 :)

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. Also sorry about the format, I've had a detour to the ER that kinda screwed my thought process.

Edit: 2011-12-21 02:32 Fixed typo and added menu path to statistics menu

  • Like 19
Link to comment
Share on other sites

thanks heaps for that informative ( if lengthy) explanation. it cleared up a few things that i wasnt understanding about the new system. I wonder if we build something in old prims, if they change the accounting system to Li only, will they all disappear?. where do i find my statistics floater?, i am still getting used to firestorm, and not overly happy with the performance so far.

Link to comment
Share on other sites

Statistics floater is CTRL+SHIFT+1 on Linux... I believe the same on Windows, but I do not know where it is on Mac.

I seriously doubt the old accounting scheme will disappear in the forseeable future. There is too much content that would severely break if they did that. Practically all sculpted trees would suddenly count as 20+ LI. I did a check on a 30m tree, 2 sculpts. 43.6 Download, 3.7 Physics, 1.0 Server... imagine what would happen to a sim full of trees. The Lindens would have to seek shelter in a bunker, I think.

  • Haha 1
Link to comment
Share on other sites

This is a really great resource -- much more understandable than my attempts to convey the same information.

Something that might be useful to folks using this to stretch the number of prims on a parcel: It's wise to keep Locked any prim linksets that use Land Impact accounting.  That's because they are vulnerable to instant doubling if ever a script is accidentally dropped on them -- which result will be at least confusing, if not disastrous.  (Similar confusion might ensue if a torus were to be linked-in later, perhaps after forgetting that LI accounting applies to the assembly.)

Honestly, in practice, if there's any relationship between the Server Weight and Script Time, I'd be hard-pressed to guess whether that would be a positive or negative correlation.  This is no criticism of the write-up, but of the Server Weight metric itself, which is a technical embarrassment.  There are plenty of reasons to want to better control script impact on sim performance (although that impact is widely misunderstood), but confounding it with the impact of geometry only worsens the confusion, fails to produce any intended benefit, and motivates counterproductive behavior.  Oh, and worse: prevents very beneficial, long-anticipated uses of Mesh -- for example as simpler-to-render fine-grained building components for use with standard prims; that's prohibitively expensive because of the script penalty, which selectively applies only to the simplest geometric shapes.

[ETA:  I'd planned to ramble a bit about this: "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."  There are some phantom objects that affect the physics engine because they still generate collisions; those have llVolumeDetect(TRUE) scripts, and are used for a bunch of things such as landing-point arrival detection prims.  I have no idea, however, whether that really has anything to do with the physics weight still applying to phantom components.]

Link to comment
Share on other sites

Qie, we are told that the server weight doubling is not supposed to be anything to do with script time. It derives from other consequences of having a linkset scripted; something to do with extra message handling (I have no idea what that means). So it is not supposed to represent the script execution overhead at all. I guess that remains the subject of possible interventions, although the strong commitment to not break old stuff would seem to make that unlikely.

ETA: It's the generation of UpdateObject messages. Seee message 5 in this thread and message 16 in this one.

Link to comment
Share on other sites

My comment about script time was in response to "Server Weight (at this point in time) mostly affects Script Time" in the "WHAT DOES IT MEAN FOR SL" section of the write-up; I should have been more explicit about that.

As it stands, however, the existence of that "Server Weight" metric has extraordinarily counterproductive effect on how people will be using Mesh... and even scripts, for that matter.  I mentioned above the fact that this metric imposes a prohibitive penalty on linking simple Meshes as components with prims in builds that contain any scripts, thus diminishing the practical utility of Mesh.  I'll give another example:

One thing devoutly to be wished is a way of displaying text on prims that is both reasonably prim-count-efficient and not subject to the security risks of Shared (or Parcel) Media.  Mesh seemed to hold such promise for this, and indeed one of my very first Meshes was a super-simple eight-material model, with all sides facing the same way, for use with a modified XYZZYtext script that I planned to write.  That would give up to 16 characters per Mesh, and as much as 32 characters per "prim equivalent" land impact.  This might make a big improvement in content efficiency on the grid, where so many prims are now used for just this application.  Except -- yep, it has to be scripted, so that means the land impact is doubled for components with such simple geometry.

So one might hope that would just be the end of the story, with the potential savings reduced.  That would be disappointing enough, but it's actually much worse than that: a scripter's response is to manage dynamic linksets of temporarily scripted objects (using llRemoteLoadScriptPin, llCreate-/-BreakLink, etc), so as to not incur the script penalty all the time for all the components of the text read-out.  Thus the Server Weight metric promotes a response that causes vastly more impact on the sim (and many more object update messages) compared to the simple, one-script, one-linkset solution.

Link to comment
Share on other sites

Thank you for posting this.  It's almost scary to think you will need a slide rule to figure out best building practices. 

What still befuddles me is this.  My basic understanding of the purpose of introducing MESH was two fold.  Higher quality builds/objects.  And that building something out of MESH would have less impact than building it out of PRIMS.  Maybe if done correctly that could be true.  But so far most of what I have seen is the opposite.

And the one thing that all this still seems to ignore is impact CLIENT SIDE.  Now I know that impact can vary greatly depending on the users equipment, especially the quality of the graphics card, but from what I have seen so far from V3 based viewers, there is higher impact even when a MESH object is not present. 

I still haven't figured it all out, my understanding is extremely limited.  I just know that I have two computers that ran SL V2 based clients just fine that are just about worthless with a V3 client atm.  And they are not 'junk' machines.  I also know that I am not the only one in this boat.  There are JIRA's for my issues.

What ever is happening server side HAS TO BENEFIT US CLIENT SIDE or quite bluntly it has the potential of being quite worthless.

To be clear, I am not against MESH.  I do object to mesh clothes being no-mod because I am from the school clothes should fit the Avatar, not the other way around.  But other wise I am all for it.  I'm just a bit burned out from having to devote a lot of time to the problems I am having with Mesh viewers, both Linden Labs and TPV's.  Time that is taken from the time I should be enjoying In World.  Unfortunately I am at the present unable to enjoy MESH.  Suxxors.

Link to comment
Share on other sites

That's a very interesting post, Jenni.Many thanks for it.

I decided to check it out, so I fired up V3 and "opted in" with a few objects. One of them, a 7 prim  picnic table, went down to 4 LI, and caused my spare prims to increase accordingly, but the three other items I tried didn't change at all. One of them is a 6-prim hut with a script in 2 of the prims and 2 scripts in another of the prims. That's 4 small scripts in the 6 prim hut. So simply adding a few scripts doesn't necessarily mean that the LI will go up.

I just remembered another item that I tested. It's a 2-prim sex bed that uses the MLP system - plenty of scripts in that - plus scripts changing the colours of each prim and the texture of one of the prims. 12 scripts altogether. Opting in changed the LI from 2 to 4, so the scripts didn't have a huge impact. Without them, the bed may be 1 LI. I linked 16 wooden cubes to it, making an 18-prim object, and the LI was 18.

Link to comment
Share on other sites

Jenni Darkwatch wrote:

Anyway... if you read this far, my apologies for the lengthy pamphlet. I hope it'll help understand what's going on. Also sorry about the format, I've had a detour to the ER that kinda screwed my thought process.

This has got to be the most inappropriate apology of all time.  Akin to Da Vinci looking at the Mona Lisa and saying, "Do you think it's ok?  Sorry about the smile ..."

Link to comment
Share on other sites

Phil, just to be sure it's clear, the number of scripts has no additional impact, just the presence of one anywhere in the linkset effectivley makes that linkset ineligible for partial land impact: no component can count less than one.  (The formula looks hairier than that, but that's pretty much all it ends up doing.)

So it's a little surprising that the 2-prim MLP bed doubled in land impact, from 2 to 4, unless one of those two prims wasn't a simple (untwisted, etc) box or cylinder.  But it's even more confusing that adding 16 simple cubes drove the impact from 4 to 18, not to 20, so I'm not sure what's going on with that.  (This is when those Land Impact details from "More info" can be useful.)

Link to comment
Share on other sites

Yes, it does seem odd that the 18 prim bed object scored 18LI, when the same bed without the extra 16 cubes scored 4LI.

The topic of this thread was news to me today. I'd read your thread on the subject but I didn't understand it, and I figured it's about mesh, so I didn't particularly want to understand it. After reading the eye-opening OP of this thread, I went round the store and changed all the objects that benefited from it, and I freed up a couple of hundred prims :) Most stuff didn't benefit because most stuff contains scripts.

There weren't many pieces where the change caused the LI to increase. Most scripted items stayed as they were.

Link to comment
Share on other sites

Hmm. In thought I was going to be warning you that you wouldn't be able to put your legs under a half-hollowed-box table if you made it convex hull, but it turns out that would have been wrong. In the top of the picture I am sitting at just such a table. On the left, physics shape display, you can see the convex hull that closes the hollow under the table, but the seated avatar can protrude into it. This is because it becomes part of the non-physical seat, I guess. If you turn the convex hull table over and stand or sit on it (3), it behaves like a solid box, as expected. Then if you turn it back to physics type prim (4) and sit on it again, you see the convex hull filling is no longer there. So I guess for chairs the problem does apply.


Link to comment
Share on other sites

Perrie Juran wrote:

Thank you for posting this.  It's almost scary to think you will need a slide rule to figure out best building practices. 

What still befuddles me is this.  My basic understanding of the purpose of introducing MESH was two fold.  Higher quality builds/objects.  And that building something out of MESH would have less impact than building it out of PRIMS.  Maybe if done correctly that could be true.  But so far most of what I have seen is the opposite.

You're right, that is indeed the purpose of mesh. Maybe it helps to emphasize a few important points. Mesh is far and beyond more efficient and less ressource hungry than either prim or sculpts - if built properly. This early in deployment, many mesh objects are not very efficient. As creators learn to use the tools to create mesh, efficiency will improve.

The misunderstanding that mesh is less efficient arises largely from the two independent accounting systems. The old accounting system tolerates atrocious building practices, with ostensibly less impact on our land ressources. In reality, if you examine just about any build out there, halfway properly constructed mesh would beat the pants off prim/sculpt based builds.

Client side render performance isn't necessarily related to mesh. As you noted yourself v3 performs worse even if no mesh is present. I don't know what the cause for this is, but I'd bet it has little to do with mesh per se. After all, every 3D game out there uses mesh. SL was about the last holdout on implementing direct mesh support.

That the current implementation of mesh is sub-optimal is pretty obvious. On the other hand, it's impossible to roll out a flawless feature. It'll have to evolve over time. The main concern with such new features is the introduction of "sticky bugs". SL has a few of those. What that means is that bugs get adopted as "features" and therefore become unfixable lest they break existing content.

Link to comment
Share on other sites

I've goofed up seating enough times that I can state it's possible to seat an avatar on a prim and end up embedded in a prim next to it, physics type doesn't matter.  And also I'd like to note that hollowing and path cutting a box really cranks up the physics weight, just managed to get one up to 28.1!:matte-motes-shocked:

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4064 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now

  • Create New...