Domino - Physics demo & problems with TransformReference

[DiggiDoggi]

Hi there!

I’ve made a simple falling domino effect. Who doesn’t like falling dominoes? The test can be seen on the first video. All dominoes are individual boxes with behaviors, and works great - as great as a simple demo could

However, I decided to replace one of domino’s TCastleBox with a TCastleTransformReference. With a Reference property set to ‘OriginalPiece’ (which is just one of TCastleBox). Now, the “clone” (TTransformReference object) behaves porperly, even if I add more of them. However, the OriginalPiece acts very strange.

So I’ve made another simple project to replicate it, and the result is the same. OriginalPiece doesn’t know what to do, so it either falls through the floor, sometimes it manages to rotate and hit the other dominoes.
On the video the 2nd and 3rd objects are “clones” (TCastleTransformReference for short) and their physics work as expected in all scenarios so far.

I didn’t debug it yet. Maybe there’s a known workaround, maybe that’s a known issue.

[michalis]

The transformations (TCastleTransform or descendants like TCastleBox, TCastleScene) to which you attach the physics components (TCastleRigidBody, TCastleXxxCollider) must exist only once in the world. So they cannot be referred to by TCastleTransformReference.Reference. Maybe that is the culprit?

You can still use the TCastleTransformReference for boxes, but for the one “original” piece, if you want it to be affected by physics, you need to put it under a new TCastleTransform and add TCastleRigidBody, TCastleXxxCollider to that transform. So sthg like this should be good:

The Box1 is inside Transform1, and physics behaviors are at Transform1.

I know, this is somewhat similar to the old feature request you submitted and we made – which allowed to usually avoid “wrapping” the referenced target in another transformation. But in this case, the “additional wrapper” (Transform1 above) is still necessary and somewhat unavoidable, we need physics behaviors only in unique transformations.

testref-0.1-src.zip (15.3 KB)

I’m attaching a project. TODO: argh, though I see it has another bug, 2 boxes in TCastleTransformReference should not “fall through”… This is some independent bug. I will fix it.

And this an example of wrong situation:

TODO 2: Hm, but we should communicate it better to the user. Like “BoxCollider1 is referenced many times, do not use physics components inside the hierarchy instantiated many times by TCastleTransformReference”.

The 2 TODOs above are for me to solve

Let me know if this helps, if not – then maybe you have found an independent problem (ah, TODOs TODOs more TODOs ), please submit a testcase then.

[DiggiDoggi]

Only difference I had was a MeshCollider on the Plane1, as it’s explained in the docs that it make the collider “static” (ie doesn’t respond to Gravity), which I thought is OK for his simple demo. It worked with simple boxes without any problems.

However, in your example, the Plane1 has a PlaneCollider. When I swapped my MeshCollider to PlaneCollider inside the project, all works perfectly fine. Even the displayed “bounding box” which acted crazy on the video, now shows proper geometry aligned with the “clone”, although it seems to be insignificant.

So it was just the collider choice.

I know you love expanding your TODO list everyone does.

My original test, with MeshCollider
domino_instances-0.1-src.zip (15.6 KB)

[michalis]

@DiggiDoggi

However, in your example, the Plane1 has a PlaneCollider. When I swapped my MeshCollider to PlaneCollider inside the project, all works perfectly fine. Even the displayed “bounding box” which acted crazy on the video, now shows proper geometry aligned with the “clone”, although it seems to be insignificant.

So it was just the collider choice.

Looking at your example, you actually have the problem I mentioned above – the Box1 has physics colliders, and it is used multiple times (due to being referenced from TCastleTransformReference).

Fixing it by changing the hierarchy, so that Box1 is underneath a parent, and parent has physics colliders – works OK, even when the Plane1 uses TCastleMeshCollider.

See screenshot and my attached version of your project:

domino_instances-0.1-src.zip (15.6 KB)

You are also right, at the same time – weirdly, indeed the problem goes away if we use TCastlePlaneCollider. My guess is that this “fix” works by accident. TCastlePlaneCollider is actually a half-3D-space (“everything with Y<0 is not allowed”) so it “looks similar from the domino perspective”, no matter which of the 3 transformations of dominoes we would assume. And it is undefined which one is in effect when doing physics calculations, since the Box1 is present with 3 transformations.

So, I would say – TCastlePlaneCollider worked by accident (though I would advise to keep it, it will be a bit faster than TCastleMeshCollider, it’s a simpler shape that is determined by a simple 3D plane). For the real fix, to have a “well defined” situation, you should remake the hierarchy as I show above.

OK, so I remain at 2 TODOs

[DiggiDoggi]

In your code from the first example (testref.zip) the boxes are falling because the BoxCollider shoud have Translation = (0,0,0) and you have some (0, -2.something, 0)… 1 TODO less

Edit. But when I change the translation it set AutoSize to false. Setting it back to true makes it wrong again… so now I see you still have this TODO. After playing the simulation, the translation (with Autosize on) is set to the Box1.Translation (the referenced, “cloned” transform)

[michalis]

@michalis

TODO 2: Hm, but we should communicate it better to the user. Like “BoxCollider1 is referenced many times, do not use physics components inside the hierarchy instantiated many times by TCastleTransformReference”.

This is now done.

@michalis

TODO: argh, though I see it has another bug, 2 boxes in TCastleTransformReference should not “fall through”… This is some independent bug. I will fix it.

@DiggiDoggi

In your code from the first example (testref.zip) the boxes are falling because the BoxCollider shoud have Translation = (0,0,0) and you have some (0, -2.something, 0)… 1 TODO less

Ah, yes – thank you for finding it.

This was still a bug: our “auto-sizing of collider” failed to calculate proper TCastleXxxCollider.Translation. But now that you pointed it out, it was easy to fix

• Auto-sizing looked at bounding box, but the “transformation cancelling” in TCastleTransformReference didn’t kick-in yet as it was not yet rendered…
• Confirmed by toggling collider AutoSize off and back on: this was a working workaround, resetting TCastleXxxCollider.Translation.
• Fixed properly now, bounding box of the reference is now OK. This example will now work out-of-the-box.

@DiggiDoggi

Edit. But when I change the translation it set AutoSize to false. Setting it back to true makes it wrong again… so now I see you still have this TODO. After playing the simulation, the translation (with Autosize on) is set to the Box1.Translation (the referenced, “cloned” transform)

Indeed, this is now fixed.

Note that changing TCastleXxxCollider.Translation indeed automatically sets TCastleXxxCollider.AutoSize to false, this a deliberate feature. The TCastleXxxCollider.Translation is determined by auto-sizing, editing this (and some other collider properties) implies “I don’t want to do auto-sizing”.

The TCastleXxxCollider.AutoSize is responsible for calculating a few properties, including collider Translation. I know, the name is effectively not optimal, “AutoSize” → it’s not only about size, its “automatic size and position”.