Dead horses… as well.
The usual expression of these days. On most replies from developers.
Just watching the conference.
Well known issues everywhere.
A bug is always welcome from a certain point of view. It can be fixed.
A limitation, incapability, is much worse.
This bug can be fixed, it’s just difficult.
Post a REAL project that is effected by this “bug” and you might get some interest. A basic sphere without even so much as a subsurf modifier applied does little to convince me that there is an issue here worth all this chatter.
Really, why should we care? With all the things we expect from these wonderful developers, why should THIS shading issue be so important?
Those links should explain the issue better
http://geekshavefeelings.com/x/wp-content/uploads/2010/03/Its-Really-Not-a-Rendering-Bug-You-see…pdf
@pappy Irrelevant.
Blender is awesome. Blender Developers are awesome. I’m happy. We’re happy.
It’s an interesting issue, that’s all.
<robotic voice>
You have expressed doubts towards the awesomeness of blender
You will be terminated shortly - thank you for your cooperation
All hail blender
</robotic voice>
Here’s are some old thread with the exact same issue in Lux and yafaray:
http://www.luxrender.net/forum/viewtopic.php?f=14&t=2459
http://www.yafaray.org/phpBB3/viewtopic.php?f=13&t=1859
Some pictures with Mitsuba:
http://www.luxrender.net/forum/viewtopic.php?f=17&t=4273&start=70
There’s also a seminal book on ray tracing called “physically based rendering” where the issue is explained in depth.
Maybe all those developers are too stupid to fix it, but of course noone disagrees that it would be great to fix. So if anything comes to mind I’m sure people would be more than happy and, honestly this time, think it’s awesome.
maybe talk more about tricks such as compositing techniques to alleviate the issue rather than beating the rotten horse. i render game poly (mid res to “hi res” objects in cycles mainly for stills, and it would be interesting if someone could come up with that. i know GI brightens up the scene so less shadows equals less of those artifacts, but then you would have to adjust things to get the game models speculars to show through.
Post a REAL project that is effected by this “bug” and you might get some interest. A basic sphere without even so much as a subsurf modifier applied does little to convince me that there is an issue here worth all this chatter.
Really, why should we care? With all the things we expect from these wonderful developers, why should THIS shading issue be so important?
Here we are:
this simple scene costs 600 k quad faces already.
Cycles toon shader, smooth.
I had to go for million subs, still the artifact is visible just smaller.
I use hard lights, 0 bounces (direct light).
No noise after a few passes (for AA only)
Horrible. Cycles can’t do it. BI can.
@Psy-Fi
Kerkythea has a solution of course, Thea too, other branches of kerky also don’t suffer from this “bug”. I’m talking about unbiased settings.
Michalis, yeah we’ve talked about it about Kerkythea…unfortunately they didn’t release their code but might be worth a try asking Anthony in case he wants to tell about the trick they used. I suspect biasing probably but I can’t tell without testing Thea. According to theory, biasing should introduce artifacts elsewhere so it should be obvious they used something like that.
Again, there isn’t a solution to this problem, because it’s not strictly a problem. That’s exactly how shadows on a low poly surface are intended to be cast. The problem isn’t the low poly surface, it’s the lack of visual continuity between the shaded faces (expected) and the smooth shading of low poly surfaces (completely non-physically correct). Any code that changes this will be a hack, not a real solution, and it WILL cause artifacts like the ones you can see if you try to do low poly animations with Thea with this option turned on. This simply isn’t a use case that path tracing was designed for. In fact, it’s pretty much the opposite of what path tracing was designed for, since one of the great selling points of path tracing is the ability to not have to worry about the hit on render time when adding substantially more polygons.
Yes, as @m9105826 and some other say, it is not a bug in Blender or other software. You have actual flat geometry and some CPU ceeap 1970-ish trick “interpolate normals around edges” that ist not flat. All “solutions” mentioned above, are just band-aids that do fancy post-pro things to blur self shadow.
I repeat: shadow from flat geometry is flat! Be it on other object like floor, or on same object as subject.
Cannot believe how very experienced ppl like @michalis keep saying opposite, it so obvious. You can so some dirty things like smoothing shadow map in scanline/opengl render, but issue still in place, you get just different artifacts.
I digged a little bit into Kerkythea’s manual http://www.thearender.com/versions/TheaRenderManual_v1.3.pdf
At page 88 there’s a Shadow Tight value described. They are confident enough to enable it by default even, but there are cases (mesh is not “well defined” is a little bit vague) where it might not work so they give the option to deactivate. And, interestingly enough, “fix” is in quotes :). Semantic bickering aside we might want to support something like that in blender too.
This simply isn’t a use case that path tracing was designed for. In fact, it’s pretty much the opposite of what path tracing was designed for, since one of the great selling points of path tracing is the ability to not have to worry about the hit on render time when adding substantially more polygons.
Agreed, however lot of new threads on BA, asking to get rid of BI. Just like that.
@storm_st
Hey, you missed some of my replies, sorry.
thread #5 (it isn’t a bug), #8, it isn’t a bug, #10 :by definition it isn’t a bug,
see? IT IS NOT A BUG. How many times should I write it?
However, on my posted nonsense-artwork, whatever subdivisions I use, the artifact is there, in the end it looks like a no AA render.
May I ask what toon shader nodes exist in a pathtracer?
This physically correct thing is killing me.
I don’t know what you have in mind but a rasterizer, a modern GLSL engine, something like that, is needed badly.
Else, get rid of BI, of freestyle, of GLSL… hey, I’m joking.
For those who’s intentions are not a physically correct rendering, cycles is not a choice.
Cycles is an alternative semi photorealistic render engine.
I agree, a good real-time/fast and modern biased engine would be great to have. Unfortunately, this is even harder to create than a pure path tracer, so it may be a while until we see it tackled.
Further reading:
http://geekshavefeelings.com/x/wp-content/uploads/2010/03/Its-Really-Not-a-Rendering-Bug-You-see…pdf
The shadow terminator issue is hard. Arnold, for example, goes to great lengths to deal with it, but ultimately you can still find it if you push scenes hard enough. Due to the shape of the geo and the shading normal differing from the true geometric normal, you end up generating BRDF rays that go “below” the surface and end up shadowed (dark spots) or end up never going low enough when geo is nearby and should obscure it (subtle “light leaks”, although that term is usually applied to other situations). For lambert/oren nayar diffuse, you can often correct the dark spots with some fairly simple checks against the geometric normal to preserve energy, but for microfacet/glossy BRDFs it gets harder. Arnold has an addition for bump-mapped and smoothed surfaces (for example using Arnold’s autobump feature to get displacement detail into the surface normal) that will deal with the terminator issue and hide it more gracefully as well.
But in the end, the second you examine other surfaces compared to the one you’re on (global illumination) and you have a shading normal differ from the geometric normal, you will run into this in some fashion. Heroic efforts are made to push the problem out as far as possible, and it seems to me that Cycles could do better in this regard, but in the end shading normals are essentially an unphysical hack and the results of that hack will show up somewhere.
Unfortunately, the best solution is to subdivide your meshes. Oftentimes you don’t need to do this in your source geo, but rather just when you are rendering it (using GPU tesselation or render-time subdivision to get as close to the Catmull-Clark limit surface as possible). It’s a trade-off.
I wonder why smooth shading can’t look at the lightness value on each poly around a vertex, then if one poly is around that vertex is significantly darker (below some threshold), average the lightness value of the two adjacent polys to the really dark one, then lighten the dark poly by that averaged amount but using weighting of the vertex that this is being done around. That should pull up the light value in the corner right on the vertex that it needs to.
Perhaps it’s a stupid idea (overly simplified solution), and makes weird artifacts. Has anyone tried testing this?
Obviously on things left flat shaded, it’s not needed. Problem is smooth shaded things (technically a cheat), are still being shaded in some aspects as if they’re flat.
I agree, a good real-time/fast and modern biased engine would be great to have. Unfortunately, this is even harder to create than a pure path tracer, so it may be a while until we see it tackled.
I agree, it seems even harder to create.
To be a good developer is not enough, you have to an artist (or very close to artists) to go beyond “physically correct” approaches.