Possible bug with shading (smooth) ???


i can’t post to bug-tracker, so i hope someone can do it for me, if this is a bug…

My problem is shading in Blender

This is my imported model - SOLID enabled - AUTOSMOOTH disabled:

This is the same in render-window:

This is the same model - SMOOTH enabled - AUTOSMOOTH enabled (NIGHTMARE):

This is the same in render-window:

You see - first 2 images are OK
But if i enable autosmooth - this produce good result in render-window, but not so good in the editor…

But i need smooth gfx - without this problem…

My suggestion is:
A) create new button = render smooth, draw solid
B) create new button = render smooth, draw smooth (the same good quality shown in render window)
C) NO extra button, but… IF smooth is disabled and autosmooth is enabled = render smooth, but draw solid

I like suggestion B or C… (C is my favourite, i think it is easier to implement in blender)

What do you think?

PS: This model was designed with CAD - i have 100 such imported models, so that it is not possible to edit them all per hand…

Don’t know what the problem is with auto-smooth, but try using an edge-split modifier instead.

HI… i think i choose a hard word: bug…

The problem is that blender ignore autosmooth on drawing - but it render with autosmooth… this is “limitation” by design.

If you say… bha… autosmooth is slow…
i don’t think it so… i used today another software - that can enable something like smooth+autosmooth (gouraud shading+smooth angle) for a object - and this software can draw smooth faces with no speed-differences… But on other side this software is bad… so that i use blender instead

but i think some glitches can be fixed - to create much better graphics from CAD

Yeah but not with the edge split modifier it doesn’t. What LOTR junkie was saying is click the model, add modifier and choose edge split. Then select the angle.

It’s a bit confusing that it’s called edge split and not smooth normal or even autosmooth or something but it does the same thing as autosmooth with the exception that it renders correctly in the viewer. Maybe it’s a bug sure but a lot of bugs you think are bugs are technically ‘features’ so I’ve come to discover.

I think a lot of Blender’s functions will be replaced by modifiers eventually. Subdivs was one of the first big ones and that confused a lot of people when it changed to being a modifier.

I would assume that it’s called edge split because thats exactly what it does, it splits the edges of a mesh.

It’s not a bug because it was never designed to be viewable in the viewport. A feature not meeting a requirement that was never gathered for it in the first place cannot be called a ‘bug’ by any normal definition of software development.


In my opinion, features in a 3d program that don’t show the user directly what happens are bugged, unless it’s not possible to do it in real time (like rendering).

(I hope you get my point: graphical features > should be visible)

As said before use the edgesplit modifier and not autosmooth.

That implies a geometric split and not a shading/normal modification. The effect is to take normals that are perpendicular to faces and interpolate them towards adjacent faces that satisfy the angle condition. I can’t even see how splitting an edge comes into that unless it does smooth shading all over and then splits edges where the angle is bigger than the condition so that the interpolation doesn’t happen but IMO that isn’t a great description based on what people would understand happens during normal interpolation.

I bet there’s hardly any end user who having known what autosmooth does would immediately consider that something called edge split did the same thing. I’m sure people will get used to it of course but call a spade a spade instead of an inverse hole filling implement.

That’s exactly what it does.

This is exactly what edge split modifier does, it splits a mesh apart along given edges. Add a ‘smooth’ modifier after edge split to see the effect or just apply the edge split modifier and fiddle with the mesh on the split boundaries.

In order to accomplish the same via normal modification only would require blender to store vertex normals on a per-face basis, which it does not currently do.


Oh so edge split isn’t really doing the same thing as autosmooth then, it’s just that it can be used to achieve the same result. Unless autosmooth also splits edges but it does it at render time. That’s not really how smooth shading is supposed to be done though as it’s not supposed to modify the geometry.

I think Blender does store vertex normals because you can export them with Python using mvert.no - it could calculate those on the fly I suppose. But anyway you only need surface normals to do interpolation - if it needed vertex normals that weren’t available, it wouldn’t be able to do smoothing at all. To do smooth shading in Renderman, you only need to export Blender’s face normals and it will vary them across the surface. Internally, it maintains the unmodified geometric normal Nf. This is the method I used to do an automatic bevel shader - it compares the smoothed normals with the unmodified normals in order to find where an edge is and displace the surface accordingly. It didn’t work completely because Renderman only knows about local surface points at a time so you couldn’t tell how far from an edge you were.

I’m sure that technique could be used in Blender though to do automatic bevelling at least in terms of shading and then displacement if they put micropolygon rendering in. But it should be able to do smooth shading properly too.

I notice you can manually set which edges are split too using the y key, I always wondered what use that would be but again there should be something like the crease function that shows up edges which have been split and not have to modify the geometry itself. If they could be weighted, that would be even better.

Its a bit narrow to say its not ‘supposed’ to be done that way. As a matter of fact thats how hard edges are achieved in most real-time engines. (incidentally they sometimes only support per-vertex uv’s so require splitting along uv seams as well).

No one ever said blender didn’t store vertex normals. It just stores them on a per vertex basis rather than a per face basis. It also stores a face normal for every face which the vertex normals are derived from. However to do hard edges through normal manipulation only would require per-face vertex normals.

Weighting would probably be nice I agree, especially since some real-time engines/formats let you specify your vertex normals explicitly.


Thanks for this thread, I now understand the purpose of the modifier. It seems pretty useful for mechanical models, as I can subdivide it and keep nice clean sharp edges. Kinda like nurbs or something.

After reading the last few posts I couldn’t find whether or not you know about this:

you can set which edges should be treated as “sharp” by pressing ctrl E and selecting mark sharp, just like mark seam marks edges for unwrapping.
You can view these edges by enabling them to be displayed. In edit mode all these viewing options are available in the “mesh tools 1” panel.

This may not add to the discussion as to why something works like this, but this rather shows how an enduser would use concepts like “splitting” and smoothing and autosmoothing.

Yes, I do mechanical modeling all the time, edgesplit is a lifesaver for me.

Is this (maybe) why Qdune doesnt interpolate normals as of yet? Maybe I’m of the mark…

Fair point, I should have said that I think it’s better to do shading interpolation by only affecting the normals. If it doesn’t adversely affect other things (having to make sure the modifiers are in the right order might be one issue but it’s not a big problem and most people probably wouldn’t apply that modifier and then edit the mesh) I guess there’s no harm doing it this way.

I didn’t know about that thanks. I swear I look at Blender’s menus one day and they’ve changed a few days later. Maybe there’s some internet feature where new developments just creep in unexpectedly.