Jump to content

Leaderboard


Popular Content

Showing most liked content on 03/26/2020 in all areas

  1. 2 points
    I made an attempt at "upresing" this fuel based rocket launch. Treating the original file as the a low resolution simulation does allow me to enable OpenCL. The uprezed version is on the right. A 500,000 voxel low res source drives a 4,000,000 voxel upres. ap_upres_smoke_pyro_setup_032520.hiplc
  2. 1 point
    you are mixing things together. That is not a name attribute on the primitives. That is a path attribute. You name attribute exists on the points. Each individual cube is represented by a point. This is what happens when you pack the geometry. So in order to color some of the cubes for instance you need the sop solver to be attached to the rigid body solver. Not the constraint solver. (unless you are trying to color the constraint primitives.) See below Lastly in order to access the cube geometry (the points) you need to work from the dop_geometry node inside the sop solver and not the Impacts. Once all of that has been setup you can then write your code. Your code should look something like this: Take note of the fact that the wrangle node is running over the points and not primitives. Since your geometry is packed I only have one point or one primitive available per cube. The name attribute exists on the points, so we have to run over points. A simple string condition does the trick to isolate the desired cubes. Inside the if statement I choose to add my color attribute to the primitive instead of the point which I am running over. This is simply just because Houdini is not very good at displaying colors that sits as a point attribute when dealing with packed geometry. So in order for it to show in the viewport I added the color in a primitive attribute instead.
  3. 1 point
    I have put together a short video that demonstrates how to upres standard Houdini 18 smoke.
  4. 1 point
    in this case you can use Polyextrude Inset table_example_fix.hip
  5. 1 point
    I put together a fuel based version of the basic density based starter rocket launch scene. This scene includes a couple of additions, that I have seen posted, here on OdForum, including Fencer's smoke drag, based upon distance from origin, and hand drawn velocity curves to encourage the smoke to travel along the curve shape. The support nodes for the hand drawn velocity are shaded purple, in the DOP network. Play around with the fit values on the gas wrangle to alter damping. Increase popnet particle count to send more fuel into the system. Increase popnet life to make fuel linger, longer. ap_rocket_lift_off_fuel_based_090919.hiplc
  6. 1 point
    that shape sure does resemble pickle
  7. 1 point
    I can't wait until people don't have masks on their face; some people I couldn't understood before the mask, now it's worse.
  8. 1 point
    https://i.imgur.com/eqsGPTs.mp4
  9. 1 point
    When my bottle start to move the fluid inside the bottle dissipate. i am using proxy sdf for collision. the fluid is fine when the bottle is not moving. but when start to move the fluid is gone. dont know what to do. Bottle.abc Water_Bottle.hip
  10. 1 point
    Definitely go for a wacom. I've exclusively used a wacom for houdini for a many years now and it's just wonderful, and it's a lot faster getting around and laying down nodes than with a mouse ontop of being ergonomic. If I only have a mouse I can barely get anything done and it's just tedious, I don't know how you people do it. Get a wacom.
  11. 1 point
    Yes, stick to Packed Disk/Packed Alembic for delayed loading. They do everything the Delayed Load Procedural did and a LOT more.
  12. 1 point
    Temperature Field and Divergence Field and what to do about it Combed straight velocities lead to mushroom puffs. Large directional forces lead to combed straight velocities. The pressure wave leading the divergence field leads to combed straight velocities. So what to do? Looking at Temperature first, it is directly used with Gas Buoyancy to drive the intensity whereby the upward direction is multiplied by temperature and then added to vel. Temperature is also used to burn fuel at an ever increasing rate with higher temperatures which then ultimately affects the divergence field. Temperature is also used by some of the shaping tools to inject noise or trigger confinement within the simulation, amongst other fields. Temperature and Gas Buoyancy DOP High temperature values fed in to the Gas Buoyancy DOP will affect the velocity field quite effectively, in a singular direction no less, the buoyancy direction. This inherently leads to nicely combed velocity with higher temperature values and large amounts of buoyancy as the simulation evolves which leads to nice mushrooms leading the way. Just like in real explosions and initial bursts of hot smoke/steam. But the director always wants more "character". That's fine and manageable in most cases as the velocities aren't that large, especially in smoke simulations where the temperature is driven by the sources. In the case of explosions, the burning of fuel can create very high temperatures and cause large upward velocities. Working Temperature with Disturbance By default the Disturbance field affects temperature. It is also cited as one way to break up or diminish the mushrooms. But how and why? And does it work? Using disturbance is designed to add noise to the temperature field around the simulation. This is one way to try to kick or disturb the rising velocity field, in an indirect way though. For Pyro, temperature is used to ultimately affect vel in two ways: Buoyancy and Combustion (which inevitably drives the divergence field). What is Divergence? Well it's randomly generated noise. It's not time coherent turbulence. Yep. If you dive down in to the Gas Disturbance DOP, in to the disturb_field Gas Field VOP you will find a lowly random VOP that is fed a vector 4 (vector P and an animated offset) and generates random incoherent noise per substep. If this sounds desperate, well it kinda is. But it works very well in some cases to etch the leading edge of the velocity to cause eddies that then form ripples and swirls. Think volcano smoke. Disturbance can be applied to temperature and it will eventually have an effect, or you can have it work directly on the velocity for a brute force immediate effect to try to etch away at that leading velocity front generated by the rapidly expanding divergence field. if it is strong enough and if it is localized to just around the evolving sim so that our container doesn't resize to maximum and take too much memory and take too long to simulate, it can work very well. Perhaps this is why the shelf tools only allows for a small value relative to the velocities that are present in an explosion or fireball: it doesn't really work for these types of sims at it's defaults. We have all of the necessary tools to implement this well enough. The Gas Disturbance DOP built in to the Pyro Solver and exposed as the Disturbance parameters can do this. It has support for a control field and even a ramp with min and max threshold values to really dial this in, if you have a field to use that is... For Smoke and combustion fire type simulations (no explosions), you can gleefully use the density field as both your Threshold Field to control the cut-off threshold for the disturbance and as the field to control the amount of disturbance you want. Or use temperature as the Control Field as with rising smoke, the temperature tends to lead the density. For fast rising smoke, you can set the Control Field to temperature and then use the Control Range to say 0 and 0.1 to try to etch the velocity field prior to it being run over by the advancing wave. For Explosions, there is feint hope. Unless you envelop the entire container with shredded velocity, there is no other field at your disposal to use to control where the disturbance should be applied. Yes you can create an additional field containing an expanded divergence field to try this, but there's better ways to coax swirls in the initial part of the explosion. In the end, as with all the other shaping tools, it comes down to magnitude. If the magnitude of the previous frame's velocity is much larger than the velocity shaping amplitude, knowing that velocities are for the most part added or subtracted in most simulation engines, you aren't going to see much effect, especially after the Non-Divergent step gets rid of most of this random pressure hash anyway. When you are dialling in a sim, you have to have the vel on for display and adjust the Visualization Range (working the leading red envelope) to get an idea as to where the velocity is fastest and what those values are (in Houdini units per second). If you have a velocity of 10 in the leading velocity pressure front and you set disturbance amplitude to 0.5, you know it won't have much of an effect. One thing that will have an effect is to apply Disturbance directly to vel for explosions and apply it within the divergence, burn, temperature or any other field that's playing a role in the fireball itself. But not to the surrounding area unless again you bypass the resizing of the container. Heck you don't even need to bypass the resize container DOP. If you are resizing on density and vel, the container will max out after the second or third frame anyway. And you can live with completely incoherent noise that for the most part is wiped out by the Non-Divergent counter pressure field. Divergence and Burning Fuel The divergence field in explosions and fireballs is the main contributor to mushroom caps over the first second or so. It will comb the velocity vectors perfectly straight in the leading pressure wave advancing in front of the density, temperature, fuel, whatever. We know why. It's the Non-Divergent step trying to remove any pressure across the timestep outside of the divergence field. It makes perfect sense then that when carefully inspecting the velocity around the leading edge of the divergence, you will find the greatest velocities. Divergence pushing outward creating a large pressure front causing the Non-Divergent step to add a very large counter pressure field that gives you that front of straight combed velocity. Large amounts of burning fuel (fuel + temperature = burn, divergence (gas expansion) then uses burn and fuel to drive the expansion of the sim) leads to a strong divergence field. Gas Buoyancy affects vel very effectively and divergence allows for rapid expansion. How do the explosion and fireball shelf tools try to avoid mushrooms? Well we see that the timescale is reduced for both options in an attempt to add enough time to evolve interesting swirls in the simulation as it evolves. But for many cases doesn't give you that nice character over the first few frames of the simulation. We also see Disturbance added but at a meagre 0.75 Shredding is set to 1. Shredding is a very nice tool for adding character to fire. As it's name implies, within the threshold tolerance of the effect, the velocity field is either stretched along a gradient direction or compressed. It is the transition between the two that gives you the real nice licks of fire. Shredding defaults to 1 and it has visualization option to see where this shredding occurs and how strong it is by it's color in relation to the velocity. If you look at the shredding, by default it is being applied along the surface of the temperature field where the Threshold Width is being set. Again this won't work for the first second of the explosion. Same for Turbulence and Confinement. They too work within the fireball and not the leading edge of the explosion. so what to do?
  13. 1 point
    Coarse Sub-Steps If you have an expanding gas field front that from frame 1 to 2 or frame 2 to 3 travels one or two Houdini units and substeps are set to 1, you will get combed straight velocity vectors which means mushroom caps. No matter how much turbulence or confinement you set on your Pyro Solver DOP, there simply isn't enough time to evolve these fields and have an effect on the result. More substeps means smaller velocities to deal with between substeps making things more manageable too. In an attempt to keep substeps at 1, you can manufacture noise and pump that in to vel but in the end two things will happen: The Non-Divergent step will take your noise and negate most of it, or you end up pumping in so much noise because it isn't working with smaller values you tried earlier, that it swamps the entire effect and it looks like a fractal hash and not that nice evolving fireball. Oh and if you really pump in tons of noise in to vel, it too can create many smaller velocity fronts pushing ahead and you end up with smaller mushroom caps! Doh... This is in essence what the Gas Disturbance DOP does. The Pyro Solver has a Gas Disturbance DOP in it's logic and those parameters are promoted up to the top asset interface but we're concerned about substeps right now and allowing enough time for turbulence and confinement to create the nice swirls on the leading edge of the explosion. So it's coming down to sub steps to try and allow for a lot more character around the leading pressure front for fast evolving explosion type simulations. Two ways to go about this: Brute force increase the global substeps for the entire DOP network, or use the Pyro Solver Substeps in the Advanced tab. Brute Force Global Substeps For explosions, the huge almost instantaneous velocities happen at the first 5-10 frames. It would be nice to keyframe animate the Sub Steps parameter, but you can't (DOPs is that way). If you set the global sub-steps to get enough detail in the first few frames you have to carry those sub-steps through the rest of the sim when things are moving a lot slower and those substeps are no longer required. Not that great. No wonder everyone tries to inject their own pumps to affect vel to avoid global substepping. Pyro Solver Substeps The Pyro Solver exposes minimum and maximum substepping logic to control when and how the Pyro Solver will substep. This sounds interesting and could be just what we need. But what is CFL Condition? No it isn't the Canadian Football League even though we know that 3 downs rule and 4 downs are for those that can't deal 3. It's named after a couple guys who in the '20's, that's 1920's, who were trying to figure out the frequency of data samples they required in order to map and predict fluid simulations and pressures/resistance to flow with fast moving collision objects (that be ships). The help note on the actual Gas SubStep DOP explains it quite well: timestep will be reduced if the velocity field will move only 1 voxel in a timestep. A CFL of 2 will allow it to move 2 voxels in a timestep. Or something like that. You can find it on wikipedia. You can set your minimum substeps to 1 and your maximum substeps to a high enough value such that if the CFL Condition is exceeded, more substeps will occur when the simulation has large velocities and less when the velocity is smaller. Hopefully this gives enough time to let the turbulence and other methods to stir up the vel field kick in. Keyframe Timescale There is a third option to controlling sub steps but that is to keyframe animate the Timescale. Yes more than valid to do this to slow down the sim at the start and then speed up when the huge velocities subside. As a matter of fact, the shelf tools set Timescale to 0.65 as an attempt to get a good looking explosion or fireball without having to resort to substeps. But this is not an automatic method. This requires intervention if you want to animate the timescale. This means you have to run the sim and evaluate. Then you keyframe the timescale and you end up with an entirely different simulation. Then you move your keys, run again. Then you increase the resolution of the simulation and everything changes again. In many ways, it's worth to at least give the min and max substeps a go and see if you can dial in the CFL Condition to get a happy balance. As you increase the resolution of the simulation, the CFL condition measured in voxels will allow substeps to run up a bit faster to the max without too much of a change in the final result.
×