Jump to content

Scratch

Members
  • Content count

    178
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    2

Scratch last won the day on April 5 2015

Scratch had the most liked content!

Community Reputation

29 Excellent

1 Follower

About Scratch

  • Rank
    Initiate

Contact Methods

  • Website URL
    http://www.scratch-arts.net

Personal Information

  • Name
    Philipp
  • Location
    Austria

Recent Profile Visitors

4,626 profile views
  1. Right, will definitely try it for the next project! Thanks, and thanks again to all that helped me along the way!!
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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!
  7. 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
  8. 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!
  9. 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
  10. 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!
  11. 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
  12. 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
  13. 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!
  14. 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!
×