This is quite possibly a misunderstanding on my part. It looks like models are always shaded with flat polygons, and the interpolation setting has no effect. Regardless of the setting (Flat, Phong, Gouraud), all polygons are flat (see image below). This is using the “Lights” module, set to Default lighting. Shouldn’t Phong or Gouraud interpolation result in a less “faceted” appearance or am I mis-remembering how these work?
Preview 2021-12-19, MacOS, MBP 16" AMD Radeon Pro 5500M 8 GB.
Sharing requires surface normals. They can be computed in Surface Toolbox module.
Moat mesh file formats allow storage of surface normals. What file format are you reading your model from? What software has created the file?
It’s a segment converted to a model in Slicer. I computed surface normals in Surface Toolbox and it shades smoothly now - thanks!
I was a little confused because Gouraud shading doesn’t require normals (but Phong does). Anyway, thanks for the help!!
To clarify, Gouraud shading uses normals at the vertices to calculate lighting and then interpolates the colors across the triangle, Phong shading interpolates the normals and recalculates the lighting per-fragment across the triangle. So both require vertex normals. STL format, for example, does not save normals, so they need to be re-calculated for smooth rendeing.
In current Slicer versions, surface normal computation is enabled by default, but you can enable/disable it by adjusting segmentation representation conversion parameters:
Got it, ok. I thought Gouraud interpolated vertex colors across the polygon and didn’t use normals.
My undergrad computer graphics class was an embarrassingly long time ago.
Ah, okay - Thanks, Andras!
Hi Andras @lassoan,
Quick follow-up to this. It seems whenever I save models as PLY, even if I’ve computed surface normals before saving, when I reload the model files, the normals have been lost. Does Slicer save surface normals in PLY files?
VTK’s PLY reader reads point normals, but VTK’s PLY file writer does not write them.
I’ve submitted a merge request to VTK to add this feature:
Probably it can get into VTK in a couple of days, but I’m not sure when we’ll update Slicer’s VTK to include this update. If it is urgent then we can cherry-pick this feature (and then it’ll be available in the Slicer Preview Release the next day), otherwise it’ll be available in Slicer in a few months.
Thanks! No, not urgent at all. Just wanted to make sure it wasn’t something I was doing wrong.
Hi Andras @lassoan,
If I wanted to do a local build that would incorporate the VTK version with this change, how do I go about that? I tried changing _git_tag in External_VTK.cmake to the latest SHA but I get the following error (Windows):
Performing update step for 'VTK'
fatal: reference is not a tree: 21f9d5e14a695d9fc387aee86b28c36bbe19fdb5
CMake Error at D:/S/S4D/VTK-prefix/tmp/VTK-gitupdate.cmake:175 (execute_process):
execute_process failed command indexes:
The latest master VTK version does not contain some of the fixes that Slicer needs, so you need to backport the PBR fix into Slicer’s VTK. I’ll try to do this for the official Slicer release today or tomorrow.
If it’s too much trouble, this is not a critical need - I can work around by using Surface Toolbox to recompute normals when I reload PLY models.
I’ve just checked and latest Slicer Preview Release already includes the fix for writing of PLY normals.
Oh, great! Thanks!
This is what I get for being a few weeks behind in preview releases…