First time I wrote and taught this class, neither mesh nor Pathfinder did exist, and the way to keep phantom and non phantom prims linked was by using scripts, exploiting some bugs. However, Pathfinder put an end to one of those bugs and thus the "volume detect scripts", which were the ones used then, stopped working. I rewrote the class entirely to teach it again in summer 2012, and then rewrote it yet once more to adapt it to book-style. The text and images below are an extract from the first section of the "Blender - Modelling Basics 103" book that you may find, together with all the other Blender books, in my inworld store and also in my Marketplace store.
"WHEN MESH WAS ROLLED OUT TO THE ENTIRE SL GRID"
(A bit of history to know where we are)
Perhaps you remember, if you rezzed before the summer of 2011, that before mesh came to the grid, the land capacity (this is how many items a sim may contain) was simply measured in "prims." There was a direct relationship: your builds use N prims, whether they be boxes, spheres, torus or sculpts, so you're using a total of N prims of the land capacity.
It was August 23th, 2011, when mesh was rolled out to the entire Second Life® grid. As with every big change, problems and unexpected behaviours were bound to happen. Maybe you remember situations like when linking a torus to a mesh object, or dropping a script into a mesh object, it caused a dramatic increase of the "prim count" of the object.
What was happening here?
What happened was that, at the same time mesh was rolled out to the entire grid, the way the land capacity was accounted for also changed.
Why did it change?
Mesh objects could go from very simple shapes to very complicated objects, having a very different impact over the servers. It wouldn't have been realistic to assign a fixed "prim capacity" value to every mesh object. Simple objects would have been penalized this way, discouraging people from creating and using mesh.
What LL did was to set in place a new and more rational way of measuring the land capacity (for it makes us aware of the real impact we're having on the servers). It started being called "Prim Equivalence" (PE), and finally received the definitive name of "Land Impact" (which is the LI we often read).
Older builds that weren't linked to mesh at all, would have their LI calculated by using the equivalence "1 prim = LI 1". Objects that were linked to mesh objects would automatically "opt-in" to the LI calculations. That's why if we linked a box to a mesh, basically nothing happened, but if a torus was linked to a mesh, the LI bounced high, because under the new LI calculations, torus are expensive shapes.
At the same time mesh was rolled to the entire grid, another primitive property was added: the "Physics Shape Type". This property has three options: "Prim", "Convex Hull" and "None". They will be explained later. Right now, this is what's relevant: the existent prim builds had the property assigned to "Prim", and we heard that we should start changing linked prims to phantom by changing the "Physics Shape Type" to "None". But, in many cases, by doing this, we again had the LI of the linked object raising quickly and often above our parcel land capacity (thus causing the object to be returned to our inventory).
This happened for the following reason:
Only an object made of legacy prims (that is, anything that is not mesh) where all of the linked prims have "Prim" as their "Physics Shape Type" and not using normal/specular maps will be accounted for under the old "1 prim = LI 1" system. (July 2013)
Any other combination will be accounted for under the new mesh Land Impact (LI) system.
However, nowadays it is very difficult having a build made only of legacy prims, or a build made only of legacy prims where "Prim" is the "Physics Shape Type" for all of them. For this reason, it is very important to get acquainted as soon as possible to the mesh accounting system if we aren't already.
Even though the "None" Physics Shape Type allowed linked phantom and non phantom prims, builders continued to use an old trick, which was called "a volume detect script," to be able to have linked phantom and non phantom prims (which is essential when building houses, for example), in this way avoiding the need to switch the prims to "None", and the resulting huge increase in the LI.
And another big change was rolled to the grid, forcing builders to stop using this script, and using the new system. This change was Pathfinder.
While Pathfinder was still in the Beta grid, alarms were raised because builds using the "volume detect script" would basically make the region crash (making short a long story).
Because of this, when Pathfinder was rolled out to the main grid, LL also provided a solution to the big issue that would mean all the old content that would rez broken, as well as to the drawback of being forced to make builds with a huge LI if we were to keep linked phantom and non phantom prims, as a result of making the "volume detect" scripts no longer useful.
The solution they provided consisted of two main compromises:
- Any existing build using the "volume detect" script would continue to be usable, as long as we don't unlink it and later re-link it. Once unlinked, we should use the new system. But at least, existing content would not rez broken.
- The LI algorithm would be reviewed, so the complicated shapes (spheres, torus, sculpts...) wouldn't penalize our builds so much, should we want to use them mixed with mesh, or just because we need to use any Physics Shape Type other than "Prim".
If you're interested, this link will lead you to the server release when Pathfinder was rolled out to the grid (August 7th, 2012), and LL explains that the LI algorithm has been revised, and how:
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12#12.07.31.262785
The news, back then, was very, very good :-) (we'll talk about it later)
So, knowing now where we are, and how we've reached this point, it's time to explain the mesh accounting system and the physics shape types. A good understanding of these concepts will help us create more optimized builds, whether they be mesh or legacy prims.
Optimized builds means creating less lag. We will always want this!
THE MESH ACCOUNTING: LAND IMPACT
As we've said, when mesh was rolled out to the main grid, a new system to account for the land capacity was adopted, and it was finally called "Land Impact" (abbreviated as LI). This system begins by calculating four values for any object, called weights, using only three of them to obtain the final LI. Those three values will show up in the mesh upload window.
You have probably heard about the weights:
Download Weight, Physics Weight and Server Weight. The fourth one would be Display Weight, but that one is not relevant for us here.
Let's talk briefly about these weights.
The Download Weight measures how much any object is going to impact the network side; simply put, it measures how much data needs to be transferred for the geometry of a shape. Complex objects have higher download weights than simple boxes, and even more significantly, big complex objects have a higher download weight than the same complex object... smaller.
Why would bigger objects have a bigger download weight than the same object, smaller? A bigger object is likely to be seen by more avatars at a further distance than a small one, so more bandwidth is required: more download weight.
This is why we have to keep an eye on this when we resize upward a mesh object (or, more generally, any object under the mesh accounting.)
Then we have the Physics Weight. This is a server side measurement that relates to how complex, in physical terms, an object is. As we will explore in the mesh upload window, indeed simple physical shapes will make this weight have lower values than more complex physical shapes.
Finally, we have the Server Weight, which is always, at least, 0.5 per object, and is related to how heavily scripted the object is going to be. That's why dropping many scripts into mesh objects could make the LI of an object increase under the mesh accounting.
Those three weights are calculated on LL's servers. To decide, then, what LI is assigned to an object, the greatest of the three values is chosen, and this value is rounded. This is how the final value for the LI is determined.
Let's study now what happens when two or more objects are linked.
By writing the following:
O(DW, PW, SW): LI
we mean in this book: "The object «O» has as download weight the value DW, as physics weight the value PW and as server weight the value SW, resulting in a Land Impact total of value LI."
For example:
My Box(1.2, 0.6, 0.5): 1
means: "The object «My Box» has a download weight of 1.2, a physics weight of 0.6 and a server weight of 0.5, resulting in a Land Impact total of value 1."
Using the nomenclature we've just established, we're now going to develop what happens when two objects are linked together.
Suppose we have the objects:
O1(DW1, PW1, SW1): LI1 O2(DW2, PW2, SW2): LI2
The linked object O1+O2 has as weights:
Download: DW1 + DW2
Physics: PW1 + PW2
Server: SW1 + SW2
The resulting LI is not, necessarily, the same as LI1 + LI2. At times it will coincide, at times it will be less, at times it will be more.
Why?
Suppose we have, for example, two objects with weights and LI:
O1(1.4, 0.2, 0.5): 1
O2(1.3, 0.6, 0.5): 1
Since the LI for both is 1, we might expect the LI of the linked object to be 1+1, that is, 2. However, let's examine what happens to the weights when we link these objects:
Download Weight 1.4 + 1.3 = 2.7
Physics Weight 0.2 + 0.6 = 0.8
Server Weight 0.5 + 0.5 = 1
The greatest weight here is the download weight: 2.7. This is rounded up to the value of 3. The LI of the linked object is 3. In this case, we would prefer to keep the objects unlinked, for the LI when they are separate is just 2, not 3.
Now let's see a different case:
O1(0.8, 0.2, 0.5): 1
O2(0.5, 0.6, 0.5): 1The LI for both unlinked objects is 1. Again, we might expect the LI of the linked object to be 1+1, that is, 2. But let's examine again what happens to the weights when we link this object:
Download Weight 0.8 + 0.5 = 1.3
Physics Weight 0.2 + 0.6 = 0.8
Server Weight 0.5 + 0.5 = 1
The greatest weight here is the download weight: 1.3. This is rounded down to the value of 1. The LI of the linked object is 1. In this case, we would prefer to have both objects linked, for the LI when they are separate is 2 instead of the more convenient 1.
To be clear, when we round a number, if the decimal part is greater than or equal to .5, the round is up, otherwise, the round is down.
As we've said, when this new accounting system was introduced, a new primitive property came holding its hand: the "Physics Shape Type" that we can find under the "Features" tab. Perhaps you've heard the words "Convex Hull" a lot... but what does that mean?
That's what we're going to study now.
We currently have three "Physics Shapes" for a given prim: Prim, Convex Hull and None. Together with the scripts usage, the physics is also relevant in terms of what makes the servers to be busy, therefore, it is important to understand the three types to correctly select the one that will minimize the cost for the server while performing the function that we need for it.
Physics Type: Prim
In this case, the physical shape is going to exactly match the visual appearance of the prim. If mesh, that is the custom shape we've defined for it.
If we're talking about a box, it's a pretty simple shape, and if it's a torus, we're talking about a pretty complicated shape, in physics terms, for the server. This is why, when making a torus to opt-in into the mesh accounting system, the numbers used to jump up quickly before LL modified the algorithm.
When we select this Physics Type for a prim, the physical boundaries of the prim will be the visible ones. We will fall through holes.
Physics Type: Convex Hull
Simply put, the convex hull of an object is an object without holes that wraps the original object. Convex Hull has a very specific meaning in maths, so although this definition is not 100% accurate, it allows us to understand, visually, what Convex Hull means.
In order to understand this, follow this procedure-demonstration:
- Rez a torus
- Resize this torus to X = 2, Y = 5, Z = 5
- Rotate it to X = 0, Y = 90, Z= 0
- Change the Hole Size to X = 1, Y = 0.25
- Now walk on the torus until you fall through the hole, as the picture below shows:
Edit now the torus, click on the "Features" tab of the "Edit" window, and change the "Physics Shape Type" to "Convex Hull".
When you close the window, as soon as you move, the physics engine will push you outside of the torus (you may either fly or be pushed down). When you walk above the torus, this time, you will not fall through the hole, as the picture shows:
That's because now, for the physics engine, the torus is the convex hull of the visible torus: the torus, without holes (in a very simplified way).
Also the LI of the torus has raised to 2. That's because once we've changed the "Physics Shape Type" to other than "Prim", the torus is now evaluated under the mesh accounting.
As we can figure, the convex hull of an object with holes is lighter for the server, in order to calculate its physics impact. Convex Hull will define a simpler object in physics terms.
Physics Type: None
This simply will remove any physic shape from the prim. The prim turns into phantom, as we have seen before, with the advantage that they have absolutely no physical influence (which phantom prims still have!)
We've said in the first section of this book that on August 7th, 2012, LL completed a review of the LI algorithm and revised it accordingly, as explained here:
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/12#12.07.31.262785
What they say exactly is:
« Changed prim accounting for legacy prims which use the new accounting system.
All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects.
This first part means that the download weight of legacy prims is 1.0, with the exception of sculpt prims, which have a 2.0 value for this, when they "opt in" to the mesh accounting system: this is, either we link them to a mesh, or we change the "Physics Shape Type" of just one of them to "Convex Hull" or "None", or we use normal/specular maps.
However, we have to keep in mind that the LI algorithm is always under review, so it shouldn't surprise us if at some time in the future a torus, or other shapes, may have a bigger LI than 2 when in the mesh accounting system. The physics could have some relevancy.
The bottom line is, always keep an eye on the way the weights and the total LI behave.
Then, LL continued saying:
Server cost will be adjusted to
MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }.
This preserves the current value for unscripted linksets and reduce the cost for linksets containing fewer than 2*num_prims scripts. It provides the benefit of rewarding creators for reducing the number of scripts in their objects. »
What the formula means, in very simple terms, is that a low scripted object in the mesh accounting system will not be penalized, as it was before Pathfinder was rolled to the grid.
TECHNICAL NOTE: WHEN SCULPTS MAY "ABSORB" THE LI OF BOXES
As we've explained before, since we can no longer use the "volume detect" script trick to link phantom and non phantom prims, we need to change the Physics Shape Type of the prims that should be phantom, to "None". After all this discussion, is clear that the build will opt into the mesh accounting system as soon as we do this, so any sculpt that forms part of the build will contribute with an LI of 2. This LI 2 is separated as follows:
Download: 2 (Max)
Physics: Might be around 1.8
Server: 0.5
Let's call this sculpt, S, so using the nomenclature from before:
S(2, 1.8, 0.5): 2
Knowing that, under the new accounting, given two objects O1 and O2 defined by their weights with the nomenclature we established:
O1(DW1, PW1, SW1): LI1 O2(DW2, PW2, SW2): LI2
the linked object O1+O2 has as weights:
Download: DW1 + DW2
Physics: PW1 + PW2
Server: SW1 + SW2
we can benefit from this, to be able to add one or more "low weight" prims (e.g. boxes) to the object without increasing the LI, when linked under the mesh accounting system. We can do this whenever one sculpt should be "phantom" (Physics Type: None) and linked to a build.
What happens now when we link this sculpt to a box?
Let's call this box B1. How are the weights distributed in a box?
We can know this by clicking "More info" in the "Edit" window when we inspect/edit an object:
and so we can read, under the "Weights of Selected" section of the little popup that shows, that our box B1 has the weights distributed as:
B1(0.1, 0.1, 0.5): 1
NOTE: If the actual weight is calculated as less than 0.1 (for example, 0.09), the viewer will round it up to 0.1 to show the information using only one decimal. But this means that, for example, two weights of value 0.05, that will show as 0.1 in the viewer, when added, will not show as 0.2... but as 0.1! (the result of adding the two 0.05).
What happens to the LI when we link S and B1 to obtain S+B1?
We saw that we have to add the weights:
Download: 2 + 0.1 = 2.1
Physics: 1.8 + 0.1 = 1.9
Server: 0.5 + 0.5 = 1
and then round the greatest value, which here is 2.1. That gives us a value of 2 for the LI of the linked sculpt and box.
This is interesting. So the LI of S+B1 continues to be 2.
What if we add a second box, B2?
We solve this by adding the weights again:
Download: 2.1 + 0.1 = 2.2
Physics: 1.9 + 0.1 = 2
Server: 1 + 0.5 = 1.5
then again we round the greatest value, which here is 2.2, and so that gives us a value of 2 for the LI of the linked sculpt and two boxes.
The practical effect is that the very low weight a box has, is being absorbed by the (relatively) high download weight of the sculpt prim. So, although sculpt prims are a bit penalized in the new system, we can use as many boxes as we need, without a penalization, for they will be "absorbed," in a way, within the LI of the sculpts.
IMPORTANT: If our sculpt prim should be phantom, then set its "Physics Shape Type" to "None". That will make the physics weight of such sculpt to be 0, and so this 0 is what will be added to the rest of the physics weights of the other prims in the linked set. Of course, use the same reasoning for non sculpt prims :-)
No comments:
Post a Comment