- User Since
- Jun 2 2013, 4:47 PM (194 w, 15 h)
Fri, Feb 17
Thu, Feb 16
Fri, Feb 10
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.
Thu, Jan 26
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.
bug mis hdr.blend
Nov 5 2016
added missing bits and updated to master.
updating the patch to correct above mentioned problems and make it to apply on master.
post the error message here and attach a file to reproduce the problem.
Which driver version are you using? Note that AMD GPU-Pro 16.3 is more stable than 16.4.
Nov 4 2016
closing as todo after IRC discussion. Will investigate further what led to this report in cycles.
updated with renders and viewport images:
Note that the exporters also do it right, which explains why external renderers render correctly also.
In which case would a dependency not need to be linked and applied like in the original file?
Nov 1 2016
I would rather close it as todo. There is absolutely no warning in the UI that packed texture will explode the memory usage, even if unpacked afterwards and that an external tool is then needed. Is it really hard to implement single channel packed images that it has to wait for 2.8?
Oct 31 2016
Oct 29 2016
any news on this patch?
Oct 26 2016
Oct 24 2016
Oct 23 2016
@deom damien (dams) The performance boost in production shots definitely comes from the new node_features because all the production shots use the group level 3. I personally didn't notice any impact on performance when just moving cases around. The new organization of the groups is to allow optimal performances in this groups while trying to follow artists usages:
switched SoA to supported kernel and AoS to experimental. AoS is faster in most cases and benchmark files are set to experimental by default. Point is to gather better time results.
2 good news :) many users on BA and I were not dreaming and AMD fixed the problem in it's latest compiler. Now it would be good if they could ship this new compiler for all platform. Could we have access to some dev drivers through Mai? Or ask during the Bconf as a dev from AMD will be here. It would be good if people working on the OpenCL kernel could have a direct email adress to stop guessing for what is on AMD's side.
Anyway, this patch gives good performance improvements on all cards and platform. Around the 5-15% in my case if we remove the compiler bug.
Oct 19 2016
It works :) The buggy render seems to be due to the flame attribute having another value mapping than on CPU. Maybe it's not due to this patch?
Oct 18 2016
Just to say it's a huge time saver for programmers. It allows to test optimisations and new features much faster. So it would be really helpful to add it at least as an experimental feature to master.
Oct 17 2016
Edited: misunderstood patch.
Oct 12 2016
Problem solved, thank you :)
Oct 11 2016
Oct 9 2016
I used this script test_single_nodes.py with my patch to get render times with different nodes. Because combinations also have an impact, it makes hard to test every possible combinations (with 84 nodes, we would have to test 2^84 combinations). So I just tested adding single nodes to see there impact when rendering the default cube at 1024spp.
Workflow is to start patched D2254 blender, choose cycles as render engine, set samples to 1, run the script once to compile all kernels. Then render a second time with 1024spp.
It is best to do it with D2264 applied to speedup kernel compilation.
Problem at the moment is that the best method to get pure render time is to get them from the console output, which isn't really easy. So if someone has a solution to expose render time to the python API through an operator or a custom property or whatever, it would really help analyze the times.
Oct 7 2016
@Lukas Treyer (cnd) would be good to add this fix to 2.78a :)
Thanks :) Fix works for the one error. Note that there is no such big object visible in the original file nor in the DXF when opened with our CAD program, it looks like one point was moved to 0,0,0. The original file being in Germany thus thousands of kilometers away from 0,0,0, it may be what makes the object so big.
I have an narrowed down file with the second error triggering a crash in our production file. bug 3.dxf.zip
@Howard Trickey (howardt) thanks a lot for maintaining this very helpful addon :)
Oct 5 2016
Oct 4 2016
Little update. Hawaii architectures based cards also greatly benefit from this patch with impressive speedups: See https://blenderartists.org/forum/showthread.php?400121-AMD-RX-480-with-8-Gigs-of-Vram-at-229&p=3100843&viewfull=1#post3100843 .
I did some test to see which nodes trigger a big slowdown on RX480. On the microd.blend at 64spp with one tile I get this rendering time (without scene preparation):
Oct 2 2016
For me it only fails when installing the first time over 2.77a. Repairing or desinstalling then reinstalling resolves the problem.
Sep 30 2016
Good patch with really useful additions.
It would be good to have an option to set the image plane's origin at the bottom of the image. For trees, people, etc... it's useful to put them on the ground and be able to scale them without them going underground.
An option to add them to a group of the same name as the image/mesh would also allow quick instancing through dupligroups.
I hope this patch gets reviewed and committed quickly :)