Support per-instance cursor events on BatchedMesh / InstancedMesh

[vincentfretin]

I open this for feedback. I just started using it in a project where I use a component to handle an hover/open/close animation on an instance of an InstancedMesh in a glb.

Live example

Multiple a-entities sharing a single BatchedMesh (draw-call reduction) or InstancedMesh (instancing) all map to the same host entity, so the raycaster and cursor collapse hover / click tracking across every logical instance: ray moves between two instances of the same shared mesh, nothing fires.

raycaster: also fire raycaster-closest-entity-changed when the closest hit's (entity, batchId, instanceId) tuple changes, even if the entity is unchanged. No per-instance mapping in core — the raycaster's role stops at surfacing batchId / instanceId on intersection details.

cursor: track (intersectedEl, intersection.batchId, intersection.instanceId) as the hover identity. Transitions within a shared mesh now fire mouseleave with the OLD tuple and mouseenter with the NEW tuple. The stored intersection is used for event payloads so leave events carry the outgoing instance's details, not the incoming one.

App-level mapping: the new examples/test/raycaster-batched-mesh example shows a batch-proxy component on each host entity that holds its own map from id to member entity and forwards mouseenter / mouseleave / click to the matching per-instance entity. Keeping the map in userspace lets apps encode whatever identity makes sense (batchId, instanceId, custom composite keys) without expanding the core component API.

Tests cover intersection details carrying batchId / instanceId, raycaster-closest-entity-changed firing on tuple-only change, and the cursor's tuple-aware mouseleave/mouseenter sequencing with the outgoing tuple in detail.intersection.

[vincentfretin]

I fixed the tests I forgot to run yesterday when I fixed the uv issue and added a non regression test for the fresh uv coordinates on click. I created another branch with the dist so you can see the example

[mrxz]

Conceptually all raycasting and cursor interactions happen on the entity level, regardless of what the Three.js contents of that entity is. While exposing more details about the intersections so that the app-level logic can handle it is fine, the changes to the events don't seem correct to me. Though obviously both are needed for the example to work properly.

For one, raycaster-closest-entity-changed now fires even if the entity hasn't changed, as a change in either instanceId and batchId is enough. Secondly I doubt that the tuple (entity, batchId, instanceId) is sufficient, as there can in theory be more than one InstancedMesh or BatchedMesh inside an entity. Say moving the cursor from instance 1 of one InstancedMesh to instance 1 of another InstancedMesh would then not registered.

My main concern is with users that simply load any arbitrary GLTF file. Depending on the file itself, an InstancedMesh might end up inside the entity. For no apparent reason to the user, this model behaves differently compared to others, with mouseenter/mouseleave events emitted without ever leaving the model, for example.

Perhaps the raycaster can be changed such that the entity level events remain unchanged, but in addition it emits "scenegraph level" events. Even without corresponding changes in cursor this might already be useful in case users are looking for raycasting against InstancedMesh/BatchedMesh or even just individual THREE.Mesh instances.

The cursor component could then be expanded to support two distinct modes, either the (current) entity based tracking or the "scenegraph" based on. (Obviously a better/clearer name than "scenegraph" would be needed). Though I'm not sure the complexity is really worth it. Depending on if/how #5396 gets implemented, it might be better to keep everything operate on the entity level, and have the raycaster/cursor know how to handle the A-Frame built-in way of doing BatchedMesh?