- User Since
- Oct 25 2015, 9:03 PM (187 w, 6 h)
Apr 6 2019
@haaput (haaput) no further work that I've heard of, although if you have a particular use case you'd like to solve, I might be of help to find a workaround. Feel free to PM me on blender.chat (https://blender.chat/direct/chameleonscales)
Jan 22 2019
Dec 18 2018
Dec 4 2018
@Daniel Cañizares (dacanizares) no idea, sorry.
Dec 3 2018
Nov 20 2018
Sep 17 2018
@Dan Hickstein (danhickstein) Still not, apart from the workarounds proposed in Stackexchange. That said, I wonder if the Everything Nodes project can address this even though it's a Cycles feature.
Aug 22 2018
May 16 2018
in intern/CMakeLists.txt, the last line add_subdirectory(SLIM) causes Linux to fail building the branch because Linux is case sensitive. We have to manually replace SLIM by slim
Apr 15 2018
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.
Apr 14 2018
@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.
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.
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.
Jan 14 2018
I made an add-on that hides the backfacing geometry in edit mode to address this issue. You can download it and find more info about it here : https://github.com/ChameleonScales/Backface-Hiding
Sep 3 2017
Sep 2 2017
I haven't heard of a planned change in the behavior of the 3D cursor for 2.8 but I'm not involved enough to know. You probably know better, so, do as you wish
You made some good points. I update my proposal :
Sep 1 2017
I think you didn't reply to Aaron by telling if you did try on RC2
Aug 26 2017
Adding info :
Detail flood fill doesn't work when the origin of the object is not at the center of the object. Doing Transform > Origin to Geometry fixes the issue.
Aug 20 2017
This has likely been fixed in 2.79. See this gif :
Aug 19 2017
ok, sorry for that.
Closing the other one and keeping this one would make more sense to me, as the other one doesn't qualify as a valid bug report (more as a feature request), whereas this one does, as I explained in my previous commentary, but I'll leave it to you from here.
Note that even the non-regressed version doesn't completely fix the issues mentioned in the other task in terms of parallelism between the UV edge and the bled edge. If the quad is distorted, you lose that parallelism :
I assigned you because you were assigned to this one https://developer.blender.org/T43709. It may be the same issue but I'd like to know if you have an answer to my question above.
Aug 12 2017
I also made a rightclickselect proposal :
Aug 11 2017
I created a clarified version of your report here : https://developer.blender.org/T52355 and closed this one.
This would be understandable as the surface of the object is affected by the boolean object. However it should at least work when the modifier is hidden, which is not the case. We have to remove the object from the modifier or remove the modifier itself.
I can't seem to have that problem with Arch Linux
Aug 10 2017
It's not a bug but the behavior of the feature is a bit cheap.
The way it extends the pixels is as shown in this image (according to my experiments) :
This has been fixed in 2.79
Aug 9 2017
I agree with Jonathan. Margin is being used for both spacing UV islands when unwrapping and extending the pixels when baking for example.
And bleeding is also used for extending pixels but this time when painting a texture. It's a bit confusing.
Jul 28 2017
Jul 27 2017
Jul 24 2017
There you go