Jump to content

Leaderboard


Popular Content

Showing most liked content on 12/12/2018 in all areas

  1. 2 points
    Hello everyone! My name is Daniele, I'm new to Odforce. This is my first post, nice to meet you! I've been a character animator for a few years but recently I started learning Houdini. I'm learning using resources I find online, including some super useful posts from this forum. I would love to use this post to keep track of my progress and share my results with you. My first project is a procedural building, hip is attached. Cheers! Daniele procedural_house_01.hipnc
  2. 2 points
    This isn't exactly the same but couldn't you create your own parameter, edit the range, then copy the relative reference to the other parameter?
  3. 2 points
    "Distant Thunder" Yesterday I wrote my first Python-node ever. With the help of this page: https://github.com/mgeier/python-audio/blob/master/audio-files/audio-files-with-wave.ipynb I managed to load a 24 bit stereo wav file (of distant thunder, which I recorded this summer at our cottage in the woods) and create geometry from it. Makes for a great desktop background, so I uploaded it as 24 bit png... :-) Created in Houdini Core 16.5, rendered in Redshift and post treatment in Luminar 2018. Cheers, Tom
  4. 1 point
    I guess isn't possible to change that. Have you consider to use spare parameters or HDA? Modifying that parameter may implies changing all nodes of the same type. That's why it's restricted
  5. 1 point
  6. 1 point
    pyro solver -----> relationships -----> collisions -----> enable collision relationship. There is that option, but I am not sure about ignoring per cluster. Maybe another pyro container for the cluster you don't want to collide is another option.
  7. 1 point
    did this on a job recently. here's the process more or less: split your cache about in half and timeshift / timewarp each half so that the first half becomes the second half, and vice versa. this means that the first and last frames are now identical and will loop. now you just have to blend the middle part. overlap each half of the cache in time so that you have some room to blend. keyframe a blendshape or the equivalent so that the caches blend from one to the other during this overlap period. to make this less jarring, you can animate a "blend" point attribute that wipes across the mesh from 0 to 1. then use a wrangle to blend your point positions from the retimed cache to the blend shaped positions: @P = lerp(@P, blended_P, @blendAttr); this works best if the wipe moves in the same direction as the prevailing ripples in the cloth. you might need to do a detangle afterwards, or do a secondary vellum sim during the blend shape animation in order to detangle parts that end up interpenetrating during the blend. totally depends on your original sim.
  8. 1 point
    I usually do it like this: vdb_maskvel_dv.hip
  9. 1 point
    Project Non-Divergent Step and Mushrooms The Project Non-Divergent DOP is responsible for 99.9% of the simulation's behaviour. Yes hundreds of DOPs inside the Pyro Solver all playing a part but all funnelling through that single Non-Divergent step. This means that if you don't like the look of your sim and the mushrooms, it's ultimately because of the Non-Divergent step creating a vel field that doesn't do it for you. If you want to see for yourself, unlock the Pyro Solver, dive in, find the Smoke Solver, unlock that, dive in and find the projectmultigrid DOP and bypass it, then play. Nothing. For most all Pyro sims, this is the Project Non-Divergent Multigrid as it is the fastest of the Non-Divergent micro-solvers. This specific implementation only takes the vel and divergence field and assuming across the timestep that the gas is non-compressible when divergence is 0, will create a counter field called Pressure and then apply that pressure field to the incoming vel to remove any compression or expansion and that gives you your velocity, nice turbulent and swirly, or combed straight out. Just tab-add a Project Non-Divergent Multigrid DOP in any dop network and look at the fields: Velocity Field, Goal Divergence Field and Pressure Field (generated every timestep, used, then removed later on). All the other fields in Pyro are there to affect vel and divergence. Period. Nothing else. At this point I don't care about rendering and the additional fields you can use there. It's about vel and divergence used to advect those fields in to interesting shapes, or mushrooms. If you want to create your own Pyro Solver taking in say previous and new vel, density, temperature, and then in a single Gas Field VOP network, create an interesting vel and divergence field, then pass that straight on to the Project Non-Divergent Multigrid microsolver, then advect density, temperature and divergence afterward, go for it. Knowing that only vel and divergence drive the simulation is very important. All the other fields are there to alter the vel and divergence field. So if you have vel vectors that are combed straight, divergence (combustion model in Pyro) or buoyancy (Gas Buoyancy DOP on temperature driving vel) have a lot to do with it. Or a fast moving object affecting vel...
  10. 1 point
    I've wanted to tackle mushroom caps in pyro sims for a while. Might as well start here... Three things that contribute greatly to the mushroom caps: coarse sub-steps, temperature field and divergence field. All of these together will comb your velocity field pretty much straight out and up. Turning on the velocity visualization trails will show this very clearly. If you see vel combed straight out, you are guaranteed to get mushrooms in that area. If you are visualizing the velocity, best to adjust the visualization range by going forward a couple frames and adjusting the max value until you barely see red. That's your approximate max velocity value. Off the shelf pyro explosion on a hollow fuel source sphere at frame 6 will be about 16 Houdini units per second and the max velocity coincides with the leading edge of the divergence filed (if you turn it on for display, you'll see that). So Divergence is driving the expansion, which in turn pushes the velocity field and forms a pressure front ahead of the explosion because of the Project Non-Divergent step that assumes the gas is incompressible across the timestep, that is where where divergence is 0. I'm going to get the resize field thingy out of the way first as that is minor to the issue but necessary to understand. Resizing Fields Yes, if you have a huge explosion with massive velocities driven by a rapidly expanding divergence field, you could have velocities of 40 Houdini units per second or higher! Turning off the Gas Resize will force the entire container to evaluate which is slow but may be necessary in some rare cases, but I don't buy that. What you can do is, while watching your vel and divergence fields in the viewport, adjust the Padding parameter in the Bounds field high enough to keep ahead of the velocity front as that is where you hope for some nice disturbance, turbulence and confinement to stir around the leading edge of the explosion. or... Use several fields to help drive the resizing of the containers. Repeat: Use multiple fields to control the resizing of your sim containers. Yep, even though it says "Reference Field" and the docs say "Fluid field..", you can list as many fields in this parameter field that you want to help in the resizing. In case you didn't know. Diving in to the Resize Container DOP, there is a SOP Solver that contains the resizing logic that constructs a temporary field called "ResizeField", importing the fields (by expanded string name from the simulation object which is why vector fields work) with a ForEach SOP, each field in turn, then does a volume bound with the Volume Bounds SOP on all the fields together using the Field Cutoff parameter. Yes there is a bit of an overhead in evaluating these fields for resizing, but it is minor compared to having no resizing at all, at least for the first few frames where all the action and sub-stepping needs to happen. Default is density and why not, it's good for slower moving sims. Try using density and vel: "density vel". You need both as density will ensure that the container will at least bound your sources when they are added. Then vel will very quickly take over the resizing logic as it expands far more rapidly than any other field in the sim. Then use the Field Cutoff parameter to control the extent of the container. The default here is 0.005. This works for density as this field is really a glorified mask: either 0 or 1 and not often above 1. Once you bring the velocity field in to the mix, you need to adjust the Field Cutoff. Now that you have vel defined along side density, this Field Cutoff reads as 0.005 Houdini units per second wrt the vel field. Adjust Field Cutoff to suit. Start out at 0.01 and then go up or down. Larger values give you smaller, tighter containers. Lower values give you larger padding around the action. All depends on your sim, scale and velocities present. Just beware that if you start juicing the ambient shredding velocity with no Control Field (defaults to temperature with it's own threshold parameter so leave there) to values above the Field Cutoff threshold, your container will zip to full size and if you have Max Bounds off, you will promptly fill up your memory and after a few minutes of swapping death, Houdini will run out of memory and terminate. Just one of the things to keep in mind if you use vel as a resizing field. Not that I've personally done that... The Resolution Scale is useful to save on memory for very large simulations, which means you will be adjusting this for large simulations. The Gas Resize Field DOP creates a temporary field called ResizeBounds and the resolution scale sets this containers resolution compared to the reference fields. Remember from above that this parameter is driving the Volume Bound SOP's Bounding Value. Coarser values leads to blurred edges but that is usually a good thing here. Hope that clears things up with the container resizing thing. Try other fields for sims if they make sense but remember there is an overhead to process. For Pyro explosions, density and vel work ok. For combustion sims like fire, try density and temperature where buoyancy contributes a lot to the motion.
  11. 1 point
    You could also take a look here ftp://ftp.sidefx.com/public/ There are some old version still on the ftp. A 9.5 for windows is also there.
×