[render_vtk] Cloned instances can interfere with each other with textured models

SeanCurtis-TRI commented 1 year ago

What happened?

This is subtle, but when a render engine gets cloned and we perform interleave renderings between the two engines, they somehow interfere with each other.

The best understanding of this bug is best articulated in this branch. It has a test that illustrates the bug.

In short, if I had a RenderEngineVtk A; and I defined auto B = A.clone();, and then call A.RenderColorImage() and B.RenderColorImage() alternatingly (without changing anything else), I should get the same image over and over. I don't.

1) The first image from A and B may not disagree (depending on the definition of the materials being rendered). 2) If I render A - B - A, then all renderings from A starting with its second have terribly incorrect materials (the ones that originally had textures). If I reversed the ordering to B - A - B, then the situations reverse and B's images (from the second onward) are messed up.

Below, I've attached the images from the linked test. The rendering pattern is A1 - A2 - B1 - A3 - B2.

- A1 and A2 match (we can render from A multiples times without problems).
- B1 *looks* similar but its material is slightly different - the diffuse value has been lost.
- A3 is completely messed up.
- B2 matches B1 -- B is not harmed (beyond its original error) for interleaved rendering.

image_A1 A1

image_A2 A2

image_B1 B1

image_A3 A3

image_B2 B2

Version

@75114dca8d

What operating system are you using?

Ubuntu 22.04

What installation option are you using?

compiled from source code using Bazel

Relevant log output

No response

SeanCurtis-TRI commented 1 year ago

@jwnimmer-tri If I've understood what I'm seeing properly, this should cause problems for RgbdSensorAsync. I'll poke and confirm.

jwnimmer-tri commented 4 months ago

@SeanCurtis-TRI I seem to recall we changed some similar things recently. Maybe those were all in render_gl though? Anyway, same question either way: do we still think this bug exists, and is real?

SeanCurtis-TRI commented 4 months ago

Well, my linked branch that illustrates the problem still exists. I can certainly rebase it and re-run it. Should be easy enough to find out.

SeanCurtis-TRI commented 1 month ago

The branch has been rebased as of today in order to test against #21962. The change to mapper there is insufficient to correct this issue.

RobotLocomotion / drake