Information about physics optimization - lag reduction and Mesh

[Davido Chrome 4]

I thought mesh can be used to effectively reduce physics induced lag by making vehicles with less collision surfaces and less individual objects to keep track of in a linkset while retaining the same amount of detail and that Mesh can be used to make less snaggy tracks and roads as well as vehicles that tax the simulators significantly less. But, this turns out to be wrong. For roads, simple primitive shapes are the best answer.

Physics Performance Cost in order of Cheapest first
Sphere
Capsule - (Not available as I type this. Possibly used by avatar collision boxes. Always used by pathfinding characters.)
Box
Triangle (A single triangle surface on an object)
Cylinder
Convex Hull (Basically the prim-shape with all holes closed and with no more than 256 vertices.)
Meshes (Which becomes a list of Triangles, I don't know how many surfaces you can add before it passes Cylinder and Convex Hull in cost, I suppose very few.)

The mesh upload Analyze functionality performs a "convex decomposition" resulting in a collection of convex hulls which approximate the overall shape of the mesh to the specified degree of accuracy.

 

Terrain and Mesh.

Mesh terrain that uses a minimum number of the largest viable triangles (i.e., a minimally triangulated terrain--maximizing the size of the triangles involved and minimizing the number) will generally be significantly more efficient than the default terrain. Terrain made out of boxes will also be highly efficient. In both cases, be sure to flatten out the linden terrain to ensure the physics engine doesn't end up testing against both your terrain and the default terrain.

Keep the terrain collision shapes simple! It doesn't have to be as complex as the visual representation. Havok is smart about mesh collisions: given a primitive shape A colliding with a mesh B, it typically only has to test for collisions between A and those triangles in B whose AABBs (axis-aligned bounding boxes) overlap with the AABB of A. This is why having a landscape with a moderate number triangles can still be very efficient so long as those triangles are fairly large and sparsely distributed (i.e., no areas where lots of little triangles are tightly packed). Accordingly, we compute the physics cost of a mesh largely based on the average size of the triangles in it. That's why shrinking a mesh makes the physics cost skyrocket: if any reasonably sized object collides with a small, dense mesh, it will likely overlap many of the mesh's triangles incurring very high computation times.

 

Vehicles and driving surfaces

Also, avoid using shapes with dimples, hollows, cuts, or any other kind of "hole" (i.e. avoid non-convex prims) on vehicles and avoid the most complex shapes like hollowed out prims and Tubes, Rings or Toruses for surfaces for vehicles. Replace toroidal wheels with cylinders (best option) or at least make them have physics shape type "Convex", etc, and keep the total number of colliding prims (prims with physics shape type other than "None") on the vehicle to a minimum. This will also reduce snagging and significantly improve performance. A simple invisible horizontal cylinder (with equal radii) placed in front of the vehicle would provide an optimal collision shield if one is still needed. (This also implies that a track with mesh turns with an optimized amount of surfaces will cause a lot less physics lag than a cut cylinder, although that is not the most effective way to go about it. The physics engine knows a prim cube when it sees it, thus using cubes is the best option. They can be stretched and resized but all gain is lost of you deform the prim in any other way. ANY other.)

However, having a too simplified shape makes the vehicle sink into prims. Ground vehicles keep track of several "average collision normals" where they hit the ground and build up a history of what that collision normal is at each point where the vehicle is colliding. If they hit a momentary normal that is totally out of agreement with their history they will discard it, but they start to modify their history to accept such disagreeing normals. The idea being to discard the momentary incorrect normals encountered at prim seams at roads. The more collisions you get the more data goes into recomputing the expected normals. So it makes sense that a "less cheap" vehicle that actually has more collision points will correct faster when encountering true ramps and obstacles (as opposed to bad normals at prim seams).

I like to double up the Convex Hulls in the wheels. The one slightly inside the other, this seems to give a nice balance between low physics load and enough collision data for the vehicle not to sink too much into ramps. Edit; These days I have found that Cylinders are actually the best option for wheels.

Troubleshooting, vehicles.

Q. Does changing the physics type only work for mesh objects? I tried changing the physics type for parts on an old Sculpted bike to none, and when I try to get on it get a Script error. "Script cannot enable physics -- physics resource cost greater than 32".

A. By changing the physics shape type from "prim" you are opting in to the land impact system introduced with mesh. The objects don't become mesh objects, their land impact is simply calculated that way. The fact that after changing some of the parts to shape "none" you still have a physics resource cost >32 lets you know that you have a lot more simplification to do before it will be efficient. Try setting as many prim as possible to "none" /and/ setting the wheels to convex hull.

[Davido Chrome 4]

I edited the post and fixed some outright wrongs...

Info is more reliable now.

For more in depth information check out This link.

[Davido Chrome 4]

Interesting findings. Simplest primitive on simplest primitive seems to make you sink into the road/ramp/whatever. However, if either or is made from mesh or a complex primitive, all is fine and dandy. Just as long as vehicle and road isn't both simplest primitive. This means that it should be best to make the roads from prims, and custom Physics shape for the vehicles.

[Kwakkelde Kwak 212]

---

Davido Chrome wrote:

This means that it should be best to make the roads from prims, [...]

---

Why is it best to make roads from prims? I'd say it's best to make roads out of mesh aswell. You can save in landimpact, upload fees and rendering cost.

[Davido Chrome 4]

Prim roads cause less lag as their shapes are mathematically defined. When an object meets a primitive the physics engine needs to make one calculation per collision, while a Mesh road causes the engine to make calculations for every face its physics shape has.

Interesting fact, I made an elevated turn from 21 prims. By adding an extra prim with physics shape none I make the linkset use the new Land impact system. The turn is still 21 prims, but it has a land impact of 11.

The same way I can make a 3-prim 64 meter straight with two prims for safety fence have a landimpact of 2 by adding a hidden prim with physics shape none. 4 Actual prims, land impact 2.

[Kwakkelde Kwak 212]

---

Davido Chrome wrote:

Prim roads cause less lag as their shapes are mathematically defined. When an object meets a primitive the physics engine needs to make one calculation per collision, while a Mesh road causes the engine to make calculations for every face its physics shape has.

---

So that means it's not the primitive being "better", but the less faces you collide with, that makes perfect sense. In other words, it is very possible to make a primitive road that's worse than a mesh one.

EDIT misread your comment about one calculation per prim and one calculation per mesh face, that should make a difference then  indeed, unless the calculation of the mesh is a lot easier, which could be the case... But if this one calculation per primitive is true, why is a mesh vehicle better? The vehicle will have a lot more faces than the road....

---

Davido Chrome wrote:

Interesting fact, I made an elevated turn from 21 prims. By adding an extra prim with physics shape none I make the linkset use the new Land impact system. The turn is still 21 prims, but it has a land impact of 11.

The same way I can make a 3-prim 64 meter straight with two prims for safety fence have a landimpact of 2 by adding a hidden prim with physics shape none. 4 Actual prims, land impact 2.

---

Yes primitive boxes have a landimpact of 0.5, because of their server weight. This also means you can get a better result with mesh probably. You can make a mesh version of your 4 primitives road and I bet it will have a landimpact of 1 not 2. It will not have more faces to collide with either.

EDIT btw you don't have to add that extra prim with "none" to let the object use the new land impact system,setting the physics of your boxes to "convex hull" will work aswell.

[Davido Chrome 4]

I am not sure which is best just yet. Primitives keeps the lag low. If all you want is low land impact go for Mesh.

The fact that Primitive on Prim doesn't work well seems to have to do with how primitives are calculated, rather than it being less efficient. Thus, best should be to use Mesh for one and primitives for the other. I suggest roads should be prims as you often want vehicles to have more custom options for the shape to control how they interact with the terrain.

Making the boxes use the convex Hull option for a road would be a bad idea, as the collision shape then would be an obblong sphere and not fit the visual representation of the box. And, according to the document I link to boxes are much more efficient than Convex hulls. And making a road from Oblong spheres would result in a rather hard road to drive on... For off road terrain though, that's a whole different ballgame.

I was at What Surf and Simboard the other day, they have new waves there that seem to be made of a whole bunch of convex hulls bunched together. And they are REAL nice to ride, believe it or not.

[Drongle McMahon 589]

"Making the boxes use the convex Hull option for a road would be a bad idea, as the collision shape then would be an obblong sphere and not fit the visual representation of the box"

But the convex hull of a box is the same box. (you used to be able to see this with Develop->Render Metadata->Physics shapes, but that seems to be broken in new releases).

You can see the effect of the havok box primitive being used if you use the More Info link in the edit floater to look at the physics weight of a prim box. As long as the box is only stretched, its physics weight will be 0.1, whether it is type Prim or type Convex Hull. This is the weight for the havok primitives as described in the wiki.

If you add just 0.05 X taper*, the physics weight jumps to 0.4*, although there are still the same number of triangles and the same number of points in the convex hull. That is because it is no longer a perfect box and therefore cannot be represented by the havok primitive box. add any other distortion (eg taper), the weight will jump to 0.4. For type Convex Hull, this is rounded up from the 0.36 from the wiki calculation.Why the Prim type also gives 0.4, I don't know.

If you start adding more distortions, especially twist, the weight will go higher, very high and inversel;y related to size for Prim shape type, size independent for Convex Hull, as expected.

Now if you do the same thing with a simple 12 triangle mesh cube using the same cube as physics shape, the physics weight will be 0.4, even though it is a perfect cube. This shows that the mesh is not recognised as being the right shape for using the havok primitive. Thus a mesh road, even if the physics shape is a perfect box, will not take advantage of the extra efficiency available from using the havok primitive.

A 3x3x3 sphere is more interesting. Once again, the undistorted sphere has physics weight 0.1, as prim or convex hull, because it uses the havok primitive sphere. Now add 5% hollow (which you can't even see!). If the physics shape type is Convex Hull, it jumps to 1,2. If it's Prim, the weight jumps to 86.1! That illustrates how bad the small triangles in the small hollow are, as far as Havok is concerned.

*actually, at 0.5x0.5x0.5, it seems still to use the primitive with that taper value. You need 0.1 for the jump. At 1x1x1, 0.05 taper is enough. Not sure why that is. There must be some sort of to;erance for fitting the havok primitivem I guess. Similar scale dependemt threshold effects are seen with cylinders and spheres.

[Davido Chrome 4]

Seems like I was wrong about Convex boxes, but prims should be more efficient.

Now, I can't seem to get how to make a vehicle that don't sinks into every prim that is at a slight angle from it's trajectory... Getting its physics cost down to 0.4 doesn't help...

There seems to be something wrong with both the info I have gathered and the way the server calculates Physics cost...

[Davido Chrome 4]

I have learned that keeping th physics cost too low means you are giving the engine too few collision events to work with. The win of having an extremely low lag vehicle is negated by that it becomes unusable. It seems that you want to keep the physics  cost at minimum above 10, if not more.

I will update the main post with the in depth explanation I got from andrew at the last user group when I have the energy.

[Davido Chrome 4]

There, post updated.

[Davido Chrome 4]

And updated and fine tuned again.