Recently I was helping a friend with a procedural modeling project, and she was wanting to place a ladder on the model in a procedural way. This brought up an interesting issue for her, as she was creating her entire object off of a root curve. She only wanted the ladder to be able to be placed around the perimeter of the object. I realized that if we used the root curve as the second input of a creep node, I would be able to have a single point follow the curve by varying the X position on the creep from 0 to 1. This allows for the position to be calculated as a % around the curve, which thereby allows the position to be set by a single parameter in the interface. Once you have the single point, which I created with the add node, creeping on the curve, you are able to use this point as a copy template point. The biggest thing to remember for orientation is that the polyframe needs to have the Normal creating an up vector and the Bitangent needs to be utilized for the normal. If the vectors are wonky after this, use first edge instead of two edges, but this will depend on the geometry. In the creep node you will need to check “Set Point Attributes From Path” and make sure that the point attributes are all copied.
This works great for one point, but what if multiple are needed? This is actually rather trivial it turns out. Instead of using the X offset in the creep node, if you instead add more points in the add node, then offset their individual X positions between 0 and 1, you can set each one of their % around the path independently, then use the creep offset to shift all of them together.
Hope this helps and good luck with your projects!
For those just starting off with Pyro you realize really quickly that cache sizes can really quickly get out of hand. I have personally seen .bgeo.sc files that have exceeded 1.5gb per file. This can really put a damper on how detailed we are able to make our simulations, so how do we make really detailed sims and not lose all of our hard drive to a single sim. Here are a couple of tricks for H15 that I have found to get the file size down to a really manageable level.
- Use a file node after your import_pyrofields node in the pyro_import node instead of caching from inside of the simulation or from the import_pyrofields node itself. This will allow you to use a couple of the following tricks.
- Uncheck any fields that are not directly needed for your purposes on the import_pyrofields node. These checkboxes are found on the Import from DOPs tab, in the Fields tab. One of the biggest ones here is the vel field. If you are not using your simulation to drive any other geometry or particles, you don’t need to store the vel field. The reason for this being such a huge savings is that you are eliminating a vector, or 3 float values, from each voxel. To put this tip into perspective, in a large, detailed sim, you can easily have more than 6 million voxels. Each of these voxels stores data for each field included, which will amount to 6 million float values for each frame. If each number is a 128-bit number, that equates to roughly 96MB per field per frame. Triple that for the vector fields like vel. To run the pyro shader, you usually only need 3 fields; Density, Temperature, and Heat. So if all you are doing is making an amazing explosion, you can turn all but those off. If you are only making smoke, no fire, you only need the Density, field, so you can make those simulations incredibly detailed and still have space on your hard drive.
- Delete any unneeded attributes from your simulation. This is a good tip in general before you cache out geometry, be it volumes, points, or primitives. Extra attributes that are stored take up space for the same reasons that the fields do. So remove them, and watch your file size plummet.
- Convert your volume to a VDB with a Convert VDB SOP before saving. This will force Houdini to use VDBs to store and load the data, which are much more efficient at managing data than the standard voxel model that is used to simulate on. The voxels are more efficient for that, but once the calculations are done, they are no longer needed and take up quite a bit of space.
- There is an option on the import_pyrofields node for compressing fields, I have not experimented with this in my workflow just yet, but I plan to soon, so I will update this trick if it helps as much as I hope.
These tricks are all things that I figured out while working on my Pyroman and Ink projects. In both cases the cache file sizes were exceeding 1.5gb/frame, which was untenable with the storage space limitations that I had. Utilizing these steps I was able to get them down to right around 200MB, a 1:7.5 reduction!