USDMeshLight - #6970
Conversation
|
There was a test failure from I didn't see a particularly good fallback, but USD has updated their attribute descriptions in the USDLux schema, so I think it might be ready to use again. That along with a placeholder description for the Arnold parameters satisfies the documentation requirement for all plugs. |
johnhaddon
left a comment
johnhaddon
left a comment
There was a problem hiding this comment.
Thanks Eric! Comments inline as usual. In addition to those, I think it's also worth adding a conversion to 3Delight, since folks have been asking for better support on Discord recently. Similarly I think there's a decent case for adding for Cycles too, since the existing CyclesMeshLight is a bit of a weird anomaly (it doesn't actually make a light).
5f7c795 to
6afc7e7
Compare
|
This is in good shape now for a look at the existing fixups. I added one more commit for Arnold : github.com//pull/6970/commits/6afc7e75cfc387638757eeab12165ed7635d0885. That corrects the behavior to multiply the light color with the surface glow response, creating a new We decided that if a mesh light has an input to I'll take care of the Cycles and 3Delight conversions next. |
Sorry, I should have read the UsdLux docs when we were having this discussion. They seem to be fairly clear that we should multiply the two together in this case :
Might be worth checking via |
|
I've updated the Arnold side of things here, and another small fix noted above.
Other than those and the RenderMan side which I think is close to having a plan ready, these updates are ready for a new look. |
Thanks Eric - Arnold stuff seems good. Might need to split the first commit up a bit when rebasing - the
Because the C++ function returns ConstPtr, we have a problem : Python has no concept of
There are two main reasons to release the GIL :
In this case, 1 doesn't apply, but 2 could in theory, so I think the way you have it is fine. |
4f3d75f to
3118fae
Compare
a37184d to
a7632fd
Compare
fad8deb to
a980a06
Compare
This fixes errors like the following :
```
Error: FAIL: testDisplayDriverAndPromotion (GafferSceneTest.CatalogueTest.CatalogueTest.testDisplayDriverAndPromotion)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/__w/gaffer/gaffer/build/python/GafferSceneTest/CatalogueTest.py", line 387, in testDisplayDriverAndPromotion
self.sendImage( r["out"], s["b"]["c"] )
File "/__w/gaffer/gaffer/build/python/GafferSceneTest/CatalogueTest.py", line 61, in sendImage
result = GafferSceneTest.DisplayTest.Driver.sendImage( image, GafferScene.Catalogue.displayDriverServer().portNumber(), extraParameters, close = close )
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/__w/gaffer/gaffer/build/python/GafferSceneTest/DisplayTest.py", line 150, in sendImage
driver.close()
File "/__w/gaffer/gaffer/build/python/GafferSceneTest/DisplayTest.py", line 115, in close
with GafferTest.ParallelAlgoTest.UIThreadCallHandler() as h :
File "/__w/gaffer/gaffer/build/python/GafferTest/ParallelAlgoTest.py", line 70, in __exit__
raise AssertionError( "UIThread call queue not empty" )
AssertionError: UIThread call queue not empty
```
We have only seen these on CI, but they can be reproduced artificially by inserting `time.sleep()` before L119 in DisplayTest. The problem is that with the right thread timings, the Catalogue can save the image to disk and request an extra UI thread call before `close()` calls `assertDone()`. The `sleep()` just makes the bad timing inevitable, but it could occur naturally when the CI machine is under unusual load.
The solution is to move the `close()` call under the same UIThreadCallHandler as the one used to check for saving, and only call `assertDone()` once at the end.
The weaving of `DisplayTest.sendImage()` and `CatalogueTest.sendImage()` with all their various permutations is getting a bit much. It does seem tempting to attempt an approach based on `assertEventually()` instead.
These match our current descriptions for Arnold light plugs.
|
The latest commits have overhauled the way I'm handling the USDMeshLight and also adds 3Delight and Cycles rendering. It's quite a big PR now, but there are patterns I've tried to make common between each renderer where possible that will hopefully make it easier to track. My main reservation now is that the Arnold backend is treating the lights more like Arnold mesh lights and not so much like USD lights. Originally I think that was intentional to get the better sampling like we get from ArnoldMeshLight, but I think we might instead need to follow the example of the other renderers and duplicate the mesh for the mesh light portion. But I'm holding off on that for now to get some other eyes on this before I make that departure. |
|
Thanks Eric! Could you reopen this from a branch on the main repo please, so renderer-specific CI can do its thing? |
|
Closing this in favor of #7098 for test running. |
2 participants
This adds USDMeshLight support for Arnold and RenderMan. The USD spec, in the default mode, calls for taking the mesh light color texture from the surface shader, if one exists. There are a couple of other simpler modes I haven't implemented yet, but I can add those in a follow-up PR or add them on here.
There's also new support in this PR for visualising mesh light textures using the existing renderer-specific texture registration system. I didn't implement the surface texture swapping for those visulisations, but it can also be added once we're happy with the overall direction here.
Checklist