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 (and more fascinating) 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