# Domino - Physics demo & problems with TransformReference
**URL:** https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973
**Category:** Physics and Collisions
**Created:** [July 16, 2025, 3:52pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973 "2025-07-16T15:52:59Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@DiggiDoggi](https://forum.castle-engine.io/u/DiggiDoggi)
#### Post date: [July 16, 2025, 3:52pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/1 "2025-07-16T15:52:59Z")
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.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [July 16, 2025, 4:42pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/2 "2025-07-16T16:42:37Z")
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](https://forum.castle-engine.io/uploads/short-url/zbFYcKMJODPUvOEyzQM99gWFlib.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.
---
### Author:  [@DiggiDoggi](https://forum.castle-engine.io/u/DiggiDoggi)
#### Post date: [July 16, 2025, 5:51pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/3 "2025-07-16T17:51:58Z")
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](https://forum.castle-engine.io/uploads/short-url/2r4VmqGIZj5LSIo6OEpxVy7qrD1.zip) (15.6 KB)
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [July 16, 2025, 6:25pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/4 "2025-07-16T18:25:44Z")
> [@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](https://forum.castle-engine.io/uploads/short-url/2r4VmqGIZj5LSIo6OEpxVy7qrD1.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 🙂
---
### Author:  [@DiggiDoggi](https://forum.castle-engine.io/u/DiggiDoggi)
#### Post date: [July 16, 2025, 6:53pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/5 "2025-07-16T18:53:50Z")
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)
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [July 23, 2025, 11:13pm UTC](https://forum.castle-engine.io/t/domino-physics-demo-problems-with-transformreference/1973/6 "2025-07-23T23:13:25Z")
> [@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](https://castle-engine.io/apidoc/html/CastleTransform.TCastleCollider.html#AutoSize) is responsible for calculating a few properties, including [collider Translation](https://castle-engine.io/apidoc/html/CastleTransform.TCastleCollider.html#Translation). I know, the name is effectively not optimal, “AutoSize” → it’s not only about size, its “automatic size and position”.