Using DCM Holdouts with Volumes

[houdiniJD]

My question is essentially this:

Is there a way to terminate a ray that is marching from the camera using a holdout in the same way a matte object would? - The performance of my renders seems consistent in 'enclosed' spaces or wide open sections.

Some background to the situation.

I have been using houdini for a while, but have only just started to dive into Mantra rendering. I am rendering a large sequence where the camera is moving through lots of subtle volumetric dust.

I have set up a HOLDOUT pass containing all the static environment geometry and modified the billowy smoke shader to multiply the colour, opacity and alpha by the shadow map sample value. This works correctly and as long as I have good enough settings for my DCM file, the holdout lines up with the beauty render.

However, I fear that the performance isn't as good as it could be. By using the holdout in the volumetric shader the opacity stops increasing when the ray reaches the samples isolated by the DCM file. It feels as though the ray would continue searching for more samples through the holdout, effectively marching until the edge of the volume or the clipping plane is reached.

- I have the camera clipping plane as tight as possible

- I am clipping the volume using a dynamic bounding box around the camera

- In the BillowySmoke shader I have tried mult'ing the density to 0 before the (IS_DENSITY_0 test) to skip large chunks of the shader

A second question. Has anyone done lots of testing of the 'hidden' holdout settings to find an ideal tradeoff between quality / file size. I had to render using at least 3 pixel samples (the final map is not filtered, so the files can be quite big!, or the quality was unacceptable.

vm_dcmcompression - At 2K, with settings below i was getting file sizes from 350meg down to 60meg. I left this at teh default of 5

vm_dcminterpolation - The default is discrete, but i was trying continuous to see if it helps with mblur

vm_dcmdepthmode - I am currently trying midpoint, but the default was closest surface

vm_storage - Increasing the Z Bit depth didn't make a massive difference to the filesize, so i guess compression is removing any variation

vm_zbias - I have set this very small to force more accurate details.

I am in the process of setting up a hipnc example with worst-case geo, but if anyone has any ideas, or things to avoid then any help would be appreciated. Would having the compression set to 8, 9 or 10 make a perceivable difference? If i get any useful images or renders, it might be something handy for the WIKI.

cheers

JD

[Macha]

Hey Jonathan, I've only briefly ran over this post but my first thought is whether dpz in the shader would be of any help?

Another thought would be in the creation of your holdouts. Could they effectively be extended along the camera rays on creation time so that they extend infinitely ( to clipping plane).

[houdiniJD]

Hi Marc

Cheers for your response. I am not sure what you mean by dpz. Are you referring to some sort of deep Z depth shader trick or a deep shadow map rather than a deep camera map. Are there any differences between DSMs from the camera and DCMs?

I have been trying various switches to force the opacity and the alpha outputs for the volume shader to equal 1 (to force the ray marcher to stop considering any more samples - based on the opacity limit) as soon as the volume shader is accessing the heldout region.

I can get the render to speed up massively and render something, but the result isn't quite right, so I am not sure what is going on.

I think i need to set up a test scene that I can post, and measure the render times. Maybe I need to use another shader as the basis - I'll start taking a look at something simpler to see what I get out.

== Extending the Holdout Depth ===============

I don't know if extending the depth of the geo would give me a different result as, as far as I know, when the holdout is accessed (via the shadow map vex command or node), the samples beyond the point that the opacity hits 1, stay at a value of 1. Because the opacity accumulates, the last Z/opacity value for a particular camera ray would be the point at which the surface becomes 'solid'. I will give it a go though, in my simple test case, to see if the rendering times vary.

http://www.sidefx.com/docs/houdini10.0/rendering/deepshadowmaps

I am not sure if I am even experiencing a problem - it just feels as though the renders are slower than they could be.

= Pre-Multing the Opacity ===============

The way I have things set up at the moment, I am essentially rendering a largeish volume and then post mutiplying the areas that I don't wish to see. Ideally I would like to get in at a lower level and tell the ray to stop when my holdout says so. Essentially pre-firing a ray to measure the max-length and then marching until the opacity hits 0.995 (the default max opacity), or the max length.

== Procedural Volume Octree ================

My volume is being procedurally generated from a CVEX shader. I also tried using the shadow-map call to the holdout at this level. Hoping that the procedurally generated volume would have the large areas that are 'invisible' culled at the procedural volume octree generation stage. I am not sure this is having any effect as I get no differences in the viewport. I feel that this maybe related to my 'toNDC' call, which would use the render cam at render-time, but I guess it is undefined in the UI. Trying to use the alternative function that allows me to specify a camera throws an error.

I have the octree depth for the vol procedural set at 64. Trying higher values seems to slow things down - I guess the pre-processing becomes the overriding factor.

I am using Houdini 11.0.723

Thanks again for your ideas

JD

[houdiniJD]

I haven't tested this yet, but it looks like the vm_background image will work with a deepshadow / deepcamera image to matte out the unwanted volume.

I will try a performance comparison to see if this speeds up the calculation dramatically - like it does using actual geometry as a holdout. If this works, then this is exactly what I was looking for.

It looks like only a single image can be specified, but with the DSM merge node, mutiple DSMs / DCMs could be combined before the render.

In my case I have a set of geometry that I don't expect to change, and some FG geometry that is animated, and changing regularly based on client feedback. Having a merged DSM file means that I can re-render only the portions that have changed and merge the latest files on disk before my beauty render.

If I notice anything odd in my testing, i'll add it here. I was approaching the problem the wrong way round. I even tried creating a volume matte object to cut out my actual volume.

cheers

JD

[nMolson]

Did you ever get this working? im trying the vm_background with both DCM and DSM rats and the "background image as Matte" option but im not getting it to hold out my volume. Not sure what im missing..

It seems to work if i load the DSM into the camera background but id rather have it in the ROP so its only applied per render

Edited February 20, 2013 by nMolson

[fieryspoon]

I'm also interested in this.  Did you ever put together a worst case geometry file? :-)