- User Since
- Jan 24 2006, 5:03 AM (690 w, 4 d)
Jul 21 2018
Jul 20 2018
It's not exactly the case that we just used something not intended to be used in this way, because when I was testing the idea of plastic deformation for the first time, I actually assumed it would work even for smaller values of damping in a similar fashion. I actually expected that it would swing back and forth a little and I would have accepted that even. But since we wanted to minimize the swinging motion it was a logical step for me to set the damping to the maximum, which worked as expected.
- I can confirm that the instability is happening also with the old springs as soon as the damping value is close to but smaller than 1.
- Also I found out that explosions are only happening for angular springs, linear springs seem to be stable even with spring2. (Maybe a general angular spring bug/limitation?)
- After some further tests suggested by Alexander, I agree that the new springs are actually showing better damping behavior for linear springs.
Jul 12 2018
Jun 24 2018
Nov 12 2017
In fact, it requires to use particles with physics that will restitute the idea of a dense flow. So, particles with forces between them.
Nov 11 2017
Thanks. Particles unfortunately won't follow the air flow, so the desired effect that the smoke flows around the sphere to its backside will still be difficult to accomplish. Instead the space above the sphere will be polluted with more smoke.
Nov 10 2017
Oct 29 2017
It's also visible from a distance (20,000 units height).
Oct 28 2017
Sep 5 2017
The issue seems to be solved by this patch. Thanks for taking care of it.
Sep 4 2017
Hey @Luca Rood (LucaRood), if there is no further fix to be expected, can you revert the changes leading to this serious issue now for the release please?
Aug 18 2017
Aug 13 2017
May 25 2017
Apr 11 2017
Looks like only the vertex group data got corrupted, when removing the Mask vertex group validate() doesn't complain anymore but the issue persists. Not sure why the adaptive displacement feature wouldn't work with "doubles" in the first place, isn't this a very common thing in 3d modelling? Edge split something and you have doubles everywhere, not sure if this issue is actually resolved by now. But thank you for looking into it anyhow.
Apr 5 2017
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:
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?