Pyro UPRES

Setup a Pyro as you would normally..This will be your low res sim. In a Geo sop somewhere, make a DopIO node and choose the pyro preset to make sure you're importing all the required fields from the low res sim. You could file cache this out..

Then..make a new Dop network. Inside this, create a smoke object and plug it into a Gas Upres node.
Point the Gas Upres node's Initial Data/Low Res Sop Path to a DopIO node you made earlier. Alternatively if you've cached it out to VDBs or bgeo.sc's you can switch the source to "file" and point it to that cache.


I've found that putting a copy of your low res sim's Source Volume helps a lot. Plug that into the last input of the Gas Upres. Switch it's Velocity setting to COPY, since you'll want to copy it from the lowres sim.

You might have to play with the smoke object's initial size settings, so that it encompasses your entire sim size. Oh - and change the division size to your desire resolution..we are upres-ing after all.

Mess around with extra dissipation or turbulence in the Gas Upres node...

That should be it.

Pyro.. without shelf tools

Setting up Pyro manually...

• You'll need to plug your emitter geometry into a Fluid Source node. You might want to turn off empty interior. As always, label with a null. OUT_SOURCE. Add a scalar volume and label it temperature. Your pyro won't react properly to buoyancy otherwise. THANKS HOUDINI.
• It's a good idea to create two bounding boxes - one for the source, one for the padding. Make the padding way bigger than the source, freeze the time so it doesn't jump around in the simulation. You don't have to freeze the source bounding box as the solver only takes the first frame anyway. Label them with nulls, with something like OUT_BOUND and OUT_PAD.

• Inside a dopnetwork -
• You need a Source Volume node. use your OUT_SOURCE as your volume path. Initialise it to Source Smoke. Set the Velocity to Add. Otherwise it will just keep overriding the velocity.
• You need a Smoke object. You might as well link the Division Size to the same parameter in the Fluid Source you created earlier. For the size and centre parameter boxes, use these respective expressions with the relevant paths and axis variations - 

bbox("../../geo1/OUT_BOUND",D_XSIZE)
centroid("../../geo1/OUT_BOUND",D_X)

• In the Creation tab, you'll probably want to tick ON Solve on Creation Frame. This gives the system some density on frame 1, so it won't immediately shrink and implode on itself.
• Next you need a Gas Resize Fluid Dynamic node. This just keeps track of the size of the simulation. Tick ON Clamp To Maximum, set it to From Object and point it toward OUT_PAD. Nice and easy, no expressions required. You still might have to faff with the padding values in the Bounds tab....
• Lastly, but not least - you need a Pyro Solver node. Plug the Smoke Object into the first input, the resize into the second and the Source Volume into the last.

That should all work! The Solver contains most of the turbulence/shaping controls for the simulation.

You now have a basic pyro setup without using shelf tools. YAY.

random rotation with POPs

To get random rotation with POP particles, add a point wrangle at SOP level with a more specific version of the following code-

v@w=rand(x-value,y-value,z-value);

Then in the dop network, add a POP-torque node and set the amount to zero, so that it takes the initial "w" value. "w" is angular velocity..all according to keikaku.

installing QLIB...what to stick in your houdini.env file

#QLIB
QLIB=C:/Users/threedee/Documents/houdini16.0/qLib-dev
QOTL=$QLIB/otls
HOUDINI_GALLERY_PATH = &;$QLIB/gallery
HOUDINI_OTLSCAN_PATH = &;$QLIB/otls/base;$QLIB/otls/future;$QLIB/otls/experimental
HOUDINI_TOOLBAR_PATH = &;$QLIB/toolbar

voronoi fracture woes & exporting alembics to maya

Voronoi fracturing is often used to create destruction fx. It also creates a lot of dirty geometry, which leads to pain when exporting your geometry to Maya -

"UVs aren't per-vertex or per-polygon per-vertex, skipping"

 This also plays havok with motion blur and any other vertex attributes you might have in play.

Using a For-Each loop, or For-Each subnetwork (if using the subnetwork, attach a Connectivity SOP first, with a "class" attribute, so the For-Each knows what pieces to run over. You type "class" into the Attriubute field of the ForEach Subnetwork parameter box) use Clean SOPs to fix any nasty geo that might have been generated. You'll want to tick most of the boxes - your mileage may vary with the Non-Manifold option.

This probably won't fix the problem still - the fracturing process can make a lot of stray edges - 2 point primitives, which don't play nice.

drop down a Primitive Wrangle and use this code-
i@vertnum = primvertexcount(0,@primnum);

It creates a variable called vertnum that counts how many vertices you have in each primitive.

Follow this wrangle with a blast that has
@vertnum==2
in it's Group box. This will kill any stray edges & hopefully fixes everything!

Getting data from strings

for example, once you've shattered something you end up with a lot of "pieces". Piece1, piece2, piece56000.
You might want to use the number as a seed value.
Usually the piece number is stored in the @name attribute.
In a wrangle, you can strip out the word piece, as follows... (and use atoi, to convert the string number to a number number)


s@testval=s@name;

@testval=strip(@name,"piece");
f@randval=rand(atoi(@testval));

voronoi shatter pieces not staying as a chunk

Sometimes..most of the time, your voronoi shatters that have thickness won't behave correctly. The sides will fall off. Boo.
What you have to do is run all the pieces through a Foreach loop and Fuse the verts back together.

This could go just before your assemble node