PolyData shading with vertex normals

[MrClock8163]

First check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the PyVista documentation, with the integrated search.
• I already searched in Google "How to X in PyVista" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I will NOT make duplicate discussions or issues in the future.

Commit to Help

• I commit to help with one of those options.

Sample Code What is the problem, question, or error?

Write a short description telling me what you are doing, what you expect to happen, and what is currently happening.

import pyvista as pv

tex = pv.read_texture(r"textures\checker.png")
reader = pv.get_reader(r"models\monkey.obj")
mesh = reader.read()
mesh_clean = mesh.clean()

# mesh.plot_normals(mag=0.05)

plt = pv.Plotter(shape=(2,3))

plt.subplot(0,0)
plt.add_mesh(mesh)
plt.subplot(0,1)
plt.add_mesh(mesh, smooth_shading=True)
plt.subplot(0,2)
plt.add_mesh(mesh, smooth_shading=True, texture=tex)

plt.subplot(1,0)
plt.add_mesh(mesh_clean)
plt.subplot(1,1)
plt.add_mesh(mesh_clean, smooth_shading=True)
plt.subplot(1,2)
plt.add_mesh(mesh_clean, smooth_shading=True, texture=tex)

plt.show()

Description

I have a triangle mesh model in OBJ format that I want to render out to a screenshot with proper shading and textures. The OBJ file contains the appropriate UV and vertex normal data.

When I read the OBJ in as a PolyData data set, I understand that the faces are split up individually. This preserves the UV map, however it breaks the shading. If I add the mesh to the plotter with smooth_shading=True, nothing happens obviously.

Several times in different threads it was suggested that the shading can be "fixed" by running a .clean() on the mesh data. While this does indeed enable actual smooth shading, it also has the adverse effect of corrupting the UV map data, which defeats the entire point.

The behavior is all the stranger, because plotting the vertex normals of the mesh reveals that the normals are correctly read from the OBJ, but they are not used during the rendering process. This feels like a bug to me. The whole point of smooth shading is the use of vertex normals instead of face normals, which in this case would provide a "smooth" appearance even with the split faces. Why are the normals even imported from the OBJ if they are not used at all? Or is there a way to make the renderer use the vertex normals in the PolyData, instead of automatically calculated ones?

System Information

--------------------------------------------------------------------------------
  Date: Thu May 09 01:28:47 2024 Közép-európai nyári idő

                OS : Windows (10 10.0.19045 SP0 Multiprocessor Free)
            CPU(s) : 12
           Machine : AMD64
      Architecture : 64bit
       Environment : Python
        GPU Vendor : Intel
      GPU Renderer : Intel(R) UHD Graphics
       GPU Version : 4.5.0 - Build 27.20.100.9664
  MathText Support : False

  Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64
  bit (AMD64)]

           pyvista : 0.43.7
               vtk : 9.3.0
             numpy : 1.26.4
        matplotlib : 3.8.4
            scooby : 0.10.0
             pooch : 1.8.1
            pillow : 10.3.0
           IPython : 8.24.0
        ipywidgets : 8.1.2
      nest_asyncio : 1.6.0
--------------------------------------------------------------------------------

Screenshots

This is an example model to showcase the issue. The model is largely smooth shaded, with the exception of a few edges. The vertex normals are exported to the OBJ to reflect this exact shading.

The next plot shows the different plot results in the following arrangement:

	Column 1	Column 2	Column 3
Row 1	Original plain	with smooth_shading=True	with smooth_shading=True, texture=tex
Row 2	Cleaned plain	with smooth_shading=True	with smooth_shading=True, texture=tex

As the 3rd plot in the 2nd row shows, the UVs on the cleaned mesh get destroyed, which makes it useless.

[user27182]

This code may be the source of the bug. Vertex normals appear to be always computed when smooth shading is enabled. No checks are made for existing normals.

pyvista/pyvista/plotting/_plotting.py

Lines 77 to 90 in fdb7daf

	if split_sharp_edges:
	mesh = mesh.compute_normals(
	cell_normals=False,
	split_vertices=True,
	feature_angle=feature_angle,
	)
	if is_polydata:
	if has_scalars and use_points:
	# we must track the original IDs with our own array from compute_normals
	indices_array = 'pyvistaOriginalPointIds'
	else:
	# consider checking if mesh contains active normals
	# if mesh.point_data.active_normals is None:
	mesh.compute_normals(cell_normals=False, inplace=True)

I think a solution here might look something like:

1. Update the prepare_smooth_shading method (i.e. the above code) to first check if any normals are currently active, and only call compute_normals if there aren't. This should prevent the issue you're experiencing.

2. Add a new public method set_active_normals. This could be called by the user before plotting. There are similar methods for other arrays, e.g. set_active_scalars, set_active_vectors, and set_active_tensors. Seems like the option for active normals is simply missing at the moment.

The second item may not be strictly necessary if normals are set as active by default by the file reader.

[MrClock8163]

So @user27182
As per your suggestion, I tested if the shading would be fixed if I uncommented that check on line 89 of the _plotting.py on my local installation of the library, and sure enough it works.

So that begs the question then, why was it commented out in the code?

[user27182]

Yes that comment was removed in #6062 as well and it does fix it. Hopefully that PR will be merged and resolve this issue. Thanks for pointing this out and confirming that this fixes the issue for you.

[MrClock8163]

I appreciate the assistance, and I hope the PR goes through.
If it gets merged, I'm gonna mark this as answered.

[user27182]

#6062 was merged and released with v0.43.8, see:
https://github.com/pyvista/pyvista/releases/tag/v0.43.8

Installing that version of pyvista or later should fix this issue.

[MrClock8163]

It did indeed fix it as expected.
Thank you very much for the assistance again!