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
This is the known "Terminator issue" in Cycles (also some other engines have trouble here).
It's a known issue and will probably be improved one day, but not considered a bug at the moment. In the meantime, the only way to avoid this, is to use high-res geometry.
I think this issue is big enough to take care of it.
I mean, this is what you get right after opening Blender, creating a sphere and rendering it.
I don't even need to tell you about rendering low poly characters. Eww...
I agree with Caetano, it is a real issue with low-poly characters what deserves to be solved.
This request actually belongs more to rightclickselect.com. If anyone wants to make a proper request there, give a link here and I'll probably upvote it.
Note that a better explanation of this issue is described in this paper, look for "Terminator problem"
https://pdfs.semanticscholar.org/7986/ebd7b5427bbe54edb7c0c9cf674fee817933.pdf
I do not understand why you need additional requests on third-party sites? I do not understand why you are convinced that this is "normal"?
It's not a bug? But problem is here, result - not good. 4 years guys. Can you make simply, that render work fine?
Some industry render engines like 3Delight have the terminator artifact too (maybe even Renderman ? I would like to test).
Asking to prevent this artifact is similar to asking bidirectional path tracing (in the sense that it adds a feature). You can call it fixing in the sense that every improvement of the software is fixing a problem, but you can't call it a bug fix in the sense that it's not an unpredicted behavior.
When Brecht wrote the code for the early Cycles version, he certainly knew this would happen. A bug is something you didn't expect when writing your code. Which is why this belongs more to a feature request website than a bug tracker.
The fact that the feature request website is "third party" is a different kettle of fish. Maybe Blender.org could have an "internal" dedicated section for that like Autodesk has with the "little annoying things" but unfortunately the dev team of Blender is 10 times smaller than the one of Autodesk. But also 10 times bigger because it has the rest of the world, which is why they let this website be handled by the others. Note that rightclickselect is very much welcoming help for improvements of its website.
Pros & cons of open source, man !
I'm agreed that this is a feature request. But this is really a vital thing for artists. We cannot render our game models. Could you add more priority to this request, please?
Even houdini fixed it in mantra http://www.sidefx.com/docs/houdini/news/15/rendering#shadow-terminator
I understand that is not a bug with code, but... this is not a "little annoying thing", it's a render problem, how corrupt final result, and render internal have same "effect", not only cycles. And there is no universal method of treatment for him. Sometimes this can not be fixed in any way, and object need remake, sometimes create new. Sorry for my english. It's a problem guys. I work with 3d max, but after Blender, don't want return, Blender is more flexible, and has great potential.
Can you fix this problem, please?
I just tested with Renderman and well...
http://i.imgur.com/9YrOYBG.jpg
If freakin' RENDERMAN didn't fix this, it's probably a hard problem.
Renderman is a studio rendering engine. It;s created not for indie artists. And Pixar does not render game models for Artstation. )
I'm pretty sure Vray has no such an issue.
In Mental ray it is solved, in Vray it is there, but less problematic (but I haven't tested it with the latest Vray).
Conversation on Corona forum: https://corona-renderer.com/forum/index.php?topic=10392.0
Some work has been done in this direction, see D2574, although that addresses only part of the problem.
Brecht, it is great to hear. I just made some short tests, but even reducing the 'darkness' of the effect would be a great step forward.
Would you please take a look on this, too?
Currently I'm fighting with this problem related to Cycles and I made comparisons with Vray: https://developer.blender.org/T51548
Thanks
Note that Eevee doesn't have the terminator artifact and it's usually better suited for lowpoly renders than Cycles.
All that said, if a Cycles workaround would increase rendertime, it would be nice to have an option to enable/disable it per object, as you wouldn't want to increase the rendertime on objects on which the effect is not visible.
As this report is archived, I will allow myself to be a little off topic.
@Caetano (Caetano). In certain situations I have found that Eevee can give a similar effect to Terminator problem in low poly meshes:
I'm not sure if it's exactly the same problem since it's not a ray tracing engine.
not a good idea to get off topic even if the task is closed.
But yeah that looks bad. However, decreasing the lamp radius makes the effect disappear.
Also remember that it's still under heavy development so I'd rather wait for the beta release to open a new task for it.
No good idea, need to resolve problem with Cycles, and blender render. 5 years this bug or more
@CHET (cheteron) There is no terminator artifact in Blender Render.
As for Cycles, once again, it's not a bug but a feature to optimize render time which has been there since the very beginning of Cycles, so no need to precise how many years the issue has been there.
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.
