Drongle McMahon is into mesh and does lots of experimenting. When I see his posts in the SL Forum I usually check them out to see what he has to say. I learn a bunch. The more I learn the more I cut from the cost of my mesh objects. So, while this article may get geeky it can save you Lindens.
Recently he has been seeing oddities in the physics model’s cost affect on items using prim type physics, which you may need to use for some objects like walls with doors. There is a thread titled: Triangle physics weight – Cautionary tales, episode 2.
His post points out some problems with physics models and how one of his went from a Land Impact (LI) of 7,671 to 0.5… why is worth knowing and understanding.
The Problem
It seems that physics shapes that use vertices outside a vertical or horizontal plane by tiny amounts will drive the LI cost up. In this case it appears to be Blender math round off errors on the order of 0.0000002 meters or Blender Units.
Drongle did the experiment using the shape shown in Aquila Kytori’s image shown above. He needed a cheap physics model to control collision for a wall with a door.
Testing was done to determine if it was just the small fractions or distorted surfaces that drove the LI cost up. As best we can tell it is the small fractions.
I think this would suggest that physics shape models should be built with snapping to the Blender grid enabled.
Order
In another part of the testing Drongle and Aquila tried changing the order of the polygons. That changed the LI cost of the model from 22k, 9k, 1.8, and 0.5.
Take Away
So, if you find a physics model with an outrageous LI cost, it may not be a problem with how you made the model. It may be a problem in SL Mesh Import of the Collada file. So, check that the vertices’ coordinates use values with a minimum of digits and possibly try changing the order of the polygons.
The troubling part of this discovery is the change from 1.8 LI to 0.5 LI. Many of those modeling will not suspect a problem with this small an error. Obviously a 22,000 LI is going to be an apparent problem and get fixed. But, small problem models will be making it into SL. Since this affects the Physics cost this has some impact on server side lag.
Drongle’s testing did not reveal a consistent pattern of what triggers the high physics cost. Nor does Blender allow us to easily control the vertex order. But, the vertex and polygon order are having an effect on LI cost. So, we are on a trial and error basis.
If we have an object who’s LI cost is controlled by Physics, we need to consider these possibilities and get into editing the model in Blender or the Collada file. Or at least considering how we are building our physics models.
Reproduce the Problem
For any problem to be fixed it has to be possible to reproduce the problem. Drongle has explained how to do that in JIRA (BUG-1081 – which is probably hidden from most JIRA users.)
These effects have been observed with well in excess of 100 example physics meshes. Two examples are provided here. In each case, the collada files described should be uploaded with default LODs, selecting the high LOD for the physics mesh and uploading without decomposition to achieve the specified triangle-based physics shapes. On rezzing, the triangle-based shape should be selected by switching to physics shape type Prim. The geometries can be compare by viewing in wireframe and/or physics shape view. The physics weights should be compared by using the More Info link in the edit floater. Note that some files may contain UV maps while others do not. In many explicit tests, no case was found where the presence or absence of a UV map affected the physics weight. The normals in Example 1 are odd, causing strange shading, but the normals have no effect on the weights.
Example 1. Cylinders with sixteen segments. The geometries of these cylinders are identical. The only differences in the collada files is in the ordering of the triangles in the <polylist> tag. There are four sets of four files. Within each set, the first triangle in the list is the same and the order of the remainder is randomized (R random number generator). The first three sets (A to C) have different first-listed triangles. The fourth (D) has the same first-listed triangle as the third (C), but with the order of vertices circularly permuted. The actual geometries produced are all identical, and all the triangles are the same shape and size. Files are named as Xnabc.dae where X is the set, n is a serial number ans abc is the vertex order (in the sense of the order they appear in the <source> tag specifying positions). Aa231.dae, Ab231.dae, Ac231.dae, Ad231.dae; Ba132.dae, Bb132.dae, Bc132.dae, Bd132.dae; Ca231.dae, Cb231.dae, Cc231.dae, Cd231.dae; Da123.dae, Db123.dae, Dc123.dae, Dd123.dae.
This set of cylinders does not include the extreme of high weights having this geometry. That can obtained by rotating the cylinder so that the first triangle is perpendicular to the X axis (to within the accuracy of the internal 16-bit data format). This is the file RotZ11p25.dae.
Example 2. Cubes with two subdivisions , with an isolated triangle that is first in the <polylist> . These differ only by the spatial orientation of the triangle. It is oriented perpendicular to X (Xperp), Y (Yperp), or Z (Zperp) axes. the suffix Rot (XperpRot) indicates rotation of the triangle in Xperp through 180 degrees around the Z axis. Xperp.dae, Yperp.dae, Zperp.dae, XperpRot.dae.
How to Check a File
So, then there is the problem of how to fix the problem.
One step is to file a JIRA BUG report and refer to Drongle’s thread and BUG-1081 – First listed triangle orientation has large effects on triangle-based physics weights. It will help if you have example Collada files to include with your report. Since we cannot WATCH JIRA items, we cannot show our interest in a fix. Our only option is to file a BUG report.
In building practices, turn on Snap to Grid (called Increment in Blender), read Precision work in Blender, and The Blender Forum: How Do I Snap to Grid. Pressing Shift+Tab toggles snapping on and off. Shift-C temporarily toggles snapping. Remember. If Snap is on, Shift-C toggles it off and vice-versa. You can set the grid ‘increments’ in the Numbers panel under Display.
I have problems with snap not providing me vertices at even coordinates. I end up using the Transform fields in the Number panel to correct the problem. I think it is a bug in Blender.
Hopefully paying attention to the coordinates of vertices in physics model will help avoid the problem.
If you look in the Collada file you will notice the images and printouts used in the thread are misleading as to what the file actually looks like. They have arranged data to make their discussion easy. The file looks like my image taken from a file comparison program named Compare & Merge.
So, we need to understand the file format to know what to change. You can get an explanation of how the file is laid out in this tutorial: Step by Step Skeletal Animation in C++ and OpenGL, Using COLLADA.
Don’t freak out. To understand the file you won’t need to understand C++ or OpenGL or deal with skeletons or animations. Scroll down to Reading Geometry Data. This tutorial is teaching programs how to read the file so they can write programs to read and use the file. It is very detailed.
The file is a text file. Its layout is XML like. You can edit with any pain text editor.
Personally I find it easier to change vertex coordinates in Blender. But, if you find you need to change the polygon order, you may have to edit the Collada file.
Is it my imagination, or did this sort of thing not happen/get fixed when they still had Qarl.
Im a bit confused. When the LI is bigger? When the mesh and physic shape are in the same position? In the examples, the orange mesh is supossed to be the normal mesh while the transparent one is the physic shape right?
I rarely need to use the same original mesh for physical purposes. Since physic meshs have collision in both sides, isnt too hard to make walls with double side mesh but just one side of physic shape. And in most of case you dont need even make holes for windows so also helps to save LI.
Also, I know that normals affects the LI of a mesh, but what I never tested is if that happens as well with physic meshes (technically should happen, since flat edge meshes are supossed to have more vertexs).
Anyway, this just shows how LL still need to do some improvement on LI. I think they tried to make a so much sofisticated system that ended having this kind of weird unexpected bugs.
The mesh object show is only the physics model. I think what Drongle ran into was models that sudden had high and unpredictable LI costs. Examining them he found a problem in the Physics Cost. To demostrate the problem he only used the physics model.
Since the physics cost is reported separately he could see where the problem was happening.
As I understand, the dual walls are to help control the hull… to force it convex… which if one is switching to prim seems odd to me.
I am still figuring out how LI and mesh work. With Drongle’s info I plan to redo some models and see if I can lower the LI.
A couple of notes on the wall example –
(1) the model(s) is intended to be the physics mesh that would normally be used with a more detailed visible mesh. For simplicity and convenience, it is used as the visual mesh too in these experiments. I have never seen a difference in the physics weights as a result of this kind of simplification.
(2) There are two walls because a physics mesh with any dimension less than 0.5m is automatically treated as type Convex hull, even when it is set to Prim, and even though it shows as Prim in the physics shape viewer. So if it’s less than 0.5m, you can’t walk through the door. Also, it seems that you can often walk through a single triangle-based shape from “behind” (the side the normal doesn’t stick out of), but less easily the other way. So two planes with opposite normals make a more impenetrable wall.
Thanks for taking the time to explain.