Jump to content

What is "PE Weight" ?


Gaia Clary
 Share

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

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

Recommended Posts

  • Lindens

Official (server-generated) numbers are provided for "prim equiv" and "physics weight".

The debug info display for streaming cost should be accurate on release, but it is viewer-generated and thus may be inaccurate. There is not currently a debug display for server weight specifically.

We're looking into what it would take to provide more detailed information after the initial release.

Link to comment
Share on other sites

So far, when physics cost is small amd server weight isn't a consideration, PE does semm to be the rounded version of the Show Render Info streaming cost (occcasionally +1). So the server and viewer are in synch on that so far. Of course there is no guarantee that will remain the case.

Link to comment
Share on other sites


Nyx Linden wrote:

The minimum for a single isolated mesh is indeed the server weight. If you look at the documentation you can see we charge 1 prim for the object as a whole and 0.5 prims for each piece. So an isolated mesh object will cost 2 if its streaming cost is low, but the per-prim cost is only 0.5. The values are rounded to the nearest prim.

Could you explain why you have choosen to set the numbers like this ? What exactly would make you trouble if you decided to charge the object as a whole with 0.5 prims plus 0.5 prims for each piece ?

Could you again publish the location of the documentation ?

Link to comment
Share on other sites

  • Lindens

When regular prims have the physics shape type "prim", twisted toruses really are that much more complex to the physics engine. We've just hidden that complexity in the past, which creates some interesting load challenges for our physics system.

We're still in the process of reviewing the formulas, but in the meantime, could you try setting the linked torus' shape type to convex hull and report back on how that affects the numbers?

Link to comment
Share on other sites

I found a more extreme "twist" which produces PE weight of 13168 for a linkset of 1 twisted torus, and two simple mesh objects (a box and a 6 sided prism).  Changing physics type to convex hull drops it to 42.  Unlinking the torus from the other meshes reduces the total to 5 - 4 for the two linked meshes and 1 for the torus.

If a twisted torus really applies thousands of times the load to the physics engine as regular prims, then something is wrong with the physics engine.  In any case, even with the convex hull physics type, mixing some types of prims and meshes leads to costs so high that nobody will use them.  Similarly a small palm tree of 900 triangles could be done as one sculpt, or as a mesh which costs 11 prims.  Again, nobody will use it at that cost ratio.

Someone else pointed out that the variable prim equivalent allows a new type of griefer exploit.  Include a script in an object which changes one of the prims from box to twisted torus on a time delay, then leave it someplace.  When the object changes, *boom* stuff gets returned.  Griefer is long gone at that point.

Link to comment
Share on other sites

  • Lindens

I'm going to be reviewing the algorithms for computing these costs over the next couple weeks.

A twisted torus has a lot of concavities, and a high triangle density. The fact that it costs more to compute in the physics engine is a fact of how complex it is to compute things physically. The higher the triangle density and the more concavities an object has, the more calculations need to take place when it collides with something. A box on the other hand is exceedingly simple to calculate a collision point for. That's not a bug in the physics engine. Whether it is really 13,000 times more expensive is something we'll be investigating to see if the algorithms are accurate or need more tweaking for the more extreme cases.

With this system we're trying to be more honest and up front about where our systems experience load that can cause lag. This is information we've hidden from and abstracted behind the primitive model of limiting things (if a simple prim costs the same as a very very complex prim, our accounting model doesn't map to our resource usage well). Of course we can't change the old accounting model for legacy content without risking breaking a lot of content, but that doesn't mean that we need to continue a poor model of accounting for new things like mesh.

Link to comment
Share on other sites

When you do your review, please consider a few things that I don't think went into the original calculations:

- The original formula was based on a target number of triangles in a full region. Many users have slower graphics cards (even Intel integrated), and so do not see a full region.  They have to use a low draw distance to get a playable speed.

- I don't think occlusion was factored into the formula.  Some objects will likely be occluded by other objects or the terrain, reducing the number of objects to be downloaded and drawn.  Larger objects, and especially ones you go inside tend to occlude more, so should not be penalized as heavily for size as they are now.

- Aside from basing a formula on technical performance, some consideration should be given to the *business* benefits of mesh.  A better looking world, or one where you can do more with a small land parcel, should attract and hold more people. If mesh is costed such that very few people use it, you lose the business benefit.

- Moore's Law (the continuing improvement in computers).  Both servers and PCs at home should continue to get faster each year.  Mesh will not displace 100% of grid content in a day, that will take years.  So the target cost formula should consider that by the time mesh is widespread, computers in general will be faster than they are now.

- A cost formula which is difficult to understand, which the current one is, and can accidentally return objects by exceeding the parcel limit when you link, resize, or change parameters, does not encourage it's use.

Link to comment
Share on other sites

Please forgive the possibly forceful tone of the following. It is because I think there are real dangers here. I hope it can be accepted in the constructive vien in which it is intended.

"Of course we can't change the old accounting model for legacy content without risking breaking a lot of content, but that doesn't mean that we need to continue a poor model of accounting for new things like mesh. "

I think this statement is disputable on semantic grounds, although that isn't really the point. The real risks are. It's not the accounting of the new thing, mesh, we are concerned with, it's the accounting of the legacy thing, standard prims, we are concerned with, when we see them drasctically increased just by linking them to a mesh.

People are used to linking objects together and seeing the cost the same as the sum of the parts. Now you are proposing to make the cost of their legacy objects increase by up to hundreds of times simply by linking a mesh to them. It is not only builders who link things. When peoples' houses disappear because they link in, say, a new lamp, that they didn't even know was mesh, they are going to perceive that as breaking their existing content. Many will not know that they have to go to a sandbox before they can rez thec returned object and unlink it. Some may never be able to rez it again because the cost has gone over a sim capacity. This is potentially going to make mesh be seen as the scourge of the grid, get it banned from estates etc. Also, the griefing potential is enormous.

I can't imagine how you would try to warn people. Maybe a message of the day, "Wellcome to Mesh. WARNING don't link any mesh objects to your existing content. It could blow it away." That would make a great launch.

The motivation to make prim equivalent cost more representative of real resource consumption is highly commendable and sensible. Applying selectively to mesh, not just on its own but to anything it gets linked to, can only damage the improvements that should accrue from mesh. Furthermore, it makes no sense to penalise burden static mesh with this relative disadvantage while doing nothing to control the already excessive resource consumption of attachments**. It will not protect performance. It will instead prevent the use of mesh which could have improved it.

At the very least, please consider disallowing "Prim" type fpr standard prims and sculpties linked to mesh; make them automatically become "Convex Hull"*.  This will not remove the problem entirely because the CH PEwts can still be substantially higher than one prim, but it will mitigate the most horrifying cases. Sculpties already have a convex hull shape anyway, and those standard prims which it used to be useful to make physics shapes from (undistorted box, cylinder, sphere) are already their own convex hulls. This would compromise any linkset that depended on concavity for function, such as sitting on it without a sit target, but that might be the lesser of two eveils, easily undone when a mesh is (perhaps inadvertantly) linked in.

*this already happens when the prim size gets small enough, so it's not too radical a proposition.

**physcics costs, which are the major worry, don;t apply to attachments, but the render and streaming costs still do.

 

Link to comment
Share on other sites


DanielRavenNest Noe wrote:

When you do your review, please consider a few things that I don't think went into the original calculations:

- The original formula was based on a target number of triangles in a full region. Many users have slower graphics cards (even Intel integrated), and so do not see a full region.  They have to use a low draw distance to get a playable speed.

- I don't think occlusion was factored into the formula.  Some objects will likely be occluded by other objects or the terrain, reducing the number of objects to be downloaded and drawn.  Larger objects, and especially ones you go inside tend to occlude more, so should not be penalized as heavily for size as they are now.

- Aside from basing a formula on technical performance, some consideration should be given to the *business* benefits of mesh.  A better looking world, or one where you can do more with a small land parcel, should attract and hold more people. If mesh is costed such that very few people use it, you lose the business benefit.

- Moore's Law (the continuing improvement in computers).  Both servers and PCs at home should continue to get faster each year.  Mesh will not displace 100% of grid content in a day, that will take years.  So the target cost formula should consider that by the time mesh is widespread, computers in general will be faster than they are now.

- A cost formula which is difficult to understand, which the current one is, and can accidentally return objects by exceeding the parcel limit when you link, resize, or change parameters, does not encourage it's use.

Whether or not this was the intent, everything here goes on to suggest that, as with anything else to do with technology, it's best to target the lowest common denominator.  Designers should strive to do the most with the least whenver possible.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4658 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
 Share

×
×
  • Create New...