Smooth shading gets averaged based on the vertex normals of the model. When the face angle of the edges is too high, the shading looks bad, which can be fixed by cutting the shading on such edges.
Auto smooth uses split normals to do that without creating extra geometry. Edge split modifier splits the edges, so there are two unconnected vertices at the same location, again having two different normals. There’s also custom normals which comes either in the imported file, or you can change the normals yourself with various ways, controlling the shading.
Custom normals work with the auto smooth option enabled, overriding the angle. If there are custom normals, button to clear them is in object data properties -> geometry data: clear custom split normals data. That’s not there if there are unapplied modifiers in the stack that change the normals.
I do understand the reply, thanks for understanding mine and noticing it comes from frustration.
Common misconception. No one wants your work or whole project file. You can still prepare one for troubleshooting, and only include enough geometry to contain an example of it. The file will still include the cause of the problem when you make sure it’s still visible in it. In this case, few polygons would likely be enough.
Yes, could request a file, which would mean that at least half of my posts would be file requests, and some percentage of those would come back with “I can’t share the file”, which in turn would mean giving an extended description of what sharing an example file means, and why it’s important, and why bug reporting instructions tell to do that, why they should post one in the starting post.
I’ve already done a tutorial on that, and also requested similar instructions in the template here as they have on the bug tracker.
I don’t request files because it’s not my problem and I don’t need it, it’s much faster to close the tab. Requesting files on each that I might be interested in would be a huge waste of time. One moderator did that for years and has 3x more posts.
After answering around 10k Blender support questions here and elsewhere, and after writing a tutorial to help people work with the community instead of just talking at them, I think I’ve done enough. People are very creative with art and have attention to detail, but when it comes to communicating a problem, all of that gets usually forgotten.
Doesn’t matter if it’s a beginner user or an expert posting, they can be as clueless about posting, and the result is the same. With beginner questions there are many possible causes, and with experienced user posting, the answer won’t be obvious - either way, need an example .blend to not waste time guessing, and not to waste time starting something from scratch just to get visuals for posting.
When you include the whole interface, it tells which blender version you’re using, the render engine and viewport settings from the header which affect what you’re showing, and whatever else is left can be seen without you saying anything, which could hint to the direction of the cause. Hiding that information means redundant writing from you, and from others if they need to know by requesting that information you could’ve easily left in the shot and not write a word.
Someone just posted a good example Textures weird and fuzzy in material mode
Cropshots are ok when replying with answers, provided the cropping is done so that it provides context where to look, but not when asking for answers.
It’s still not a substitute for an example .blend, which will contain the cause of the problem. Or in case it’s a problem in Blender, it gets tested on multiple systems and the same file can be included in the bug report, just as the instructions say.
