|On this page
Usually geometry data requires a specific format to fully represent the nature of the geometry. The Geometry ROP interfaces with many plugins and native formats to provide support for a lot of ways to save geometry. However, some systems just expect raw data. For these, the Geometry Raw output driver can dump point attributes, detail attributes, an volume data directly to a file to be read by other processes. This does require careful specification of exactly how it should be written.
Save to Disk
Saves the geometry to disk with the last control settings.
Save to Disk in Background
Starts another copy of Houdini in the background and instructs that copy to cook and save the geometry. This allows one to continue working and load the .raw files as they complete.
Opens the control dialog to allow adjustments of the render parameters before rendering.
Valid Frame Range
Controls whether this render node outputs the current frame or the image sequence specified in the Start/End/Inc parameters.
Render Current Frame
Export only the current frame.
Render Frame Range
Export the frames in the Start/End/Inc frame range, but also allow exporting of frames referenced by in-range frames.
Render Frame Range Only (Strict)
Only export the frames in the Start/End/Inc frame range. Do not allow exporting of other frames, including frames referenced by in-range frames.
Specifies the range of frames to render (start frame, end frame, and increment). All values may be floating point values. The range is inclusive.
These parameters determine the values of the local variables for the output driver.
The number of frames to be rendered by the output driver.
The current frame being rendered (starting at 1 and going to
Render with Take
Uses the settings in a particular take while rendering. Choose Current to use the current take when rendering.
The SOP node, object, or SOP subnet to render from.
The file to save the binary data to. The extension does not matter, so depends on what system will be reading it. Often
.raw is used to make it clear it isn’t a defined format.
Specifies whether the geometry should be transformed into world space before written out.
The byte ordering of the raw data. Unless all the data is single bytes, you need to set this based on how the data was created. There is no way to tell what to set this to, other than knowing which “endian-ness” the program that created the data used, however “Little” (the default) is common on modern systems.
The least significant byte in a multi-byte number is first. This matches the normal memory layout of modern architectures (Intel and ARM), so it is commonly used.
The most significant byte in a multi-byte number is first. This is sometimes called “network ordering” and is common in, but not limited to, network protocols.
While many know the story of Gulliver’s travels, of how the eponymous main character washed ashore of a land of little people, they may not recall why the nations of that island were at war. There was a schism about whether eggs should be cracked from their little side or the big side first.
A similar problem arose in the world of computer science. When storing a multi-byte value, do you store the big portion or the little portion first?
Number of Blocks
The name of the block. This becomes the attribute name for detail or point blocks, and the volume name for volume blocks. For a zero block it is a useful way to comment why the block exists.
The source for the information for the block.
The block will be filled entirely with zeros.
The provided float value will be repeated throughout the block.
The provided integer value will be repeated throughout the block.
The detail attribute matching the block name will be saved to the block.
The point attribute matching the block name will be saved to the block.
The volume matching the block name will be saved to the block.
The expected size of the detail attribute, point attribute, or tuplesize of the volume.
The type of data stored in this block.
Floating point values.
How many bits to store for each value.
For integers this is an unsigned value from 0..255. For float, the unsigned value 0..255 will be fit to the floating point values 0..1.
For integers, this is a signed value from -32768..32767. For float, this is either binary16 or bfloat16.
For integers, this is a signed 32 bit value. For float, it is a binary32 floating point representation.
For integers, this is a signed 64 bit value. For float, it is a binary64 floating point representation.
The usual 16-bit float representation, often called half, is binary16. This is used by OpenEXR and OpenVDB and internally in Houdini as a way to store floats in less space by reducing both the range and the precision.
BFloat16 is a truncated version of binary32 where the range remains unchanged, but the precision has been reduced to a mere 8-bits. This is commonly used in machine learning.
Collate with Previous
When a point block is saved to disk, it could either be interleaved with other point blocks or form its own contiguous block. If it is not marked as being collated, it will save its own contiguous block (possibly including any successive blocks that are marked as collated) If it is marked as collated, all the blocks that are collated together will be written in turn for each point before going to the next point.
Similar to endian-ness for binary numbers, there is disagreement about whether volume data should be X-axis first, or Z-axis first. If you are reading volume data, you need to set this based on the convention used by the program that created the data.
The Z-axis is the outermost loop. Consecutive elements in the file will be consecutive X-values. This matches Houdini’s internal Volume layout.
The X-axis is the outermost loop. Consecutive elements in the file will be consecutive Z-values. This matches OpenVDB’s internal volume layout.
For float blocks, this value is written tuplesize number of times.
For integer blocks, this value is written tuplesize number of times.
Create Intermediate Directories
When turned on, creates intermediate parent directories for output files as needed. Currently only applies to generated scripts, images, and shadow maps.
Initialize Simulation OPs
Forces all simulation OPs to be reset. This includes DOP Networks, POP SOPs, and other OPs that cache their results.
This is the safest way to render out a simulation, because it starts the simulation from scratch and discards any partial simulations you might have done with different parameters.
Alfred Style Progress
A percentage complete value is printed out as files are written. This is in the style expected by Pixar’s Alfred render queue.
Report Network Use
The number of bytes sent or received by the distributed simulation primitives during the cooks triggered by this geometry output is printed.
This does not track use by, for example, saving a file to an NFS mount. It only tracks the network communication of nodes such as the Gas Net Exchange Border DOP.
If saving the geometry to disk fails due to a disk writing error, Houdini will usually error the output node immediately. This is desirable for most cases where a failure to save means an illegal path, which is not recoverable. However, sometimes files fail to save due to network issues. If the number of save retries is non-zero, Houdini will re-attempt to save this number of times. Each time will be accompanied with an output to the console of the failure to save and a five second wait in the hopes that the network will clear up.
Save in Background
When saving more than one frame, save in a background thread. This can make saving faster for large file sizes, but may use more memory since it will retain the output geometry until the save completes.
A script command can be specified for execution at various execution points. The expression language selected for the script parameter determines whether the command is in hscript or python.
Prior to execution, this node is automatically set as the global current node.
To run statements from a file, specify the path to the file with
.cmd extension (when the language is set to Hscript) or a
extension (when the language is set to Python). Additional arguments to the
script can also be supplied. They will be parsed in a shell-like manner.
Run this script before any rendering.
Run this script before each frame.
Run this script after each frame.
Run this script after all rendering.
Run this HScript after each frame’s data has finished writing to disk. This is always after the corresponding Post-Frame Script and always before the Post-Render script, but the order otherwise is undefined. When Save in Background is enabled this allows delaying script actions until the file has finished saving.
Frame being rendered.
Total number of frames being rendered.