Jump to content

Scratch

Members
  • Content count

    183
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Scratch

  1. 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
  2. Exploding vellum grains

    @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!
  3. Exploding vellum grains

    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!
  4. Exploding vellum grains

    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.
  5. Exploding vellum grains

    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.
  6. 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
  7. Right, will definitely try it for the next project! Thanks, and thanks again to all that helped me along the way!!
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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!
  13. 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
  14. 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!
  15. 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
  16. 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!
  17. 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
  18. 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! Could you elaborate that a bit more? It sounds interesting, but I am afraid I dont quite get what you are explaining here. Thanks
  19. 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!
  20. 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!
  21. 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!
  22. 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
  23. Hey Folks! I currently need to mesh a particle fluid sims using VDB (sim particles come from both, houdini and RealFlow as alembic with point attributes on them) but I ran into serveral issues. My current workflow is as follows: fluid sim particles -> vdb from particle fluid -> vdb reshape (dialate, erode) if needed -> smooth vdb sdf -> attribute transfere v from particles to mesh -> convert vdb (to polygons) -> rop alembic output So far so good. Technically, it works, but I constantly run into the problem that I either get a detailed mesh (with less or no smoothing), or a smooth mesh with far less details (they - especially fine droplets - all get smoothed away). Second option to get a smoother fluid body is to use a high influence scale witihn the vdb from particle fluid node, but that also connects droplets together which shouldnt interact (leaving me with spaghetti-like strings instead of fine independent droplets). I attached 2 Images to illustrate both cases. I read on the net (http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=31865 -> jeff's first post) and in the manual that you can mask your vdb smooth sdf node by annother vdb fog volume. It furthermore brought "mask VDB" volumes in the vdb from particles node to my attention, which somehow sounds suitable for what i'd like to do - but i dont know how to generate or use it at the moment. Extract from the Houdini Manual, vdb from particles node: "VDB Mask -> Create a mask field VDB. Generate an alpha mask that is very useful for subsequent constrained level set smoothing of the level set surface from the particles. This alpha mask is defined as the FOG volume derived from the CSG difference between a level set surface with a maximum radius of the particles and a level set surface with a minimum radius of the particles. This mask will guarentee that subsequent level set smoothing is constrained between the min/max surfaces thus avoiding the problem that surface details can be completely smoothed away." Now my questions are: Is it somehow possible to get a smooth fluid body AND preserve the fine detail / droplets? Can someone explain to me what mask volumes are and how they work? (i read the manual, somehow figured they might be connected to my problem, but it does not make to much sense yet) How do I use and generate mask volumes propperly to use it in conjunction with the vdb smooth sdf node? Can you guys maybe show me some workflow examples? Furhtermore, is it somehow possible to create velocity streaks? Or take the velocity into account? Thanks in advance for your help and time!
  24. Q-Solver Plugin for Realflow

    Hey Folks, I recently heard about Yannik F.'s Q-Solver Plugin for Realflow (275$) which looks really promising for small-scale liquid-simulations (good surface tension, sheeting, etc.) In my opinion even better than some custom fusionCIS stuff). What do you guy's think about it? (There's a lot more RnD stuff on Yannik F's Vimeo-channel) Annother Example: Release-Notes: https://www.youtube.com/watch?v=5Ud8qBa35r8 I'm (still) wondering if something like this is possible in Houdini. I know that Alejandro Echeverry is working on some similar stuff (http://forums.odforce.net/topic/18111-flip-smorganicsheeter-effect/) , but his tool is to my knowledge not yet finished and available for public use. Is there something similar in H? I did some small-scale stuff a few weeks ago, it turned out ok, but the results couldn't get close to the q-solver stuff - even with a surface tension microsolver attatched to my flip-solver. Some the discussion regarding my project and the topic can be found here: http://forums.odforce.net/topic/22272-how-to-emit-additional-small-droplets-from-a-water-drop-crown-splash/. I'm courious what you think!
×