Great ! Can’t wait to build a test version, please let me know once you have it !! I have tried c4484057, it gives me some error when i try to build it in Visual studio.
Could you p.m. the error?
Yes Sure. All i did was downloading the latest commits c4484057 and buit it in windows.
Ah, I think its a c++ version error. I like to use initializer lists for array and vector inits. I’ll have to look into that later.
Ok, Great ! Thank you very much indeed.
Blender’s source code (the internal code anyways) recently moved to C++ 2017. 22 June 2020
It might be a good idea to read through the task: https://developer.blender.org/T76783
Is that mean if i use VS 2017 to build, the error will be fixed?
Visual Studio version is not the same as C++ version, but newer VS probably defaults to newer C++. I think it’s configurable per-project… but I don’t use Windows much.
Okay, that’s good to know that Blender has moved to C++17. Mengzhe, are you able to compile with the C++17? There should be a dropdown menu that allows you to set that.
It works, i have successfully built it. Many thanks
Thanks for the work @mattoverby
Question: Will be possible to have the “plastic” option from the original blender softbody in this new implementation? The feature that keeps the deformation along the simulation?
Hey @EvertonSchneider . I’ve seen that your main OS is Ubuntu and since you already have a build working, I want to ask you how you built this branch. I’m on Linux Mint and I’ve downloaded the branch and built it like a normal version of Blender, but I’m not quite sure if I’m getting the new solver made by Matt. The soft body interface looks the same as the existing one. Do I have to make some configuration first before building Blender?
I’m using the blender wiki default instructions to build blender on Ubuntu.
It’s ok, it seems that you are on right way. The UI is the same as the old for me too… but under the hood it’s the new implementation. Just test and start using and you see the differences, try the suzzane falling into a collision plane and you will see.
I do not plan on handling plasticity defo. Once the interface is more reliable there may be an easy way to fake it in the future by resetting the rest shape between frames. That’s not really plasticity, but it may be sufficient.
I have not changed the interface at all. At the moment the interface variables are ignored. I plan to add some UI support very soon.
I appreciate people testing out the code. I’m happy there are a lot of people are excited to try it out. I’ve only recently started tagging “stable” versions, but I may accidently commit unfinished code here and there. This is very much a rapid-development branch, so please bear with me if there are instabilities or bugs.
I’m trying to play more with the SOC-2020-SOFT-BODY and I see some strange behavior related to mass and friction (I know that it will be tweakable later…) Not sure if I can “report” here what I’m finding. I’m doing just some random tests by now…
The first “T” and the “E” are ok for me… but the “S” and the last “T” are a bit weird
Thanks for posting a video, you’re 100% correct that there are issues with both mass and friction.
- Right now, there is no friction, so that’s why things are sliding around.
- When it comes to mass, this is an issue with the mass being distributed to the lattice. I’ve mentioned it a few times in my weekly updates, but at the moment the mass of the embedded object is not accurately transferred to the lattice, and that’s what we’re seeing here. It’s probably why the S flips over and hangs as if there is something heavy attached to the top of it. This will be improved in the future by both a) a better lattice generation and b) better mass computation.
One thing to double check, are goal positions turned off? I think they are on by default (which pins EVERY vertex in the sim), but depending on the stiffness of the goal position springs they might not be obvious. This would also cause very goofy looking motion.
Thanks for the clarification, I will assume that in my tests.
I’m sorry for that… I will re-read your reports, I already did it but I forget about it…
I always disable the “goal” option, it’s off in this test.
Thanks for the clarification! This make sense for me now, I will keep testing and see what I can do with it in this stage. It’s already very fun to play with.
Nah it’s my fault for not being clear about it . I’ve mentioned it in text but I don’t show what the problem looks like, so it’s hard for others to tell whether its a known bug or an unknown one.
I appreciate you testing things out and especially posting videos here. That’s super helpful for myself (and probably others) so I can see the behavior I need to correct and prioritize.
After this commit the simulation appears to be slow motion and some glitches…
BUT the result of the softbody over the mesh is way better! I can see much more “jiggle” over the mesh, it’s becoming better and better.
In this example the subdivision is applied and with 3 levels we have the glitch.
Yeah, I’m still working out some bugs. I can’t promise that every commit will be stable. The slow-mo is just me reducing the time step, which is currently decoupled from the Blender frame-rate.
Edit: I just pushed another tag that doesn’t have this issue in case you wanted it: softbody-stable-v3. At the moment I’m experimenting with different constraint update strategies to see what might work the best.