When you think it can't get any worse...

[Miriel Enfield]

---

DanielRavenNest Noe wrote:

---

Also the 250K triangle budget is based on a region full of mesh objects. A PC on the low setting has a draw distance of 64m, and can only actually see 20% of a region at a time.  The combined effect of these penalties ensures that parcel costs of mesh range from high to absurd relative to sculpts.

---

Agreed. And I know I've hammered on this before (even if I did mess my math up a bit in the other thread), but penalizing meshes compared to sculpts isn't doing anyone on an older computer any favors. If you make it cheaper to use sculpts instead of more efficient meshes, you'll get more sculpts instead of meshes.

[arton Rotaru]

I have sent you an e-mail with just the physically more complex parts (Hi LODs and their physics meshes).

I have the boat now down to a physically Physics Weight of 84. Same as it's PE. Though, if I double the scale of the boat (~32m hull length), I have a PE of 121, PW 14.4. Setting it physical, PW = 276.4

Edit: I have sent you the updated version, too. Btw. It's scripted already, so you can ride it.

 

[DanielRavenNest Noe]

Mesh doesn't have to be equal to sculpts in cost.  It does have better features - eaier modeling, higher maximum detail, custom UV maps on up to 8 surfaces, custom physics shape, and ability to rig to avatars to wear.  But it does need to be in a reasonable range compared to sculpts.  By that I mean perhaps twice the cost in ordinary cases, going up to maybe 4 times higher for extreme cases.  Not ten or a hundred times higher.

Meanwhile, for clothes, meshes can be more complex than sculpts per linked item, so it is quite possible to have higher total triangle count.

[Constance Flux]

"Mesh doesn't have to be equal to sculpts in cost "     Agreed

"But it does need to be in a reasonable range compared to sculpts. "   Agreed

Unfortunatley, large objects like castles, large houses, giant rocks, waterfalls, large trees etc will not have the benefit of mesh as the PE for these objects is far too high. It can often be 100 to 1 compared to sculpties. So what would be a 3 prim  giant waterfall as a sculpty could be 300 prims as mesh.

I do hope that we see more reasonable PE for large objects very soon so that all areas see the benefit of mesh

[Falcon Linden]

Hey Arton,

I haven't had a chance to look at the .dae files you sent yet, but I did have a look at the boat in world. The most important thing I noticed is that there are a number of pieces for which you are using a convex decomposition when you could simply replace them with boxes for 1/4 the cost (0.1 vs 0.4 prims) with little to no loss of fidelity. I'm not sure what effect this would have on server weight, though, as the the total number of prims would be higher. Also, although you can only sit on one part of the tower, you have physics bits for each level. You might consider removing some of these extra parts (i.e., setting them to no physics).

I hope that helps. I'll try to look at the .dae files when I can.

Falcon

[arton Rotaru]

You mean just uploading a box as physics shape, without decomposing it (Analyze) results in a PW of 0.1 instead of 0.4? Haven't tried that yet, I believe, because the physics weight was pretty low so far :matte-motes-wink-tongue:. The platforms on the tower, yes, I could set 2 of those to none, but think about, it is possible to stand on each of those. Personally I don't like that the tower itself is physics type none already. :matte-motes-big-grin: 

I'm now at a PE of 82 and a physical PW of 82.3. So at that particular size of the object, I will probably get a lower physics weight than PE when the boat has all it's missing parts. But if you scale this thing a bit up, physics weight skyrockets compared to PE.

But thanks for the hint, I'll try uploading box shapes without decomposing them. Since every 0.1 value counts massively when it's physical.

 Edit: Ah wait, you mean regular prim cubes as physics shapes, and set the meshes to none. Arrrgh, I hate doing this, since we can create a collision shape with the mesh asset. From a residents point of view, any prim you add which is not necessary, is a prim to much. But if this helps bringing a high PW count down, it's an option, yup.

[Drongle McMahon]

I am sure Falcon means linking the boxes after upload. Unfortnately this way of making physics shapes is severely compromised by the minimum 0.5 PE per prim in a linkset. That overrides the 0.1 it is in the physics cost equation. I did a jira about this a long time ago (CTS-563).

[Falcon Linden]

Hey Arton/Drongle,

That is not correct. There is no minimum PE per prim in a linkset. This is because not all prims will affect all weights (e.g., no physics prims will not affect physics weight) and because only the highest of the three weights is used to determine the PE. 

I took your boat in world and replaced the 4 convex hulls in the tower with 4 boxes. If you go to Develop | Show Info | Show Render Info, you will get a text overlay on the bottom right of your screen. Near the bottom of the overlay is the streaming or network cost for the linkset. Call that 'NW'.

Let's call your boat A and my boat with 4 boxes B.

Boat A, Non-Physical: PW = 14.4, NW = 84.5 --> PE = 84  ( NW is probably more like 84.499 and getting rounded to 84 on the server but 84.5 on the viewer)

Boat A, Physical: PW = 84.0, NW = 84.5 --> PE = 84 (same as above)

 

Boat B, Non-Physical: PW = 13.3, NW = 84.7 --> PE = 85

Boat B, Physical: PW = 77.8, NW = 84.7 --> PE = 85

 

In other words, whether you add the boxes or not, you're streaming cost bound, not physics or server cost bound. Adding the 4 boxes added a total of ~0.2 to the streaming cost which, in your case, just bumped up the PE by 1. Adding another 4 boxes (just as a test) only increases your NW to 85.2, which still leaves your final PE at 85.

Of course, in this specific case, the only incentive for switching to boxes is slightly improved physics performance. For vehicles, though, this can still really matter at the end of the day.

Falcon

 

[Drongle McMahon]

You are right, of course, for meshes with huge streaming costs, like Arton's boat. It's the server costs of physics prims that make them uneconomical for less complex meshes. So, for a very simple  example, my bench now has a streaming cost of 0.2, and with it's own physics shape, two boxes decomposed, has a PE of 2 (3 with a script). If instead I link the same two boxes to make the physics shape, it ends up with a PE of 3 (5 with a script). So this is one example where that method is ruled out. The physics cost is 0.9 without the linked boxes and 0.2 with them and the mesh set to "None", so it's a lost opportunity. I have come across several other cases where the physics-by-prim was the best method before the server cost was introduced (it wasn't called that then; it just crept in unannounced), but became unaffordable after it was introduced. I thought "severely compromised" was suitable for a 50% PE increase, but if you like I will temper that down to just "compromised".

ETA: another example, in case you think I'm making this up. My wooden staircase is PE 2 (good LOD) or 9 (bad LOD). Its physics shape is 15 flat planes, physics weight is 1.1 (triangle-based) or 3.0 (decomposed). Before server weight, that could be 1.5 for 15 prim boxes, small enough even for the good LOD version without increasing PE. With server weight, PE is 10 for either model with the linked box physics. That's increased even for the bad LOD version. It's increased five-fold for the good LOD version.

[arton Rotaru]

77.8 for physics sounds not that bad. Probably I use that method for some parts. :matte-motes-nerdy:

[Drongle McMahon]

"That is not correct. There is no minimum PE per prim in a linkset."

On further thought, surely that is incorrect.......

The server (simulator) weight is defined in the wiki as ...

 ----------------------------------------------------------------------------

1. Take a base cost per object
2. Add a cost per prim in object * number of prims <-------------------------------------------!!!?
3. Multiply by an "active" multiplier if object is dynamic (physical or scripted)

dynamic_multiplier = 2.0
static_multiplier = 1.0
per_prim_cost = 0.5  <----------------------------!!!?
base_cost = 1.0 

Cost scaler is currently 1.0

Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)

--------------------------------------------------------------------------------------------------------------------------------

(note mistake - "active_cost" in equation is called "dynamic_multiplier" in the listed variables)

So for n prims: Server weight(per prim) = 1*(1*(0.5+1/n), which can never be less than 0.5 (1.0 if dynamic)

The rule is that that the highest of server/physics/download weights become the PE, the PE can never be less than the server weight, and, as we see, that can never be less than 0.5 per prim. So the PE can never be less than 0.5 per prim.

Isn't that a minimum PE per prim? Have I missed something?

 

[Drongle McMahon]

Ah. Perhaps you meant that there is no minimum marginal PE per prim? (that is, increase of PE on adding a prim). I would agree with that because whenever max(download_weight, physics_weight) >> server_weight, adding a prim can have little or no effect on PE. I don't think that invalidates my statement that this method is compromised. In the case of boxes, it is.

Going even further, we can define the conditions when using the simple (undistorted sphere, cylinder, box) prims for physics shape will not increase the PE. If we need n such prims, then as long as max(download_weight, physics weight) >= ( 1 + n/2 ), we will not increase PE. That is, n <= 2(max(p,d)-1). (I won't start on dynamic objects because the dynamic penalty is too complicated.)

Where download weight is the highest, that's all, but when the physics weight is greater, we can say a bit more. The physics cost of a decomposed box shape is 0.36. That is always less than the 0.5 server cost per box for a prim used as a physics shape*. So for a physics shape made of boxes, the physics shape made with decomposed boxes will always be cheaper than the same shape made with linked prims. (Before the server cost, the linked prims cost only thie physics weight, 0.1, and were cheaper). Triangle based shapes can cost more or less than the decomposed shapes, depending on dimensions. They can certainly be less than the prim physics alternative for objects more than a couple of meters in size.

Cylinder and sphere shapes are a completely different matter. A decomposed six-sided cylinder already costs more (0.52) than the server cost for a linked physics shape prim (0.5). Spheres are even more expensive. So if you need these shapes, you will do better with the linked prim than the decomposed shape. The difference becomes very large if you want accurately rounded shapes with many vertices. Even if your physics weight isn't limiting, presumably this will minimise the load on the physics engine.

All this means that if your PE is determined by the physics weight, you can minimise that by making the physics shape by using a combination of decomposed box shapes and linked spheres and cylinders. Don't ever stretch the circular sections of the cylinders or spheres unequally though, or distort them in any other way.

*this depends on the current values of the relevant constants in the wiki, which may change. Currently CH physics weight = 0.04*(1+v) for v vertices.


[Drongle McMahon]

Oh. It's not just the server weight compromises simple prim physics shapes. I was forgetting effect of the the new feature of download weight (aka streaming cost), whereby prims linked to meshes are given mesh-like download weights.

So, I was just trying out a linked sphere used as a physics shape for a mesh with physics shape type None. The mesh had a download weight of 4.2, but was downloaded without a physics shape. On its own that means it has to be physics shape type Convex Hull. As the default convex hull (the medium LOD) has many vertices, it has physics cost of 15, and so the PE is 15. Then I added a sphere to make the physics shape, linked it to the mesh and set the mesh physics shape type to None. As expected, the physics weight of the linkset went down to 0.1, but instead of the PE going down to 5, the rounded sum of the combined download weights of the mesh and the sphere, it was 7. That's because linking the sphere to the mesh had increased its download weight to 2.3. Using the reasonably sphere like low LOD for a decomposed physics shape gave a physics weight of 3.7, and thus a PE of just 4. So in this case, the simple prim physics shape method is compromised by the application of mesh-like weights to prims linked to meshes. Bofore either that or the server weights  were introduced, adding the sphere would have added just 0.1, leaving the rounded PE at 4. With just server weight, it would have gone up only to 5.