@Sebastian Parborg (zeddb)
it seems this is still not solved. And not documented.
I tried to use attractor (goal) with force field and it changes nothing.
@Sebastian Parborg (zeddb)
Thu, Jul 18
Doesn't seem to be a regression to me: copying the content of the file to 2.79 makes it possible to reproduce the issue there as well.
all is good if there is no particle instance modifier on wheat_1
Can confirm a crash here, checking...
Wed, Jul 17
Tue, Jul 16
Mon, Jul 15
Is not similar: dependency graph can not detect entities being added/removed and perform actions on this. Such issue is something what is easier and more localized to do as a part of force field removal.
Sun, Jul 14
Thanks for replying, using a small ammount of noise in the force field WITHOUT hairy dinamycs enabled help to create a lite animation for a large ammount of hair particles without need for long bakes and physics configurazion for the hair particles effect, things that (for me at least) usually takes a lot less time without quality loss in much scenes, configuring physics and baking everything takes much more time for pretty much the same result on not important things, the force field noise animation without hair dynamics enabled is a feature that i personally use a lot, and i wouldd really like to use it in 2.8, so i created this post... (For the people that says it is just a glitch animation, it is not, in the example file in this post i just made a random situation to se the animation bug, with a bit of configuration the result is really enjoyable for a lot of situations)
This seems to work with Hair Dynamics turned on (in 2.8) whereas it was "working" without that in 2.79 [but that is more or less pure jitter].
Update for the latest master with additional comments and improvements about random number generator states.
Fri, Jul 12
Just tested the release candidate and the bug is still here. Strangely it did appear to work once, with strange results, but after that it went back to only taking into account frame one of the rigid body simulation.
actually, what @YAFU (YAFU) said says it all... [that was rather stupid by me, excuses...]
Hello! Thank you for answer and sorry for the inconvenience. All the best!
Working for me in F12 render (cycles, not eevee), but not rendered viewport (neither cycles, nor eevee)....
Thought this has been reported before, but cannot find it...
Wed, Jul 10
The issue here is that dynamic paint does not work if after an enabled subsurf modifier. Putting it before and everything is working.
Tue, Jul 9
Remove hard limit and comments on that, increase soft limit.
Remove both the hard limit and the comments on said limit.
But i am not sure what is this exactly about:/* Hard limit is 16M to avoid reaching the object limit in Blender. */
@Brecht Van Lommel (brecht), unless i'm missing something, we can totally remove hard limit here.
I'm fine increasing limits.
Sun, Jul 7
Wed, Jul 3
Possible related to T59272: Dead particles not included in render (F12), but visible in viewport?
Looks particles are displayed (and are participating in the sim) that should have been 'killed' by the density setting... confirming for now and checking...
Mon, Jul 1
Sat, Jun 22
Jun 6 2019
Jun 1 2019
I also run into this issue today. Tried everything within my knowledge but it wont work. SIngle bake does work , but thats not useful with multiple items. How did they do the open movie projects without this?!?!?
May 29 2019
This is indeed a known limitation, we should improve the UI here once but for now it is require to have the same level for both.
May 21 2019
That should work fine, yes.
Still not sure if I understand correctly:
Have a decent play with the removing and adding, cause it produces different results all the time.
Problem is Removing the Ridgid Body World in the first place [which in turn removes the ridgid bodies from the objects].
If you want to keep the ridgid body settings (but for some reason wont those object not to participate in the simulation), why not move the objects to a different collection [not the RidgidBodyWorld one]?
The big issue here though is that it sets EVERYTHING to default Dynamic/Active and resets mass. Even if it already had a rigidbody. So you lose everything you set up already.
May 20 2019
I'm not sure if this belongs to https://developer.blender.org/T64879 or here,
As stated in T64877, this is true for all (EDIT: not all, some) Physics types and these are not just disabled, but removed.
Indeed, seems weird.
Think this bug is back - bb88485a1693751baff8a61917987323dbee654a distorts smoke with the adaptive domain.
May 18 2019
This continues to happen in the new blender 2.80 3b8ae2c08f5c
When you create a cube and fill it with particles in volume mode and with grid distribution, a diagonal row is missing, if you invert the grid only this row appears.
May 14 2019
It is working in 2.8 build of 2019-05-13
May 5 2019
@Bastien Montagne (mont29) thanks for the detailed comments! We'll have to more carefully look at the points you mentioned. Good idea to make the naming scheme consistent, to properly indicate the parts of the new solver. I'd suggest using "manta" there to distinguish it from the old smoke and liquid version.
May 4 2019
Note: just updated the branch against latest master (was kinda painful, thanks to some 'cleanup' in BKE physics files :( ), would be nice if patches could be updated too.
Some initial usability review after using the branch for a few tests, and a first quick review of the patches:
May 2 2019
@Nils Thuerey (n_t) Hmm, looks like the branch could use a merge with master again. ;)
May 1 2019
Yes, it’s still on my radar for this week or next one…
The plan is still for @Bastien Montagne (mont29) to do the initial code review. @Bastien Montagne (mont29), will you have time to do this in the next few weeks? Spending like one day to go over the code and testing the functionality.
Apr 26 2019
I have another question here for the experienced blender devs (@Brecht Van Lommel (brecht) @Sam Van Hulle (sam_vh) @Martin Felke (scorpion81) @Jacques Lucke (JacquesLucke) and maybe others?): what would be the best next steps for an official 'approval' of the mantaflow diffs? I saw the 2.8 timeline, and I guess it would be ideal to verify that the patch is in a good enough state some time soon. Then it could be merged into the main branch as soon as possible after 2.8 is released in July, such that it can be included for the 2.81 release.
Apr 25 2019
Apr 23 2019
@Brecht Van Lommel (brecht) Okay, yes - the GIL seems to be unproblematic so far. It could make the UI somewhat unresponsive when baking large sims, though. The new node system notes look interesting. I think for mantaflow it would neat to go for the "everything-nodes" direction, where a node graph would define the data flow of the simulation. This could then use a python back-end, or directly hook into the mantaflow functions (the functions that are exposes to python are the crucial ones that ideally would also be available as nodes). It's definitely a good point to keep in mind.
Apr 18 2019
Ok. The main concern is not so much that it's slow for fluid simulation by itself, but if multiple performance sensitive areas use Python it does become a problem to have these global locks. If this is how the Mantaflow API works and it's a big burden to use C++ instead it seems acceptable.
@Brecht Van Lommel (brecht) Good question, to add to sebbas comments, there are a few reasons for the python bindings: a first mundane one is that that's how the mantaflow solver worked originally, and it would have been a lot more work to switch to C/C++ bindings. Also, the performance impact is negligible, as mantaflow provides all the solver building blocks via python, but each of the steps is quite expensive. So there are no low-level operations in python (e.g. access to grid cells), but just a small number of calls to high level functions that typically make several passes over the full grid.
There's a pull request from David Ullmann extending the NOPYTHON option.
@Brecht Van Lommel (brecht) Right now the only way to access all Mantaflow functions is through Python. In terms of performance I wouldn't say that this is an issue. Once the Manta solver acquires the GIL it will compute one "step" and only once completed release it. The time between steps where other resources (like the UI) can acquire the GIL and Manta has to wait for it would be the only delay during a bake job. This delay is negligible from my experience unless there are other resources that could block the GIL for a very long time.
@Nils Thuerey (n_t) Yes, you're right. Those lines won't be needed in the future anymore. Will remove them.
Apr 17 2019
Can someone remind me why this is integrated through Python rather than C++, and how much work it would to change it to C++?
@Sebastián Barschkis (sebbas) - I noticed the exported python scene has a few lines at the top for OS/multi-processing checks that don't seem to be used or necessary. (from "withMP ... up to VARIABLES", ca. lines 8 to 18). Those could be removed, right?
Apr 16 2019
@Ulysse Martin (youle), thanks for the video. What I tested is that when I'm at e.g. frame 50 and press Delete Bake then, I would expect it to remove all results from the physics sim, and you'd have to go back to frame 1 and play to simulate again. That doesn't happen here. If you're at frame 1 this patch works fine indeed.
I join a .gif video to show before and after applying the patch on my computer:
This patch doesn't seem to do anything for me.
Apr 15 2019
I can confirm an issue with delete bake action.
Apr 14 2019
Apr 8 2019
Hi everyone, great to see the manta integration being re-revived! @Sebastián Barschkis (sebbas) thanks for the large patch collection. I just checked out and tried the revised diff "from scratch". Works nicely on my MAC. The sims also run through without problem (I tested based on the quick-smoke and quick-liquid setups). So I think this patch looks good, overall. There are some obvious next steps, like removing the old liquid/smoke modifiers, and cleaning up the code, but I think this would be better to address once the manta code is integrated.
Apr 7 2019
@Bastien Montagne (mont29) Yes, that's definitely a good idea. I just updated the diffs (now it's branched from the 2.8 "master") and also synced it with the fluid-mantaflow branch which can be used for test builds. From here we could now get the review rolling.
Apr 4 2019
Would need to have a closer look, but could be caused by the change in the evaluation order of rigid body, similar to T63028.
Apr 3 2019
I'm getting this error printed in the terminal (probably related to this issue):
ERROR (bke.rigidbody): /home/zed/prog/blender/source/blender/blenkernel/intern/rigidbody.c:299 rigidbody_get_shape_convexhull_from_mesh: no vertices to define Convex Hull collision shape with