Drake: Upgrade MeshcatVisualizer to use QueryObject
I keep running into small changes I'd like to make that would be trivial given the QueryObject interface to SceneGraph, but are difficult/impossible using the current lcm draw message communication. For instance, I want to visualize the collision geometry instead of the visual geometry, but cannot.
This shouldn't be a hard change, but I don't quite have the cycles to do it myself yet. Any volunteers?
RussTedrake
All 5 comments
EricCousineau-TRI
on 14 Oct 2020
Also related to #13038 and #13934. I think the right solution for all of these is to write a shiny new MeshcatVisualizer in C++.
If we do rearchitect, then another pain point of the current architecture is that meshcat animations do not include any meshcat visualizations that are performed outside of MeshcatVisualizer. For instance, MeshcatContactVisualizer is a separate system, and we cannot include contact force visualizations inside the animations. For that particular example, we could potentially have an optional contact results input port on the MeshcatVisualizer system, but more generally, it would be nice to think through whether there is a better way to allow external meshcat calls that get recorded.
RussTedrake
on 2 Nov 2020
If I were working on this, I'd first want to do the feature port to QueryObject in Python, just to change as little as possible as an aid for debugging.
At that point, it would be fairly rote to copy the implementation into C++ and work on the zmq build dependencies, etc. We could ask Kitware to take the porting part, for example, but probably not the QueryObject rewrite part.
For recording animations, I'd advocate that it live on the receiving (server) end, not the client end. That way, all clients' contributions are recorded in one place.
jwnimmer-tri
on 2 Nov 2020
Agreed on both. I will take the token on this, and hope to have the QueryObject upgrade in python soon.
RussTedrake
on 4 Nov 2020
I'm going to close this and rely on #13038 to track the migration to c++.
RussTedrake
on 15 Nov 2020
Related issues
peteflorence
路
5Comments
Islam0mar
路
4Comments
RussTedrake
路
4Comments
liangfok
路
4Comments
palmieri
路
4Comments
Most helpful comment
Also related to #13038 and #13934. I think the right solution for all of these is to write a shiny new MeshcatVisualizer in C++.
If we do rearchitect, then another pain point of the current architecture is that meshcat animations do not include any meshcat visualizations that are performed outside of MeshcatVisualizer. For instance, MeshcatContactVisualizer is a separate system, and we cannot include contact force visualizations inside the animations. For that particular example, we could potentially have an optional contact results input port on the MeshcatVisualizer system, but more generally, it would be nice to think through whether there is a better way to allow external meshcat calls that get recorded.