Jump to content

Hunter Williams

Members
  • Content count

    8
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Hunter Williams

  • Rank
    Peon

Personal Information

  • Name
    Hunter Williams
  • Location
    Boston
  1. Using the FEM Solver for car crash / destruction

    Hey, I think you should check out Steven Knipping's course on this- really great series on vehicle destruction, actually using rigid body system: https://www.cgcircuit.com/tutorial/applied-houdini---rigids-iii Super flexible and fast. As I understand it, FEM in the Houdini context is about volume conservation, so it will likely always want to return to its original shape, and you'd always be fighting that tendency if you went that route. Not really sure you want to be conserving volume with being metal, the whole point of basic vehicle crash is that it compresses and reduces "volume" -although take with a grain of salt since I'm new to Houdini On a side note, tt's really weird because I understood the Finite Element Method generally as breaking a large system up into finite pieces to solve, so honestly not really sure why a voronoi fracture + RBD sim isn't "technically" FEM anyways. Just saw your post hadn't been answered so wanted to give any info I had!!
  2. Issue advecting vectorfield

    Hey guys! Trying to figure out the whole custom vectorfield aspect of the pyro solver, but running into some issues.. I created a new vectorfield (Cd) under the smoke object, importing a Cd vectorfield that i want to use in a source volume node (replaced velocity with Cd to Cd as another forum post on here suggested). Then I added a gas advect field microsolver to the advection input of the pyro solver. With the multi checked on the visualization and Cd in for diffuse, I can see that the vectorfield is properly being sourced, but it doesnt advect by the velocity field for some reason, it just sits there. The gasadvectfield node should move the Cd by Vel right? I've found some good forum posts about this here, but for the life of me can't replicate the effect. Any suggestions / advice? Thanks! Cd_advect_v01.hiplc
  3. Boolean for instanced packed fragments for RBD

    Hey guys, I'm having an issue that has had me scratching my head for the past few days now. I'm creating a building for an RBD sim with instanced packed fragments. In order to save memory, I'm creating 3 fractured walls to iterate throughout the building. I'm then carving out the windows using a for each block, iterating through each fragment (nearest to windows) and a boolean to subtract the window hole geo, then repacking to the fragment into its piece. This way, the extra inside faces are attached to each respective fragment, and it becomes a new piece. Alternatively if I just booled the entire wall, I would have issues repacking with the new faces. The problem is that at the end of the for each block, it returns the subtraction geometry merged with the subtracted geo. It doesn't do this with lower density fractures- weird!! I've iterated through each pass to see where the extra geo is coming from, and can't find it for the life of me. Please take a look at the file attached, and let me know if anyone has any ideas! btw- apologies for the file- didn't have time to clean it up Thanks! Hunter buildingFracture_v12_debug_wall.hiplc
  4. I don't have access to Houdini ATM, but did you create UV attribute before or after the RBD sim? If I'm not mistaken (as I'm new to Houdini as well), I believe you have to create the UV's initially and make sure the attribute is transferred throughout. Also, you can create a separate UV attribute for the inside edges based on that attribute you mentioned from the boolean. I don't use Redshift so otherwise, it could be a redshift thing. You should use the UV quick shader to check the UVs after the DOP network for troubleshooting. However, on another side note, I've found that adding an attribute called "inside" on the original geo and setting it to 0 with a default of 1 is better for getting inside faces- it makes sure that new geometry always has the inside attribute with a value of 1 instead of depending on the boolean node to do it. I could just be paranoid though. I'll take a look when I get close to Houdini, but someone more experienced feel free to jump in Best, Hunter
  5. Random Voronoi Fracturing

    You can use creative ways to to glue neighboring voronoi fractures together in a random pattern ( combining different noises in a VOP to run the constraint types ). This also helps with the convex hull situation so there is no overlapping geo. Lots of different techniques. Depending on the scene and type of demolition / fracturing, you could use the new booleans to fracture, which are extremely detailed and robust. Best, Hunter
  6. scaling RBD sim problem

    @Skybar I did change it after I created the nodes! That 100% solved it. Dropping down a new gravity node after scaling in the HIP file options did the trick- I thought I just had to restart the sim!!! Thanks! Hunter
  7. scaling RBD sim problem

    Luke and tamagochy - thanks for the replies! I did scale my project in the HIP file options to one unit being .1 meter- and the truck is apprx. 40 units long, so in the above video its about 4 meters long. I'll try to scale it without using the HIP preferences, but just using a transform and see where that gets me. Thanks! Hunter
  8. scaling RBD sim problem

    Hey guys! Hoping you can help me out with this. Trying to get this RBD sim to time properly, tried even scaling the scene in the HIP file for the DOP network to have best avail information. Density should be pretty accurate for steel as well. The sim feels like its going in slow motion / in space / another planet- gravity feels very low even though its definitely the correct -9.8m/s^2. Should I just speed it up post- cache? Or is there some option I'm not looking at. Pretty new to Houdini, so let me know what y'all think / any other suggestions? Thanks!! F150_body_metal_v01.abc preview_cache_v01.mov 180505_hardConstraintTest_v07_metal_only_slide.hiplc
×