- User Since
- Jun 2 2013, 4:47 PM (199 w, 17 h)
Fri, Mar 24
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).
Thu, Mar 23
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:
Sat, Mar 18
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.
Thu, Mar 16
@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".
Wed, Mar 15
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) ?
Tue, Mar 14
@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.
Mon, Mar 13
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?
Sun, Mar 12
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.
Tue, Mar 7
Updated diff to make it compile with C++11 as Brecht suggested. Also added missing bits for optimal performance.
Mon, Mar 6
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 45. 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 sill 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.
Sat, Mar 4
Mon, Feb 27
- 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.
Sun, Feb 26
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?
Jan 18 2017
Maybe related to this https://developer.blender.org/T48834#410518. Anyway, I can confirm that I experience exact same problem from time to time on big scenes (crash at render begin or when render finishes.) But it's rare enough (about once a day) to be acceptable in my case, although it's annoying to lose 30min of rendering. But restarting blender always worked for me.
Jan 16 2017
@Sergey Sharybin (sergey) Ok, great if it's intended to work on GPU. For some reason, it doesn't work with the split kernel. Everything compiles and renders, but without any replacement by GI after the chosen bounce number. On CPU, it works great.
Jan 14 2017
Great speedups on CPU indeed. Is there a limitation making it impossible/not worth on GPU?
If some improvement visible to user (in speed or functionnality like SSS and volumetrics) can be reached for 2.79 with this new code, I would add it to master.
If benefits are only for programmers, I would add it to 2.8. Otherwise, it would just be risking breaking rendering on different configurations, cluttering the bug tracker more than it is already and maybe releasing a 2.79 (which may be used over a long period by many users) that will not be stable.
Jan 10 2017
Can confirm the bug. Indeed, changing the rotation value in the N-Panel works, but the modal rotation in the 3D view doesn't work anymore. Having a scale not equal to 0 deactivate the bug.
Can confirm the bug for both files.
Indeed, selection is wrong, can confirm, but it's a known limitation that Blender can't handle large object counts.
I'll however let the bug open until it's sure that the problem really comes from the amount of object.
I can confirm the bug.
Can confirm the bug, viewport render restarts indefinetly.
Jan 7 2017
Can't reproduce the bug here on Linux, painting in UV/image editor and clicking many times in the 3D view.
Looks like a driver issue. Windows 10 is known to be pretty unstable also, installing new drivers that are rather experimental without asking. Attach your system info (help menu -> save system info).
Can confirm the behavior. Really looks like a bug indeed. It only happens when the bevel modifier is activated, so I'll let @Howard Trickey (howardt) decide.
The size cannot be changed, because of the driver it has. Deleting the driver and increasing the size doesn't show up more particles. By the way, the size is in particle system/ physics section, not render. There is a scale option in render, but deactivating or activating it doesn't change anything, so I guess it's not what you meant either?
You worked hard for this report, but I can't see what is not working as expected. Please add a screen-shot of how it looks and how you think it should look.
@Ajlan Altug (jacobo) can't reproduce issue, but it may be due to missing alembic file?
Can confirm the bug. Is pretty annoying as it can't even be canceled. One has to kill the process to cancel it.
Jan 3 2017
@Aaron Carlisle (Blendify) put some reviewers to get it reviewed, looks good.
Dec 22 2016
@Aaron Carlisle (Blendify) I must say I also experience a lot of non-reproducible crashes since 3-4 weeks with buildbots. I set the auto save at 1 min to be able to restore the file before it crashed, but it doesn't help. Redoing the exact same steps after opening the autosave doesn't trigger a crash. It happens most of the time with material and when entering edit mode, but also sometime at rendering start or end.
Really don't how to report those bugs, but they are there.
Dec 17 2016
Dec 16 2016
From a design point of view, will it allow to link/append node trees from addons (like Luxblend for Luxcore or animation nodes) with needed textures, meshes and whatever can be referenced in a node tree?
Dec 8 2016
That new effect is really cool :) I can definitely see some good usage for it in engineering and architecture. And it then makes sense to have it as a node.
Dec 7 2016
Tried different revisions, will try more tomorrow, but at least in may 2015, it worked. So it happened after may 2015. Just one year and a half of commits to check :D
Dec 4 2016
Nov 20 2016
@Bastien Montagne (mont29) thanks for the fix. It is also my feeling that Linux Builds crashes much less. At least in this case, windows help get a cleaner code :)
Nov 15 2016
Nov 14 2016
added a check for the integrator setting "cycles.use_transparent_shadows" as user may disable transparent shadows even if some transparent shaders are present in the scene. Thanks to @Mai Lavelle (maiself) for her help on finding this solution.
Tab to spaces and some wrapping corrected. For some reason, the wireframe line still is not aligned...
@Sergey Sharybin (sergey) Well I thought the reorganisation alone didn't give any speedup, which is true for BMW. But I've tested other files and got following result on Win7 x64 with 16.11.2:
|Scene||spp||Preparation time||master||D2340||D2341||gain (over master) reorganisation||gain (over master) selective node compilation|
Interesting to note that gains on Windows are comparable to those on Linux for Barcelona at least with -8% with D2341, although Linux is way faster than Windows again.
Nov 13 2016
I can confirm the bug and it's pretty annoying. Looking back at old projects, I did some serious mistakes because of this 90° rotation only happening on blocks. Would be great to have the fix backported to 2.78.
@Mai Lavelle (maiself): first bunch of benchmark with this patch, I'll be updating as it comes:
Ubuntu16.04 with AMDGPU-Pro 16.40 and RX480
All scenes from the cycles benchmark pack, using GPU version of the files with tile size of 2048x2048. Patch applied on top of 818af9c3315cb883436a3d75d634f449133cd3d9. Times are with scene prepartation time removed (so pure rendering time)
Nov 12 2016
Nov 11 2016
@Bastien Montagne (mont29) but only on windows, Linux just doesn't really reload/update the node group.
yes still happen:
Reloading the whole Blend file works as expected.
Nov 6 2016
Thanks for the quick fix Lukas. The image is much cleaner indeed :) And requiring twice the resolution only is much better.