Skip to content
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

Open
evantryan opened this issue Apr 17, 2020 · 4 comments
Open

Incorrect render result. Maybe because of FaceVarying normals? #48

evantryan opened this issue Apr 17, 2020 · 4 comments

Comments

@evantryan
Copy link

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...
test_cycles

example of expected result from blender cycles...
test_cycles_blender

gaffer appleseed render for comparison...
test_appleseed

example gaffer scene and supporting alembic caches...
example_files.zip

@boberfly
Copy link
Owner

boberfly commented Apr 21, 2020

Hi @evantryan
Yep Cycles doesn't support FaceVarying out of the box and Blender/Cycles is really tagging at a per-face level whether or not to 'smooth' it which doesn't convert very well to how Cortex/Gaffer conveys the data. It's a fairly non-trivial thing to solve other than patching Cycles itself to support 'Corner' normals ('FaceVarying' is 'Corner' in Cycles-speak) or splitting the vertices so that they can have unique normals, but this would require some complex conversion code.

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.

@boberfly
Copy link
Owner

Semi-fixed here:
891da24

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!

@evantryan
Copy link
Author

@boberfly That is awesome! Thank you! Should this be a checkbox in the CyclesAttribute node? Thanks again!

@boberfly
Copy link
Owner

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants