# Particle Stock – Part 2

This got pushed by the wayside a little as a number of other tools took up more time, but I’ve finally gotten it to a suitable standard to release it. There are a number of improvements and optimizations I plan to add over the coming days, but at the moment it’s pretty useful as is! The premise is simple: Effects can be saved out as 2D image sequences, and read in to render out 3D particle effects with considerable speed and easy customization.

# Particle Stock – Part 1 : Building a Renderer

I’ve almost finished a useful tool, but there’s quite a lot to it so I’ve decided to split this into two parts. In this first part I’ll go over the core mechanic of the tool and something that a lot of people seem to have difficulty with, building a renderer. Sadly, not a full renderer, just a way of converting 3D points to 2D screen space.

In order to understand the code, we’ll need to do a quick little crash course in how rendering works. I’ll try keep it simple and short, but if you already know or simply want to see the Particle Stock code, skip on Part 2 (as soon as it’s up!).

The process is done in the following steps:

1. Convert target position to camera local space (It’s relative position to a camera sitting at origin and pointing down the -z axis).
2. Convert from camera local space to NDC (Normalized Device Coordinates) space. This is a perspective transformation which uses the camera’s settings to map positions into a -1 to 1 range for each axis. These are the points which are visible to the camera.
3. Convert NDC space to the current format (eg, 1920 x 1080).

This is mostly done using matrix math. Matrices can be daunting at first but are actually quite simple. If you want a detailed breakdown on how all of this works, I highly recommend the scratchapixel explanation. The simple version is that matrices store the rotation, scale and translation of a point in one easy to use form. These are known as affine transformations, which means they are linear and preserve straight lines resulting in orthographic views. These are what we use to move objects around in 3D space, and is where we begin step 1.

# Camera from EXR

Alright, this is one that a couple of people have done for other programs that use an upwards Y-axis (Maya, SoftImage etc.), but this works for an upwards Z-axis for programs such as 3ds max, Blender etc.

The extra feature this offers is that it prevents camera rotations from flipping over, eg, instead of going from 359 to 1, it will now go from 359 to 361. This makes a significant difference if you plan on using the camera for motion blur, as otherwise you will get a frame of extreme rotational blur. So, that’s what it does, let’s see how it works.