Is it possible to update StaticCollider

[skywalkershen]

There are several cases that:

• It might be possible to occasionally transform child mesh
• It might be possible to occasionally transform the already generated static mergedMesh

I know there is a kinematicCollider, yet it is too expensive to use since it is updating transform on every frame, and like staticCollider, once a bvh is constructed, there is no way to update it, and the rerender of the collider will trigger the child meshes' rerender.

It would be more convenient to provide interface for update mergedMesh's transform and refit/recomposing boundsTree.

[ErdongChen-Andrew]

Good point! I think in your case, you can access the boundsTree of the map directly from the global store and call boundsTree.refit() when needed.

const colliderMeshesArray = useEcctrlStore((state) => state.colliderMeshesArray);
// then access geometry.boundsTree from one of the meshes

I’ll also add an active prop to the KinematicCollider so it won’t update every frame unless needed

[skywalkershen]

Good point! I think in your case, you can access the boundsTree of the map directly from the global store and call boundsTree.refit() when needed.

const colliderMeshesArray = useEcctrlStore((state) => state.colliderMeshesArray);
// then access geometry.boundsTree from one of the meshes
I’ll also add an active prop to the KinematicCollider so it won’t update every frame unless needed
Thank you for the reply.

Actually I've tried accessing mergedMeshsArray from store.
But the thing is that the mergedMesh is created in StaticCollider scope and then directly pushed to the store. And since it is stored in array, not mapped with id, there is no way to tell which mergedMesh is the one needed to be adjusted outside the Collider.

So I got two approaches in my implementation:

1. for some scenario requires high level of customization, I simply skip Collider component and implement mergedMesh and bvh reconstruction logic in my code and push it to the EcctrolStore. The pro is that I have full access to mergedMesh, the con is that since I have both props like position/rotation/scale as props passing down to control the mesh, as well as transform controls to mutate the scene graph node property in place, I have to handle all the matrix transformation and some model preprocessing myself and carefully sync it to mergedMesh, which is prone to error.
2. Another option is kind of hacky:

return isDynamic? (
      <group
      key={`primitive-no-collider-container-${config.id}`}
      onPointerEnter={onMeshPointerEnter} 
      onPointerLeave={onMeshPointerLeave} 
      onPointerOver={onMeshPointerOver} 
      onClick={onMeshClick} 
      onPointerMissed={onClickMissed}
      >
        <primitive 
          key={`primitive-no-collider-${config.id}`}
          ref={ref} 
          object={memedScene} 
          position={position} 
          rotation={rotation} 
          scale={scale} 
          visible={isLoaded} 
        >
          {children}
        </primitive>
      </group>) : (
      <StaticCollider 
        key={`collider-${config.id}`}
        onPointerEnter={onMeshPointerEnter} 
        onPointerLeave={onMeshPointerLeave} 
        onPointerOver={onMeshPointerOver} 
        onClick={onMeshClick} 
        onPointerMissed={onClickMissed} 
        debug={false}
      >
        <primitive 
          key={`primitive-collider-${config.id}`}
          ref={ref} 
          object={memedScene} 
          position={position} 
          rotation={rotation} 
          scale={scale} 
          visible={isLoaded}
        >
          {children}
        </primitive>
      </StaticCollider>
    )

It simplifies the logic by supposing for most of the cases mergedMesh should be static, and will remove the collider during mesh modification, and when the modification is done, reconstruct the collider. The thing is there is always reconstruction of the mergedMesh and removing/adding back node to scene graph, which will leads to a obvious pause if the manipulated mesh is with complicated geometry.

So, I would like to suggest:

1. For collider, maybe useImperative/forwardRef to expose a reconstruct/refit method so user can modify the specific mergedMesh
2. For collider, since it is a group wrapping all the children, maybe it would be nice to update the transform of mergedMesh according to the transform of the group, that way the user can take all the children as grouped, and just manipulating with the collider then getting bvh updated automatically, instead of manipulating children nodes and manually syncing transform to the bvh.
3. For the mergedMeshStore and collider, maybe it would be better to add an id as prop for collider when generating mergedMesh, then store them as Map, and provide a method to getMergedMeshById, that provides more flexible control to modify specific mergedMesh

I really appreciate the work you have done and sorry for not being able to make pr for my points due to tight schedule.

Btw, are you posting on rednote for this project and previous physics engine based control? I also commented on one of your post, if possible, may I add you as contact on wechat?

Thank you.

[skywalkershen]

Another thing, is it possible to generate/dispose bvhHelper depending on props debug rather than always generate bvhHelper and only toggle their visibility on debug change? From my memory snapshot, for some scenario, the bvhHelper itself takes over 100mb, so it would be nice to have an option not generating bvh at all

[ErdongChen-Andrew]

In v0.0.17, you can assign a bvhName to <StaticCollider bvhName="map001" > or <KinematicCollider bvhName="map002" >. This allows you to reference them in the global store by name. The mergedMesh is used only once for bvh generation, they are not rendered or added to the scene, so not included as children of the collider group.
The <KinematicCollider> now supports active prop, which can toggle its behavior.
BVH helper should now work as expected, they will only generate when debug is true.