ammo-shape fit: all Includes Invisible Child Geometry Despite includeInvisible: false

[Tpleme]

When an A-Frame entity uses ammo-shape="type: hull;", it appears to include the geometry of its invisible child entities in the parent's collision shape calculation, even when the default ammo-shape property for the parent is expected to respet includeInvisible: false.

The child entity is configured with its own ammo-body and ammo-shape (and visible="false") solely to act as a kinematic trigger for collision events (like grab detection), but its geometry is unintentionally contributing to the physical size of the parent's main collision body.

I am using AFrame 1.7.1 and aframe-physics-system 4.2.3.

Reproduction Code

<a-scene physics="driver: ammo; debug: true;">
    <a-box id="box" height="0.5" width="0.5" depth="0.5" material="color: red;" ammo-body="type: dynamic; mass: 1;" ammo-shape="type: hull;">
        <a-box id="inner-box" visible="false" ammo-body="type: kinematic; emitCollisionEvents: true; disableCollision: true;" ammo-shape></a-box>
    </a-box>
</a-scene>

Steps to Reproduce:

• Set up the A-Frame scene with the provided code.
• Enable physics debugging (physics="debug: true;").
• Observe the wireframe for the #box parent entity.

Expected Behavior

The element #box ammo-shape (set to type: hull) should only fit the visible geometry of itself. Since the child #inner-box is set to visible="false", and the default ammo-shape propertie includeInvisible is false, its geometry should be completely ignored in the parent's hull calculation.

Troubleshooting Attempts

Tested Removing Child Physics Components. When I remove the ammo-body and ammo-shape components from the #inner-box, the parent's physics shape still calculates its ammo-shape considering the child.

Confirmed Child Components are Necessary: The child's ammo-body and ammo-shape are required so that I can capture grab/collision events on the child (as a trigger) while keeping the parent as the main physical body. Like creating an area arroud the object to act as a area of event trigger for hover and grab.

[diarmidmackenzie]

In three-to-ammo, we have this code.

export const iterateGeometries = (function() {
  const inverse = new THREE.Matrix4();
  return function(root, options, cb) {
    inverse.copy(root.matrixWorld).invert();
    root.traverse(mesh => {
      const transform = new THREE.Matrix4();
      if (
        mesh.isMesh &&
        mesh.name !== "Sky" &&
        (options.includeInvisible || (mesh.el && mesh.el.object3D.visible) || mesh.visible)
      ) {

In this case, "inner-box" consists of a Group and a child Mesh (this is standard for an A-Frame entity with a Mesh).

Setting visible="false" sets the visible flag on the Group, not the Mesh.

In Three.js, makign a parent invisible makes all its children invisible too, but the code above doesn't acknowledge that - it just looks at the mesh.visible flag and infers that a mesh is visible if it's "visible" flag is true.

In this case that's not correct, because it has an invisible parent.

We could use a recursive function like this to determine whether the mesh is actually visible:

function isObjectVisible(object: THREE.Object3D): boolean {
  if (!object.visible) return false
  
  if (object.parent) {
    return isObjectVisible(object.parent)
  }
  
  return true
}

Then replace the test with:

        (options.includeInvisible || isObjectVisible(mesh)

I don't know what the intent of the two different clauses in the current code is - looks like it's maybe an attempt to recognize that visibility can be determined by the mesh's visible flag, or the parent el's visible flag. But flawed in a couple of ways:

1. doesn't consider higher level ancestors
2. seems wrong to combine the conditions with ||. && would be more appropriate.

I'll dig into the git history here, and see if that offers any explanation for this code.

A decent workaround might be to explicitly set visible=false on the mesh, using a component like this.

      AFRAME.registerComponent('hide-meshes', {
        init() {
          this.el.addEventListener('object3dset', this.onObject3DSet.bind(this))
          const mesh = this.el.getObject3D('mesh')
          if (mesh) {
            mesh.visible = false
          }
        },

        onObject3DSet(event) {
          event.detail.object.visible = false
        }
      })

When I use this, it's also necessary to set "includeInvisible: true" on the invisible child (else you hit an infinite loop in the ammo wasm, I guess because you have an ammo shape with no geometries?)

This code seems to work as you want...

<html>
  <head>
    <script src="https://aframe.io/releases/1.7.0/aframe.min.js"></script>   
    <script src="https://cdn.jsdelivr.net/gh/MozillaReality/ammo.js@8bbc0ea/builds/ammo.wasm.js"></script>
    <script src="../../dist/aframe-physics-system.js"></script>
    <script>
      AFRAME.registerComponent('hide-meshes', {
        init() {
          this.el.addEventListener('object3dset', this.onObject3DSet.bind(this))
          const mesh = this.el.getObject3D('mesh')
          if (mesh) {
            mesh.visible = false
          }
        },

        onObject3DSet(event) {
          event.detail.object.visible = false
        }
      })
    </script>
  </head>
  <body>
    <a-scene physics="driver: ammo; debug: true;">
      <a-entity position="0 0 -4">
        <a-box id="floor" height="0.5" width="10" depth="10" position="0 -2.5 0" ammo-body="type: static" ammo-shape></a-box>
        <a-box id="box" height="0.5" width="0.5" depth="0.5" material="color: red;" ammo-body="type: dynamic; mass: 1;" ammo-shape="type: hull;">
          <a-box id="inner-box" visible="false" hide-meshes ammo-body="type: kinematic; emitCollisionEvents: true; disableCollision: true;" ammo-shape="includeInvisible: true"></a-box>
        </a-box>
      </a-entity>
    </a-scene>
  </body>
</html>

[diarmidmackenzie]

The additional mesh.visible was added here:
InfiniteLee/three-to-ammo@91597be

"various fixes for bugs uncovered during three-ammo development"

Seems like a bad fix to me, because of how invisibility passes down the object tree in Three.js. Maybe there is a need to handle a mesh with mesh.el not set, but this doesn't seem like the correct handling of visibility.

[diarmidmackenzie]

@Tpleme - if you want to attempt a fix to three-to-ammo, we hace patched that before using npm patch-package.
See e.g. #21

@vincentfretin Maybe we should pull three-to-ammo into C-Frame, so a wider group of people can help with its maintenance?
https://github.com/InfiniteLee/three-to-ammo/

[vincentfretin]

Yes absolutely. It seems we already forked it? https://github.com/c-frame/three-to-ammo Or you just did it?

[diarmidmackenzie]

Yes absolutely. It seems we already forked it? https://github.com/c-frame/three-to-ammo Or you just did it?

Oh - I guess I did this already! And there's a C-Frame version on npm, which is what we now use in this repo. While since I looked at this, and I'd completely forgotten doing that!

https://www.npmjs.com/package/@c-frame/three-to-ammo

So we should target a fix to this repo: https://github.com/c-frame/three-to-ammo
Then I can push to npm, and moving to the latest version should solve this issue.

No need for patch-package any more...

[Tpleme]

Thank you for your help in this issue.

I am taking my first steps on WebXR, but i would love to help you guys in this repo if theres anything i can do.

[Tpleme]

I have opened a PR to fix this issue. Fix: IncludeInvisible including invisible child elements#6