- User Since
- Jan 24 2006, 5:03 AM (583 w, 6 h)
Dec 20 2016
Dec 11 2016
Using Carve actually doesn't fix the issue in Bmesh but thanks anyway. ;)
Dec 9 2016
Dec 7 2016
Dec 4 2016
It can be reproduced with the official 2.78a release and todays buildbot version for Win64.
Dec 3 2016
Then I suggest to change the default method back to Carve until someone will take care of the Bmesh method. In the current state and without active development this is an experimental feature at best.
Nov 16 2016
I couldn't reproduce the compositor issue, so I assume a mistake from my side. It works correctly, don't bother.
Nov 15 2016
Appears good to me.
An intentional change that ignores previous affinity settings just to overwrite it, is not really better than "Windows stupidness".
May 6 2016
Jul 26 2015
Looks like it comes down to following requirements and thus considerations for Blender redesign:
Jul 21 2015
Apr 3 2015
The unlinking issue can be harmful to your work. Think of one who would like to move a complex simulation rig into a different scene for logistic reasons, everything looks perfect for the user as everything appears to work. Now he deletes the simulation in the original scene and saves his work, unknowingly that he just destroyed his simulation which he considered to be safe in the other scene.
Apr 2 2015
I have to correct the report again. Apparently when linking to the new scene both rigid body and constraint settings will be linked as well. But if you now unlink both from the original scene the settings in the second scene are gone too. I guess they should be copied then?
Mar 23 2015
Let me correct the report then as follows.
Mar 21 2015
Aug 27 2014
No specific steps, load the cube_bugtest.blend into Blender and render animation (baking is optional). After the first frame the result should look like one of the wrong examples above.
Aug 20 2014
Looks like the bug is back. I can confirm that my test blend file doesn't work anymore, too. The cube disappears completely now despite a fully baked simulation.
Jul 19 2014
Thank you for taking the time to explain, I'm fine with it then.
Jul 17 2014
Generated coordinates are about object space and as much as I wouldn't expect global space to be deformed by modifiers I wouldn't for generated coordinates.
Jul 15 2014
Jul 11 2014
A quick own build shows no crashes anymore, will check others when they arrive on graphicall.
Jul 9 2014
So, I did some deeper testing and can provide some more concrete info now.
Jul 7 2014
Rendering in CPU and GPU crashes for me immediately on this file. Before starting the actual rendering process. Viewport rendering also crashes. I didn't test the latter for this file before, but in other files it worked most of the time.
I used baking everywhere but it crashed anyway, and this very early not as late as frame 65. On what OS are you working on? I have learned that Linux is much more "unconcerned" when it comes to bad memory access other than Windows, making it even harder to reproduce errors.
Jul 5 2014
May 15 2014
I found the cause, it's the "persistent images" option which prevents not only images to be reloaded on frame change but also smoke data. Disabling this instantly fixed the problem.
May 14 2014
May 9 2014
May 4 2014
Tested on Windows. Works in part but the simulation still continues on rerendering and then produces still artifacts.
Jan 23 2014
Could you at least make the "Copy Data Path" from the right click menu returning the correct path? This would certainly lower the barrier for users to actually use this feature. Thank you nonetheless.
Jan 10 2014
Thanks but the driver still doesn't accept this path. It doesn't accept the full path and not 'node_tree.nodes["Mapping.001"].rotation' as sub-path, so how do I resolve the problem?