Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by Feather

  1. Hard constraints stretching beyond rest length?

    This method seems to be far more controllable. Thanks again Pavel!
  2. I can't figure out why the hard constraints are stretching before the glue constraints break. The hard constraints have a rest length and as far as I'm aware its not being updated. I've set the constraint iterations to 30. 60. and even 100 which does help but they continue to stretch. Upping this iteration number isn't viable in terms of time for the scale simulations I'm looking to use this and so I'm hoping someone can help me. Maybe I just shouldn't be using glue here at all? I've put together a quick and dirty example file of this problem and attached it below. Snap_Constraints_Example.hip
  3. alembic objects into copy to points

    Have you tried using alembic archive?
  4. Hard constraints stretching beyond rest length?

    Thanks Pavel, I've been able to get it to remove prims based on exceeding a certain force limit as you suggested. They do not stretch in this case much at all but It does seem to apply forces evenly across the entire object. Once it reaches the threshold all of the constraints break at the same time. I'm sure I could set variable thresholds for the break to occur where I want it to but without anything impacting the object I would be basically painting certain weak points so I doubt it would produce a very natural result. The object I'm breaking is made of long beam structures that pull and rotate each other as they fall. I want to make sure that as they are getting torqued I can split and splinter those beams naturally under their own weight. Without an impact, determining where torsion would occur would take a bunch of simulations and repainting. Is there a more natural way to find stress points between pieces and weaken them dynamically?
  5. solver not working on animated mesh

    Sorry if I was unclear. Plugging your wrangle into the Object_Merge is not all of what I was suggesting. You you cannot simply switch the input of your wrangle. Important information is coming from each of those nodes. (Object_Merge)Input_1 is the geometry being fed into input 1 of your solver. It updates each frame and pulls in whatever is plugged into input 1 into your solver. Meaning this is your animated geometry. From this object merge you need to take the point position and use that to update the position of the points you're solving the infection on which is Previous_frame.
  6. Hard constraints stretching beyond rest length?

    Thanks for taking a look and no worries on the experience thing this is like.. exactly what the forums are for, I don't know either haha I guess it very well may be an unsolvable thing like unstoppable force vs immovable object. BUT this is a pretty common situation in destruction where you have a base simulation and want to do secondary fractures. For what its worth I've just tried glue constraints with different strengths. For example the would be hard constraints are -1 and the middle is set to some random strength. THESE STRETCH TOO. They don't snap back to their rest length like the hard constraints though.
  7. Hard constraints stretching beyond rest length?

    Continuing this in hopes someone can help me out. I had a suspicion that the hard overwrite of the "Animated Static Object" may no play nicely with the constraints and so I tried using a constant force to see what happens. Turns out even with a constant force of like 10^10 you get ... this. It does seem to respect the hard constraints more but not really all that spectacular a failure. >.<
  8. Hard constraints stretching beyond rest length?

    Still trying to find a viable balance between the glue and hard constraints but they simply don't behave as I'd expect. Sti I would expect that hard constraints are respected explicitly and do not break or stretch. I would also expect that glue constraints not matter how strong, when a piece with a hard constraint is under force would always break. This seems to not be the case, different levels of glue strength and RBD object density result in long and shorter stretch lengths before the glue decideds to snap in a catastrophic failure sort of way. From what I've gathered, A glue strength of 1 per 1000 units of density is the balance point for glue that will stretch the hard constraint only a slight bit but I can't seem to drive this otherwise and it's not very intuitive. Attached is a more simply animation example to really make this obvious.Snap_Constraints_Example_2.hip snap.mp4
  9. solver not working on animated mesh

    First of all, if you can help it, use Alembics. Will save you a lot of headache. Second, you're running your simulation using previous frame as the input to your wrangle. If the previous frame was the first frame of anim... that's what your solvers going to use every frame because its never looking at the new anim. You need to use the object merge Input_1 to update the position of all your points to match the new position of your animated FBX. Previous frame is where you can pull the last frames infection data from and apply it to the points of the new anim frame before solving the next frame.
  10. When you convert multiple primitives to a VDB the VDB is a single primitive, hence you're only getting one name in the process. You need to do this conversion inside a for loop(by name) to ensure the correct name is copied to each piece.
  11. FLIP SIM- Collision and Sticking Problem

    I just ran into this last week actually. Using a volume sample and pointing to a collision volume with a division size below .01 resulted in this box like error. It seems to only happen if the collision volume drops to a division size of less than 0.01 but otherwise is fine. I couldn't seem to get this to show up in the collison display or trouble shoot it. If anyone can help I would appreciate this as well.
  12. Bullet Collision problem

    Hey all, I'm trying to pack primitives for the bullet solver that include baked ODE data for compound collisions proxies. The red nodes are a method that is currently not working but is ideal for setting up constraints. Attached below is a example file with identical inputs to identical simulations with one key difference. In green I am baking ODE data inside of a for loop and packing each object individually the ODE data is maintained and the simulation works. In red I am copying the name data to the ODE baked primitives, and instead pack each piece using the name attribute OUTSIDE The forloop. In this case the ODE data is lost. There are two nulls on the side where I've broken out a single identical piece to show the ODE data difference for each means of processing the pieces.Does anyone know why the pack using name would remove the ODE data from the piece? WhyTho.hip
  13. Flip solver problem

    Is this what you're after? There were a couple things here regarding the collision and the way you had set up the solver. Don't want to explain in detail if I misunderstand the question. Coffee.mp4 Before I attached the Hip file it needs notes, pending your response, don't wanna do a bunch of notes if Im misunderstanding.
  14. Wind from rotating fan

    Theres an additional input atop the solver for a external velocity force. I mean you could try running both simulations simultaneously and having them interact but.. if you're not really looking for anything visible from the van velocity then I Would just cache the directional velocity of the fan sim and use it as a force in the following smoke simulation and rbd sims.
  15. Smoke - flat leading edge

    Without seeing your hip file I can only take a guess. That plateau looks like you've multiplied up the density of what would have otherwise been a very thin or empty voxel. If this is the case you're sending density values greater than 1 into your shader which is often going to make your shading experience a bad one. The image below from left to right is. 1. The original simulation, with a density of 1 and a shader render density of 1. This is the sim's natural look. 2. This has a post multiplication of 10 before and a shader render density of 1. This is what I believe you've done and why you see the plateau. 3. This is the same volume, with a density of 1 and a shader render density of 50. This is the correct way to make a thin simulation render more dense without lifting the empty voxels. Either you need to lift the density emitted in your sim to begin with or make sure that you're working with the shader to change the look of the sim, not the actual density values Edit: This sim has an upward velocity of about 20-30. The leading edge is curved but when rendered incorrectly will look flat because the curve is very subtle. Cranking the density values before it gets to the shader erases the variance responsible for the curve. .
  16. Simulating flip from bottle

    Hey so I'm not sure if this is a Hiplc problem or not, hopefully someone else can chime in on this but I'm not seeing baked geo in the locked file nodes. I know this used to work just fine in 16, you could lock a null or whatever to bake the geo into the hip file but I wonder if this changed for 17.5.+?
  17. I imagine my answer is not ideal but the only instance I've seen that enables lighting output from Maya and Houdini to match is using Arnold. Scene descriptions from Arnold produce exactly the same result as they use the same lights and materials. This means your Houdini scenes only use Arnold lights, Arnold materials etc and similarly your maya scenes only use Arnold lights and materials. Without Arnold you're stuck kind of guessing and trying to match by eye or making up for it in comp later. When this is done properly, lighting setups can be passed back and forth between the two packages so long as the scene scales match.
  18. How to drive smoke and blend shape

    Where, in this hour long video, Is the effect you're trying to recreate?
  19. Voronoi with thickness

    This was just uploaded a few weeks ago. Should be what you're after. https://www.youtube.com/watch?v=en0m5uDD3NQ
  20. Flip Reseed Flicker Problem Thread - Gas Seed Marker

    Okay so using two GSM nodes has a far smoother result as it does not produce the kind of popping and bubbling HOWEVER, it does still present a problem in that the particles it seeds are random. Kind of like staring at a scatter sop with the seed set to $F and hitting play. I need a way to reproduce the function of the GSM node without completely deleting all points within that voxel. I need it to leave the desired density behind. Has anyone played around with custom reseeding tools or density control using sop solvers inside their simulation?
  21. If you're flip simulation flickers from using reseeding particles this threads for you. TLDR: I've found a temp solution but want a better one. Inside the flip solver search for a node called "Gas Seed Markers"(Its renamed to "Reseed Particles") Uncheck the "Build Inside Surfels". This will stop the popping but maintain the effect of deleting the unnecessarily dense overlapping particles. Starting this thread for myself to document my thoughts on this but also for anyone else who needs reseeding to keep their simulation in check. So far I have a temporary solution to my issue but I want a better one. My hope is that we can discuss a better means of achieving the desired result of consistent fluid particle density without flicker or popping. The masterclass doesn't explain reseeding and I couldn't find much on the topic in forums or elsewhere for how it works. The node responsible is Gas Seed Markers(GSM form now on). It checks the number of particles per voxel within the surface field for inside the fluid and outside within a given number of boundary voxels and does three things. A. When particles exceed the desired density per voxel GSM will cull the points of that voxel. B. If voxels beneath the surface do not have the correct density GSM will add points. C. If there are not enough particles on the surface, within 2-3 voxels GSM will fill that voxel with the desired number of points per voxel. It seems on one frame the GSM node will delete ALL particles within a voxel that exceeds the limit. Then the next frame, because the void was created it will then repopulate the void with the desired density. So this is where I'm hoping for some help in understanding, in order it's: 1. GSM determines particles are too dense. 2. GSM deletes all particles in voxel. 3. Complete solve (particles partially close in on this void) 4. Next Frame of solver - void still exists so GSM adds particles to this voxel with points = Flicker / Pop. So to start the thread: First - Does Gas Seed Marker delete all particles within a voxel that exceeds the density limit or is this an optical illusion? Second - I'm having trouble getting this node to function outside the context of the flip solver. I want to see it populate points into the Geometry data but it has a lot of requirements regarding the slice index that I don't fully understand. If anyone has or can create a working example of this node functioning outside the context of the flip solver I would greatly appreciate it. For now I'm going to try using two GSM nodes one after the other. The first only performs the cull operation and the second performs the fill before processing the solve. Will post back with results shortly.
  22. Ring pyro burst

    Your first sim looks pretty promising actually. You would get a lot closer to your desired initial poof using the combustion model rather than just straight smoke. Try using the first exploding points as a fuel and temp source for the combustion model and just limit your gas expansion so it doesn't get too out of control.
  23. Simulating flip from bottle

    This is a great start! To answer a few of your questions - 1. Maya geo vs Houdini geo. Depends on a couple of things. Is the geo from maya, imported, processed, and then cached or are you just directly importing the geo from the FBX? FBX and alembic both sometimes bring in geo as packed geo, poly soups and this brings with it a number of problems. Houdini's geometry format is very efficient. You're going to have a lot quicker results using it. When you bring in your FBX, for your own sanity, never point your sim directly at that FBX. Import it, unpack it if necessary(usually only alembics are packed), convert it to poly, attribute clean it, trail it for velocities, and cache it as bgeo.sc 2. Scale is everything for flip. Small flip sims are always fun. On the one hand, using flip is intuitive and fun and, on the other hand, using flip for small scale simulations is kind of like using an excavator to do the work of a spade. Can you? yes, should you? It's going to be a lot of work and frustration because the tool is powerful but works best on medium to large scale simulations. Scaling flip simulations to the scale flip operates best at helps for sure BUT you wind up dealing with a lot of strange motion blur issues in the future when you scale things back down for your scene. It's not that this isn't something you can correct for just something to keep in mind because the amount you wind up scaling your object to bring it into flips happy place is .. completely arbitrary and the speed of your animation is again arbitrary. You can't just multiply by X percent because you're after all the cool inner swirly bits n such and bringing those down along with the speed at which your character swings it about means .. two very different numbers and splitting those velocities apart to scale them properly. As for volume loss, small quick moving objects and flip don't get along super well. The collision geometry often moves quickly enough that thin walled objects move through a fluid rather than push the fluid along with it which results in volume loss, see the particles flying out the backside of your bottle? There are a couple of things you can do to combat this. A. Make your collision volume with thicker than reasonable walls for such any thin walled object. B. Make sure your collision volume is calculated on a single frame, just once, and animated. That way it has proper collision velocity and the collision volume does not deform over time. C. Substeps of course. 3. For sourcing, I see no reason why this wouldn't work. The resolution of the volume responsible for the boolean is whats going to determine how exactly 100% of the bottle you fill but that seems fine. 4. Simfiles only caching points doesn't work because they contain the volumes the simulation uses to update the solver so you can pick back up in the middle of your sim at a random frame and move forward. If you just want the points you don't need to cache the simfiles. Just make sure your dopnet is only bringing in "flipobject1" "Geometry" and cache that to disk. Something to keep in mind, Flip does not recognize that the space the fluid is leaving creates a vacuum. Bubbling back up into the bottle is a big part of the pouring effect and something that I would be very interested in seeing here. Also always happy to look over the hip file anytime. Do include the geo files for the bottle if they're file references.
  24. The example file for the vellum solver uses a pins group to animate a few of the points of a sheet and the solver takes over for the rest. Have you tried grouping a couple of the points and use them as animated pins?
  25. Cellular structures in fire

    I've never seen that solver before, I can't even get the node to show up with opunhide haha A lot of that kind of texture can be achieved with the settings in the pyro solver. I found this video really helpful https://youtu.be/fTIeGob0Wuo?t=1071 The video is a little old so I do believe the solver and shader have been updated since then but the parameters on the new nodes are far more intuitive and the things taught in this video translate pretty easily to the new shader and pyro solver.