After a discussion on the mailing list, here's a hip file to demonstrate how to do volume instancing with overrides per instance.

Here are the main lines
-A Material Sop set to “Point Attribute” has to be put in the Instance OBJ
-You must select what parameter you want to override on the shader and set the values from any attribute that exists on the sop.
-Create a Geometry OBJ with a small volume in it. Don't attach any shader to it.

The only downside I've found is that the python generation can be a little bit long when there are many particles.

Also, it's better to have a high res volume to save time at rendering. It looks like the renderer has less interpolation to do when it can query the value of a voxel directly. Anyone has a better explanation for that?

François

Also note that if you want to vary the density per particles, what I usually do is create an Alpha parameter on the shader, promote it to the material level so I can use the override mechanism. Then I multiply the incoming density attribute directly by that Alpha parameter in the shader.

François

P.S.: I'd love to understand why the render can be very long when the scaling of each puff is too large. Could it be made faster by increasing the puff resolution to an insanely high amount.

Hi.

It could be that when you scale your “puff” of smoke up, you're effectively telling Mantra to cover much more area. As well when you have a scene of much thinner smoke, that'll take any renderer much longer to march through the volume field so to increase your render time. This is because Mantra (or your shader, actually) has to march through the density to figure out whether or not at this point density has reached its limit. The sooner Mantra can reach that density limit, the early Mantra can move onto other pixels.

Another factor that can help with your volume rendering speed is the step size. You can really think marching through your volume field like walking a straight line from point A to point B for 100 yard. If you take a much bigger stride, you'll reach point B much quicker. However, you're missing a lot of details in between steps. If you take a much smaller step, it'll take you much longer to reach point B, but you're covering a lot of detail. Of course, “covering lot of detail” in volume rendering as it's limit too. After a certain point, it's just diminishing return. So you'll have to strike a balance.

When I had to render a sky of cloud (in simpler case), I've had to set the step size to 0.5 or so to ensure the render will complete within reasonable amount of time, all the while was sufficient to get the necessary detail. But if the scale of my smoke was much smaller, say, within 10 meters, step-size of 0.5 might only be good for preview renders…


Stacking up volume primitives together could also mean more RAM usage as well… I think Mark Elendt had talked about this one on 2008 Siggraph.

Generally speaking (and for many cases), for particle based smokes, I still find i3d to be much more flexible… albeit it could use a major update to make it much more efficient and better, I think…..

Thanks for the info and I will try in more details the i3d to better know the pros and cons of each.

François

Hi Francoisd,

I have tested this couple of years back Now I am trying to re create and render houdini is crashing 16.5.268 (MAC OS high sierra). I totally forgot how to do material over ride thing. Thanks for the example. It deserves to be in example file. Works like a charm in 16.5.311. I am trying to create rocket trail smoke. I am thinking of instancing a disk cached volume with animated noise. Lets see how its going to turnout.

cheers