Meshcat SetProperty Method Can't Toggle Visibility

[cohnt]

What happened?

Previously, I was able to toggle the visibility of a meshcat visualizer programmatically with, e.g.,

collision = MeshcatVisualizer.AddToBuilder(
        builder, scene_graph, meshcat,
        MeshcatVisualizerParams(role=Role.kProximity, prefix="collision"))
meshcat.SetProperty("collision", "visible", False)

However, I've noticed that this no longer seems to work. I put together a simple example below (partially based on this). I would expect it to display the collision geometry, but not the visual geometry, but both are visible.

sdf = """<?xml version="1.0"?>
<sdf version="1.7">
  <model name="foam_brick">
    <link name="base_link">
      <inertial>
        <pose>0 0 0.025 0 0 0 </pose>
        <mass>0.028</mass>
        <inertia>
          <ixx>1.17e-5</ixx>
          <ixy>0</ixy>
          <ixz>0</ixz>
          <iyy>1.9e-5</iyy>
          <iyz>0</iyz>
          <izz>1.9e-5</izz>
        </inertia>
      </inertial>
      <visual name="base_link">
        <pose>0 0 0.025 0 0 0</pose>
        <geometry>
          <box>
            <size>0.075 0.05 0.05</size>
          </box>
        </geometry>
        <material>
          <diffuse>0.31 0.01 0.13 1.0</diffuse>
        </material>
      </visual>
      <collision name="box_collision">
        <pose>0 0 0.025 0 0 0</pose>
        <geometry>
          <box>
            <size>0.074 0.049 0.049</size>
          </box>
        </geometry>
      </collision>
    </link>
  </model>
</sdf>"""

from pydrake.all import (
	StartMeshcat,
	DiagramBuilder,
	AddMultibodyPlantSceneGraph,
	Parser,
	MeshcatVisualizer,
	MeshcatVisualizerParams,
	Role,
	JointSliders
)

def model_inspector():
    meshcat.Delete()
    meshcat.DeleteAddedControls()
    builder = DiagramBuilder()

    plant, scene_graph = AddMultibodyPlantSceneGraph(builder, time_step=0.001)
    parser = Parser(plant)
    parser.AddModelsFromString(sdf, "sdf")
    plant.Finalize()

    # Add two visualizers, one to publish the "visual" geometry, and one to
    # publish the "collision" geometry.
    visual = MeshcatVisualizer.AddToBuilder(builder, scene_graph, meshcat,
        MeshcatVisualizerParams(role=Role.kPerception, prefix="visual"))
    collision = MeshcatVisualizer.AddToBuilder(
        builder, scene_graph, meshcat,
        MeshcatVisualizerParams(role=Role.kProximity, prefix="collision"))

    # Should show the collision geometry and not the visual geometry, but it doesn't work
    meshcat.SetProperty("visual", "visible", False)
    meshcat.SetProperty("collision", "visible", True)

    sliders = builder.AddSystem(JointSliders(meshcat, plant))
    diagram = builder.Build()
    sliders.Run(diagram)

meshcat = StartMeshcat()
model_inspector()

Version

70fc904

What operating system are you using?

Ubuntu 22.04

What installation option are you using?

compiled from source code using CMake

Relevant log output

No response

[jwnimmer-tri]

Possibly #19578 is relevant here. I can take a look this week.

[jwnimmer-tri]

Note that MeshcatParams has a field visible_by_default. Setting that to False might work around the problem.

[jwnimmer-tri]

\CC @RussTedrake FYI

I think this is working as intended.

We have a struct MeshcatVisualizerParams with this field:

  /** Determines whether our meshcat path should be default to being visible. */
  bool visible_by_default{true};

When MeshcatVisualizer first publishes its geometry, that is the setting that governs whether or not the geometry starts out as visible. It does not try to adapt to anything that already exists in the scene tree; it publishes the geometry that it has, using the visibility its been configured for. In a sense, it "owns" that meshcat path and can do whatever it wants with it.

In your example code above, it seems pretty easy to set visible_by_default=False for the collision params. Is that a viable solution for you in general, or is there a more complicated use case where it's a problem?

---

Aside: It seems a bit unusual to visualize Role.kPerception instead of Role.kIllustration, especially with the path visual. Is that chose of the perception role on purpose? In case Illustration could be used instead of Perception, the functions AddDefaultVisualization or ApplyVisualizationConfig offer sugar to set up default visualizers, which include both illustration (i.e., visual) and collision (i.e., proximity) at once, with good defaults.

[cohnt]

I can confirm that using visible_by_default works for what I'm looking for. Thanks!

I mainly noticed this as a change in behavior (even if it is a change from unexpected behavior to expected behavior). If I run this code with Drake built at eb88259, for example, the behavior is as expected. I've seen the code used this way in a couple places, including Russ' manipulation notes. (Here, here, and here.)

Re the aside, this was a cobbled together attempt at a MWE, partially inspired by this. In my current project, I'm using Role.kIllustration for visual geometry, and Role.kProximity for collision geometry. But thank you for checking on that for me!

[jwnimmer-tri]

Possibly #19578 is relevant here. I can take a look this week.

I think either one of #19577 or #19578 would have caused this change in behavior.

In #19577, we started running the initialization event during JointSliders::Run, which would have triggered the pre-existing "set visible" during initialization, overriding your prior SetProperty.

In #19578, we delayed the "set visible" from an initialization event to the first stepped event, but that would still happen during JointSliders::Run regardless.

I've seen the code used this way in a couple places, including Russ' manipulation notes.

I've opened a PR to clean up the notes: RussTedrake/manipulation#239.

For others reading this, I'll underline again that in my mind the AddToBuilder is a low-level API, and users should prefer the high-level API AddDefaultVisualization or ApplyVisualizationConfig whenever possible. When using the low-level API, the user takes on more responsibility for putting together all of the pieces exactly right, which can lead to problems like this one.

If there are cases where the high-level API is not capable enough, I'm always happy to hear feedback in case we can improve it.