Closed RussTedrake closed 3 years ago
Another alternative has always been to avoid the zmqserver. I have a working version of meshcat visualizer in python that relies only on ipython kernel comms as the transport. That works great on local machines, but not on colab / deepnote (both of which use a custom kernel implementation).
But perhaps I should consider a visualizer that hosts the websocket connection directly (as zmqserver does now). This would be instead of kernel comms, would have the advantage that it would work outside of jupyter, but would still cut out the zmq layer. This feels like perhaps the best solution. There are still many decisions to be made (do I support multiple clients? do I store the scene tree on the server and allow a new client to get the history, or act more like drake visualizer and require the viewer to connect before any important message is sent?).
Here's a burn-down list for this version
I've decided to run with the Meshcat in C++ solution for this. Closing this since I've moved the discussion to https://github.com/RobotLocomotion/drake/issues/13038
Related to #144 . This is a possible work-around for lack of interaction in deepnote (and spotty support for ipywidgets more generally in the jupyter-like cloud notebook ecosystem).
set_control
, e.g. viathis.set_control("test", this.mycallback, 50, 0, 100, 0.1);
in the javascript to add a slider to the ui.set_control
messages are also parsed in the javascript, it's easy enough to pass them through the zmqserver.this.set_control("test", '(value) => this.connection.send("slider=" + value)', 50, 0, 100, 0.1);
update_control
for this? Or a variant ofset_control
that takes only the value.update_control
messages.Note that the python client receiving the ui updates need not be the original
meschat.Visualizer()
object. I'd be happy to have a separatemeshcat.UISubscriber()
type object instead. It might be cleaner.