Uniform normals memory about hdblackbird

[boberfly]

Yeah I guess the Cycles devs might've just have flattened out buffers for speed benefits as perhaps indexed lookups might add some overhead in shading? Not sure here... :)

[dedoardo]

Yes, I think it's safe to close this for now. If a related feature request or bug comes up it should be addressed there.

[boberfly]

Hey @dedoardo

To be honest in-practice I don't think face normals are very common as your main geometry representation's normals. I believe enabling/disabling the smooth toggle is a very Blender-centric way of setting normals and something I don't think is needed in-practice with proper face-varying support. Also for subdivided models you would never want face-normals, you'd rely on creases and would keep the normals smooth. I'd like to be proven wrong though.

Also are you aware of using the GeometryNode shader that has "True Normal" as an output? That gives you the geometric normal, but I guess it would not work with light calculation (even so, I doubt the need for it and it can be emulated with face-varying normals and most likely these models would be base cage meshes/low-poly models anyways, so the 3x overhead isn't as bad as you'd think).

Actually I was wondering if indexed face-varying could be stored on the device instead for UVs (and I guess normals also) which would let you share vertices at the expense of storing an additional index buffer.

[dedoardo]

Hi @boberfly, thanks for the info.
I did not know about the GeometryNode! It does seem to be an output only node which reads information from the ShadingData so yes, it is limited to the geometric normal. As you said, the extra memory for uniform normals might not be that bad in the bigger scope of things.

The face-varying index buffer could be a good general-purpose solution for any attribute, but it seems like unnecessary machinery. I could be wrong and there could be other benefits to it though.

[bareya]

Are we closing this one?