Cycles HDR texture support

I haven’t finished a patch, but I forced Cycles to store all textures in RGBA float format to see what the difference was for environment-lit scenes. I thought you all might be interested in seeing this.

The other thread on my Cycles patches was getting…long. Time to break these up. :rolleyes:

Here’s the before/after. Details in the post.

By the by, for all the drive-by observers, that was only 100 paths/pixel. The brighter lighting obviously contributes some noise, but this didn’t take long to render and there’s plenty of budget room for more rays to knock down the noise. :wink:

http://www.zoopedup.com/blogs/uploads/facebook-like-button0.jpg
http://www.guaronomics.com/images_guaronomics/main/google1.jpg
http://icons.iconarchive.com/icons/famfamfam/silk/16/award-star-gold-2-icon.png

:wink:

Does it incorporate in the color management already?

Yeah, all the sRGB stuff and whatnot is in there, although applying sRGB to HDR data is a little odd. It does work though.

Update: I tried the grace cathedral in sRGB mode, and it totally blows out the top light and drops the other stuff down by attempting to unapply a (non-existing) gamma on the image. So…don’t use sRGB mode unless you know your texture already had an sRGB profile burned in. For HDR textures, usually you want linear color space, and you want to apply color space transformations to it before you even use it for rendering.

That is a huge difference! An UI option for textures (to choose between HDR and LDR) would be best I think. :slight_smile:

Great work Mike!

Just made a donation; thanks for your support, Mike!

wow, it’s like day vs night comparison, incredible work!

OK,
what about this hard shadow casting? Where this came from?
sRGB for environment lighting is odd. Use linear, always.

A few small very bright spots in the env map cause the harder shadow edges. With HDR range the importance sampling is able to focus on those spots more, as it should. Those hard shadows are actually correct, as far as I can tell. (There’s a 200000 to 1 ratio of the brightest value to the darkest value in the env map…it’s a tough one, which is why I use it during development.)

So amazing difference! Like DingTo, i vote for an option to switch between HDR/LDR, i’ll use HDR all the time i can any way :slight_smile:

@michalis the shadows came from the light point represented the background texture! not a lamp!

That is really awesome! Nice work Mike :yes: And thanks for the info about the color space modes :smiley:

A few small very bright spots in the env map cause the harder shadow edges. With HDR range the importance sampling is able to focus on those spots more, as it should. Those hard shadows are actually correct, as far as I can tell. (There’s a 200000 to 1 ratio of the brightest value to the darkest value in the env map…it’s a tough one, which is why I use it during development.)

Wow!
I see now. Awesome job.

I tossed a patch over to the Cycles mailing list that is a stopgap for dealing with HDR textures. It siphons off 5 texture slots and makes them floating point texture slots only, and detects textures that use half/float/double internal format when loading them to stick them in the proper slots. If anyone gets a chance to build with the patch and give me feedback, that’d be much appreciated.

Could someone please make a build with Cuda for windows? :slight_smile:

So if cycles couldn’t handle floating point correctly what kind of impact was that having on renders that used 16bit or 32 bit per channel displacement maps.

The 16/32bit per channel displacement maps were being mapped down to 8bits whilst being transferred to the gpu, which means your going from your nice float exr to 8bit tga quality…

too slow.
doublebishop wins I guess :smiley:

However, are you sure its reduced to 8bit integer?
I don’t see why it should matter for displacement if the image has float or integer.

The vertex coordinates and the normal vector surely are stored as float.
Why convert the displacement float to a integer and displace a float by an integer multiplied with a float (influence)

That’d make no sense and would be a complete slap in the face of software development.

@Mike, Just wondering how hard it would be to open up the use of using alpha channel as an output to the image texture node in the node editor?

Here are Win builds with Cuda. (for 1.3, 2.0 and 2.1)

Win32
Win64

I’m not sure. That’s one area I haven’t dug into yet, is messing with the nodes on the Blender side (as opposed to the Cycles code itself).