ogsRender produces different image results from viewport/render view

[dj-mcg]

Describe the bug Automated tests will use ogsRender to produce image results. This will often produce images that are different from those that are seen in the viewer or render window when working interactively.

Steps to reproduce Steps to reproduce the behavior:

1. Run testProxyShapeDrawColorAccuracy
2. Observe the resulting image - only the top face illuminated, noisy shadow pattern

Expected behavior The image matches what is seen in the viewport

[santosg87]

adding the pxr label, as this requires the pxr-USD unit tests

[huidong-chen]

@santosg87 Do we still have this issue? I think our automation relies on ogsRender so it might already be working?

[mattyjams]

Hey @HdC-adsk! We're still seeing a strange discrepancy here when comparing the behavior between the Pixar batch renderer and the VP2.0 render delegate.

I'm using the test scene located here: https://github.com/Autodesk/maya-usd/blob/dev/plugin/pxr/maya/lib/pxrUsdMayaGL/testenv/ProxyShapeDrawColorAccuracyTest/ProxyShapeDrawColorAccuracyTest.ma

When I open that scene in interactive Maya (2019.2), set the Cube_1 assembly to Collapsed, and switch the lighting mode to "All lights", here's what I see with the Pixar batch renderer:

And here's what I see with the VP2.0 render delegate:

There's a bit of a brightness/value difference between the two, but otherwise they match reasonably closely, which is good.

I'm getting different results though when I generate the images through the unit test here: https://github.com/Autodesk/maya-usd/blob/dev/plugin/pxr/maya/lib/pxrUsdMayaGL/testenv/testProxyShapeDrawColorAccuracy.py

With the Pixar batch renderer, I'm getting this:

While with the VP2.0 render delegate, I get this:

It looks like maybe shadow bias artifacts? I'm not sure why we're seeing something different with the render delegate between the viewport and ogsRender though.

[huidong-chen]

Hey @mattyjams , How can I run the unit test? I cannot reproduce it manually so would like to see if there is any difference in the unit test.

[mattyjams]

@HdC-adsk: Yeah, it is unfortunately fairly cumbersome right now, but here's how I'm running the test in the maya-usd repo on Linux (we have it automated internally):

• Navigate to the directory that contains the test scene: cd plugin/pxr/maya/lib/pxrUsdMayaGL/testenv/ProxyShapeDrawColorAccuracyTest

• Launch Maya with the MAYA_MODULE_PATH set so that the built plugins are available.

• Copy and paste the contents of the unit test script here into a Python script editor tab.

• Replace the if __name__ == '__main__' block at the end with something like this instead:

  
  suite = unittest.TestLoader().loadTestsFromTestCase(testProxyShapeDrawColorAccuracy)

results = unittest.TextTestRunner(stream=sys.stdout).run(suite) if results.wasSuccessful(): print("SUCCESS") else: print("FAILURE")

- Execute everything in the script editor tab and that should run the test. You should hopefully then find the output images in the newly created `tmp` directory in your current working directory.

[mattyjams]

I took another look at this, and I think things are indeed working as expected.

The Storm-based Pixar batch renderer (poorly) supports depth map shadows but not ray-traced shadows, while the Viewport 2.0 render delegate supports both. The directionalLight in the Maya scene for the testProxyShapeDrawColorAccuracy test was set to use ray-traced shadows (which is the default). This meant that the "all_lights" image written by the test would not include shadows when run with the Pixar batch renderer, but it would include a very noisy shadow when run with the Viewport 2.0 render delegate, since the geometry is just a very simple cube.

When using the Viewport 2.0 render delegate in an interactive Maya session, if I switched to using "All lights" and turned on shadows, then I started seeing something in the viewport that looked more like the noisy shadow image generated by ogsRender.

Shadows aren't important in this test, so I simply turned them off in #815.

Thanks for taking a look @HdC-adsk!

[mattyjams]

This should be resolved with the merge of #815. Closing...