Anyone Using VrayHDRI for 8 bit maps?

[WimOos]

I am used to dragging bitmaps etc. from xnview into the map slots. Don't know how this happened, (i think it was a speed issue with loading maps over the network) but the nice thing is you can have all you textures visible and just drag the 1 you want into max. The vrayhdri does not allow you to do that, so you have to load maps from within dialog box. It would be nice just to drag and drop the maps into the vrayhdri slot.

[Deflaminis]

The big advantage of the VrayHDRI (to me) is the elliptical filtering mode which makes textures on oblique angles look much nicer than the standard map filter.

[Pixelab]

Hello, when using the script bitmap to VRayHDRI, does it keep the output rollout settings intact ?

Because we use a lot of curves on my bitmaps and don't want to lose those in auto convert

Also, does it behave well within a color correction ?

Finally, it adds an invert 0.4545 gamma, I guess that's because max bitmap loader loads it with a 2.2 gamma when working in linear, correct ? Or is ignored if you use you use the "3dsmax mapping" mode ?

[Pixelab]

Hello, when using the script bitmap to VRayHDRI, does it keep the output rollout settings intact ?

Ok, I made a mistake during my first tests, it does keeps the curve intact (I initially saw a flat curve but simply had to zoom because the range when from 0-1 to 0-10000... HDRI, of course)

[alexander.kazandzhiev]

Yes, there is no easy way of editing the output curves settings through MaxScript, so it just attaches the same instance to the newly created VRayHDRI texture. It's there since 3.30.01.

Best regards,
Alexander

[Joelaff]

We use VRayHDRI for everything. Got in the habit with 2014 because there was a bug that would randomly cause gamma issues with the Bitmap node.

The reasons to use VRayHDRI over Bitmap are manifold:

VRayHDRI supports elliptical filtering, which is far superior in almost all cases.

VRayHDRI supports tiled formats like tiled EXR or .tx which load only the tiles that are needed at render time, and keep them cached as needed. If you have large maps this is really helpful. The .tx format works with 8bit images as well, so you can have tiled 8bit images, and not have to convert them to 16bit half float as tiled EXRs. Note you can also use non tiled formats, and then the image is just loaded into memory. Note that when using tiled maps (or VRayProxies for that matter) you really want your assets on a local drive (ideally SSD). Using tiled formats or VRayProxies with your assets on a file server can bog things down a lot, and load up your server and network.

The VRayHDRI node also only loads a single bitmap once, even if you have multiple nodes. (Bitmap loads one for every node, wasting memory.)

VRayHDRI has some useful settings for gain and gamma, including the independent render mult (gain).

The only drawback to VRayHDRI is that it does not seem to update image sequence textures correctly in the view ports most of the time. To get around this we use a shell material with a VRayMtl node and a Bitmap for the viewport display, and then use the real material at render time. Shell materials have no measurable effect on render speed, either.

Maybe Chaos could take another look at this image sequence issue. I think they said it was a Max bug?

[super gnu]

im not sure if it is still an issue, but i remeber ages ago, when using vrayhdri, it would always treat all images internally as 32 bit.. meaning more memory usage for an 8 bit image as opposed to loading it with the standard bitmap loader.. this is all a bit vague, as it was ages ago.. and i cant find the specific thread..

[vlado]

im not sure if it is still an issue, but i remeber ages ago, when using vrayhdri, it would always treat all images internally as 32 bit.

This was a long time ago and is no longer an issue.

Best regards,
Vlado