High Dynamic Range Images formats for VrayDisplacementMod

[noel_d3]

That would be good if the VrayDisplacementMod could work with high dynamic range images,

3ds max already makes it with his displacement (a little as a push map)



Vraydisplacementmod already accepts HDRI but seems limited or clamped



if the VrayDisplacementMod could work with HDRI that would incite the softwares such as Z-brush or Mundbox to export images of displacement in the HDR formats like radiance ( .hdr ), OpenEXR (.exr ) or tiff with 32 bits not only 16 bits.
I think that that could be although Vray is the first engine to accept them that would make it possible to render displacement with much more detail.

Best regards,

Leon

[Syclone1]

what would be the advantage of using HDR images for displacement?

[instinct]

the by far increased precision and depth you could visualise. in a default grayscale 8bit image you have exactly 256 different height values possible....in 32bit float you got...well...a lot more :P

[Pixelab]

256 is not enough ?

[panthon]

I dont really see the benefit of using hdr as displacement maps. From zbrush you can export 32 bit images, but i would say 16 bit are more than enough in most of the situations...It's a matter of creating a big displacement map if you need such detail. As far as I know people tend to break the process in two stages: displacement map for the big indentations and bump map painting for surface microdeformations, as pores and such. So, displacement shouldn't deal with super extreme micro bumpings, as it is a waste of rendertime and memory consumption...

[instinct]

Actually i dont see the benefits too much in micro stuff, but in the BIG things....for example you could create a complete site if you get 32 bit dem data and it would be rather accurate terrain then. Without a single poly

Thorsten

[vlado]

Because of performance reasons, the maps for the 3d displacement mode must have some bounds which are known in advance to V-Ray. Currently, it always assumes that the maps are between black and white. Of course, a parameter for manual control of these min/max values can be added. Note that 2d displacement does not place any bounds on the displacement, since it presamples the displacement map anyways and can figure out what is the min/max value itself.

Also, note that the .hdr format does not offer any more precision than regular LDR 8-bit file formats. This is because in the .hdr files, each color component still has only 8 bits of precision. If you really want more precision, you should use a file format with either 16 or 32 bits per channel.

Best regards,
Vlado

[instinct]

so if i input a floating point 32bit tiff, or a floating OpenEXR, will Vray take advantage of the additional precision already ?

Thorsten

[mike.edel]

i only know that it works with 16bit depth
that would be 65536 discrete height steps
or one meter steps if your terrain is 65536 meters high
i guess thats enough for most cases

btw: for steep terrains you can clearly see that 8bit are not enough, you can even see banding and steps in normal terrain in some cases (very smooth gradients tend to show banding at 8 bit greyscale)

i tend to use 16bit png files in those cases...

[vlado]

so if i input a floating point 32bit tiff, or a floating OpenEXR, will Vray take advantage of the additional precision already?

Yes, since internally the displacement always works with floating-point values. However, for real 32-bit floating-point textures you need 3dsmax 8.

Best regards,
Vlado

[samuel_bubat]

@noel: What you could try to achive the effect you were requesting.
(I´m not shure if it works !!). Load your HDR in HDRShop.. use the "-"
key on your numpad to turn down exposure until there are not overbright/
bleeding areas anymore. Now select "scale to current exposure" from
the Image/Pixel dialogue. If you move you´re mouse over the image
all colors should now be below 1 (1 is a LDR white in HDRShop).
HDRShop shows the color values in the bottom bar.
So now you should have a HDR that colors values are not above white
so vray should not start to clamp. But because it´s still a floating point HDR
all the inbetween values should still be preserved. All you have to do is
raise your displacement "amount" value... presuming the whole idea works at all

I made some test with HDR´s and displacement in the past..wich shows
that HDR´s produce a much smoother results than LDR






cheers,

sam