Wire-Solver: Falling fir-branch - Attache wires to another wire-object

[Scratch]

Hey there, 

I am currently trying to simulate a (single) falling fir-branch like the ones you can see in this image:

I would like to use a wire solver for that, but I am having a hard time to make the needles stick to the branch. How would you go about that?

Desired setup:

* branch as wire obejct (soft body behavior when colliding)

* needles as wire object attached to the branch (soft body behaviour as well)

* gravity in place, falling fir-branch, colliding with a ground plane.

I tried the "Attach wires to surface" shelftool, but that attaches the selected wire points only to existing points on the branch-geo (which is low res, with just a few points). I would like the needles to be independent of the branch geo so that I can have a rather lowres branch geo (tube, less subdivs), and lots of needles. I would like to attach them like it is possible with folicles in maya, having them stick wherever they are on the surface, not having them stick to one of the input points on the fir branche geo. Using the point attribute "pintoanimation" or "gluetoanimation" also does not work. Doing so, the needles jitter around as soon as they are not in line with a points of the underlying branch geo. 

Do you guys know any solution for that?

Thanks in advance for your time and help!

Cheers,

Philipp

 

 

 

[Scratch]

After spending some more hours on this I figured it might be better to use FEM for this.

Advantages:

• Volume-preserving
• even more realistic
• no need for a complex setup. Create tetrahedrons and go.

I will keep you posted on the progress

[Scratch]

I found that thetrahedralising the very thin needles is not really easy. I ended up converting the geo into vdb, dialating it to make the needles thicker, and then converting it to tets. But still, since it is a complex shape, it only seems to work when you have a high number of polys, resulting in a highnumber of  tets, which means very long sim-times. I haven't managed to get a lower res tet mesh out of it, so if anyone has an idea, please drop me a line . I have around 100k tets now for my branch, but the sim-results look promising! I am now working on finding the right values for the behaviour, but I have to say that this embedded workflow (tet mesh driving a highres mesh) works really nice! I hope I can return with further updates soon! Cheers!

[Farmfield]

Haha, reading your first post I was just gonna suggest FEM for this - though I would not use that level resolution at all, I would basically sim the whole branch as hull.

[Scratch]

I would love to not use that level of resolution. I know that tis is insane. What I did is convert the whole branch to a VDB, dialated it a bit so that the needles are not that thin, convert that to polys, remeshed it to get a evenly subdivided (tri)mesh, polyreduced it (keeping 15% of the polys) and then fed it into the thetrahedralize. The problem I ran into iist that it seems to need a certain (and to me way to high) number of input detail/polys to not error out (marking the entire geo als "Invalid Prims"). If you have any suggestion how to overcome that, making it work with less tets, please let me know, I would be very interested in that. The solid embed node is also erroring out. Once I had a (way to highres but working tet mesh), I simed that, and embedded the highres geo of the branch. 

You can see the branch-geo I am simulating in my reel: http://www.scratch-arts.net/demoreel.php (around 0:50). 

Thanks in advance! 

Edited August 23, 2016 by Scratch

[Scratch]

Update: I found a workflow that tends to work:

• convert your mesh (can be multiple parts, not connected) to vdb (SDF)
• dialate it slightly using reshape SDF , so that it is a bit bigger/thicker than your input mesh (that tends to help since the tetrahedralize sop has trouble tetrahedralizing thin geo)
• smooth the vdb a bit (round geo tends to work better aswell)
• convert it back to polys -> you get a fully connected mesh / single piece
• use a polyreduce sop to reduce the polygons to a reasonable level and increase the equalize edges parameter until you get a somehow uniform edge-length / distribution of polygons for your reduced topology
• afterwards, the tetrahedralize sop should fail less likely. 
• now use the "limit steiner points" which controls how many tets will be created inside of the model - to further control the number of tets created in total. 

For me, that worked way better then the solidembed sop which uses a somehow similar approach, but relies on the remesh node rather than using the polyreduce. My method got me from around 100k to 20k for max reduction of tets, while the solid embed node failed to produce any results (maybe I missed something here). I will do tests to see if I need to increase the tets for my sim, I have a feeling that I might not have enough tets inside the model now (which would mean, I need to incr. the steiner points again). 

Stay tuned! 

 

Edited August 23, 2016 by Scratch

[TheDude]

Even though you're kinda deep on this setup, I really feel like wires would be the way on this specific situation for speed and quick iterations. Based on your vid it looks like you already have lines to set up the geo for the fern branches. From there all you have to do is use the same functions you are using to make the geo, to set up the attributes for the wiresolver (kangular, stiffness, width), and from there just slap it straight into the wiresolver. Will take a bit of trial and error setting up the attributes but will be tons faster so you can iterate quicker to get the desired result. From there just deform the geo based on the parent wire (quaternion rotation + position). Hopefully also be less headache setting all that up than the process you did to get it into fem

[Scratch]

Hey Dude

I am happy to go other ways if they proof to be better, faster, easier, so thanks for pointing that out! It is just a personal project, so no rush, no deadline, just a fun playground

I thought about wires too in the begining, but since the branch and the needles are separate objects, I couldn't figure out a way to make the needles stick to the branch when simulating (techniques I already tried and problems I encountered are described in my very first post). Furthermore, the needles are so thin, that I think it would be hard to preserve their volume. What's your take on that? I would totally give it another shot!

2 hours ago, TheDude said:

 From there just deform the geo based on the parent wire (quaternion rotation + position). Hopefully also be less headache setting all that up than the process you did to get it into fem

Could you elaborate that a bit more? It sounds interesting, but I am afraid I dont quite get what you are explaining here. Thanks

Edited August 23, 2016 by Scratch

[TheDude]

Ah good to hear there's no pressure on deadline! I think the first step would be making sure that the original 'rest' wire position, and then he original 'rest' geometry are all combined into a single system, then as long as you can transform that wire object in x y and z, and you can get your full geometry to correlate, you are in a good place. If they are separate objects, this would include object merging everything together and making sure you can move it all as one. I might be misunderstanding something here though, not 100% on your setup for the branches.

If this part works, then you can do the next step by simulating the wire object as if it is the plant itself.

Once you pull this back out of dops, you now have your wire object that is static, the wire object that is simulated and moving, and then your full geometry which is static. Lock off quaternion orientation on the wire and you will have enough data. You will reference the position of the geo and the static wire, and then as the animated wire moves, move your full geo with it based on the original position comparison. on top of that, rotate that position by the quaternion on the animated wire as it deviates from its original orientation.

So some practical code for this

 

//Setting up our variables for the position and orientation of our current geo, static wire, and animated wire

int StaticWireParent = pcopen(1, "P", @P, 100, 1);
int AnimatedWireParent = pcopen(2, "P", @P, 100, 1);
vector StaticPos = pcfilter(StaticWireParent, "P");
vector AnimatedPos = pcilter(AnimatedWireParent, "P"); 
vector4 StaticOrient = pcfilter(StaticWireParent, "orient");
vector4 AnimatedOrient = pcfilter(AnimatedWireParent, "orient");

//Doing Stuff with our data

vector DifferenceP = @P - StaticPos; //difference in position from full geo to its "parent" wire point
vector4 DifferenceOrient = qmultiply(AnimatedOrient, qinvert(StaticOrient));
@P = AnimatedPos + qrotate(DifferenceOrient, DifferenceP); 

// So our position is the wire sim position, plus the difference of our geo:static wire, accounting for the orientation change

Hope this helps, learned this trick from my old lead, super, super handy for these situations

Edited August 24, 2016 by TheDude

[Scratch]

Thanks so much for the detailed explaination! Nifty trick! Sounds a bit like what the point-deform sop does? (Deforming a input geo based on a pointcloud)

I attached a basic wire-sim with standin geo that shows the problem I have when using wires. The geo lives in one single geo node, so everything is together, moving together, but the topology is not connected. The branch and the needles are distinct objects with no (topological) connection to eachother. If you would run a connectivity you would end up getting the branch as piece, and each needle as distinct piece. Thus, if you simulate it as a wire object, the needles do not stick to the branch. There are ways to constrain them using constraints, but that (as far as I got it until now) always means constraining the needles to a distinct existing point of the branch beo. (constrain to surface shelf tool e.g. constrains the needles to the nearest surfacepoint it can find on the branch - which is not what we want, we want a behaviour similar to a folicle in maya (which is uv-based, i know)). Furthermore, using the point attribute "pintoanimation" does also not work. In the end, I found it more simple to just throw it into a FEM sim, getting around the needles do not stick to branch problem, and avoiding the anim and rest setup you desrcribed above altogether. I ended up with a simpler file to handle, and yes...also longer sim times. That was a drawback I was willing to accept looking at the trouble the wire-setup gave me but if you know a workaround to make the wire sim work (maybe use the given file to demonstrate?) - then let's try it!

Also attached, a first image sequence of the FEM-Sim I am doing in the meantime which is showing the Tet-mesh. I am currently working on getting a playblast of the embedded highres geo aswell (which is deformed by the tet-mesh), but since apprentice does not allow me to store the sim result, I am forced to do the sim over and over again for each and every playblast. I am considering to get Indie...the apprentice limitations are seriously in the way, hindering me from iterating and working efficiantly. And 200 a year is not really a sum you can complain about for such a tool. 

I will keep you guys informed!

Cheers and thanks again!

 

firBranch.hipnc

FirBranch_FemSim_v002.zip

Edited August 24, 2016 by Scratch

[petz]

did just a quick test but using wires seem to work fine ...

petz

 

 

firBranch1.hipnc

[Scratch]

Awesome! Your setup makes a lot of sense! Thanks for sharing, I approached the wire-setup totally wrong in that case

I think this as a base, and using it in conjunction with a point deform (quick test showed it seems not to work too good) or using the setup like TheDude describes to deform a highres mesh could indeed work. If not, one could do it like you did, going for a more procedural model based on the underlying wires.

Its great to have 2 different ways of doing stuff, FEM and wire-solver-approach! I will do some more tests playing with this in the next days if I get the chance!

Thanks alot!

 

Edited August 25, 2016 by Scratch

[TheDude]

Whow, didn't even know about the point deform sop! 

[Scratch]

Glad that I am able to give something back!

I did a sim over night (about 4,5h for 100 frames on a macbook pro 2011, 2,4GHz i7 quadcore, 90k Tets), which turned out quite nice. I think FEM is a good solution if you have a predefined (single) model, that you need to sim, but when you have the freedom to do it from scratch, petz's approach is for sure the better one! The wire-solver runs near realtime because the underlying sim-geo is so simple. Even if you crank up the points, it stays quite fast!

Using the wires to deform a highres mesh (somehow similar to the embedded workflow of FEM) seems to be a different story...I tried the point deformer, taking the simed wires to deform my highres mesh (attached image), but that produced strange flickering when it falls. It gets better as soon as it collides on the floor, but overall, it seems not to work very well. I might miss something here though. Maybe the code-approach of the dude does not suffer from that issue, haven't tried it yet.

Lookign at everything, the best method in my eyes is the wire-solver, taking the simed-curves as input/base to procedurally model the highres mesh as petz shows it in his example file. It is fast, you can even simulate a lot of falling fir branches (maybe falling on top of each other) without hitting the performance limit. That is what i want to try next, I hope I can manage to do a sim on the weekend.

Again thanks guys for sharing your wisdom! Much appreciated, I am learning a lot here. Stay tuned!

FirBranch_FemSim_v003.zip

Edited August 26, 2016 by Scratch

[petz]

8 hours ago, Scratch said:

Using the wires to deform a highres mesh (somehow similar to the embedded workflow of FEM) seems to be a different story...I tried the point deformer, taking the simed wires to deform my highres mesh (attached image), but that produced strange flickering when it falls. It gets better as soon as it collides on the floor, but overall, it seems not to work very well. I might miss something here though. Maybe the code-approach of the dude does not suffer from that issue, haven't tried it yet.

the reason why it doesn´t work properly is most likely because the fir needles are to close to each other and the pointDeformSop doesn´t know which point belongs to which wire.  maybe try to use wirecapture instead to see if it does a better job. if it doesn´t work either, you´ll probably have to use a custom solution but this depends on setup and geometry.  can you upload a basic example file?

[Scratch]

Hey petz! What you say sounds very reasonable. I will put together a file as soon as possible for you. The wirecapture is new to me, it will give it a read! Thanks again for all the help!

[Scratch]

Hey guys,

sorry for the long break. Here is a file that illustrates the point deform problem. I just took the initial wire-test-file petz did and connected the sim and the initial (highres) standin-geo to a pointdeform node.

I will also (finally) give the wirecapture a read now! EDIT: I did try it out, the wiggling is gone, but it seems to have - like petz said - problems to sort out geometry with points being very close to each other. (Which makes sense to me, because it for sure uses a somehow similar lookup method as the dude described). Anyway, I attached a file showing what I got. If someone knows a way to improove the result - fire ahead please! Otherwhise, it seems to be best to just use the wire-curves directly as a base for modeling. This works perfectly.

Cheers!

firBranchWireSim_pointDeform_v001.hipnc

firBranchWireSim_wireDeform_v001.hipnc

Edited August 30, 2016 by Scratch

[petz]

it´s best if you try to keep the wire close to the center-axis of the geometry you are going to capture. if this isn´t possible for some reason you could use a lattice in point mode followed by a deltaMushSop. this should work but you´ll probably loose quite a bit of local deformation on your highres mesh...

hth.

petz

[Scratch]

Thanks for sharing petz!

So you use the lattice in point mode to deform the highres-mesh and the deltamush will then smooth out the deformation, interesting approach!

From what I saw and tested until now, your first aproach, which is to use the curves as base of the actual model still seems to be the best appraoch - it saves us from all the trouble we have. Going down that road would mean to adapt my firbranch generator for it, but that shouldn't be a big issue.

I will give it a shot over the weekend if I can and report back to you guys! Thanks so much! Can't stress that enough!

[petz]

On 1.9.2016 at 1:51 AM, Scratch said:

So you use the lattice in point mode to deform the highres-mesh and the deltamush will then smooth out the deformation, interesting approach!

don´t forget to wire the original geometry into the second input of the deltamushSop. this way it´ll keep local shape deformations as close as possible to the original mesh.