Artifacts in Cycles render for lowpoly models. #37814
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
23 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37814
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Changed status to: 'Open'
Added subscriber: @PaulGeraskin
#70716 was marked as duplicate of this issue
#61745 was marked as duplicate of this issue
#61668 was marked as duplicate of this issue
Changed status from 'Open' to: 'Archived'
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.
Added subscriber: @ChameleonScales
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...
Added subscriber: @AlmaTalp
I agree with Caetano, it is a real issue with low-poly characters what deserves to be solved.
Added subscriber: @cheteron
Same problem... 2017 year
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.
I made it: https://rightclickselect.com/p/rendering/Mtbbbc/fixing-terminator-effect-and-other-rendering-artifacts-in-cycles
Thanks
Added subscriber: @Blendify
Note that a better explanation of this issue is described in this paper, look for "Terminator problem"
https://pdfs.semanticscholar.org/7986/ebd7b5427bbe54edb7c0c9cf674fee817933.pdf
The question is then how a workaround could be made from algorithm side, am I right?
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
Added subscriber: @LukasStockner
@LukasStockner Maybe something you would like to work on someday.
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
Added subscriber: @brecht
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
Added subscriber: @Stefan_Werner
{F2686563}Problem not fix today
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.
Seems as a good idea using per object base.
Added subscriber: @YAFU
As this report is archived, I will allow myself to be a little off topic.
@Caetano. In certain situations I have found that Eevee can give a similar effect to Terminator problem in low poly meshes:
terminator_monkey_eevee.blend
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
@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.
And how change this feature, for normal shading?
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
Added subscribers: @DavidHorbach, @nacioss
Added subscriber: @Renderbicks
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:
Added subscriber: @LucasVeber
@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.
I found this called "Shadow Bias":
@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.
Very nice find. Thanks for the PDF and info.
No Terminator Effect with Redshift (latest trial):
Added subscriber: @PtiLuky
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.
The fix in "Ray Tracing Gems" applies to a slightly different problem.
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.
Thanks for letting us know, glad to know. Fingers crossed.
Added subscriber: @Archost
Added subscriber: @RafaelChacon
Added subscriber: @item412
Added subscriber: @ChristophWerner
This comment was removed by @ChristophWerner
@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:
f3a4f12ac0, type: Releasebuild 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
system-info.txt
terminator_effect_cycles01.blend
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.
OK. Thank you.
Hopefully it will be fixed soon.
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.
Added subscriber: @Asco
I have this problem, I ask you to fix it urgently, it interferes with the work.
Added subscriber: @lichtwerk
I think this is already on the module list:
#66305 (Render & Cycles Module)
#68920 (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/).
These are very good news @Stefan_Werner , thanks for sharing!
Added subscribers: @3di, @dark999, @grosgood, @SpectreFirst
Added subscriber: @zebus3dream
@Stefan_Werner 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:
373e936e3esmooth shading bug test geometry.blend
Looks like the same problem, as always. No difference to the old builds for me.
@Stefan_Werner 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 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!
I’d donate my left nut to science for this to be in the next daily build.
Added subscriber: @BukeBeyond
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.
This comment was removed by @BukeBeyond
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.
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.
@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 and @LukasStockner did:
So please let us discuss here constructively with knowledge.
This shows that other engines do better than cycles.
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.
Removed subscriber: @nacioss
@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.
@cheteron @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.
@cheteron @AlmaTalp
@cheteron @AlmaTalp @LucasVeber 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
Shadow bias, and don't tell me than cycles beter. Cycles didn't win.
And when u render in Arnold - turn on backfacing
Eevee render.
BXyi1rJYLN.mp4
@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
Apple Seed might use the same method as Vray or Arnold/RS does.
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.
https://www.yiningkarlli.com/projects/shadowterminator/shadow_terminator_v1_1.pdf
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.