The unpredictable physics weight

[ChinRey]

I just wanted to show you an example how difficult it can be to predict physics weight for a mesh with a complex physics shape.

These two paths are exactly identical in every way except one of them was rotated 180 degrees in Blender before exporting. The physics weights are 2.9 and 1.2 respectively.

The download weights are also different, but not enough to matter: 2.329 and 2.194, the one with lowest physics weight also has the lowest download weight.

Now, which of them should I keep? Decisions, decisions, decisions...

Edited August 18, 2018 by ChinRey

[OptimoMaximo]

The real question is, to me, why this discrepancy? A mesh model is built in a deterministic way (vertex order and triangle lists), why in the world should it generate non-deterministic results when converted into a binary format? It might beneficial to know the world orientation it had in Blender in relation to its vertex order: where is the 0 vertex in world coordinates and relate that to the physics weight?

[ChinRey]

51 minutes ago, OptimoMaximo said:

The real question is, to me, why this discrepancy? A mesh model is built in a deterministic way (vertex order and triangle lists), why in the world should it generate non-deterministic results when converted into a binary format?

But non-deterministic it is. I tried to rotate it back and ended up with physics weight 1.4. That is for a model that should be exactly identical to the 2.9 download weight one.

 

51 minutes ago, OptimoMaximo said:

It might beneficial to know the world orientation it had in Blender in relation to its vertex order: where is the 0 vertex in world coordinates and relate that to the physics weight?

Vertice order should not matter for physics weight. We don't have detailed control of vertice order in Blender but I tried to randomize it and it didn't make any difference.

The orinetation may be a clue though. Both version has the lowest edge centered exactly on the zero coordinates. The high DL one is leading along the negative y axis and twisting along the negative x axis, while the low DL version runs along the positive axises.

Not sure if dimensions matter but they are 25x52x18 m and the width of the strip is 4 m at the ends, fluctuating a litle bit along the path.

(Edit: Just in case anybody wonder, maybe I should mention this is a part of an opensim project, one half of a path running up along a 32 m tall extinct volcano. It's custom made to fit a specific terrain and I'm not sure if I'll upload it to SL at all. Anybody who wants to use it, will have to do some serious terraforming to make it fit.)

Edited August 18, 2018 by ChinRey

[OptimoMaximo]

2 minutes ago, ChinRey said:

The orinetation may be a clue though. Both version has the lowest edge centered exactly on the zero coordinates. The high DL one is leading along the negative y axis and twisting along the negative x axis, while the low DL version runs along the positive axises.

From your observations, i wonder: knowing how the mesh gets encoded, perhaps the translation within the encoding box from negative ranges to positive ones may affect this behavior. If you don't mind doing this test on the path object you have, you may try moving the whole object in the positive ranges for all axis, so that each vertex falls within positive grid numbers.

[Fionalein]

In a perfect world they should be identical, however rotating 180 degrees in one direction and then back might actually give you very small deviations from the original state.

Edited August 18, 2018 by Fionalein

[ChinRey]

1 minute ago, OptimoMaximo said:

If you don't mind doing this test on the path object you have, you may try moving the whole object in the positive ranges for all axis, so that each vertex falls within positive grid numbers.

I've done it already. That is, since the DL is so exceptionally low anyway, I did it the other way, moving the whole thing 100 m in negative direction along all axises. It didn't change the DL at all.

[ChinRey]

2 minutes ago, Fionalein said:

In a perfect world they should be identical

I thought SL was supposed to be a perfect world(?)

[OptimoMaximo]

1 minute ago, ChinRey said:

I've done it already. That is, since the DL is so exceptionally low anyway, I did it the other way, moving the whole thing 100 m in negative direction along all axises. It didn't change the DL at all.

It didn't change the DL how? I am assuming it stays low DL weight? In such case, the higher DL weight may be determined by the fact that the object lays across the zero vector, with vertices indexing positive and negative range coordinates, while a consistent sign in their coordinates gets handled better

[ChinRey]

4 minutes ago, OptimoMaximo said:

It didn't change the DL how? I am assuming it stays low DL weight?

That's right.

 

4 minutes ago, OptimoMaximo said:

In such case, the higher DL weight may be determined by the fact that the object lays across the zero vector, with vertices indexing positive and negative range coordinates, while a consistent sign in their coordinates gets handled better

I tried to center the object as a whole at the zero point, giving a mixture of positive and negative coordinates along all axises. DL stayed at 1.2

Then I finally figured out how to sort the vertices in a controlled way. Zero vertice at <0,0,0>, all vertices sorted in ascending order, first along x, then z, then y axis. DL: 1.2

Vertice order randomized: DL: 1.2

Object rotated back to the original: DL: 1.4. Not nearly as high as it was but still consistently higher than the 1.2

[OptimoMaximo]

Now rotating it back to the original orientation doesn't give out the same result of 2.9 you had before... its non deterministic nature drives me nuts....

[Beq Janus]

A lot of this comes back to the compressibility of the mesh and other factors.

I would have to spend some time with the model and an explicit step by step reproduction to give any certainty but the following observations can be made.

1) If you rotate an object in Blender and then export it, has the bounding box changed as a result? If so then the multiplier used in the cost calculations will change. 
2) vertex ordering is important.
3) Vertex alignment "might" be important.
4) As discussed in similar threads in the past, there is a potential that arbitrary ordering of vertices when they are stored in the viewer contributes to the differences.

Here is a "special" Tip I've not shared before, mostly cos the majority of people won't understand what on earth I am talking about, more still will not be able to implement it, if I get a chance I will consider adding this to the firestorm uploader, but I'm wary of trolls that claim optimisations like this are "cheating" and I end up with a stream of abuse. whether the tip is of any value or not, in the long run, doesn't matter it illustrates some of the variability.

Here's the tip.

For any mesh for which a considerable proportion consists of aligned faces, sort the vertices by their normals, not by their vertex order.

Why does this help? 

Meshes are compressed using zip compression. For any given data set there will be an optimal ordering which gives the best compression. In hard surface models and most non-organic builds, certain aspects of a mesh will face in the same direction, they may be at varying depths or heights but will have the same normal. Sorting by normal therefore makes that data set more compressible. 

In one extreme case, I have achieved up to a 20% compression with this, though it is more typically lower (around 5%) which is verging on "noise", but if you are in a thread like this puzzling over small variations then subtle runtime variances are going to be a contributory factor. 

In #2 and #3 above ordering and alignment, both of these can affect compressibility. zip compression is effectively a Huffman encoded run-length pattern compression. It looks for repeating series of bytes and then substitutes a small token, the most frequently recurring pattern gets the shortest token with subsequent patterns getting longer tokens. If you align a row of vertices along the X axis such that all the X coordinates are identical then there will be a high frequency of repetition of that value in the compressed stream. if instead, you align that row along 45 degrees then every single one will be different. In most cases, the difference it makes is negligible as you will frequently find that some other data fall into line instead. 

Going back to the start of the thread and noting that this discussion started talking about physics and then went on to discuss opensim. It should be noted that few if any open sim grids support Havok for their physics and a physics shape produced by Firestorm or any viewer that is not just a mesh or simple convex hull is not guaranteed to work and it may well be utterly broken. As there is no reference viewer for Open Sim, no guidance as to how OpenSim should treat uploaded physics data anything other the triangular mesh should be considered unsupported.

[ChinRey]

3 hours ago, Beq Janus said:

1) If you rotate an object in Blender and then export it, has the bounding box changed as a result? If so then the multiplier used in the cost calculations will change.

No. The bounding box is the same.

 

3 hours ago, Beq Janus said:

2) vertex ordering is important.

Is there any reason why that should apply to the physics model and the physics weight? It matters to download weight because it affects the compressibility and thus the amount of data downloaded. But the physics model is never downloaded at all so that can't apply to it.

 

3 hours ago, Beq Janus said:

For any mesh for which a considerable proportion consists of aligned faces, sort the vertices by their normals, not by their vertex order.

That's a really good tip. Now, how do we do that in Blender?

It can't explain this though. This is physics so compressability shouldn't matter at all.

 

3 hours ago, Beq Janus said:

Going back to the start of the thread and noting that this discussion started talking about physics and then went on to discuss opensim.

That was a digression, I shouldn't have mentioned it at all. It's all about how the mesh behaves in SL - or on the beta grid rather.

But it's part of a build that will never be seen in SL, unless somebody are willing to pay the tier for 16 sims. I may upload this part and a few others to SL if anybody has can use them in other contexts though. That's why I tried it on the beta grid too.

[animats]

That's interesting. Collision detection first wraps an axis-aligned bounding box, parallel to the X, Y and Z axis, around each object. It's done that way because the bounding boxes can be sorted by X, Y, and Z, which makes it cheap to figure out which ones are overlapping.

When two bounding boxes overlap, the detailed collision check is made for each object pair that's inside both boxes. This works great when the objects are small or roughly aligned with an axis. The collision detection cost of an object is higher for non axis aligned objects. Worst case is a long diagonal in X, Y, and Z.

What matters is orientation in world, not during upload. The physics cost computation is during upload. Maybe it's a coarse approximation assuming the object will be aligned in world as it was at upload.

Edited August 21, 2018 by animats
Clarify