If you want to improve it from here you should make sure that the underlying geometry is better. This dense triangulated fan topology is part of the remaining shading problems.
Instead of turning off the autosmoothing completely you can also play around with very small angles of roughly 1 degree.
Yeah you’re getting the same results that I am and reaching the same conclusion. Seeing as it will be too much of a chore to clean up the geometry manually it might be best to find an alternative nurbs–>>>polygonal converter. This solution would’ve worked fine if the material was diffuse like wood for example, but seeing as it’s metal the issue will continue to presist.
Still very confused how the shading errors only occur when at a perfect “back” view angle. At least when using the pre-made normal data.
Well its not that much work. Most of the artifacts are gone by clearing the custom split normals. Whats left is that the angles towards the inner ring are quite steep. So the autosmoothing is kicking in. Both adjacent triangles of these edges will get smoothed. But these giant triangles span along the whole flat surface. The other big surface triangles end with a single point at the rings border. Thats why they dont get smoothed. Thats why their shadings are different. If you want make one more little inset scale around these ring to solve shading in a simple way. The big triangles should not connect with an edge on the ring bending inwards.
Making those insets are going to be a bit of a pain though considering that the ‘ring loop select’ function doesn’t really behave properly when the surrounding geometry isn’t quads. I tried various different selection options, but I haven’t found one which will easily allow me to select those rings.
Then go to face mode, box select all flat faces surrounding the ring with some box selects and inset those. The result is roughly the same.
The only resulted in more artifacting in my case, it’s possible that I’m misinterpreting you.
Just a rough demo you can make the inset size even smaller
I mean the large hole isn’t really that big of an issue in terms of shading, it’s all of the small circular indents on the front.
In principle its the same with them. Be aware of the fact that the models topology isnt very good in some aspects and its not fitting to the shading as a reflective metallic material, its prone to visible shading issues. A better edgeflow would make it much easier. There are transitions of mesh parts with different “resolutions”, that is really problematic in your case. For the remaining artifacts of the indents the weighted normals modifier will work well or refine the toplogy there aswell. Refining to a cleaner quadbased edgeflow might also be neccessary for the tip of the axe.
I guess I’ll just have to manually retopologize it… Might slam the model from Fusion into something like FreeCad or Solidworks though to see if they have more success with the export.
Just a little update, the mesh is too malformed to be salvaged by retopology in my opinion. I do however see a crease in Fusion which I believe is causing the issue based on my previous experiences. I just need to find a way to fillet that line you see where the shading issues are occurring.
Not sure if I understood what your plan is, but I wish you luck. Just be aware that in principle the problem here is that many parts and their topology are not designed to play well together and so in fact there is more than one problem in here. If you want a clean topology this output mesh definitely needs some rework. For a complete retopo the mesh you shared is very well suited and it’s also very well possible to adapt its topology directly without creating a separate retopo mesh. But in any case it needs manual work. The export does not consist of well aligned patch subdivisions. Some areas have very differing resolutions like in the attached screenshot where the cylinder of the ringhole and its bevel on top meet. A comparable problem exists on the other end of the beveled edge. Thats the core problem. Beside that these giant elongated triangles easily lead to problems, but we discussed that already.
I don’t think I’m gonna do a complete retopo, because in that case I could just model the whole things in Blender. From my experience Fusion loves to connect their triangles to the nurbs seams such as edges so I’m just gonna have to find a way to bevel out that transition between the two parts of the head.
After further research I believe this might just be an issue with Blender. Take this machete I recently made, it has perfect topology (all quads, except for a very small amount of tris). Yet it still has the same shading issues.
Hey, sorry but I dont know what I should see on this photo. And what is the issue, that you see shades in orthoview or what?
You can see that it has this weird almost inset like shading error on the flat part of the blade. I’ll download marmoset or Quixel Mixer later to see if the same issue occur. I know that the models didn’t suffer from this error in UE4 unless they were using a high poly normal bake.
I had another look at your shared file, In principle the shading could hint at a small bug or at least a computation is maybe on its precision limit here. If you want, try to report it. Problematic is that its just a minor shading issue in a very specific case. Quite some things influence the calculation of the shading aswell as the normals, so its harder to find the cause, and as I said it could also be correctly caused by bad topology in combination smoothing limits and something else.
Its dependent or at least incluenced by the smoothing of face normals, changing them to flat shading solves any issues.
And yeah you can alternatively “fix” it by tweaking the calculated normals as you’ve posted in the last post, just as the weighed normal modifier is there to reduce predictable problems and a good topology is also less prone to such shading issues.
It needs perfectly coplanar face aligned to the camera frustums near plane and then some slight normal deviations by the normal smoothing as it also immediately disappears if the axe is slightly rotated in orthomode instead of the view.
And rotating the model and ortho view 90 degree horizontally also removes the issue, that why I think it could be a precision thing, maybe the underlying math is changing signs here or its near the floatingpoint precision and thats causing a bad contuinty for the shading.
But then there was the same issue?
I think that it might be a bug seeing as it also appears on the machete I made through regular subdiv modeling. Also going into orthographic mode and slightly shifting back and fourth a few degrees with the numpad solves the issue.
Its really hard to say based on the limited information I have. I eg asked you how it looked with the normal bake for UE4. If yes it would make sense to check the normal map and see whats going on there. Having comparable shading issues also happening in UE4 with a normal map makes many of the possible causes for a bug in blender unlikely.
But if you think its a bug, you should make a bugreport.
