So im trying to create an explosion with a shock wave effect. Ive tried animating the source, but that just makes the smoke stretch and not look good. Also ive tried using particles but the smoke doesnt move fast enough. Im a Houdini Newbie, so please bare with my “stupid” questions….That being said, im asking for how you guys all approach an explosion and more importantly the shock wave effect of it.

Divide and conquer is a good approach. Simulate the shockwave separate from the other components of the explosion.

Shockwaves move very very fast. At 1 Houdini unit = 1 Metre, you could have the shockwave travelling 5 or more Metres across a frame. To evolve and capture complex turbulence across a single frame can go only one of three ways:
1) oversample the simulation by either animating the timescale or using the cfl condition to bump up the sub steps where the sim is moving very fast
2) manufacture your own turbulent velocity field and brute force inject it in to the simulation
3) a combination of sub steps and brute force velocity injection

1) Oversampling is pretty straightforward and will change the look of your simulation as it gets much more accurate. As you increase the time steps, your simulation will converge on to a similar result. So pick a reasonable timestep or cfl condition that gives you a reasonable solution, hold your breath and sim. Use the Wedge ROP to wedge certain values and run a bunch of sims in turn. Pick the best one and move on.

2) Manufacturing vel fields can take on any approach you can think of to compute an interesting velocity field. The advantage of pre-computing velocity fields is that as you increase the resolution of your simulation and it remains roughly intact, thus highly direct-able.
It can be any one of:

- construct your own velocity field in SOPs using whatever means at your disposal. Heaps of Curl noise in the Fluid Source SOP can help a lot. Radially outwards from your blast region using say a sphere converted to a volume sdf converted to a velocity field and add heaps of curl.

- use a particle system which is used to drive the velocity. A few hundred points sub stepped a lot to compute interesting velocity fields can work fine. The idea is to substep a lightweight particle system instead of your super-heavy fluid simulation. Works well. This technique has been used to drive a great many fluid sims in many feature film effects.

- combination of sculpted velocity fields and particles.

- use a heavily sub stepped fluid simulation with it's vel fields saved to disk and use that as your velocity fields. This is the sprite approach to fluid simulations. Do a single very high res sub-stepped fluid simulation and crafted and then use this vel field .bgeo sequence injected directly in to your simulation. It's amazing how successful this can be, especially knowing that rotating in the Y axis by a random amount can look like a completely different simulation if you need to do two or more in the same shot.
The nice thing about these vel volume sprites is they are real sub stepped simulations so you get that nice organic feel along with direct ability.

3) Combination of 1 and 2 above. So using the simulation to do the vel fields does indeed yield a more “organic” natural looking simulation but is pretty non-directable and 2 is all about injecting your own vel for direct ability. How you mix in your velocities is what this 3rd option is about.

The default method for injecting your own velocities in to the fluid sim is pretty limited. You can experiment beyond the various options in the Source Volume DOP (I'm thinking the blended average option). You can unlock this operator, dive in and muck about in the network or create your own velocity mixing system based on whatever you want.

So there you go… I really don't care how the vel field is crafted in the end as long as the vel field is interesting and plays to the shot/explosion in question.

And once you get your single awesome shock-wave going, create sprite sequences of the vel, density, fuel, temperature fields to disk for re-use later on. It's just hard drive space and additional local drives are cheap these days. Again a simple rotate in Y with two identical simulations can look different enough to fool the viewer. Again an oft-used technique.

Wow lots of info. Thank you for taking the time to type of that. I will mess around with all you explained and let you know how it goes. Again thank you very much

Ok so i took the time to carefully read through your response. Alot of it was still way over my head. Things like Wedge ROP, Volume SDF (what is sdf) and ect.. im still very new to houdini, so excuse my ignorance literally. I saved your post though, so as i learn what some of the things you mentioned are and do ill revisit and try again

The Wedge ROP is a ROP type node designed to iterate or “wedge” values for any parameter value per render sequence. A handy way to see how Lighting or simulations behave to iterating values on a parameter automatically.

The Wedge ROP simply does the management of the loops and the parameter changes. You need to refer the Wedge ROP to another ROP actually doing the sequence render.

In the case of a fluid explosion simulation, you may want to run 10 simulations where you vary the Gas Expansion parameter as this has a great deal of effect. You can add a new Geometry ROP and point it at the Object/SOP that is fetching the fields from the simulation. Here you set up your sequence, say it's 100 frames long.

Next you add a Wedge ROP and point it at the Geometry ROP. Set the Wedge ROP up to do 10 passes from 1 to 10 with an increment of 1. Don't use random but wedge a range on your Gas Expansion parameter which you need to type the full path to in the given parameter to wedge. Next give it a range of whatever makes sense.
When you render from the Wedge ROP, it will actually execute the referenced Geometry ROP but change your Gas Expansion parameter to the given value for each pass.

Wedging sims is invaluable in finding the proper values.

—-

An SDF is a Signed Distance Function. For Volumes, you can use the Iso Offset SOP to compute a Signed Distance Function for your manifold (water tight or closed) geometry. This calculation is for every single voxel in the generated volume: given the surface normal, what is the distance to the nearest surface, then encode this value in the voxel.

Values that are inside the geometry are given -ve values and values outside the volume are given +ve values.

Once the SDF is generated (which is the time consuming part), you can use this SDF representation of your geometry to do all kinds of very cool things very quickly: am I inside or outside the geometry, what is the direction to the nearest surface (just take the gradient of the SDF to get this), how far away am I from the nearest surface (the actual voxel value), etc. The efficiency of these look-ups is why we have SDF volume representations of our objects. Plus Pyro/Smoke and FLIP Solvers works with volumes and not surfaces.

If you use POPs inside of DOPs and you have RBD's in there, the RBD Object DOPs create these collision SDF volumes for you and the particles collide against these volumes very efficiently.

The Pyro Solver uses SDF representations of collision geometry to determine where collisions are happening. Actually the Pyro Solver uses an inverted SDF where inside values are +ve (makes it easer to manage when adding multiple collision SDF's).

Hope this makes sense.

Thank you for all your help! Ill look into all that stuff you just explained