-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metallic IBL Reflection #1356
Metallic IBL Reflection #1356
Conversation
@mattyjams and @JGamache-autodesk , the logic I'm applying here is pretty simplistic. I'm not sure if the metallic+roughness logic that is in For reference, this is the code from the lighting fragment.
At the very least, it allows for a basic reflection estimation in the viewport now |
We've tried to adapt the specular formula into the combiner with some modifications as we believe pertains to reflectivity. Below you can see a comparison of the before and after of the test sphere with our test IBL, with before and afters of this PR. I include the lit and unlit versions to discern how much things differ. Lit is forward/colorful, unlit is behind and greyscale since the sphere itself has no color. The shader setup in Maya is that the sphere is a light grey, with a black/white checkerboard in the specular/metalness parameters. The IBL is a validation room with a checkerboard pattern and bright text. Similarly here is a comparison with the gramaphone asset in the Apple USDZ gallery. Again, each section includes the lit and unlit version of each asset. The IBL is a basic HDR room. I believe however the specularity of the metallic workflow should be tinted by the diffuse color, but I am not sure how to integrate that into this specific fragment. In both images you can see that the unlit versions remain unaffected as we hope. Note: I have not attempted to update the clear coat logic that @JGamache-autodesk mentioned yet. Perhaps that should be left to a secondary PR, once this one is sorted. |
4bde3fa
to
617f3c3
Compare
lib/mayaUsd/render/vp2ShaderFragments/usdPreviewSurfaceCombiner.xml
Outdated
Show resolved
Hide resolved
lib/mayaUsd/render/vp2ShaderFragments/usdPreviewSurfaceCombiner.xml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already looks a lot better for metallic workflows. I have a small thing that might help if you want to try it, otherwise the code is a big step in the right direction.
There is a nice discussion on metallic looks here if you are interested: PixarAnimationStudios/OpenUSD#1174 |
Thanks for that reference and the pointers, they help clarify quite a bit. I'll iterate a bit more internally and update the PR accordingly. |
617f3c3
to
8e3c485
Compare
…eview Surface spec
8e3c485
to
8801944
Compare
I think your suggestions really helped. Here's a new before and after. Let me know if you think there's any other changes I should try here, but otherwise I feel like this is in a good state for me personally. |
Looks nice indeed. Thanks. |
Looking great indeed. Great job! |
@kxl-adsk I'll look into that however I had some questions:
|
We are adding support for interactive tests in PF, but we won't have the ability to add them with additional dependencies (like MtoA). So Arnold SkyDome is not something we can use in tests. @JGamache-autodesk do you have any recommendations on what would make sense to do in a test without Arnold dependency? |
Thanks! I'll get that set up as part of this PR. |
@kxl-adsk I've added a test to this PR. I also made some modifications to the utility libraries to handle changing cameras and differing color management environments (it was erroring in our environment where we had recently enabled color management workflows) |
We recently debugged a scene that failed to render correctly with the V2 Light API. The main issue with shadows was fixed in another PR, but there were still 3 other problems where the Light API V1 was not on-par with USD and the V2 Light API. 1- Directional light affects IBL lighting Create a test scene: - 20x20 plane at the origin, usdPreviewSurface shading, 50% metalness - aiSkyDomeLight with an environment map - Directional light with *zero* intensity Rotate the directional light, and watch how it affects the lighting of the plane. That light has zero intensity, so it should have no effect. 2- textured occlusion does not affect environment lighting One of the assets in the scene had a textured occlusion map which correctly worked with scene lights, but not with aiSkyDome lights. 3- specular highlights from regular Maya lights did not have enough base color for metallic workflows. That one was fixed for aiSkyDome lights in PR #1356 but direct lighting still used the old formula.
The USD Preview Surface shader setup only reflected IBLs (represented by an Arnold SkyDomeLight with a texture) if the specular color was not black. It also did this when the specular workflow was not enabled.
This PR fixes that (and addresses my needs in #933), so that metallic workflows also are capable of reflecting the IBL.
I also took the liberty of removing the autogeneration comments because, as far as we could discern, these are no longer direct results of the auto generation.