-
Notifications
You must be signed in to change notification settings - Fork 10
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
Incorrect render result. Maybe because of FaceVarying normals? #48
Comments
Hi @evantryan One thing I could support is either a constant or uniform (whole object or per-face) smooth/hard boolean primvar which could at least set hard/smooth this way, but that would require setting this manually. |
Semi-fixed here: This should match the Blender way of setting hard/smooth normals. What you'll need to do is create a PrimitiveVariables node and make a constant boolean named "_smooth" to set what you want. Next build should have this. Cheers! |
@boberfly That is awesome! Thank you! Should this be a checkbox in the CyclesAttribute node? Thanks again! |
Due to how it could be constant or uniform it is a primitive variable rather than an attribute, but perhaps for the constant case it could also be set as an attribute as an alternative way... |
I'm not entirely sure if this should be an issue. I'm getting a warning...
WARNING : MeshAlgo : Variable "N" has unsupported interpolation type - not generating normals.
when rendering with cycles. Unfortunately, the render result is also incorrect.
I've seen in other threads that this is because cycles doesn't support FaceVarying Normals. I've also seen a mention of using a MeshType node to get the correct results. I have been unable to find a combination of options in that node to get correct sharp normals.
I've included a simplified gaffer file along with some cache files (just a cube) from blender, maya and gaffer (in case it had to do with where the alembic came from). The gaffer file has a cycles set up and an appleseed set up for comparison. I've also included a cycles render from blender to show what the expected render would look like.
Is this a bug? If not, is there a way to get the cycles result in gaffer to look like the result from blender?
Thank you so much for working on GafferCycles!
example of the issue from gaffer cycles...
example of expected result from blender cycles...
gaffer appleseed render for comparison...
example gaffer scene and supporting alembic caches...
example_files.zip
The text was updated successfully, but these errors were encountered: