Scratch
-
Posts
183 -
Joined
-
Last visited
-
Days Won
2
Scratch's Achievements
Newbie (1/14)
32
Reputation
-
Hey all, I have some guide hairs in vellum and my orient (point-)attribute which is generated using the guide deform sop is "flipping" (sign changes on orient vector components). This causes the guides to freak out during simulation, showing randomly changing length, jittering and weird behaviour etc. Knowing that vellum needs a stable orient attribute to produce stable sim results, I tried to delete that orient attribute coming from the guide deform sop and instead let it be calculated on the vellum constraint node using "compute missing orientation". The values are somewhat the same and somewhat also different, but I also see some "flipping" orientation values from frame to frame on some guides. If I disable the orient attribute on the guide deform sop (create orient attribute off) and on the vellum constraints sop (compute missing orientation off), I assumed no orient is calculated for my guides, but to my surprise, I still have an orient attribute present after the vellum constraints sop. The even bigger surprise was, that this orient attribute produced a totally stable sim. This left me rather confused, and I hope you guys can maybe shed some light on whats going on here. Why is my orient attribute flipping, how can this be prevented, and what (where) is the best way to calculate a stable orient attribute? I unfortunately can't provide a hip-file showing the issue cause my current project is under NDA, but I still hope you guys can make some sense of what I say. I am using Houdini 18.5.392. Thanks in advance and all the best, Scratch
-
@matEvil: Thanks man! I will have a look at this! @tamagochy: Also thanks to you! I tried that but it unfortunately leads to a lot of volume loss. But reducing it further from my initial settings did help a bit I have a version now that I'm quite ok with, but I will continue testing on the side. Thanks to all of you!
-
Hey Matteo, Atm, I only use the attractionweight point-attribute that is driven by a noise to control clumping with the built in attraction settings of the vellum solver (advanced tab). Constraint-whise, I only have a vellum configure grains in my network.
-
Hey Luca Thanks for your hints! Can't post the Hip-File unfortunaety since it's project based, and wasn't able to recreate it at home yet. But I got a somehow stable result now by lowering the constraint iterations to 1000, and lowering attraction to around 25. Repulsion is also critical as it seems and the default value of 10000 looks to be too high for some cases. Those settings will cause the clumps to break up on impact, but on second thought, when you drop wet sand from 1m onto a collider in the real world, it will inevitable break up on impact so it should be ok for now.
-
Hi guys, I'm currently trying to setup a test of vellum grains with loose sand and clumps falling from 1m down on a pighead-collider (grain size of around 0.001). I did lots of tests already but can't manage to get a stable result where the clumps (more or less) keep together on impact. They stick together mid air, but as soon as they hit, explode and spread in numerous pieces. Scene and sim is according to realworld scale. Settings I use are all default but: Common-Tab: Substeps 12 Constr. Iterations 2000 (That high since I was told it needs to be roughly the amount of grains you want to pile up, and having grains around 0.001 in size makes pretty huge stacks.) Static Friction 0.75 Dyn. Friction 0.15 Advanced Tab: Repulsion: 1500 Attraction weight 1 (weighted/multiplied with a point attribute (0 to 1 values) that defines loose sand and clumps based on a noise pattern.) Attraction 100 It would be very cool if someone help me figure out why this is not working. Any hint or even a example-scene is much appreciated. Thanks in advance for your time!
-
Right, will definitely try it for the next project! Thanks, and thanks again to all that helped me along the way!!
-
Changed the Settings to cm so 1 unit is 0.01m, solver spatial scale results in 0.01 / gravity is -981, density 0.001, Dopnet-timescale 0.1 (for slowmotion look) and around 8 substeps on the wiresolver. Should have the same effect than scaling the Geo down by a factor of 100 (m->cm) without touching gravity, density and spatial scale. Siming it in realtime (timescale=1) also worked, but needed a pretty high substep amount of around 50 on the wiresolver to get good results. But that seems to be right aswell, since timescale of 0.1 is like having 10 substeps, and I am substepping this some further 8 times on the wiresolver (10x8=80 in total). So having 50 steps for realtime seems to be ok. Thats how it made sense to me, and I am really happy with the results so far
-
Done!
- 28 replies
-
- 2
-
-
- wire solver
- dops
- (and 4 more)
-
Update: The only way I could get the simulation (branch falling fom 5cm down to ground) to work under real world scale conditions (1unit = 1cm) was as described above, by increasing the scene frame rate (to e.g. 250) and "filming the falling branch in slow motion" like you would when shooting this in slow-motion for real. This has the advantage that the movement - which takes place in less than a second - can be simulated accurately without the need for heavy substepping. I can not cache it with Houdini's Apprentice, but if I'd be able to, I'd cache the sim-results out in slow-motion (bgeo files), and then retime the geo-cache to whatever speed I like it to be for the final. I am not sure if this is the right way to do it, but it seems to be a way that works. (The file I worked with today is attached.) Playblasts and breakdowns will hopefully follow during the week One question regarding substepping emerged during the tests today: When do I need to increase substeps on the entire DOP-Net, and when is it enough to just increase it on the particular solver? Cheers! firBranch_wireSim_v003.hipnc
- 28 replies
-
- 1
-
-
- wire solver
- dops
- (and 4 more)
-
First test for the wire-setup is here. The sim works, the highres is based on the sim-curves, so it moves along without any problems. What I have difficulties with at the moment is sim-scale. The branch itself is 10units long. When I sim with standard settings (1unit=1m), the sim works out fine, but looks slow motion, because the branch,is actually 10m in size. When I set my scale more towards realworld scale (1 unit = 0.01m = 1cm), the sim goes crazy. I have to do enormous substepping, to compensate, resulting in very long sim times. And the wire-settings (parameters) need to be tweaked all over again. (sim-settings are corrected for the scale -> gravity at 981, solver spatial scale at 0.01). It only works with standard substepping values when I "film it in slow-motion", meaning to crank up the scene-frame rate to about 250fps like you would when filming this for real with a camera. After that, you could save a cache and retime that cache to realworld speed. But I am not sure if this is how you do it. What would you guys say is the best way to approach this? I attached my latest file for you to play with. (1unit = 1m version). Cheers! firBranch_wireSim_v002.hipnc
-
I tried the latice + deltaMush approach and it works! It is still not perfect, but like petz says, this seems the best method if you have wires that do not match your highres mesh 100%. I don't think this is the way to go when you can decide from scratch how the setup will be, but it is a good way if you are somehow locked in on which model and wires you have to use. Thanks alot for this petz! I will now try to adapt my setup to use the simulated wires as base of the actual highres model. This method has none of the problems from above, and I think, this is the best way to do it for my case. Further updates will follow Thanks guys! firBranchWireSim_latticeDeltaMushDeform_v001.hipnc
-
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!
-
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
-
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!
-
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
