Triangle physics weight - Cautionary tales, episode 2

[Drongle McMahon]

I am still struggling to understand the oddities of triangle-base physics weights. Here is another example, related to recent discussions of flat walls. It's two planes 0.5m apart (so that it doesn't secretly switch to convex hull) 6x5m with a 1.6x 2.5 door gap. I made this initially in Blender, from a flat plane, rotated to be vertical, cut out the door, then duplicated, moved and flipped normals. This is a normal physics shape that anyone might use. It has 12 large triangles. Rezzed on Aditi and set to type Prim, its physics weight was 7671. Arrghhh!

Looking at the Collada, it had tiny variations in coordinates that were expected to be identical, of the corder of one part in a million. I assume these were rounding errors from the rotation calculations in Blender. So I edited it to have all the coordinates exactly as they should be. Now the physics weight as type Prim was 0.5, the minimum possible.

Finally, I edited the coordinates so that the x-most side of the wall was not exactly vertical, but was still exactly planar. The bottom was moved out by 0.0000002m, less than one part in a million. The weight went back to 7671.The moral of the story - if you are going to make flat walls, make them VERY flat.

Note that adding perpendicular triangles prevents this effect. So it should not happen with multiple walls in one mesh. That is the work-around.

Here is the perfectly flat version of the file. If anyone wants to confirm or refute this, you can simply edit the first (X) coordinates in the part that's tabulated. Note that it has to be the ones that start at 0.5. It doesn't work with the ones at 0 (Uh??? Why?).

 

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset>
    <contributor>
      <author>Blender User</author>
      <authoring_tool>Blender 2.63.22 r50948</authoring_tool>
    </contributor>
    <created>2013-01-07T23:54:54</created>
    <modified>2013-01-07T23:54:54</modified>
    <unit name="meter" meter="1"/>
    <up_axis>Z_UP</up_axis>
  </asset>
  <library_images/>
  <library_geometries>
    <geometry id="Plane-mesh" name="Plane">
      <mesh>
        <source id="Plane-mesh-positions">
          <float_array id="Plane-mesh-positions-array" count="48">

 0   -3   -2.5 
-0   -3    2.5 
 0    3   -2.5 
-0    3    2.5 
 0   -0.8 -2.5 
 0    0.8 -2.5 
 0    0.8  0 
 0   -0.8  0 
 0.5  3    2.5 
 0.5  3   -2.5 
 0.5 -3    2.5 
 0.5 -3   -2.5 
 0.5  0.8 -2.5 
 0.5 -0.8 -2.5 
 0.5 -0.8  0 
 0.5  0.8  0

</float_array>
          <technique_common>
            <accessor source="#Plane-mesh-positions-array" count="16" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="Plane-mesh-normals">
          <float_array id="Plane-mesh-normals-array" count="18">1 0 0 1 0 0 -1 0 0 -1 0 0 -1 0 0 1 0 0</float_array>
          <technique_common>
            <accessor source="#Plane-mesh-normals-array" count="6" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="Plane-mesh-vertices">
          <input semantic="POSITION" source="#Plane-mesh-positions"/>
        </vertices>
        <polylist count="6">
          <input semantic="VERTEX" source="#Plane-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#Plane-mesh-normals" offset="1"/>
          <vcount>4 4 4 4 4 4 </vcount>
          <p>13 0 14 0 10 0 11 0 9 1 8 1 15 1 12 1 6 2 7 2 1 2 3 2 2 3 5 3 6 3 3 3 4 4 0 4 1 4 7 4 15 5 8 5 10 5 14 5</p>
        </polylist>
      </mesh>
      <extra><technique profile="MAYA"><double_sided>1</double_sided></technique></extra>
    </geometry>
  </library_geometries>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Plane" name="Plane" type="NODE">
        <translate sid="location">0 0 0</translate>
        <rotate sid="rotationZ">0 0 1 0</rotate>
        <rotate sid="rotationY">0 1 0 0</rotate>
        <rotate sid="rotationX">1 0 0 0</rotate>
        <scale sid="scale">1 1 1</scale>
        <instance_geometry url="#Plane-mesh"/>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

 

[Chic Aeon]

LOL> I have absolutely NO CLUE what you are talking about but wanted to give you extra brownie points for getting the cute little clickable 'spoiler' bar at the end of your post.

I spent a long time today fixing odd little bits of meshes that Blender wanted to leave out in the cold WAY away from the rest of the mesh when mapping. A puzzle for sure but I did get it fixed. I kept reminding myself that this is a free program and I am grateful, honestly, for its use.

So very much to learn. If we can put a couple of new notches in our belts every day, it is a good one.

[Aquila Kytori]

Not the first time i have opened a collada file but the first time i have seen something in it I understand , so pictures for Chic :

 

Question for drongle : what do you use to open your collada files to get neat tabulations like that ?When I open with Notepad it looks a mess.

[Drongle McMahon]

"Question for drongle : what do you use to open your collada files to get neat tabulations like that ?When I open with Notepad it looks a mess."

I opened it in Wordpad or Notepad and edited it by hand. That's ok for very simple files like this. Makes it easy to make adjustments. For things with many more vertices, I use a free statistics package called R to output the edited numbers nicely and then paste them into the right place in the file.

By the way, the last two lines need to have X=0.5000001 if you want the wall absolutely flat - they are the vertices on top of the door, half way down.

[Aquila Kytori]

Hi drongle

ok i will try with Wordpad tomorrow its a bit late now ......

---

Drongle McMahon wrote:

By the way, the last two lines need to have X=0.5000001 if you want the wall absolutely flat - they are the vertices on top of the door, half way down.

---

That wasn't what you were meaning , only displacing the lower edge of the second plane = high LI or should the whole plane  be "flat" but tilted to get high LI ?

 

I had understood that if any one or or more of the vertices were not on the X = 0 plane by a tiny amount this would cause the problem ?

Edited to add : quote from your post

"Finally, I edited the coordinates so that the x-most side of the wall was not exactly vertical, but was still exactly planar. The bottom was moved out by 0.0000002m, "

ok i missed that part so the second plane is flat but ever so slightly tilted (?)

[Drongle McMahon]

In fact, you do get similar huge weights if you just move the bottom points, or even just one corner. I kept it completely flat though to exclude the possibility that it was non-flatness that caused the effects. However, there will be rounding errors due to the imprecision of the digital numbers. So it may not be exactly flay even with this precaution. I did do some experiments using a bounding box 0.65535 wide, with 5 decimal places in all numbers. In principle that would remove precision errors in the 16-bit upload format. I still got the effects, but I'm not sure it worked as intended. So it's still an open question, I guess.

[Chic Aeon]

LOL. TY will come back and read tomorrow. Today was SO NOT GOOD IN SL and I am recovering. Got lots of Blender files to test though. That counts .

 

I AM LEARNING MORE EVERY DAY!!!! *wink*.

[Aquila Kytori]

ok, :

 

Notes on above :

I deliberately had Snap to Grid disabled so that the tiny variations could show up and what a mess some of those co-ordinates look ! (why are some expressed as 1.88745e-7 and others like 0.009895405 etc ,)

In the past i have seen my pointer in Blender move " by itself " .This is because the connecting cable is to stiff and sometimes pusshes the mouse a little when i let go of it .I'm wondering if some of those numbers have not been caused by that .

As i was modlling the planes ALL vertex positions, scaling and rotaions were done using the keyboard but as individual vertices had to be select with the mouse who knows what "errors " were cause by the mouse moving .

Ok uploads t othe Beta :

First image is of the wall using the 2 planes as physics (step 5, collada , Planes not indevidually zeroed in their X axis)

set to Physics shape Prim in edit panel . Physics weight 1.8 not terribly high but higher than i would normally expect for something like that .

Next image is same wall but this time using the physics planes after they had been zeroed in X axis ( step 7, )

Again set to Physics shape prim. Physics weight 0.5 as i would have expected .

I don't think i have advanced your research very far and i have used up all the geek in me for this week .

It has made me wonder if vertex positions can get so messy and cause ........slight differences in Physics weight just how often does this happen.

BTW I did the uploading to beta twice , this morning and again this eveing and got exactly the same results.

Just a thought wouldn't it be easier testing if instead of planes with cut-outs for doors just using 2 simple planes?

[Drongle McMahon]

Thanks for looking at this.

It's strange, to say the least. The exact numbers in your unflattened file (step 5) are different from mine, and the vertices appear in a slightly different order. So first I tried changing the numbers to the same as in your file, taking account of the different order. When I switched that to type "Prim", it was immediately returned, but if I looked carefully, I could see the LI go up to 22542 just before it disappeared!

So that suggested it was the order. In some earlier experiments, it was the order triangles were specified that mattered, rather than the order of the vertices in the <polylist> table. In this case, my file has quads, in a polylist tag like this (with a bit of manual formatting). Each line is one quad....

<polylist count="6">
  <input semantic="VERTEX" source="#Plane-mesh-vertices" offset="0"/>
  <input semantic="NORMAL" source="#Plane-mesh-normals" offset="1"/>
  <vcount>4 4 4 4 4 4 </vcount>
  <p>
         13 0   14 0   10 0   11 0    
     9 1    8 1   15 1   12 1
     6 2    7 2    1 2    3 2
     2 3    5 3    6 3    3 3
     4 4    0 4    1 4    7 4
    15 5    8 5   10 5   14 5
  </p>
</polylist>

So, I tried rotating (circular permutation) the order the quads were listed. In all except one order, the physics weights were between 9000 and 23000. In the other case........you guessed?.......it was 1.8. Here is the exceptional order ...

 4 4    0 4    1 4    7 4
15 5    8 5   10 5   14 5
13 0   14 0   10 0   11 0    
 9 1    8 1   15 1   12 1
 6 2    7 2    1 2    3 2
 2 3    5 3    6 3    3 3

Somewhere in there must be another clue about what's causing the high weights.

Can you show us the <polylist> (or <triangles>) section from your step 5 file?

Maybe you could try permuting yours to see if you get the high weights with a different order?

(Note - you didnlt mention a UV map, so I assume like me you didn't make one. In case you did, the numbers in the polylist will be in threes instead of twos, because they will have the indices into the UV coordinates as well as the positions and normals. And if they are triangles instead of quads, there will be three pairs/triplets per line instead of four.)

 

[Aquila Kytori]

 

           4 0      0 0     1 0     6 0
           5 1      7 1     3 1     2 1
           7 2      6 2     1 2     3 2
         12 3     14 3    9 3     8 3
         13 4     10 4   11 4    15 4
         15 5     11 5    9 5     14 5

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset>
    <contributor>
      <author>Blender User</author>
      <authoring_tool>Blender 2.64.0 r51232</authoring_tool>
    </contributor>
    <created>2013-01-09T22:52:57</created>
    <modified>2013-01-09T22:52:57</modified>
    <unit name="meter" meter="1"/>
    <up_axis>Z_UP</up_axis>
  </asset>
  <library_images/>
  <library_geometries>
    <geometry id="Plane_001-mesh" name="Plane.001">
      <mesh>
        <source id="Plane_001-mesh-positions">
          <float_array id="Plane_001-mesh-positions-array" count="48">

 1.88745e-7  -3    -2.5
-1.88745e-7  -3     2.5
 1.88745e-7   3    -2.5
-1.88745e-7   3     2.5
 1.88745e-7  -0.8  -2.5
 1.88745e-7   0.8  -2.5
 1.88745e-7  -0.8   0
 1.88745e-7   0.8   0
 0.5000002   -3    -2.5
 0.4999998   -3     2.5
 0.5000002    3    -2.5
 0.4999998    3     2.5
 0.5000002   -0.8  -2.5
 0.5000002    0.8  -2.5
 0.5000002   -0.8   0
 0.5000002    0.8   0

</float_array>
          <technique_common>
            <accessor source="#Plane_001-mesh-positions-array" count="16" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <source id="Plane_001-mesh-normals">
          <float_array id="Plane_001-mesh-normals-array" count="18">-1 0 0 -1 0 0 -1 0 -1.50996e-7 1 0 0 1 0 0 1 0 1.43051e-7</float_array>
          <technique_common>
            <accessor source="#Plane_001-mesh-normals-array" count="6" stride="3">
              <param name="X" type="float"/>
              <param name="Y" type="float"/>
              <param name="Z" type="float"/>
            </accessor>
          </technique_common>
        </source>
        <vertices id="Plane_001-mesh-vertices">
          <input semantic="POSITION" source="#Plane_001-mesh-positions"/>
        </vertices>
        <polylist count="6">
          <input semantic="VERTEX" source="#Plane_001-mesh-vertices" offset="0"/>
          <input semantic="NORMAL" source="#Plane_001-mesh-normals" offset="1"/>
          <vcount>4 4 4 4 4 4 </vcount>
          <p>4 0 0 0 1 0 6 0 5 1 7 1 3 1 2 1 7 2 6 2 1 2 3 2 12 3 14 3 9 3 8 3 13 4 10 4 11 4 15 4 15 5 11 5 9 5 14 5</p>
        </polylist>
      </mesh>
      <extra><technique profile="MAYA"><double_sided>1</double_sided></technique></extra>
    </geometry>
  </library_geometries>
  <library_visual_scenes>
    <visual_scene id="Scene" name="Scene">
      <node id="Plane_001" name="Plane_001" type="NODE">
        <translate sid="location">0 0 0</translate>
        <rotate sid="rotationZ">0 0 1 0</rotate>
        <rotate sid="rotationY">0 1 0 0</rotate>
        <rotate sid="rotationX">1 0 0 0</rotate>
        <scale sid="scale">1 1 1</scale>
        <instance_geometry url="#Plane_001-mesh"/>
      </node>
    </visual_scene>
  </library_visual_scenes>
  <scene>
    <instance_visual_scene url="#Scene"/>
  </scene>
</COLLADA>

 

not sure i did it right so tried putting the collada in the spoiler.

 Edited to Add: that worked 

What determines the order of the ploygons in the collada ? I ask because after i had made the cut-out for the door i had to manually select the vertices to remake into quads and  now i'm thinking the collada can't know the order i did that surely ?

[Drongle McMahon]

When you say "that worked", what do you mean? Did you get high weights?

I think the ordering in the Collada file depends on the internal data structure in Blender, the exporter just taking them in the order they appear as it asks for the data. (Except for the ordering of <geometry> tags, which you can tell it to arrange alphabetically to cope with material assignment issues in SL.) Thise working on the exporter code could confirm this.

In that case, the order depends in some way on the precise way the mesh is constructed and edited. There may be an exact sequence that produces the orders we had, but I think it would be very difficult to make any general rules. If we knew what was required to avoid the high weights, it's possible the exporter could be modified to avoid them. That's one of the reasons I am trying to understand the problem. At least a reliable set of guidelines would be very useful.

[Drongle McMahon]

Here are the two versions that give the low (1.8) physics weight. The small numbers show the order of the vertices in the position list in <geometry>, yellow where they differ. The numbers in circles show the order of the quads in the <polylist>, with an arrow indicating the order of vertices (dertermined by the normal), and the line indicating the first vertex listed. All looking from a high X towards low X.

Quite a lot of differences there, but the important thing is probably that the first quad in both cases is exactly the same. Why does that avoid the high weights?

[Aquila Kytori]

hi again

---

Drongle McMahon wrote:

When you say "that worked", what do you mean? Did you get high weights?

---

No lol , i meant getting the collada file into the Spoiler

Anyways I have now tried changing the polygon order of the Collada file that was used for the Physics (planes) mesh (Message 8 , step 5)  . I took a couple of screenshots just in case someone reading this wonders what all this is about  :

 

original polygon order in my collada file:

                                                         4 0    0 0   1 0   6 0
                                                         5 1    7 1   3 1   2 1
                                                         7 2    6 2   1 2   3 2
                                                         12 3   14 3  9 3   8 3
                                                         13 4   10 4  11 4  15 4
                                                         15 5   11 5  9 5   14 5

ok my results: 

                                    polygon order                  Physics weight when set to Prim (LI)

                                       0 1 2 3 4 5                                   1.8

                                       1 2 3 5 4 0                            12372

                                       2 3 4 5 0 1                              5188

                                       3 4 5 0 1 2                             16512

                                       4 5 0 1 2 3                             16197

                                       5 0 1 2 3 4                               9757

 

Note, anything over around 11,000 got autoamically "returned to inventory ..............parcel full " but i caught the numbers before that happend.

 

In your next post you said

"Quite a lot of differences there, but the important thing is probably that the first quad in both cases is exactly the same. Why does that avoid the high weights?"

 

 So as the 0 1 2 3 4 5 order (above)  gave a physics weight of 1.8,  I did the last 3 uploads with orders starting with 0 but the rest random :

                                    polygon order                       Physics weight when set to prim

                                      0 5 4 1 2 3                                           1.8

                                      0 1 3 2 5 4                                           1.8

                                      0 5 2 4 1 3                                           1.8

and that seems to confirm what you said.

 Edited to add: ooooops ......... in th first picture the text should read polygon order 5 0 1 2 3 4     ( I forgot the 4 )

[Kwakkelde Kwak]

---

Aquila Kytori wrote:

 

 

 

ok my results: 

                                    polygon order                  Physics weight when set to Prim (LI)

                                      

0

1 2 3 4 5  

                                

1.8

                                      

1 2 3 5 4 0

                           

12372

                                      

2 3 4 5 0 1

                             

5188

                                      

3 4 5 0 1 2

                            

16512

                                      

4 5 0 1 2 3     

                       

16197

                                      

5 0 1 2 3 4  

                            

9757

 

---

So the weight differs when a different poly is the first. I don't see any numbers on for example 123540 vs 102354 vs 140235. One would expect those to give the same weight.

OR

the 0 poly in the same place all the time, not as the first in the list though. So for example 102345 vs 203451 vs 304512.

[Aquila Kytori]

Hi Kwakkedle

To many variables to test but i'm sure if Drongle hasn't tried uploading the example polygon orders you suggested he will be doing that after reading your post , lol.

In drongles first post he seemed to be asking for someone to confirm or refute his findings and thats all i was ever trying to do .

Thats why I used those 2 polygon order lists , Circular Permutation ( Drongles message N° 9 ) and the second ,always starting with the first polygon (message N° 12)

If Drongle hasn't posted the results of lists you suggested i will do the uploads at the weekend

[Drongle McMahon]

There are 720 possible quad orders. It would be possible to generate all those with a program, upload as a linkset and set them individually to Prim shape type. However, what's uploaded is a list of triangles, 12 of them. So that would be about 490 million possible orders. That would be impractical. I would only do this sort of complete investigation with simpler shapes though, maybe just two or three triangles per plane. Even with just two squares, there are 24 triangle orders and 254 (I think) different patterns of displaced vertices. That's more than 6000 possibilities without even considering different displacement sizes.

I'm afraid that exhaustive analysis, without direct access to the server code that does the calculation, is just not feasible*. In the case of the cylinders, in the previous thread, I used random sampling of orders of the others to test the effect of the first triangle. This is the altertnative, using hypothesis testing. For example, hypothesis = "a subset of possible quads in the first position will give a low weght". The trick is to invent tests that can disprove the hypothesis, rather than those that just provide circumstantial support. I have to admit, my test was just the circumstantial support kind. I haven't thought up better tests yet.

*Even Aditi L$ run out as well as time.

[Drongle McMahon]

Well. I set out to see if I could do an exhaustive analysis with the simplest possible mesh. Two equilateral triangles, one small one and one larger, both perpendicular to the X axis (before applying small shifts). The larger is at the highest X coordinate. I tried applying an X offset of about 0.000001m (about a millionthof the X size) to each vertex, one at a time (as well as some combinations). For each offset vertex, I changed the order of the triangles in the polylist, and for each triangle order I tried all three possible vertex orders of the triangle with the offset (circular permutation only because reversing the sequence reverses the normal, and in other experiments that did affect the weights). I also tried swapping the triangle positions on the X axis for some of these states.

I can't show all the results, as I didn't complete them all. Here are the results for both triangle orders with a single offset vertex in the larger triangle, for each offset vertex and each vertex order. The numbers at the vertices show thier order in the <geometry> tag, not in the <polylist>. The large triangle is shown in the view looking from positive X towards the origin, as shown in the diagram. The left shows the large triangle first in the polylist, and the right shows it after the smaller triangle. A spot indicates the vertex which was displaced +0.000001m along the X axis. This is green for cases where the Prim physics weight is the same (0.5) as the case with no displaced vertices, and red for cases with hugely increased weights. The order of vertices in the <polylist> is indicated by the red aorrows, starting at the red number. The weights observed for type Prim are shown in the middle.

I can't discerne any consisten pattern in these results. So I am going to abandon hope of understanding what is going on here. It depends on the order of the vertices as much as on the order of the triangles in the <polylist>. It also depended on the physical order of the triangles along the X axis.Incomplete observations with displacements in the small triangle showed they could have even larger effects, also depending on these three factors. In one case, with a displacement in the large triangle, adding a displacement to one of the smaller triangle vertices cancelled out the effect of the first displacement.

I suppose this could have something to do with incorrect coordination of the iterators that look through the polylist and geometry during the calculation, so that they are associating coordinates that belong to different vertices. That would occasionally lead to imaginary narrow triangles that would cause high weights. However, as long as I can't see any pattern, I cant see any way of testing that possibility. It might also be some unexpected sensitivity of the approximation of triangle widths. I had hope to be able to invent some rules to avoid these effects, but I have to give up now. Of course the extreme effects in these examples would lead any creator to make changes that avoid them. But in the case of the cylinders, there were substantial but non-catastrophic effects that might be substantial weight increases without the creator realising. Maybe we just have to hope that it gets fixed.

[Garvie Garzo]

why, why, why indeed?

One thing that does seem to help is ctrl A > choose Apply Scale and Rotation in object mode before export. Mind you I have no idea why (why, why, why) this makes a difference, but when i am uploading a mesh that i was pretty sure should be around 5 LI and instead i see 45 on the uploader preview, i think, ohh... wonder if i did that ctrl A scale rot thingie. (apologies for technical jargon)

I suspect there is some sort of data prurge that makes for a friendlier meeting between the incoming .dae file and SL's moody and unpredictable uploader. 

i am still puzzling over when, why (why, why, why) and how number and orientation of triangles matter. i make mostly small curvy things (where small differences have HUGE impacts in LI) and think of each and every upload as a foray into a culture where haggling is still the norm. 

 

 

 

 

 

[Drongle McMahon]

I think the effects you describe must be something different from those I was investigating, because you saw the differences in the upload dialog. This doesn't show the physics weights you get with the type set to "Prim". It only shows the weight for type "Convex hull". You are quite right, though, that it is generally much better to apply rotation and scale before exporting the collada file. There are several problems that can arise if you don't do that, and may affect LI.