Should support a (basic) resource pool?

[EricCousineau-TRI]

In RobotLocomotion/drake#13971, @RussTedrake found that having HTML JS clients re-download the IIWA meshes every time for each new pydrake...MeshcatVisualizer instance is rather slow.

He was able to work around it by #75, which relies on using the same existing object path.

In an ideal path, there would be a way to (naively) cache the data objects (perhaps on the sending client side?) based on byte comparison.

Then you get the same benefit; additionally, if someone were to visualize a large scene (e.g. 20 IIWAs in the same setup), the websocket only has to receive the meshes once (rather than 20 times).

\cc @gizatt

[EricCousineau-TRI]

From the README: https://github.com/rdeits/meshcat/tree/85fd641e8897ffe453502e0ec152225562999b0b#programmatic-api

The actual geometry and material for a given object are simply references to those existing UUIDs. This enables easy re-use of geometries between objects in Three.js, although we don't really rely on that in MeshCat. Some information about the JSON object format can be found on the Three.js wiki.