- User Since
- Jun 2 2013, 4:47 PM (207 w, 6 d)
Thu, May 25
Couldn't reproduce here. Please use latest buildbot before reporting a bug. It may have already been fixed.
I think it's more a design problem than a bug. It's one of the area in Blender that doesn't follow the philosophy of "don't think for the user". The depsgraph will decide in which order the modifiers should be applied and sometime fails at finding the right order, because in some case their are several possibilities, all valid and it's more a question of artistic decision.
The solution to it would be to have a way for the user to order modifier execution. The everything node system will solve it on the long term. In the meantime, it could be solved with a scene stack of modifiers instead of being limited to object stack.
Wed, May 24
It is just how blender works, not a bug. I also find it not really understandable that a display option has an impact on geometry without any warning nor infos in the tooltip. But it's a design task more than a bug. Zero could also completely disable that behavior like in many other cases in Blender (letting objects use the unit system as one would expect)?
Sun, May 21
@Brecht Van Lommel (brecht) and @Sergey Sharybin (sergey) wouldn't it be better and possible to take last valid texel value instead of 0,0,0 for replacing NaNs while cycling through all the texels of the texture?
ok, tested a little bit more. Some errors only show up when other addons are activated. An easy way to see it is to activate all addons and press F8, then you get the errors form castle, creaprime and animated text plus this:
@Brendon Murphy (meta-androcto) creaprime, castle and animated text stil have reloading problems, other are solved :)
I tested the other ones again to see if the new build solve the other problems:
measure panel support F8 now as long is it was not activated, otherwise, creating a new file or reloading give this error:
Hi @Okavango (Okavango) , can't reproduce either in latest build, I must have had an old build somewhere. Updated task.
Sat, May 20
Fri, May 19
I see no errors in latest buildbots, please try with one from https://builder.blender.org/download/ and post an image showing where it's wrong if the bug is still there.
I'm speaking about addons that don't support to be reloaded. The new template system allows to have different addons activated depending on the startup file chosen. It sometime lead to reloading addons (like F8) and crashes when those don't correctly reload.
Thu, May 18
managed to get a reproducible case. But I get the feeling it's only one of many bugs. Will see, here is the file:
Wed, May 17
Tue, May 16
thanks for the quick fix :)
Sorry for the duplicate then :/ I can't merge it with a task I didn't create.
Mon, May 15
Sat, May 13
Sun, May 7
ok, sorry was my bad :/ resolved.
note that buildbot from last week was still working, so it's pretty new.
I would exclude release kernel from this. Many users work on stable but try buildbots regularly. As the buildbots use the same folder as the last and not the coming release, it will make the stable release to recompile all kernels every 2 weeks.
Sat, May 6
Mon, May 1
You can also use a mix. As Jesterking said, you can cherry-pick all commits related to one tool only. Then you only have a few commits related to several tools that can be copy-pasted by hand.
@João Araújo (genio84) Please split the diff per tool. It will be hard to get a quality review for all of them before 2.79. It will allow to commit some of them independently.
@João Araújo (genio84) Can you update the diff with your latest fixes for review?
Fri, Apr 28
Apr 26 2017
Hi @Salvador Ureña (Asticles) ,
Sorry for the delay, I'm very busy at the moment and actually I'm not an official cycles developer. I only have rarely access to a GCN 1.0 card and it's hard to fix without proper hardware. Officially, GCN 1.0 cards will not be supported for 2.79. I can't promise anything, I'll do my best.
Apr 19 2017
Hi @Pascal Schön (VanCantus) ,
Do you plan to separately commit this also for 2.79. I think it would be great to test the whole for 2.79. If you have an updated version that apply on latest master, I'll be happy to test.
Apr 17 2017
Hi @Germano Cavalcante (mano-wii) ,
Finally got time to test. It is pretty reliable and easy to use. Only problem I found is that after a rotation during scaling, it will invert direction (do a negative scale if you were doing a positive one and vice-versa). Otherwise, really useful addition :)
Apr 16 2017
Apr 14 2017
Great to see this issue tackled :) A version for 2.79 would indeed help. In 2.8 I can't even select, so it's hard to test the patch :D
Apr 13 2017
your attached file doesn't crash using buildbot from yesterday in my case (tested 20 times, changing layouts, viewport mode, then F12, etc... windows 7, VS2015 build). But I have the exact same problem on a regular basis. As you say, it only happen on complex scenes and is random. So I never managed to give a simple working example.
Are you sure that the attached file really crash on older buildbots? It may be that this version is still too simple to happen often.
Apr 10 2017
after loading factory settings, I re enabled every addon and every possible option in userpref and it still works. So it is not due to an addon nor option. It seems it was due to a somehow corrupted userpref.blend.
@Salvador Ureña (Asticles) Could you try this build ?
Hit F12 without changing anything once, if the bug is still there, retry with "use selective SVM compilation" activated in the render -> performance tab. Then please report results here.
Apr 8 2017
I got this error with Barcelona "1- time: midday" scene:
Using latest 17.4.1 driver with RX480 on Windows 7 x64
Diff is not made against a master commit and doesn't apply on latest master.
Apr 7 2017
Apr 1 2017
closing until I find the steps that lead to such a broken mesh.
Mar 24 2017
Very useful addition :) I would be very happy with it as is.
For suggestion, enable the user to choose the start location of the new knot by riping under the mouse cursor (so with nothing selected, a knot is added under the mouse cursor).
Mar 23 2017
Ok, another precision. Python doesn't suffer from this problem. So replacing the divide node at 0.0084667 with a multiply node at 1/0.0084667 workaround the bug. But it's really cumbersome. This view is at 39 unit from origin. I wouldn't call that far away, so precision shouldn't be an issue. Maybe constant folding could do this job and change the divide node to a multiply node? Or just rearrange computation to maximize precision?
it's the math divide node that trigger the bug:
Mar 18 2017
Can also confirm. I encountered the same bug today. After double checking, the OGL size and/or position is wrong, the cycles size and/or position is right.
Mar 16 2017
@Bastien Montagne (mont29) well actually, @Campbell Barton (campbellbarton) asked me to split the task in 2 on IRC. The point was that path shouldn't be saved in presets, at least not in every case. I have no strong opinion here now that the encoding bug is fixed. It just works, even if one can find it a bit "dirty". So maybe you can speak about this together?
Mar 15 2017
New version has the same problem, works but is insanely slow, making testing nearly impossible. Can someone else test on Intel CPU with Radeon Crimson 17.3.1 (driver from March 2017) ?
Mar 14 2017
@Sergey Sharybin (sergey) thanks for the update, I will test and report. The slowdown is with latest driver, but with CPU device. GPU is fast as usual. But when working on laptop, it's great to be able to compile the kernel for CPU. With master, it won't compile. With this patch it compiles. Only problem is that OpenCL CPU is (hopefully was) approximatively 400x slower than normal CPU render. It may be a driver bug, but Luxcore works great on OpenCL CPU on the same machine with same driver.
Mar 13 2017
thanks for the quick fix :)
thanks for the very quick fix :)
This patch is very usefull to work on the kernel in the train with a laptop, thank you. But it's very slow using the AMD 17.3.1 driver and Intel CPU as device. The default cube at 50% HD and 10 spp takes 8 minutes to render. Would it be possible to make it render at a more normal speed?
Mar 12 2017
Latest master fixed the crash but an edge is still missing.
Mesh used for intersection is on the left. Note that it has 3 layers. The intersection result on the right only has 2, whatever method is used.
Mar 7 2017
Updated diff to make it compile with C++11 as Brecht suggested. Also added missing bits for optimal performance.
Mar 6 2017
Improvement of 30% to 50% given above are on production scene from the official benchmark pack (BMW, Classroom, Barcelona)
But if you do full selective compilation you are pushing artists ti a situation when adding complexity to their scenes and materials has non-linear dependency on rendering time: one adds one extra node and render time goes up by a factor of 2.
That will not happen. The heaviest node I had during my test (I tested every single node to see impact on rendering time to make my first 3 patches) gave a slowdown of 10%. But even then it's not a slowdown compared to master, it's a lesser improvement. Going from 30% faster to 20% faster is already a gain. And if a user doesn't want the 30% speedup because it could become "only 20%", then he just leave the option unckeck?
- Regarding kernel compilation time, Barcelona takes 15seconds on my machine instead of 45seconds on master. With multi-threaded kernel compilation, it would go beneath 5sec on an 8 thread machine as the longest kernel take less than 5seconds to compile.
- People working on materials do it in viewport, which is not concerned by this patch. So there will be no more compilation for them. For all other cases like sculptors, animators, modelers, people doing archviz, etc. most of the time they will only use library materials, thus not needing any recompile. And even people creating materials, will most of the time only use the same nodes over and over again, only the combination being changed, again, this will not trigger any recompile either.
- For the scary case their would be a recompile: 50% faster render is so huge, I get better complete render time with this patch, including kernel compilation than on master only taking pure render time. So there is simply no reason to not use it in real production scenes.
Mar 4 2017
Feb 27 2017
Great to see this problem tackled :)
- I think it's definitely a good idea to ignore faces for object in bounding box mode. Those are most of the time complex meshes which are instanced a lot like trees. They would occlude the geometry the user really see and give unexpected result for the user (particularly when the bounding box is not visible in the current view, because the zoom level is too high). But for wireframe, I don't see a clear reason to do it. Maybe it could be an option in the snapping part of the 3DView header.
Feb 26 2017
yep, latest buildbot works. Can be closed.
Feb 21 2017
Using the latest version in the branch ( 681089237e33d2fe4b1c46e4a8368c686e60be34 ) I get the following results on 1rx 480 on windows 7 with driver 17.2.1 (pure render times):
Feb 17 2017
Feb 16 2017
Feb 10 2017
This object with this mesh "happened" during work, without script. Sadly, I just noticed the weird behavior to late. The last steps I could remember I did, didn't permit to recreate the bug.
Applying the scale indeed resolves the problem.
But still, why does the extrude properly work on 2.74 and not in master?
Well, I guess it's not a that problematic if this bug stays in master, it seems to only happen very rarely anyway. and 2.74 allowing to extrude an object in a direction that is scaled to 0 is non-sens anyway.
As the steps to lead to that mesh are nearly impossible to find, we can just let it archived until someone get the same problem.
Jan 26 2017
I managed to recreate files that crash on render start with --factory-startup with dummy meshes and textures. But like @matali23 (matali23), when I reopen the file and hit render, it works. So submitting the file wouldn't help much. But it's a real problem, so it's sad if it get's ignored.
Jan 19 2017
@Joey Ferwerda (TheOnlyJoey) I report bugs since 3 years and a half now. I must say this bug is really nasty. I already tried to reproduce it by replacing every mesh with a subdivided cube with similar polycount and every texture with a generated one of same resolution. But even without changing polycount, object count and texture count and sizes, the file just wouldn't crash anymore.
As I said in my comment, most of the time, only reopening the same file, without changing anything is enough to workaround the bug. So I don't see how a file could be submitted here. Maybe let @Bastien Montagne (mont29) and @Sergey Sharybin (sergey) decide if the crash log is enough to find the bug?