Jump to content

Triangle-based physics weights: Episode 4


Drongle McMahon
 Share

You are about to reply to a thread that has been inactive for 3579 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Triangle-based physics weights - episode 4.        

The triangles of a triangle-based (not Analyzed) physics mesh are specified in the collada file in a <polylist> or <triangles>  section, which lists triplets of vertices specifying each triangle. Episode 3 showed how the choice of which triangle came first, and the order of the three vertices specifying it, could have large effects on the physics weight of a simple physics shape such as a 12-sided cylinder, even though the resulting geometry remained identical.

Unfortunately, the minimum weight could not be achieved directly in an export from Blender. Instead, it required manual editing of the collada file. However, if it's true that the first triangle is the most important factor, then it might be possible to get low weights by starting with an optimized collada file for a relatively simple mesh, importing that, and then building the rest of the physics mesh. When you do that, Blender does keep the imported mesh as the first thing in the collada <polylist>. So this is an investigation of that approach to lowering triangle-based physics weights.

As a target model, I chose a roof supported by columns. Starting with four columns, this could be extended by adding extra pairs of columns. A suitable physics shape for the columns was a six-sided column. So the first step was to optimize the triangle order for such a column. It was 3m tall, open ended, and with 0.29m diameter so that bot x and y dimensions were at least 0.5m. This was investigated as for the 12 sided column in episode 3. Two orientations, points along x or y axes, and two directions for the diagonals were looked at. For each, all cyclic permutations of first triangle choice and of vertex order in that triangle were observed, with the results shown here.

 fpic1.png

The range was 8-fold, from 0.6 to 4.8. Eight configurations had weight 0.6 (green), and one of those (outlined) was chosen as the collada file to import into Blender. The remainder of a four-column structure was made using normal Blender methods for the remaining columns, exactly the same dimensions, and for a single flat quad roof. Adding more column pairs and stretching the roof made six, eight and twelve column structures. However, the weights after upload of the exported collada files were quite high. So the exported was edited to repeat the complete set of rotations of  triangle orders and first triangle vertex orders for the first, originally imported, column at the top of the <polylist>.

 fpic2.png

The same configuration gave the lowest weight (yellow) for all models, although it was not that (top left) that had given the lowest weight for the isolated cylinder.  Surprisingly, the lowest weight for four columns plus a roof was 0.7, only 0.1 higher than the lowest found for the isolated column. Clearly, this approach can produce very low weights, but it may not be with the configuration optimized for the isolated column. The lowest weight for the six column structure was also impressive, but the effect seemed to diminish as the number of columns increased. (The weights for models constructed completely in Blender were 2.7, 5.2, 8.4 and 11.8 for 4, 6, 8 and 12 columns, although this is likely to be highly variable depending on exact details of the construction.)

So the process was repeated, first importing the isolated-column collada file new configuration found to be optimal for the multi-column structures, and then adding the remaining parts. The result was disappointing, giving weights of 0.9 (vs 0.7 for  4 columns), 2.1 (vs 1.2 for 6 columns) and 9.0 (vs 4.4 for 8 columns). Examination of the collada files revealed that the order of vertices in only the first triangle exported file was different from that in the imported single-column file that had been used to start the construction. Changing this to the original imported order gave weights of 0.6 and 1.3 for the 4 and 6 column structures. The former was even lower that the optimize value and equaled the best obtained for just a single column!

However, the repaired order in the 8 column structure actually produced a higher weight, 15.9. Further inspection of that collada file revealed that the order of vertices in the quad defining the roof was different. Testing all four cyclic permutations of the vertex order for the roof quad gave weights of 15.9, 4.4, 5.8 and 4.5. So this part of the polylist was also having a large influence, even though it was nowhere near the top of the <polylist>.

In conclusion, these experiments showed that optimization of the identity and vertex order of the first triangle in the <polylist> can achieve dramatic reductions in triangle-based physics weights for a given geometry. However, this may not be fully achieved by simply importing a previously optimized starting shape. The reduction in weights may become somewhat less effective, and/or less easy to achieve, as the complexity of the final mesh increases. Furthermore, elements other than that at the top of the <polylist> can sometimes be important in determining the weight.

At least it is clear that some playing around with the order and orientation of parts of the mesh is likely to be effective in reducing the weight of these physics shapes, but I have not been able to find a general direct approach to optimization.

The preferred solution would be a weight calculation that always produced the same weight for the same geometry, irrespective of the order of component elements in the collada. We will have to wait to see if that might be forthcoming. One problem will certainly be that existing models that have the lowest weights by chance might see substantial increases with a more consistent calculation, and that could cause problems including unexpected returns from increased LIs.

 

ETA. Here's a picture of the eight-column version of the model. The triangulated column at the nearest corner is the imported one. The rest is added on in Blender. The columns are 3m high, 2.5m apart.

fpic3.png

  • Like 1
Link to comment
Share on other sites

Hiya Drongle,

Because I had nothing better to do at the moment, I went through all four of your Episodes. I have few questions:

1) Are you nuts?

2) Do you get the feeling that the wiki (which I have not read) was written by someone who knows less about how mesh and physics weights work than you do?

3) Do you worry that, if you do discover the underlying method to this apparent madness, it will change tomorrow?

The sensitivities you've discovered (to small displacements, initial orientations, etc) don't reveal any underlying root cause to me. Rather, they suggest that the code is riddled with boundary conditions. When I've encountered behavior like this in the past (in signal processing systems) I've often tossed the code and found something else. That's obviously not a solution here, but the results of your experimenation don't leave me feeling very hopeful.

Link to comment
Share on other sites

1) Are you nuts?

No. (But I would say that if I was....). I did consider the possibility until someone else was able to confirm the initial observations that started it all; the very different weights for the same geometry exported from different packages. I do enjoy puzzles though.

2) Do you get the feeling that the wiki (which I have not read) was written by someone who knows less about how mesh and physics weights work than you do?

No. It was (mostly) written by Falcon Linden (at least, that's what the wiki edit page says). He knows infinitely more about mesh physics than I do. I only know what I can observe.

3) Do you worry that, if you do discover the underlying method to this apparent madness, it will change tomorrow?

I've given up trying to understand the cause. It's too complicated (although the cause may be simple). I hoped to find a simple workaround to get consistent weights, but now I think I have to give that up too. I would be happy to see it change, but I can't comment on how likely that is.

Clearly, many people, including me, failed to notice these discrepancies for a long time. That means people were able to accomodate to them without insurmountable problems. In view of that, it would be a reasonable decision to leave it as it is, especially to avoid breaking existing content.

I think my interest was mostly aroused because it drew into question advice that I had given out about choosing between triangle-based and convex-hull based physics shapes for different kinds of models. With this sort of variation, any such advice becomes unreliable in any particular application.

 

Link to comment
Share on other sites

I'm glad you like puzzles, and that you questioned your own advice. Too few people do that!

That the physics weights are so nutty tells me that nobody really understands how they're computed. Is Falcon Linden aware of your observations? If so, and if there's been no reasonable explanation of your observations, wouldn't it be safe to say he knows far less than infinitely more about this than you do?

;-)

Link to comment
Share on other sites

I have submitted jiras, although with very simplified cases and much less extensive data. They have been acceped and forwarded into the internal sytem, which means I have no further information on their potential fate unless or until something changes. I would have added these cases to them, but that's no lomger possible, which is another reason I put them here, so that at least the information is available.

Link to comment
Share on other sites

Most of this is greek to me, but I get the same feeling I had when developing software for medical instruments, where I'd get some library of routines from a company, complete with source code. Even though I was ostensibly the developer of the final software, I'd have to figure out how some of it worked by observation. I spent countless hours in support forums, scratching my head along with other users, trying to figure out what was happening. The folks at the vendor company were often of little use as the support personnel were not those who'd written the code. Those original authors were often long gone, or had never been there in the first place. ;-)

Some things never change?

Link to comment
Share on other sites

...Some things never change?
I am voting a definite yes on that one!

And apperently a lot platforms profit from overly obsessive players and users and their observations or tests. So nutz or not, it can never be wrong to have that one person inspecting the very microcosmos of things in order to contribute to a better outcome at the end =)

Link to comment
Share on other sites

  • 1 month later...

Drongle, it is possible to add to a JIRA item even after it has been locked and imported to the internal tracking. Email Alexa Linden and explain what you want to add and why.

Or just file a new JIRA and reference the previous one. The Lindens will take care of collecting the info and getting it to the right people.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3579 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...