Hi,

I am trying to add the billowysmoke shader to a volume node and all I am getting in the renderview is a pixelated box. I have added a spotlight and changed the shadows to depth map shadows for a better look but I still only getting a pixelated box.

I am not sure if I have just missed something in the parameters which is making it do this or something? Any help would be great, thanks.

File attached.

Here is what I am getting in the render view.

Try increasing the pixel samples under mantra > properties > samples > pixel samples

Juan

Wow, Thanks Juan,

I think this has fixed the problem now.

I also found that the “do noise” within the billowysmoke shader was not ticked which also helped solve the problem.

Sam

Glad it helped

IPR in preview mode always uses the raytracer. Your Mantra ROP Output Driver is set to Micropolygon rendering which is the default when you don't create the output driver but just dive in to ipr and hit render (which creates the Mantra ROP for you).
For a square box of fog, go with raytrace or the PBR render engine (might as well go PBR here).

Yep increasing the Pixel Samples cleans it up but you should also bump up the Transparent Samples from the default of 1 to at least 2 or 3 on the Mantra ROP. Note that Transparent Samples are only used by the Raytrace and PBR render engines.

When you render with PBR, you should set your ipr and mplay gamma setting to 2.2 at the bottom right. This will reduce noise and set up to light in a linear fashion (brightens the darks and accounts for the monitor's 1/2.2 gamma display curve). Should always set gamma to 2.2 when using PBR.

For fun, enable light scattering within the volume by changing the Volume Limit from 0 to 2 on the Mantra ROP. With this you will get more noise but this noise can be reduced by setting the Noise Limit lower, say 0.035 or 3.5%. The render times increase but the volume will take on a more realistic look.

Thanks Jeff I am starting to get more a realistic look now.

I followed all the steps you mentioned but I got stuck at the ipr and mplay gamma settings. Do you mean the colour space from linear to gamma 2.2? I had a look at your file and couldn't see where you had changed the gamma.

Thanks

Sam

The gamma setting is in the colour adjust toolbar at the bottom of all viewers in Houdini, including the default hidden color correct toolbar in the viewport which can be exposed by accessing the menu in the upper right viewport (the left yellow text beside the camera text).

It's identified with the icon that is a gamma2.2 curve on a graph. Just type 2.2 in there.
Beware that if you choose to work in a linear colour space workflow, you need to adjust all texture maps used for colour assignments in surface shaders such as diffuse and reflect require a colour correction gamma 1/2.2 colour operation. (this includes jpegs and any file output by Photoshop including tiffs, exr's that by their definition should be saved linear but not by Photoshop…).

I always change the presets for Colour in Houdini. If you wish to do the same, go to the
Main Menu > Edit > Color Settings…
and in the pop-up dialog, go to the Color Correct tab, set the top field to 2.2, check everything below and press both Apply and Save Default.

—-

Rendering with PBR (and most everything in general in any application) should be done in a linear colour space. Why? Because monitors and the OS that drives the monitors have an inherent 2.2 gamma response that causes darker regions on software UI's to display correctly.

But what about imagery? Well because the monitors have boosted blacks to render our software interfaces correctly, imagery that you create will have darks that are brighter than you thought as the pixels you paint are being affected by the display's 2.2 gamma curve. Trust me when I say that Photoshop does NOT do anything in this area by default. What you see is what you get.

This means that colour that you see on the monitor is arguably visually correct but the image that drives the colour that you see must be colour adjusted with a gamma of 2.2, or boosted blacks in order to display correctly.

This is not an issue in print and the web but for us, as cg artists that work with light, who use a render engine need to worry about this at some point in our career.

The real issue is not dialling in your lights to look good at a brightness level of 1, but to be able to expose the image at different stops (doubles or halves of brightness like a real camera does) and have the image linearly brighten or darken across the full visual colour range.

If you work with the gamma set to 1 you can create beautiful imagery. No denying that. You can certainly artificially and instinctively boost the lights to counter the 1/2.2 monitor response which is holding down the darker regions which ultimately exposes more noise. You just brighten until the darks become less darks but then the brighter regions become more exposed exponentially so because of the 1/2.2 gamma response of the blacks. So you reduce the diffuse component of your surfaces. Then re-adust the lights, then the shaders, then the lights, argh!

This is a shell game. There are countless tips on-line that show you how to brighten an image in Photoshop and it is all screwed because all you really need to do is apply a gamma 2.2 to the image, hold your breath and brighten, then apply a 1/2.2 to see the correct result.
In essence by setting the display gamma to 2.2, you are boosting the display of the darker regions so now if you increase the brightness of a light, the entire image will brighten linearly and naturally but you are post-correcting the display to account for the monitor response (and it's difficulty in rendering the darks).
This is a gross simplification as there is the eye's light intensity response to take in to account but for this explanation, simple is better for now.

Without applying a gamma of 2.2 to the display, you will be fighting lights and diffuse shader values for everything.

—-

As you work with PBR, you want to bump up physically correct lights in stops along with the exposure of the viewport in brightness stops. That's why there are the +- up/down stops beside the brightness bar in the ipr and mplay viewers.
When I light with PBR these days, I am always increasing and decreasing physically correct lights in stops (double the value for up and half for down). Works wonders. No wonder Katana has stops on hotkeys for selected lights when working with Arnold. I get it. In spades ‘cause it works.

Again the big gotcha is you need to colour adjust all your texture maps that are used in any shader colour operation (diffuse, specular, reflection, refraction tints, etc) out of Photoshop and downloaded images from the web with a 1/2.2 colour correction operation in order to bring them in to linear space. If not then they will be brightening the lighter colours far more than the darker colour regions.

I hope you get this. There is a lot of info on working in linear colour space on the web but I want to tackle the big why for CG artists rendering images:
Working within a linear colour space allows you to brighten and darken physically correct lights and exposure of the final rendered image and see linear results where darks and lights brighten/darken the same amount. Period.
That’s more than enough reason to move over.
The details you can resolve in the darks and lights at the same time are amazing.

—-

Why Houdini and other CG software in general ship with a gamma of 1? Laziness I suppose.
You see up until about 8-10 years ago, most displays were only supporting 8 bits and you would render to 8 bit unless you were rendering finals for film to convert to cineon. Disk space was expensive back then and I mean buy-a-new-car expensive for just 10GB drives. Heck even Flame/Flint are STILL 8 bit so why go 16 bit? That was left for cineon files back then and their 12 bit log format (with the toe and shoulder lut files).
Then came tiff with it's 16 bit and 32 bit float support and now the standard OpenEXR with it's support for 16 bit half floats and 32 bit full floats.

Yes software vendors are slow to move off of old defaults.

Should Side Effects get with the times and fully embrace linear colour space and make it default?
I think you know what my answer would be.