User Details
- User Since
- Feb 4 2013, 5:58 AM (426 w, 5 d)
Aug 11 2020
Jun 29 2019
@Aaron Carlisle (Blendify) please correct me if I'm wrong, but closing this issue because Blender Render was removed doesn't make sense to me, because you can perfectly use Cycles to bake textures.
But I'm ok with it because it is not a bug but more like a feature request.
For all interested in producing dithered textures, there is a workaround:
Newer GIMP versions support dithering when converting from 16 or 32 bpc to 8 bpc.
So you can bake 32 bit textures in Blender, export them as exr, open the exr file in GIMP, convert to 8 bit with dithering, export as PNG.
Not very streamlined but it works.
Jul 8 2018
I tested this on Linux with various file formats and libopenimageio 1.8.12 .
Mar 16 2018
I'm happy to say that with current builds (b0823962e9b) this issue is solved. Both methods converge now. The final picture is a bit different from both pictures I originally posted:
Jul 20 2017
I'm not sure if it is float precision issue, but one can see pretty quickly (after 4000 or 8000 samples) that it will converge to a different result.
Jul 14 2017
The issue still persists here with build 0f793ee. @Brecht Van Lommel (brecht) did you render my example .blend file before closing this issue?
Apr 6 2017
Jul 9 2016
Jun 13 2016
The new if statement is working for me :)
I made some progress:
After inserting some printfs in the block starting at line 464 I made these observations:
Jun 10 2016
After upgrading to gcc-5 and gcc-6 I was not able to produce correct renderings anymore (with the -flto trick I used in gcc-4.9)
So I looked at the code in intern/cycles/kernel/closure/bsdf_microfacet.h
May 19 2016
Sorry for the noise. I came to the conclusion that my understanding of correct and incorrect is wrong.
Yes I compiled it myself, hash 89df672.
Hmm, thats strange: To produce correct indirect diffuse color, all RGB channels have to be non-zero.
If only one channel is non-zero then the result is always grey. (although there are different colored objects that should reflect their light onto the baked object)
Can someone confirm this?
Seems that baking produces wrong results only for the RGB(1; 0; 0) diffuse color case.
The intermediate values are ok.
I can reproduce it on Debian.
But the patch doesn't fix the problem.
Before the patch the direct light was buggy.
After the patch the indirect light is buggy.
Mar 18 2016
@Sergey Sharybin (sergey), I just tested the gcc5.5 glibc 2.19 builds. There is no improvement unfortunately.
Mar 17 2016
Finally I'm able to build Blender myself.
The cause of this issue seems to be optimization done by gcc.
Feb 1 2016
Why not make this an option? I used the old orbit behavior to quickly setup the camera for axonometric projection (useful for isometric games and tile rendering).
Now this is much more complicated.
Jan 26 2016
I tested build b336124 on the same hardware (AMD Llano APU), but different OS:
Jan 20 2016
@Sergey Sharybin (sergey), I tried your suggestion with the Debug panel, tested every combination of SIMD flags, and without any SIMD flags, with and without QBVH, but unfortunately nothing has changed.
I can't test the OpenCL kernels because I have a pre GCN (graphics core next) APU, which is not supported by Blender.
A strange problem really, with no solution in sight. I'll try to test it on some other systems and report back.
Nov 28 2015
I still have this issue with the buildbot version on Debian. buid-date: 2015-11-27 hash: bafccb0
Nov 11 2015
@Sergey Sharybin (sergey) This happens in both, viewport and final render. Worked fine in 2.71
Here my system-info.txt:
Oct 19 2015
I can also confirm this bug. It seems that some but not all faces get rotated by 180 degrees during baking.
Here another example .blend:
Press "Bake". After baking connect the bake_texture output to the Diffuse BSDF.
Oct 18 2015
I experimented with clamping roughness to zero if it is less than 0.000173.
Seems to work well.
Not a real fix but a workaround.
Oct 15 2015
Hmm..., maybe the issue is OS, or compile flag dependent.
I use the 64 bit Linux builds from buildbot.
@Carlo Bergonzini (Carlo) Andreacchio, @mohamed (mohamed) Sakr: what OS are you using?
Yes this still happens with latest git HEAD.
I use CPU renderer on AMD Richland APU.
Sep 27 2015
Thanks, for the explanation, Bastien.
I found a setting in the preferences called "Use 3D Viewport" (Screen->Render). I had to deactivate it for my purposes.
Still for quick preview renders we could have another shortcut like ALT+F12, because I think many artist are not aware of this feature.
Just my opinion.
Aug 29 2015
Aug 13 2015
Press F12 to render it. (The viewport doesn't respect the new "Clip" option. It always has the "Repeat" mode. Maybe I should file a separate bug report for this?)
I'm using a second UV map called decal.
The sphere should mostly be covered by the sand texture. Only in the middle it should have the stone texture.
Aug 12 2015
Sep 16 2014
@Alexey (Inwader77) I think what you describe is dithering after rendering, which is functioning without flaws (Dithering is applied on the "Composite" Node).
What I mean here is dithering the texture after texture baking.
Aug 23 2014
Thank you, Sergey! Waiting for the OIIO fixes.
Aug 8 2014
@marc dion (marcclintdion)
Of course dithering should be an option. My last post could be misunderstood.
Right now dithering can't be applied on "Save Image", no matter what options you choose.
I think the solution for this problem is not a Cycles specific fix, but a general fix for the export routine for byte images.
So when you save a float image to a byte image, dithering should be applied (as is done when you render).
Jul 25 2014
Jun 6 2014
@Sergey Sharybin (sergey):
Brecht already fixed TIFF and TGA.
Formats that are still affected are: DDS, JPEG2000, IRIS and DPX
Mar 5 2014
Feb 24 2014
Jan 18 2014
Thank you for the fix, Sergey!
Jan 4 2014
It seems that the "Image Drawing Method" in File/User Preferencies/System plays a significant role here.
GLSL is probably the most stable method (no crash so far), but it's slower than the other methods.
"DrawPixels" and "2D Texture" both cause this segfault.
After a second thought it might be a bug.
Blender 2.69 consumes 26 percent of my 2GB with a 4000x4000 image.
So why should the current development version crash?
Tested again, It's not a problem with the image loading, but with image viewing!
When I enable Backdrop or Show Viewer-Node in UV-Editor then Blender consumes very large amount of RAM.
Another thing I found out is, when I change the "Image Draw Method" to GLSL, RAM consumpion improves dramatically, and I can handle 8K Images on my 2 GB RAM system.
(though Draw Method: "2D Texture" seems to be a bit faster on my system)
But still the current version seems to consume more RAM than 2.69.
So it's not a real bug, but maybe improvements to RAM usage can be done some time in the future.
I tested it again on another Linux computer with 8 GB RAM.
To achieve the same crash I needed to resize the image to 8000x8000.
Thomas could you please test it again with test_image8000.png?
Jan 3 2014
I'm pretty sure I'm not running out of memory. (My swap partition would cause a significant slow down otherwise)
Instead, Blender crashes immediately, without touching the hard disc.
And 2.69 doesn't have any problems opening the test image.