Physics Costs v Server Costs For Simple Shapes

[Ciaran Laval]

If I rez a standard cube inworld, the physics and download cost is 0.1 and the server cost 0.5.

If I upload a mesh cube and use that cube as the physics shape, the download cost is 0.1, physics 0.4, server 0.5.

Now if I link a standard cube to the mesh cube and make it invisible, then set the mesh cube to physics shape none, I can get the physics cost back down to 0.1 but obviously the server cost now increases to 1.0.

First thing this suggests is that it's probably better to use inworld prims for simple shapes, but if I really want to use mesh, is the server cost or the physics cost the better one to optimise?

[Rahkis Andel]

Knowing someone more knowledgable than me will probably step in and elaborate or correct me, here is my opinion:

If the shape is really so simple that a prim will suffice, I see no reason for the extra overhead of uploading mesh. It's the same thing for physics shapes, if not moreso (I believe the physics system is optimized to use the prim cube). If a cube is all you need, use a cube.

For the sake of  using one thing over another, Mesh is more an alternative to dealing with sculpties than it is to prims. Also, if you need something with a lot of variance in it's topography, a triangle based mesh physics object will be usually be preferable.

Edit: To directly answer the question, focus on optimizing the physics cost. That will have the largest effect on all parties involved.

[Drongle McMahon]

"First thing this suggests is that it's probably better to use inworld prims for simple shapes"

There are a restricted set of "simple" shapes that correspond to the primitives in the physics engine. They are (1) any box that has no distortions other than stretching along the three axes, (2) a perfect sphere, with exactly the same stretch on all three axes, (3) a cylinder with a perfectly circular cross section and no distortions. These are recognised by the system and scored as 0.1 physics weight. Make the slightes distortion, and their weights will jump (if connected to mesh). So as long as you stick to these restrictions, you can make very cheap physics shapes this way. This is specially good for spheres and cylinders which are otherwise quite expensive, even as convex hulls, because of their curved convex surfaces. However, there are two risks. First, they can get unlinked. Second, they can get stretched (with edit-linked) so that they don;t satisfy the rules any more and the weight jumps. So for items with mod permissions, they are not very safe.

"I really want to use mesh, is the server cost or the physics cost the better one to optimise?"

It sounds silly, but whichever is the higher. Otherwise your optimisation has no effect on LI. However, server weight is only an issue for the very simplest shapes. Physics weights are more often higher than download weight, and therefore the cause of high LI, than people realise. This is especially the case with small curved objects.

[Ciaran Laval]

Thanks for the reply. Simple shapes are good for getting your head around how mesh works so it's nice to work with them but I do tend to agree that if a basic prim will suffice, then it's probably the better tool, especially now that Drongle has pointed out the perils of editing linked parts.

[Ciaran Laval]

Thanks for the reply, good points to ponder here, especially with regard to issues such as editing linked objects. Thinking that others might want to mod Mesh items puts a different slant on a lot of areas regarding Mesh building, whereas building for yourself allows more versatility as you'll know the limitations as you built it yourself with those limitations in place.

Plenty to ponder, thanks a lot.

[Codewarrior Congrejo]

in addition - here the 'official' answer from the wiki:

Why does a mesh cube have a land impact of x when a prim cube is one?

Prim count was not a realistic weight of the objects' resource usage and how they affect performance. However, we are not changing their contribution to resource costs on legacy objects in order to maintain existing content.

Drongle already mentioned it prims are allways being weighted with these values.
This here explains the 'why' they are counted differently. Means unfortunately we can't really rely on these values and compare them with mesh imports.

PS: same goes for the displayed weights of sculpties. They also keep these values in order to preserve existing content.

[Rahkis Andel]

---

Drongle McMahon wrote:

However, there are two risks. First, they can get unlinked. Second, they can get stretched (with edit-linked) so that they don;t satisfy the rules any more and the weight jumps. So for items with mod permissions, they are not very safe.

---

That's rather disconcerting. I wouldn't have thought of that.

 

This sounds like a case of "buyer beware". A lot of content creators could be inadvertantly selling at one LI and as soon as you edit it in a certain way, boom.

[Codewarrior Congrejo]

.. should just add a notecard saying: "editing objects in this package at own risk for the amount of landimpact  - we offer no guarantee !"  ; )

[Ciaran Laval]

Thanks for the Wiki quote, 0.4 physics weight isn't too heavy, I may just build for myself and then worry about building for others, I keep holding myself up by finding little issues that put me off but I really just need to get on with it and then take it from there,

Obviously I don't want to cause chaos by being wasteful with resources!

[Kwakkelde Kwak]

---

Ciaran Laval wrote:

Obviously I don't want to cause chaos by being wasteful with resources!

---

In that case, you might want to forget on focussing on the highest weight. You might also want to forget about prims altogether. There's more to the weights than just the landimpact.

A simple prim box in SL has 108 triangular faces (on the highest LoD), since it has 3x3 squares on all 6 sides. A box shouldn't have more than 6 squares (12 faces), one on each side. This is unless you want to divide one side into multiple textures, but then a prim won't work either. 108 faces might not sound like a lot, but it's almost 10 times more than needed. If you use a lot of boxes on a sim, let's say 5000, you can understand all the useless faces taking up rendertime, causing viewer side lag. The 12 : 108 faces (11%) could even be lower if you remove faces inside walls, on the bottom of objects, anywhere you do not see them. In all cases I encountered, the mesh object was superior in all weights over prims, often by a factor 10 or more.

I would only use prims in situations where you need the extrusion or other mods not available for mesh. Something like a scripted bottle that you can fill or empty by changing the height of extrusion or taking a piece out of a pie by setting the cut to a certain amount is not possible with mesh objects.

One other thing, regarding the physics cost.

Like the visible geometry, the rule should be "if you don't need it, don't use it". So small objects which won't be used for collisions can be set to "None" for a physics shape. This will result in a physics weight of zero because the object will be excluded in the physics calculation by the server (for that particular object in the linkset). It can't be used for the root prim and there's a small risk, since people might unlink (making the linked object a root) or fiddle with the physics settings after buying them.

 

[Rahkis Andel]

---

Kwakkelde Kwak wrote:

---

Ciaran Laval wrote:

Obviously I don't want to cause chaos by being wasteful with resources!

---

A simple prim box in SL has 108 triangular faces (on the highest LoD),

 

---

Well...That's surprising.

I will alter my advice above to the following:

 

The rule of thumb here should be "moderation":

Clearly the basic SL prim square is unforgivably dense for it's purposes as a visible object, so stick to mesh for everything except physics shapes.

If you need a simple physics shape, choose the simplest prim object that suits the shape you need. If you need a complex one, use a mesh physics shape that is as optimal as possible while still retaining enough shape to satisfy it's purpose.

[Kwakkelde Kwak]

---

Rahkis Andel wrote:

Clearly the basic SL prim square is unforgivably dense for it's purposes as a visible object, so stick to mesh for everything except physics shapes.

If you need a simple physics shape, choose the simplest prim object that suits the shape you need. If you need a complex one, use a mesh physics shape that is as optimal as possible while still retaining enough shape to satisfy it's purpose.

---

I would even advice to use mesh for pretty much all simple physics shapes. I'm not 100% sure how the physics engine calculates a prim's shape, but I can't imagine a prim box is easier on the engine than one or two planes . A ground floor can be two triangles. Depending on its thickness, other floors can be either two or four triangles. Just make sure you don't analyze on upload, the resulting convex hull won't be usable for rezzing objects on, at least as far as I've experienced.

Adding a prim as physical shape means it is there, simple as that. That means the viewer will have to render it, even if it's invisible. I do remember reading something about a change in the rendering process where objects set to 100% alpha won't be rendered, but I don't know if it is implemented yet or will be implemented at all. Also, adding a seperate physical object means you'll run into issues when scaling your objects.

[Ciaran Laval]

---

Kwakkelde Kwak wrote:

I would even advice to use mesh for pretty much all simple physics shapes. I'm not 100% sure how the physics engine calculates a prim's shape, but I can't imagine a prim box is easier on the engine than one or two planes . A ground floor can be two triangles. Depending on its thickness, other floors can be either two or four triangles. Just make sure you don't analyze on upload, the resulting convex hull won't be usable for rezzing objects on, at least as far as I've experienced.

---

Apparently Havok loves cubes:

http://wiki.secondlife.com/wiki/Mesh_and_LOD#Havok_Physics_tips_and_oversimplifications

[Ciaran Laval]

---

Kwakkelde Kwak wrote:

A simple prim box in SL has 108 triangular faces (on the highest LoD), since it has 3x3 squares on all 6 sides. A box shouldn't have more than 6 squares (12 faces), one on each side. This is unless you want to divide one side into multiple textures, but then a prim won't work either. 108 faces might not sound like a lot, but it's almost 10 times more than needed. If you use a lot of boxes on a sim, let's say 5000, you can understand all the useless faces taking up rendertime, causing viewer side lag. The 12 : 108 faces (11%) could even be lower if you remove faces inside walls, on the bottom of objects, anywhere you do not see them. In all cases I encountered, the mesh object was superior in all weights over prims, often by a factor 10 or more.

 

---

The reason I was using Mesh was to try and avoid having faces that wouldn't show, so inside edges aren't required when another prim will be against them, but in terms of checking resources, it doesn't seem to make much difference when I make comparisons.

 

 

[Drongle McMahon]

"Apparently Havok loves cubes"

Yes, but the problem is that it only recognizes them when you link them as prims to make the physics shape. If you make a physics mesh that is a perfect cube (or cylinder or sphere), whether analyzed or not, it doesn't recognize it and doesn't make the saving engine resource and physics weight that it could. So only the linked prim method can get you those efficiencies.

[Codewarrior Congrejo]

The reason I was using Mesh was to try and avoid having faces that wouldn't show
good thinking : )

One more thing to keep in mind: luckily as in most 3D engines of this type, we do not have to actively render every single face. Things that appear outsides of our FOV (field of view) are being derendered, and will be updated once they reach your view again. Also several algorythms, including ray casts will try to determine which object is actually visible to you or possibly hidden behind other objects.

But the more optimized and reasonable mesh creators will build, the better for all of us. (Linden labs servers, as well as for users being in need to render way too many faces)

This being said: keep that mindset ! - because it's the right one =)

It should never be' looks' being prefered over  optimization. The look we can define heavily with textures and other procedures

Regarding the SL cube / primitives. There is a reason they have more faces then we would regularly add ourselves to a simple primitive shape. Hencing the fact they need to provide the ability  to be cut/ hollowed and much more. Most people forget this, when pointing fingers at the too dense appearing internal objects. 

[Kwakkelde Kwak]

---

Ciaran Laval wrote:

The reason I was using Mesh was to try and avoid having faces that wouldn't show, so inside edges aren't required when another prim will be against them, but in terms of checking resources, it doesn't seem to make much difference when I make comparisons.

---

The only fair comparison would be a sim full of the objects you are trying to compare. That is if you mean all real resources rather than the numbers SL shows you for the different weights. The weights are just an estimation, some common sense will probably do a far better job than the automated process.

About the other remark, the physics engine might like boxes, but linking a box to a mesh as physical shape sounds just plain clumsy to me.

Anyway, the simple fact you are thinking about all these things makes me believe you'll do a more responsible job than the average builder here in SL.

[Ciaran Laval]

---

Kwakkelde Kwak wrote:

 

Anyway, the simple fact you are thinking about all these things makes me believe you'll do a more responsible job than the average builder here in SL.

---

I've been playing with Mesh for ages, it's dithering and excuse making now on my part although I really do want to avoid getting into bad habits and it's good to be able to decide, that face really doesn't need to be included and that being my decision.

 

[Ciaran Laval]

---

Drongle McMahon wrote:

"Apparently Havok loves cubes"

Yes, but the problem is that it only recognizes them when you link them as prims to make the physics shape. If you make a physics mesh that is a perfect cube (or cylinder or sphere), whether analyzed or not, it doesn't recognize it and doesn't make the saving engine resource and physics weight that it could. So only the linked prim method can get you those efficiencies.

---

Now this is another confusing area, probably worthy of further discussion at some point. Do you mean it needs to include the system prim cube shape for this efficiency saving? I ask because the wiki states that convex hull is more expensive, yet when you change a mesh or prim to physics shape prim, the land impact score is likely to rise.

[Drongle McMahon]

What I  mean is that perfect boxes/spheres/cylinders weigh only 0.1 when they are used by linking in undistorted traditional prims (and setting the mesh to "None"). It doesn't matter whether their shape type is Prim or Convex Hull. If you provide an identical shape as a physics mesh, as part of the upload, it is not recognised as such and so you don't get the 0.1 weight, whichever shape type you use, and whether it is "Analyzed" or not. If it's a cylinder or sphere, the weight will be higher whether it's shape type is Prim or Convex hull.

[Ciaran Laval]

Ah thanks, yes understand where you're coming from with that reference.