Drake's precompiled drake-visualizer renders meshes incorrectly

[rdeits]

Rendering a mesh in the drake-visualizer shipped with Drake causes that mesh to be displayed incorrectly, almost as if the normals are all inside-out. The exact same mesh renders properly in the drake-visualizer compiled with Director master and with the binary drake-visualizer provided by Pat at https://bintray.com/patmarion/director/ .

Here's a mesh rendered in drake-visualizer, as built by Director master:

And here's the same mesh rendered in the drake-visualizer shipped with Drake:

The easiest way to test this without starting a simulation is to manually send a load_robot message to the visualizer. The following Python snippet does so (but will need to be adjusted to run on anyone else's machine):

import sys
sys.path.insert(0, "/home/rdeits/locomotion/drake/install/lib/python2.7/site-packages")
import lcm
import drake
msg = drake.lcmt_viewer_load_robot()
msg.num_links = 1

link_msg = drake.lcmt_viewer_link_data()
link_msg.name = "torso"
link_msg.robot_num = 1
link_msg.num_geom = 1

geom_msg = drake.lcmt_viewer_geometry_data()
geom_msg.type = 4
geom_msg.position = [0, 0, 0]
geom_msg.quaternion = [1, 0, 0, 0]
geom_msg.color = [1, 1, 1, 1]
geom_msg.string_data = "/home/rdeits/locomotion/drake/examples/valkyrie/urdf/model/meshes/torso/torso.dae"
link_msg.geom.append(geom_msg)
msg.link.append(link_msg)
lc = lcm.LCM()
lc.publish("DRAKE_VIEWER_LOAD_ROBOT", msg.encode())

[rdeits]

@jamiesnape assigning you, as requested

[rdeits]

All versions of drake-visualizer do show this issue if the mesh's alpha is less than 1.0. I recall that being a fundamental VTK issue, but I'm not sure what the problem is. The only difference is that the version shipped with Drake also shows this issue at alpha=1.0

[SeanCurtis-TRI]

Generally, I'd imagine this is related to how transparency is handled (i.e., doing a front-to back ordering) and is addressed with the "transparency peeling" switch in VTK.

[jwnimmer-tri]

I'll propose that we don't try to repair director (or rebuild VTK), but rather just work around this in Drake -- e.g. don't set alpha to anything other than 0 or 1 when transmitting load_robot on meshes. Or scream in the console. Or something. => dynamics

[SeanCurtis-TRI]

Acknowledged.

I'll probably modify the code where we dispatch model definitions to drake_visualizer. That should be the correct pinch point in the hour glass. That way, whether screwy values come in via parsing or user-settings, they'll get processed immediately before hitting drake visualizer.

Admittedly, there's nothing we can do about referenced objs that, in turn, reference material files that provide non-binary transparency. But, hey, you can't have it all.

[SeanCurtis-TRI]

@jamiesnape This behavior seems to no longer be present. Does drake_visualizer depend on drake's specific VTK dependency and could this have been alleviated by subsequent updates to the VTK binaries?

[jamiesnape]

Yes and possibly.

[SeanCurtis-TRI]

Good to know. I'm not 100% confident of the sample test I did. I'll try another that more closely reflects the issue's problem description to convince myself of whether this issue can/should be closed or not.

[jwnimmer-tri]

As of #12664, the Valkyrie models are no longer on master. Might be time to just close out this issue.

[SeanCurtis-TRI]

I'm going to close this. It can be re-opened if we have a more concrete repetition of the error.