By reading part of the second link of this post you can learn that this is due to a normal interpolation problem.
Okayyyyy normals are one of the elementary bricks of CG !!! cycles badly handling normal is just like a plane flying ‘sometimes’ ! LOL !
Well this is a bug beeing worked on but i need a solution NOW ( simply because the bug is known since dinosaurs era and also because i really need the AO node !!! )
This bug only appears when you turn on the smoothing on low poly object.
Solution won’t come from devs ( seems to be a kind of habit ) but from users finding a cheat by chance.
And here’s the cheat:
Pretty simple !
We need to use the true normal ( the non interpolated ( AKA flat ) face normal ) instead of the interpolated normal and feed the AO node normal input with this.
The bad part is that you cannot have smooth object. Only flat shaded.
I made a small nodes setup for switching from smooth to flat normals when output of AO node is pure black ( wich normally don’t happen ).
Here’s the nodes setup:
This unfortunately implies two AO calculations and is therefore slower but it dramatically reduces the visual defect though not eliminating it totally ( switching brutally between smooth and flat is a kind of abnormal behaviour ).
So here’s the final result: right before, left after
If you read the whole of it though, and not selectively (BTW your actual bug report is here), you can learn very quickly that the problem is far from that simple.
I can understand frustration, and even appreciate a bit of drama, but please try to not misrepresent the issue, nor the effort spent in dealing with it.
I saw it’s far from simple. And it is simply because wrong choices were made at start. Now the burden is too big and simple problems are melted with other ones making things somewhat unsolvable.
I perfectly know that it’s easy to express frustration ( with a bit of drama ) without contributing. But as a former aeronautics dev i know that an app must handle the minimum basic things before handling second importance ones.
In CG, normals handling ( no matter wether it’s about volume, particles, hair or anything else ) is the fundamentals. If it has been modified for handling anything else than triangles normals, no doubt it will fall in exceptionnal buggy cases.
Also ( and though it’s not the place for arguing about this ) the intro text of the D6250 is just wrong:
<<These artifacts stand out when the scene is far from the origin or the scale of the scene is too large or too small compared to 1.>>
The artifact happens on small scenes beeing close ( 2m ) to the world origin.
The problem is clearly composite and ray offseting is IMHO badly handled ( btw it’s a basic bad choice ) and due to floats resolution/range ratio.
I’m simply frightened that cycles still uses floats for PBR ! doubles should be everywhere and i just wonder why Brecht and his friends are still stuck with floats…
Though doubles wont solve the preexisting issue ( due to digitalization of analog values ) they will throw the problem far away.
At last but not least, i sincerely feel the devs struggle on this thing and am kinda upset with the amount of brainburn on those fundamental things that raise problems that should not raise. The effort you talk about is noble and impressive but i look at it as a waste of time & competence.
normals are one of the elementary bricks of CG !!! cycles badly handling normal is just like a plane flying ‘sometimes’ ! LOL !
) without contributing. But as a former aeronautics dev i know that an app must handle the minimum basic things before handling second importance ones.