System Information
linux 64, nVidia GTS 250
Blender Version
2.69.1
Short description of error
Artifacts are become for lowpoly models.
Video: http://www.youtube.com/watch?v=_pvcLyHokbY&feature=youtu.be
File: https://dl.dropboxusercontent.com/u/26887202/blender/ren_2_69.blend
Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps
it's a feature but not an option. The code is written so the light rays behave that way. If it was written in a more natural way, renders would take much longer.
To avoid the terminal artifact like the Mantra render engine did, I guess you would have to add some code that changes the light behavior hopefully only on the areas of the render where it's relevant in order to not increase render time too much. Although that is completely my guess and I'm not a developer. I'm sure it's more complicated than that.
It's not an optimization. The shadows accurately match the low poly mesh, but what you need is to have them work as if it was actually a smooth high poly mesh that the smooth normals make it seem like it is.
All renderers suffer from this to some extent, some have solutions for common cases.
This feature is problem for me. Why can not everything be done in a normal way? For smoothed normals to be calculated, as smoothed, and not as flat. And do not say that this is such a feature
This is a serious issue and needs to be fixed as soon as possible. I made a test with Maya/Arnold and there's no terminator effect at all.
My posting of today was merged immediately by Brecht van Lommel. Good realtime job as usual ;-).
My examples will show the actual issues very well. If you work with low-poly models you can't subdivide for some reason you are stucked with this:
https://developer.blender.org/T61745
And this drove me mad a while ago and I thought it's bad geo:
I spotted this issue in 2001 with Mental Ray. This was fixed later. Also Arnold is rendering as expected:
@Brecht Van Lommel (brecht) pardon me if I say something stupid, but... as far as I understand, this shadow issue happens when a face projects its shadow to one of its adjacent face. So isn't there a way to prevent faces from casting shadows to their adjacent faces? Dismiss them from the shadow ray, when smooth shading is on?
No, it's not that simple. There are valid shadows from adjacent faces that you'd be losing.
We have some ideas to tackle this, but it takes some research as there are no published algorithms I'm aware of that work as well as for example Arnold.
Ok. I was thinking these were shadow issues, but actually it's not since turning off shadows does not fix the issue, it's more related to the way the faces themselves are shaded. I probably won't be able to help, I don't know how pathtracers work... Good luck with it :) Indeed, renderers such as Arnold and Guerilla have fixed it.
@Brecht Van Lommel (brecht) Even if not perfect, the "bias" solution could work in many cases, it's still better than no solution at all.
As far as I understand, it's all about computing the shading ray starting slightly above the face normal. I assume you know the principle, but just in case see the page 2 of this doc:
https://fenix.tecnico.ulisboa.pt/downloadFile/1689468335601264/Its-Really-Not-a-Rendering-Bug-You-see....pdf
Could be nice to implement as a quick workaround, and later if you have time work on a more definitive solution... Just saying.
Some of the work done on this subject (by Alejandro Conty Estevez, Pascal Lecocq, and Clifford Stein for Sony Pictures Imageworks) done for Arnold renderer has been published in Nvidia's Ray Tracing Gems (book in open access), part III, chapter 12.
I don't know if this is adaptable for our situation but I leave that in case it might help.
Some ideas for solving this problem are listed here:
https://wiki.blender.org/wiki/Source/Render/Cycles/Optimization#Ideas
If I had time to work on this, probably trying to ignore intersections with some faces is the first thing I would try. For closed meshes backfaces could be ignored, or more specifically adjacent backfaces (sharing a vertex) if it's sufficient. Maybe would need to differentiate between convex and concave cases based on the normal.
@Brecht Van Lommel (brecht) This issue still exists in version 2.81 Alpha.
(version: 2.81 (sub 8), branch: master, commit date: 2019-09-08 21:40, hash: f3a4f12ac090, type: Release
build date: 08/09/2019, 16:01)
Or is it my mistake and I've forgot so set something?
See my simple attached example.
I mention this because the issue is noted as solved:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles
This issue is not fixed yet. There was a patch lately to fix terminator effects when using bump mapping, but this is a different context.
2013-2019
Devs are you looking for a solution to fix the problem, or you close your eyes to the problem?
Please answer kindly here. The Blender team does a fantastic job with 2.80 and 2.81 now and sets the priorities for the development. The Terminator issue is not a bug, but a technical ray tracing "feature" since ray tracing exists. A correction is not trivial to code. So please be patient.
Don't cheat, it is not a feature, it's a bug! For 7 years other software solve problem, but there says that is a feature, and old bugs copy to the new version. When the normals are displayed as it should, and render lives its own life. Resolve pls the problem, don't say about "features"
Hi,
We are all kind people and we respect the devs a lot. But I would say that this is a bug at 2019. All production renderers support this. Could you, please, reopen the issue so that we are able to track it?
We know that the devs are very busy with other stuff. But, please don't close this issue. In other way, we will see it at 2040.
No. It's not a bug. "The terminator problem results from improper selfshadowing due to planar-polygon approximation of smooth surfaces."
Above someone posted a link to a PDF describing this issue.
It's removed in eg. Arnold and Redshift with different methods but from what I read it's not like fixing a general bug. I am pretty sure that the Cycles team will have this on their future list.
I think the issue is still open but was not set on high priority due to the 2.80 development.
2019 year, and there are still people who consider a feature terminator effect. *facepalm*
Hey guys... please stop this everlasting feature/bug war, be wise :-) ... From a technical standpoint, it may be a feature (it's not supposed to work in the current implementation), but from the users side, it may be bug (not working as we expect it to work). Anyway, it's an issue.
The problem is there are very, very few skilled developers to work on it. If it was easy, it would have been already fixed. There's not much to do, but waiting kindly for someone to fix it...
Thanks to all for answering. We wanna be wise. )
Right now I see only one problem. This issue is closed and archived. And this is a problem. The devs will forget about it. I think we need to reopen it.
Nope, Brecht said previously he's aware of it and it's on his Todo list. He just needs time, he has other priorities for now, or we need another skilled developer to pick it up.
I think this is already on the module list:
T66305: Render & Cycles Module
T68920: Cycles: improve shadow terminator handling
I spent some time looking into this.
This not only caused by shadow rays but also due to Cycles deciding between bsdf_eval_reflect() and bsdf_eval_transmit() based on geometry normal only, as recommended by the PBR book (http://www.pbr-book.org/3ed-2018/Materials/BSDFs.html). We'd need to evaluate the reflection, at least for diffuse BSDFs, even when the geometric normal is pointing away from the light source.
Combining this with an "ignore all backfacing hits from the same object ID" heuristic seems to remove those artifacts in the simple test scenes I've tried. Still would a lot more testing, and I've implemented the heuristic on the Embree backend only at the moment.
One other idea I have is that instead of ignoring certain hits in shadow rays, we could use a dynamic ray offset. It could be based on the position where a smooth surface would be (https://perso.telecom-paristech.fr/boubek/papers/PhongTessellation/).
@Stefan Werner (swerner) Here's another piece of test geometry. This time the parts of the model with the artefacts aren't that low poly, also there's no normal map applied. Not sure if it's actually a bit worse than in previous builds? Currently I'm using 2.82 (sub 1), branch: master, commit date: 2019-11-22 18:14, hash: rB373e936e3e64
@Stefan Werner (swerner) Here's another piece of test geometry. This time the parts of the model with the artefacts aren't that low poly, also there's no normal map applied. Not sure if it's actually a bit worse than in previous builds? Currently I'm using 2.82 (sub 1), branch: master, commit date: 2019-11-22 18:14, hash: rB373e936e3e64
Looks like the same problem, as always. No difference to the old builds for me.
Looks like the same problem, as always. No difference to the old builds for me.
@Stefan Werner (swerner) Darn it. I don't suppose you have any insight into a timeframe for a resolution do you? Jules Urbach, the owner over at Octane had agreed to get one of his engineers to throw a few tips in Blender's direction, but it doesn't look like he's going to come through.
@Stefan Werner (swerner) In case you have an experimental patch for this, i'm pretty sure many users will volunteer to test it out. I can compile it and provide a build. Thanks for your work!
We would not consider this a "Low poly" problem. Currently, there is no way to render a high quality cube with a bevel modifier, smoothly without a black reflection artifact. It shows up on many film quality assets too.
We have been considering Cycles a cutting edge renderer, but unfortunately, this is changing our mind. I wish there existed an open source algorithm for the team to implement.
This was solved with the terminator offset setting implemented a few months ago:
https://developer.blender.org/D7634
About your beveled cube issue, this sounds more like a normal shading issue. You can try settings like "auto-smooth", or Weighted Normal modifiers to overcome this.
Thank you Lucas, that solved majority of the problem.
Before:
Weighted Normal modifier + Auto Smooth (Mesh Settings)
However, there is this terminator like, line artifact that remains. Close up:
The line disappears when the ground plane is removed (while the black corner artifact was always there), so it may not be a terminator problem. In fact, the line moves with the Sun and shadow position, so it is some reflection of the shadow, but it is not solvable with any setting of the "Shadow Terminator", as it is a reflection problem.
None of this happens with Eevee, not ray tracing. The interpolated normals with smoothing are not well limited at sharp angles, and they seem to be shooting inside the geometry or terminating unpredictably, and very unnaturally. But if other algorithms can handle these exceptional cases, so can Blender one day. Also the bevel modifier should manage smoothing better without the help of another modifier, and other switches across the ui.
Here is all smoothing off, bevel larger radius, and 64 segments, max bounces 64 as well.
I don't know, perhaps it is natural... Seems to me, a smooth edge should not misbehave from its adjacent sides with a big reflection line even at 128 segments. Perhaps it is because the bevel modifier is joining an abrupt circle shape to the flat surface, where as in the real world, a smoothed object (sandblasted and then polished) would never have such a preserved sharp corner. It would be like in signal processing, all higher frequencies would be removed.
The only solution is to use higher subdivided meshes to cover the effect when you don't need low-poly models.
Cycles is a cutting edge renderer. I assume the "issue" is still not really understood by most people. The terminator effect is a raytracing and maths problem. EVERY path tracer is affected by this and in some, it's "fixed" but not really solved. I found out that renderers like Arnold or Redshift have solved it for convex surfaces but then for concave surfaces, it still exists, while the Blender dev team was aware of this and fixed it with another method to shift the shadow border.
The only solution is to use higher subdivided meshes to
Higher subdivided mesh - it's not solution! If you need to make a low poly mesh and make a nice render? Then this method is not suitable!
Don't offer stupid methods in 2021 instead of solving the problem
This was an unfinished posting by accident. I have completed it in my former response. My apologies.
You have two issues here: You don't understand this classic ray-tracing problem called "Terminator Effect" and your toxic way to communicate is absolutely unacceptable. This is a developer board and not a social media platform. Please take this in mind.
The terminator issue has been solved in Blender by a workaround actually. Shifting the shadow border might be unsatisfying for some people but there is no other way to fix it completely.
As I said: It's still unsolved in other renderers like Arnold and Redshift. They have fixed it for convex surfaces but for the price that concave surfaces still show the terminator effect. I have some examples somewhere of my research scenes with Maya I can post here later.
@CHET (cheteron) Just to make clear that the other renderers haven't solved the issue. It's just inverted. :-)
This is an older comparison. I've tested it right now with Maya 2020.4 and the latest RS and ARNOLD versions. Still the same. Why? It's not an easy task to solve the terminated rays.
But mighty Blender devs like @Brecht Van Lommel (brecht) and @Lukas Stockner (lukasstockner97) did:
So please let us discuss here constructively with knowledge.
No. They don't. They just moved the problem to the concave side. It still exists. Not solved. Just switched. Check my latest picture. It's cleverly solved in Blender. It's the same scene but with a Shadow Terminator Offset. Physically not correct but a brilliant idea and a proper workaround for low-poly shaded scenes.
Mental Ray solved it like 10 years ago. I tested the Blender 'solution1 in 2.91 it resulted black rim around the sphere. No win yet.
@CHET (cheteron) Look at the background wall of Arnold and Redshift renders, you will see lighting issues. Then by default they solve the terminator effect better than Blender with convex meshes (sphere) but not with concave meshes (wall). The terminator shifting setting of Blender is a workaround that does the trick.
I am pretty sure that Mental Ray hasn't solved it or maybe similar to Arnold/Redshift. I recognized the Terminator Effect the first time when MR came out and we all thought it's a bad bug. Please show me an example that it's overall solved. BTW: In Blender it's solved with a workaround. Brecht has worked on Arnold. He's knowing why this issue exists and why it's not solvable 100% for low-poly models.
@CHET (cheteron) @Alma Talp (AlmaTalp) THIS is the same issue. Just inverted. It won't happen when you see it on the sphere like in the Blender example. ARNOLD, RS, and all other renderers claiming to have it fixed are just using another workaround because the Terminator Effect is more extreme on convex surfaces.
@CHET (cheteron) @Alma Talp (AlmaTalp) @lucas veber (lucky3) Vray is using a similar workaround called "Shadow Bias". I am pretty sure that the programmers of Mental Ray found no better solution.
Source: https://blenderartists.org/t/is-there-a-workaround-for-the-terminator-problem/676417/11
i know about this
@CHET (cheteron)
Evee uses shadow maps, while Arnold and Cycles are raytracers, then they can't be compared. The shadow issues in Eevee are due to shadow mapping inaccuracies, unlike raytraced shadows which are technically perfect. The shadow issues in the Arnold and Redshift renders are due to the terminator issue.
I think blender's implementation of appleseed's fix is nice, but it's still unusuable due to the additional artefacts it causes around the edges of objects.
I'd love to know how Corona Renderer fixed it back in 2017, the result is flawless and it requires no user interaction:
https://coronarenderer.freshdesk.com/support/solutions/articles/5000516258
Exactly. EEVEE is not a path-tracer. But interesting that the result is similar to Arnold/RS. Looks like the programmers used some kind of this method or maybe no ray-traced shadows? :-P
Blender uses Apple Seed's workaround. I don't believe Corona has the same inverted artefacts as seen in Arnold and Redshift (I could be wrong though; I haven't used Corona in around 4 years).
Thank you Michael for the comparative analysis with Arnold and Redshift. It is quite reassuring.
As I am relatively new to 3d programming, I would like to understand what is happening better.
Can someone explain why the ray terminates? What makes the normal interpolation wrong, and how does the ray get trapped? The artifact happens with reflections too. In that case, I am assuming the interpolated normal and reflected next ray get trapped inside the object. It seems the normal interpolation needs some limits. I would like to think about the problem, if the experts can give us some kickstarting insight.
This one has already landed in Cycles over a year ago - D5399
This paper only addresses cases with bump/normal mapping.
Thank you again Michael.
As I thought, the problem is not that hard. Perhaps it is avoided not to sacrifice performance. As the interpolated normal decorallates with the original normal (dot towards 0), it needs to blend to a tangent, so it does not enter inside the original geometry, or in concave cases, exit to the other side. This would fix artifacts with normal and bump textures too.
Another idea to explore is limiting the reflected normal to stay outside. In case of refraction, the opposite, as the ray should stay inside. At a quick look at the paper, that is the focus, as it is the diffuse distribution hemisphere that is an additional problem.
But it should be noted, this problem is not limited to shadows, nor diffusion, as in my example above of sharp reflections on a smoothed cube.
To minimize the performance hit, there could be a single branch into an exceptional case as the abs dot falls below a certain safety say .25, at which point a smooth blend to a correction begins. That blend could be contoured artistically as in the paper.
