Task: evaluate externalized ids prototype for high-priority use cases.

[paulmartel]

Task: evaluate externalized ids prototype for high-priority use cases.

[w0rm]

Example use cases include:

• connecting the bodies/shapes from the physics engine with user defined information (like meshes, color, etc.)
• being able to select bodies with mouse
• being able to interact with certain bodies
• being able to detect collisions events (when a certain body has collided with another body)
• being able to query specific information from the engine, e.g. where is a certain body located now

[paulmartel]

1. connecting the bodies/shapes from the physics engine with user defined information (like meshes, color, etc.)
   

See the updated Spheres example.

2. being able to select bodies with mouse
   

Seems like this would need customized Ray/Shape collision detectors to calculate which shape if any has the closest collision along a ray ( a pair of Vec3's for world position and world normal ) projected "from the camera" through the clicked point on the view screen.

3. being able to interact with certain bodies
   

Any kind of meaningful interaction will involve replacing immutable bodies in a copied world (and possibly immutable shapes within copied bodies. It seems to make sense that these replacements would keep take over the ID associations of their originals, so any exposed IDs would remain valid.
We'd probably also want a means of deleting bodies from the world (MAYBE shapes from bodies, too, but this seems less useful) with a simultaneous purge of all external structures referencing their IDs. I'm imagining that in the long term we may want some kind of callback registry to support this.

4. being able to detect collisions events (when a certain body has collided with another body)
   

This seems like a variation of your code to expose all contacts (for diagnostic display) with added filtering for specific objects and possibly for new vs. previously reported/handled contacts. This MAY also be some kind of registered callback or event queuing done by the regular collision detection code.

5. being able to query specific information from the engine, e.g. where is a certain body located now
   

Mapping IDs back through the world to access current physics state and attributes seems not very difficult.

Maybe we should prioritize these and split them out as separate issues/tasks.

[w0rm]

@paulmartel I think I've already mentioned this, but what do you think about only exposing body ids? The shapes can be pretransformed at the time of addition to a body. From the user point of view, meshes can be generated for the whole bodies, meaning less meshes and less WebGL draw calls.

[w0rm]

I decided against id in the new api #43, because ids make api very difficult. The Body data approach lets users decide what they want as data. This can be meshes https://github.com/w0rm/elm-physics/blob/master/examples/Common/Bodies.elm that really simplified the demo setup, or even ids if users wish to link external information.