3Delight volume rendering

November 16, 2019

3Delight for Houdini Volume rendering test.

Adding vdb vel fields to FLIP

November 16, 2019

Using vel fields to control the flow of FLIP sims is quite the handy trick, and using the new source volume nodes set to “pull” allows you to add in your vel fields without them looking like they are taking over the sim completely. Here’s a hip file too: directable_FLIP.hiplc

Continue Reading...

Just an update, I’ve compiled the for the latest production build, and zipped up for you lazy assholes.  Houdini_USD_17.5.258_Win_x64

I had a great time playing with Katana, and setting up a nice demo scene using my good
friend Filippo’s VDB caches. 3Delight is killing volume rendering!

I know most of you aren’t interested in this, but hey, there has to be at least one other dickhead out there that wants to compile the USD Plugins for Windows.
We need to install a couple things, namely Microsoft Visual Studio 2017 Community, and also CMake. Get them below. When installing Visual Studio grab all the C++ add ons.

Microsoft Visual Studio


Okay, so lets get to it. We need to grab the houdini toolkit folder, located in;
“C:\Program Files\Side Effects Software\Houdini 17.0.459\toolkit” for example. Copy and paste the toolkit (and obviously all it’s contents) to somewhere. I have whacked mine in here: W:\dev\toolkit but put it wherever you want. We need to set a couple environment variables in order for everything to work.


Let’s make a new environment variable and append the path variable. Remember this is the “User variables for YourName” section, not the System Variables. Make your new var CMAKE_PREFIX_PATH and fill in the path the cmake directory.


And now, let’s append the user path variable. Edit this bad boy, and hit new to append our path to the bin folder.


Sweet azz. Now let’s keep moving, it’s already making me sleepy. In the root of the usd_houdini_plugins folder, which for me is: W:\dev\toolkit\usd_houdini_plugins\
make a folder called “build.” Now In here is a “CMakeLists.txt” file. The default output is to dump everything into C:\Users\YourName\Documents\houdini17.0\ and this is shit. It will be dumped in with everything else, and be hard to fish out. If you don’t care about this, ignore the below custom output location set up. But for those who want to keep it out of there, see below!

Here’s the Vanilla, let’s delete stuff. Remove all the if >>> down to endif, and set your path to where you want to output the data.


Below is what I’ve cleaned it up to. It’s where all my houdini/pipeline tools live.


And here is the append line to make the DSO go to your custom locale. Just add the INSTDIR pathto\\where you added in above\\dso in the line below, and you’re gold.


Here is my CMakeLists.txt
Okey dokey, with that done, open a command prompt and CD to the build folder we made earlier. Now your prompt is at W:\dev\toolkit\usd_houdini_plugins\build> (obviously your location is different!) let’s do some hacking.

run: cmake -G “Visual Studio 15 2017 Win64” ../  and wait for the magic. Here’s a boring gif of the process for sheer entertainment.


Amazing. I feel like Neo, I’m sure a pill offering is on the near horizon for me. Hop inside the build folder and you can see all our hard work. Double click the following: “usd_houdini_plugins.sln” this will launch Visual Studio, all ready to rock n roll.

All we need to do is select the “install” and go and change from “debug” to “release” then right click “install” and “build”


Once it’s all done, you’ll get some sexy confirmation messages in the output window. If it all went to plan, there will be all the USD Plugins in the location you chose earlier.


Sweeeeeeeeeeeeeeeeeet! Now add this to your houdini.env file:                          HOUDINI_PATH = “W:/Pipeline/Houdini_USD;&”

We made it Wendell! I hope you managed to stay awake for this. I didn’t. Here’s a zipped up binary built against 17.0.459 for you lazy bastards Houdini USD Plugins








Pixar USD on Windows 10

January 4, 2019

Well after a mind-numbing experience building USD on Windows, a feat I won’t be repeating in a hurry, due to how shit it is, I present a much easier route, which results in minimal hair loss. Victor Yudin has been busy compiling and releasing USD + goodies under his saturn github.

It comes with UsdView, Embree plugin, Maya 2018 plug, MaterialX, and OSL support. Hurray! Thank Jesus. What we will do is get his compiled version up and running, bind the cmd file to the .usd extension so we can just double-click, and even add a USD icon!
It will be, almost useful.

Grab this version: https://github.com/VictorYudin/saturn/releases/download/1.0.160/usd-v18.11.tar.xz

As the latest Houdini 17 USD plugins(which we will compile in the next exciting episode)
are built against v18.11, not the more recent v19.01, simple huh?


So once we unzip it’s almost ready to go, except that the “usdview.cmd” script inside the bin folder only contains the following:

@python “%~dp0usdview” %*

We need to add some more info in here to help point everything to the correct versions/locations of all the shit it needs. So delete that lonely line, and fill  the script with the following.

@set BINP=%~dp0
@set LIBP=%~dp0..\lib
@set PYP=%~dp0..\lib\python
@start pythonw “%~dp0usdview” %*

This is so simple, it feels like installing a Windows 98 screen saver. Let’s continue! Next on the list is testing out our setup to see if UsdView launches. Now is a good time to grab some USD data, head on over to: http://graphics.pixar.com/usd/downloads.html and grab the kitchen set. Once you’ve unpacked, we need to open a terminal, and cd to the bin folder. the command for launching is simply: usdview “path/to/usd” see below.


Like the Angel in it’s a Wonderful Life, you just have to believe you are making a difference, and to hang on. Let’s see what happens….


Huzzah! We made it Wendell. By default the viewport is the hydra openGL, but Victor compiled Embree too, so if we go to View>Hydra Renderer> Embree we will toggle over to ray traced land. It’s a fair bit slower, so be mindful of zooming around. There is preliminary AOV support in this mode.


And prim ID and Normal AOVs.



Sweet. Now this is all good and well, and we could/should create a shell working environment that has usdview in the path, etc, etc, but let’s go all out lazy Windows double-click shall we?

The file extension .usd isn’t registered in Windows, so we need to do this manually. Fire up a terminal in “admin-super-overlord-mode”

type the following: ftype extfile=”W:\Pipeline\usd\bin\usdview.cmd” “%1”

obviously replace the path with your location.

Next type the following: assoc .usd=extfile

Now if you double-click the Kitchen_set.usd file it should launch usdview. For our final trick, we need to use a nice free utility, that doesn’t even install!

file types manager

Grab the x64 version here: http://www.nirsoft.net/utils/filetypesman-x64.zip and unzip that bad boy. Launch the application directly, and scroll on down to .usd file type.


Right click the usd extension and select “edit selected file type.” navigate to the location of the .ico file, and maybe even pop a brief description in. Here’s a link to a little USD ico file I made: usd_simple64.ico


In the next exciting installment we compile the Houdini 17 USD plugins from scratch, and demo exporting out.








I’ve been having a serious look at using spheres and also boxes to represent the collision
shape in bullet simulations. Spheres are great in that you can rely on the geometry to not get caught and hang on to each other. Boxes offer a nicer settling motion in certain setups too. The main reason I wanted to look at it, was to avoid always needing to use glue constraints. Sometimes I want a nice quick voronoi fracture that uses the clustering option, and this yields shitty collision approximations with convex hulls.

Enter vdb sphere packing! It allows me to fill the wacky geometry shapes and use those as colliders. I just save out my points, and transform the original pieces. Voila!


Dot Product & Normalize

September 25, 2018

These are two of the most used functions in Computer Graphics, and quite a lot of the time, the underlying process of how it works, is ignored.

Normalizing a vector is essential for a variety of reasons, and below is the long way around to do it, as opposed to the normalize VOP.


We need to find the length of the Vector, as this will be used as the divisor for the x,y,z components of the Vector to be normalized. This is done by taking the x,y,z components and taking each to ^2 power. Then we add those values together and find the square root. Now we have the length of the Vector, and  can use it as the divisor. Voila!

Now it’s time to do the Dot Product! Mysterious I know. But very handy in shading/lighting and other areas of Computer Graphics. The Dot Product is the Cosine of two normalized vectors. Cosine being the trig function equal to the ratio of the side adjacent to an acute angle (in a right-angled triangle) to the hypotenuse. That’s pretty neat!

Below is a quick animation of the Cosine around a unit circle. The unit circle being a radius of 1 of course. The Dot product of two normalized vectors, which we will see is just multiplying their components and adding them together, creates a trigonometric function.

Here is the long way of doing it, instead of using the dot product VOP.


First we normalize both Vectors. Then we split the x,y,z components of each vector and multiply them. Adding the results of this all together. Bingo! Very Simple really isn’t it. Additionally, using a trig VOP to use arc cosine along with a radians to degrees, will give you the actual angle between those two vectors.

I Have been working on this for the last six months.

Tinkering with using uniform or varying volume, along with reflection and refraction to create more interesting attenuation of light.