- User Since
- Oct 12 2014, 1:52 PM (157 w, 6 d)
Mon, Oct 16
I think this thread in BA forum is related (just in case developers can find some pattern there):
Sep 18 2017
I have read before that the mere fact of having installed some GPU overclocking application can bring conflicts with Blender, even for CPU render. I say this because I read above about MSI Afterburner. So just in case to do reliable tests, if you have any of them installed (MSI Afterburner, ASUS GPU Tweak, etc.), completely remove the application.
Sep 11 2017
Maybe new Russian Roulette method helped here?
Just to mention just in case. If you increase Lamp size (1 for example), some weird things still happen in this scene using resent blender from buildbot:
Sep 10 2017
Regarding the comment above, I'm not sure how this could be OS dependent. But I can still reproduce the problem in Linux, blender from buildbot 11a9434c2de
Sep 1 2017
Here the explanation by Pascal about this in Principled shader:
Aug 26 2017
I agree with 'bigbad' about "They are for testers and user feedback" part in that message can be confusing, and users could spend time making reports that will then be closed. Maybe delete that part of the message, and even better than that expressly clarify that Blender 2.8 is not yet in a stage in which user reports are accepted.
Aug 17 2017
For "bmw27_cpu.blend" scene downloaded from blender.org (not the BMW27.blend scene belonging to Blenderartists forum), the time you get 2 m 32 s looks to me very little time for an 8-threads i7 CPU. 5 m 51 s looks to me more feasible. What is the exact model of the CPU? Did you compare side by side the resulting images to see if they look the same?
Jul 21 2017
Yes, that nodes setup from the link makes a lot more sense. I just thought that to do something like that could be as easy as mixing two Emission Nodes connected to Volume, and controlling the weight with Layer Weight. I am very bad with nodes, my mistake.
Ok, sorry, Perhaps obvious to experienced people, but Layer Weight Node documentation did not clarify anything about not usefull for Volume. Now I have just found the right way to do what I intended to do in cycles:
Here I mention some other examples where I encounter problems with volumetrics. I am not good with nodes, so I apologize if this is due to my mistakes with configuration.
In the following example there are differences between GPU and CPU render:
Jul 10 2017
Jul 9 2017
Thanks for the fix.
Here I modified the file a bit and packed a free HDRi to make sure we are all comparing the same scene:
Jul 8 2017
Jul 7 2017
Some tests. The effect is also visible with pure metalic Principled BSDF connected to eevee material output. Glossy BSDF connected to eevee material output looks very similar to Cycles (Glossy and Principled on Cycles).
May 19 2017
I can confirm this on Linux too, GTX 960. Hash: a7c4b6f
May 17 2017
Testing the patch with the scene shared by pafurijaz user here:
I hope I have applied the patch correctly, otherwise my apologies if it was not so.
May 16 2017
Here's what I get in Blender from buildbot ( 8ca9fa5fd36 ) with GPU:
Mar 21 2017
It seems Shadow Catcher is working well in my tests, it seems to react well to the variation of different lights:
Edit: corrected the previous scene (had forgotten to select to repeat with offset in one of the modifiers):
Mar 17 2017
Yes, it is. That's what I mean when I say I've seen this kind of problem before. So let's wait for what cycles developers say about this.
Whenever you see this kind of strange problems related to slowness in certain frames or frame intervals, you should see if this is related to Motion Blur enabled.
I have seen other times Motion Blur cause these kind of problems. I do not know if this is due to a bug or just it is one of those known problems that usually have Motion Blur in Blender.
Mar 15 2017
This is working now.
I think that with 'OpenGL depth picking' it's going to be the first time I'll be able to use Blender with intel on Linux.
Mar 12 2017
Mar 8 2017
Mar 6 2017
@Lukas Stockner (lukasstockner97) , This is the story: I was having these crashes when trying to use image as plane with my photos revealed and exported from Darktable (tif format). The crash was always reproducible, I always did the tests without packing the tif in .blend file.
So then I had decided to report the problem, and because the problem does not occur with any tif, I decide to pack the tif into .blend file to include in the report. So before sending the file I do the test again, and, wait a minute!... Is there when I find that packed tif does not produce the crash.
So yes, the problem basically happened with the original file.
Mar 5 2017
Dec 4 2016
Oct 20 2016
Thanks Lucas for the clear report and thank Sergey for the fix.
This problem had given me more of a headache with some addons, and some people out there having this problem but without them knowing exactly why.
Oct 10 2016
Not directly related to the problem you mention, but at least you can use GPU compute until you can solve the problem. If you are using nvidia drivers installed from repos, I recently read that in Linux Mint you still need to install 'nvidia-modprobe' package. You look for that package, install it and reboot the system. Remember that you also must have installed 'libcuda1' related package. And of course you should use official Blender downloaded from official Blender 3D website which include precompiled CUDA kernels (tar.bz2 file for Linux). Extract to a folder and run there 'blender' file.
You can search about 'nvidia-modprobe' and Blender in Google, there is much written.
Sep 28 2016
So who should open the new report about bmesh boolean modifier?. I really do not know how to open this report and what information provide there.
Sep 22 2016
I can reproduce the problem if 'File > User Preferences > System > Images Draw Method > DrawPixels' is selected, in Blender 2.77a ( abf6f08 ) and blender from buildbot 2.78 ( 21e9db9 ).
Kubuntu Linux 14.04 64 bits, GTX 960 (370.28)
Sep 21 2016
It makes no sense to me that Carver (almost a CAD tool) can not be used in Orthographic view. By the way, Pixivore examples are working on Ortho view:
Hi. I think I can reproduce this:
Sep 15 2016
Sep 11 2016
Aug 25 2016
Thanks for reporting to nvidia and for update here what nvidia says.
Aug 23 2016
Aug 19 2016
I can confirm this. Kubuntu 16.04 - GTX 960 - nvidia 370.23 (beta driver acording nvidia home site). Blender from buildbot: d41dfe3
Aug 18 2016
Thank you sergey.
This new patch seems to be working much better. I've tried it with my file with different sizes and strength in lamps and shadows match pretty well in the plane with shadow catcher and in the plane without shadow catcher.
I have also tried the file 'shadow_catcher_submit_01.blend' by hype, and the blue emmiter ring no longer have much influence on the total shading, which is good. In this scene I just noticed that there are some reflections in the plane with Displace Modifier under the hard black shadow, and I'm not sure about whether this should be so. Select the Sun lamp, set Size=0, and you start to move the Strength smoothly from 0 to 10 while you see the shadow changes in rendered view preview. It looks a little weird for me, but maybe that's as it should be.
I recently discovered this about the Shadow Catcher and I'm not good at compositing, then sorry if my .blend file have errors.
My concern is whether the intensity of the shadows obtained on the plane with shadow catcher should be similar to that obtained on a plane with difuse material and without shadow catcher. Here in this scene render shadow catcher when you just open and render image. If you enable the first render layer and disables the other three, you get the scene with shadow over the plane without shadow catcher (I guess):
Aug 5 2016
Yes, but if this was a particular problem with the graphics tablet like this I had, then the problem should be present in texture paint, curve draw and GP (exactly like the problem I had). Sorry if I intruded on the report, I just requetsed the test to discard that this could be a general problem with the graphics tablet in Blender or system, because I had seen those similar artifacts that I had that time.
To see if it is a problem with the graphics tablet on your OS. Could you try if you have the same kind of problems in .blend files I had shared here?
Jul 28 2016
Working well now.
Jul 26 2016
I have compiled from master and I have not been able to reproduce the problem anymore, it is working very well.
Jul 20 2016
Ok, I see. Thank you.
I really do not know much about sculpt in Blender, so I really do not know exactly how it should be the behavior of the brush. So I have some questions.
I have compiled Blender from master (690063e) and when open the test file I noticed that "Accumulate" option is enabled by default now. If I disable "Accumulate" before beginning to sculpt, then the behavior is the same as mentioned earlier in this report, making that kind of bump in the first stroke. So this should be that way when "Accumulate" is disabled?
Jul 19 2016
Jul 15 2016
Sorry for the typo in the title, maerial=material
The user can not edit the title, right?
Jul 5 2016
Perhaps I have not been clear here. Apparently you refer to World (HDRi environment texture) strength. You do not touch that value in the scene, you leave that value to 1. With "strength=0" I am referring to the lamp selected by default when you open the scene. You just open the scene and render in Belnder from master (Do not forget to load the HDRi). Did you not get a resulting image like the first image I've shared?. I think it should look like the second image I obtained in Blender 2.77a.
I know, there is no logical reason to put there a lamp with strenght=0. But anyway I do not see any reason to get a resulting image like the obtained from master (first image).
Regarding whether this occurs in CPU/GPU, master/buildbot:
On my machine the render looks good with 2.77a (abf6f08):
Sorry, this happens with any type of lamp with strength=0
Jun 26 2016
Jun 19 2016
Jun 16 2016
Stefan Werner, Do you have in your OS the virtual memory located on a 7200 rpm disk?
Sorry if I misunderstood, but your system freeze reminds me of those I have in Linux when the system begins to fill the Swap intensively on a slow disk (as one of 7200rpm). That always happens in Linux when intensively fills the swap, swap management is not good on Linux (you look in google how a lot of people try to avoid using the swap by configuring swappiness).
What I mean is that if the freeze on your OS was due to the intensive use of the swap, then maybe in a system with more RAM the problem does not occur.
Jun 15 2016
With Cosmos Laundromat default scene (for CPU benchmark) I still have CUDA out of memory error. I guess I need more than 16 GB of RAM for patch works in this scene?
Jun 14 2016
My test in case it result useful. I'm not sure if I understand if this applies to Maxwell cards too for example.. Anyway here my test:
Jun 9 2016
Manuel: Utiliza el traductor de google tanto para escribir en inglés como para entender lo que aquí los desarrolladores te dicen.
Jun 8 2016
Jun 6 2016
Thank you. Now there is no fireflies and CPU and GPU render result match.
Jun 3 2016
David Jeske (jeske). You configure on Cloth, Quality > Steps at least a value of 10.
Jun 2 2016
May 30 2016
May 22 2016
May 19 2016
Compiled from Master, it is working well now!
I opened a report bugs.freedesktop.org
May 11 2016
I have contacted Nikolai Kondrashov, DIGImend founder and main developer. I shared with him the next file showing Evtest, Xinput and Blender output while drawing on Blender:
May 7 2016
That's right, I have not noticed weird behavior in other programs on Linux when pressure sensitivity is enabled. Also, texture paint and curve draw are working really well on Windows 7 with the same hardware. So I discard hardware problems.
I'll see if I can report somewhere issues related to the driver on Linux.
You let me know if I followed well the steps:
Yes, I can compile from master. But give me some instructions or text to read if I have to enable any debug option because I have not much idea about that.
Thank you Bastien. But unfortunately I do not notice any change in the behavior of my tablet with this build when pressure sensitivity is enabled. I still have the same problem.
May 4 2016
Thanks Bestien. I know it is difficult for developers if they do not have one of these graphics tablets.
May 1 2016
Hi. No, I do not notice changes in curve draw or texture paint. This is still broken. Compiled from master (hash: b1f6cd5)
By the way, I've contacted by mail to a person who has a similar tablet:
Apr 29 2016
Hello. The previous evtest was obtained by drawing the curve "on the air" over the desktop. Just in case, this evtest was obtained by drawing the curve in Blender:
Apr 27 2016
Ok, I'm a little confused. Apparently the addons also have to do with the problem. Currently responsible in my setup is "Natronizer" addon. But I could assure you that I have had this problem before and before having "Natronizer" addon installed.
Here I share my simplified configuration folder for you to test 2.77 if you can reproduce the problem. Rename your configuration folder 2.77, and extract and copy 2.77 folder there I'm sharing:
Apr 26 2016
This happens to me from time to time (Linux 64 bits), and has also happened to me with vector blur. In my case, I think the problem is related to when I save a new startup file (Ctrl+U) with Cycles as render engine by default. When this problem occurs again, I must delete " startup.blend" and "userpref.blend" from my user configuration. I must delete the two files, because if I remove only one, the problem still occurs.
Apr 21 2016
This is what I get from "evtest" drawing a curved line along the verticlal:
Apr 20 2016
Hello, here the test with pinta on Linux and Windows:
Apr 6 2016
Kubuntu Linux 14.04 64 bits, GTX 960 4GB, i7 3770
Mar 10 2016
Feb 16 2016
Sep 28 2015
I'll try to do a quick summary to not be confusing.
The behavior regarding whether Blender is installed from repositories or official Blender, is the same.
The scene "crash" in all Blender 2.7x (tested on 2.70, 2.72, 2.73, 2.75, 2.76 RC2, git master).
The scene works well in Blender 2.68 or 2.69.
Executing Blender 2.7x from terminal with "-t 1", the scene does not crash, play animation in viewport works well!
I can not compile in Kubuntu 14.04. In 15.04 I had to disable compositor otherwise I get errors. Here is the log after crash:
Sep 27 2015
Very nice that cmake-gui! Thanks. Anyway I'm getting errors when trying to compile. I will continue investigating.
Ok, my knowledge about compiling blender are minimal. I just follow this guide:
and I compile using pre-defined build target "make". I have no idea about cmake and flags. The truth, I understand very little about what explains the link you gave me. If you can give me some easy instruction about how to compile with this thing enabled (just for a simple user of Blender) I would be grateful. Perhaps modifying something in CMakeLists.txt file?
Anyway, I will continue researching about this and see if I can do it.
This is weird. On my machine this is an "always crash", "always reproducible."
Tested in two different 64-bit Kubuntu installations. For now I was using official Blender tar.bz2 (2.73a and 2.76 RC2). But I just compile/build from master, and the crash also occurs.
You analyzing these crash logs before I posted, you could give me some clue about what may be going wrong in my machine?
Here attached scene (zip). I hope I'm not breaking the license:
Sep 25 2015
Sep 12 2015
Here it is:
Aug 12 2015
Ok, thanks Martin.
@Martin Norris (MartinNorris). Yes, I see a similar result. But it's hard to know if anything changes a lot with that "flag3.blend" file.
Here I have done some testing with the other file involving collision, comparing 2.73a, 2.75.4 and patched 2.75.4. Here videos and files: