Rendering an HDRI synthetic sky texture

[Mauritius]

Render an HDRI map that represents the sky, and then use that map for HDRI lighting of an outdoor scene.
[...]
Using Maya, and having at your disposal Mental Ray (if necessary) and in my case, doing the final render via 3Delight (a Renderman compliant renderer), what options are there - as in plugins, Mental Ray's sun/sky sim, etc.
Since you already use 3Delight, spending some time reading its manual might be worth your time. ;)
3Delight's tdlmake utility has a -skymap option that generates a HDR environment texture of the sky at any time & location on earth (basically what some renderers call a 'physical sky').
The parameters are as you describe. It doesn't do any clouds. If you need clouds, check out Cloudwright (http://simul.co.uk/cloudwright).

.mm

[jupiterjazz]

Since you already use 3Delight, spending some time reading its manual might be worth your time. ;)
3Delight's tdlmake utility has a -skymap option that generates a HDR environment texture of the sky at any time & location on earth (basically what some renderers call a 'physical sky').


Exactly,
for very lazy people here is the part of the docs Moritz refers to, you can find it also online (and it's also in one of my second batch of upcoming video tutorials):

http://www.3delight.com/en/uploads/docs/3delight/3delight_12.html#SEC17

tdlmake -skymap

Generates a latlong environment map that is a representation of a sky as seen from the given position and the given time.
The parameter to `-skypmap' is a comma separated list of six arguments specifying:

`latitude, longitude, timezone, julian day, time, turbidity'.


Ranges for each parameter are:

` latitude' ` longitude'
These two coordinates specifie the location of the observer, in degrees.

` timezone '
This is the standard time zone indicator. Starting at 0 and ending at 12.

` julian day'
Day of the year, from 0 to 365.

` time'
Time of the day. `6:30 PM' is `18.5'.

` turbidity '
This is a measure of "haziness" ranging from 2 to 10. A value of 2 will give a clear day and a value of 10 will give a very hazy skylight.

An example command line would be:

% tdlmake -skymap 42,74,5,10,12.5,4 daylight.tdl



The parameters are as you describe. It doesn't do any clouds. If you need clouds, check out Cloudwright (http://simul.co.uk/cloudwright).

.mm

Didn't know this one, coolness!

[Bryan Y]

Since you already use 3Delight, spending some time reading its manual might be worth your time. ;)
3Delight's tdlmake utility has a -skymap option that generates a HDR environment texture of the sky at any time & location on earth (basically what some renderers call a 'physical sky').
The parameters are as you describe. It doesn't do any clouds. If you need clouds, check out Cloudwright (http://simul.co.uk/cloudwright).

.mm
Thank you for the reply. It may be a solution.

I would like to point out though that I have read the manual and I was aware of that as an option (although I didn't recall it being able to render in HDRI mode). The one shortcoming I'm aware of with regard to that method is the fact that its haze is behind any clouds you render over the map, unless you can query the haze at each pixel - not to mention other atmospheric effects that would be better integrated with the dome rendering, as opposed to layered over it.

[Bryan Y]

If you need clouds, check out Cloudwright (http://simul.co.uk/cloudwright).
Cloundwright looks very cool. Thank you!

[Mauritius]

Thank you for the reply. It may be a solution.
This stuff is an implementation of the physical sky research paper most renderers base their's on as well. This paper didn't cover clouds. For diffuse stuff haziness is sufficient. Clouds are needed if you want to use this as a backdrop or for specular reflection of course.
I would like to point out though that I have read the manual and I was aware of that as an option (although I didn't recall it being able to render in HDRI mode).
There is no 'HDRI mode'. This is a buzzowrd anyway as soon as you're rendering float. Then anything is "HDR". The -skymap generates a float image. :)
The one shortcoming I'm aware of with regard to that method is the fact that its haze is behind any clouds you render over the map, unless you can query the haze at each pixel - not to mention other atmospheric effects that would be better integrated with the dome rendering, as opposed to layered over it.
You can easily switch haziness off when generating them map and then use a tweaked standard fog atmosphere shader, you get what you want. There's also a very good RenderMan Earth atmosphere shader available as part of the source for the 'Texturing & Modeling' book (this source is available online freely).

.mm

[Mauritius]

'timezone'
This is the standard time zone indicator. Starting at 0 and ending at 12.
This is bollocks of course. Timezone is from 0 to 23. Looks like they forgot to fix this in the docs again for 7.0. :)

.mm

[Bryan Y]

There is no 'HDRI mode'. This is a buzzowrd anyway as soon as you're rendering float. Then anything is "HDR". The -skymap generates a float image. :)
Ah, but I beg to differ. An image is only HDR if it has a realistic gamma mapping of light intensity across the range of 0.0 to 1.0. Mostly what I'm saying, is just because an image is saved out as floats does not mean that it conforms to a usable HDR gamma mapping. If you can confirm that it does, that'd be great...

[Bryan Y]

There's also a very good RenderMan Earth atmosphere shader available as part of the source for the 'Texturing & Modeling' book (this source is available online freely).As it happens, I recently purchased that book and I've been meaning to investigate that further.

I also just purchased the Cloudwright program, but my Windows machine cannot support it (at the moment), and the program won't run on my Mac machine (I suppose I should configure Windows under Fusion on the Mac).

Lots of possible solutions here, but as usual, it's hard to find a great out of the box solution, and instead some sort of pipeline needs to be built.

[Mauritius]

Ah, but I beg to differ. An image is only HDR if it has a realistic gamma mapping of light intensity across the range of 0.0 to 1.0. Mostly what I'm saying, is just because an image is saved out as floats does not mean that it conforms to a usable HDR gamma mapping. If you can confirm that it does, that'd be great...
What do you mean by "realistic gamma mapping"? What has it got to do with the range? What on earth is a "usable HDR gamma mapping"? You might beg to differ but what you say makes absolutely no sense whatsoever to me.
So no, I can't confirm it. :)

Most HDRs store linear intensities as float data. Which is neither to say they need to store them linearly nor in float, to qualify as HDR.
Upon display, such linear data would likely be fed through some sort of tone mapping & color correction to match the display capabilities of the target display and viewing entity (likely a human). But again, this doesn't mean you couldn't have a HDR that stores values which have undergone some sort of gamma correction already for display purposes. You'd then have to store this gamma with the image data of course to make it useful in other contexts (i.e. lighting/rendering).

However, I never heard of this being done. Which is why it is a fair assumption that float data stores linear intensities.
On the other hand, if you could point us to any definition of the term HDR that contains any constraints on gamma to back up your point, I'd be thankful. I for sure couldn't find any. ;)

.mm

[joie]

Did you try HDRShop and his skymap generator plugin? :)

[3delight]

Hello,

Ah, but I beg to differ. An image is only HDR if it has a realistic gamma mapping of light intensity across the range of 0.0 to 1.0. Mostly what I'm saying, is just because an image is saved out as floats does not mean that it conforms to a usable HDR gamma mapping. If you can confirm that it does, that'd be great...

I think there is some innacuracies in there :) There is a mixup between the HDR data format, the actual image data and the gamma correction.

Firstly, the gamma correction can be extracted out of the equation since it is not directly involved in the subject. What you probably mean is that high dynamic range images can potentially have much more precision in blacks so that appropriate gammas can reveil details that were unseen on low dynamic range displays at other gammas. But for this to be true, the image has to be properly rendered/pictured: using an HDR data format to store a low-dynamic range image doesn't add any range to that image, although further processing on that same image will certainly benefit from the underlying HDR data representation.

Then, an HDR-enabled data format (such as floating point TIFFs, LogLuv tiffs, radiance and openEXR formats) is a data format designed to repesent images containing both very dark and very high color values and have a good decimation where it matters (In rendering, there is no need to have dense decimation in the super bright values for example), and using a finit number of bits :) Of course, you want to minimize the number of bits used (to save space) while still having a very useful range. The formats I mentionned above all make compromises in some areas.

An interesting lecture (especially the two references at the end of the page): http://www.anyhere.com/gward/pixformat/tiffluv.html

-- 3Delight

[Mauritius]

I think there is some innacuracies in there :) There is a mixup between the HDR data format, the actual image data and the gamma correction.
There is also the use of the term "HDR" in contemporary digital photography that Bryan might have been referring to. In this context no assumption about gamma or the like can be made anymore whatsoever.

It mostly refers to pictures created by manually or semiautomatically, locally blending multiple images of the same subject, shot with different exposures.

See e.g. this flickr set (http://www.flickr.com/groups/japanhdr/pool/).

However, I'd argue these people kind of abuse the term as it was defined by the scientific communtiy a long time before they started doing these things.

.mm

[DrYo]

I thought High Dynamic Range simply meant the ability to reproduce a greater range of intensities than possible with 24-bit images.

If I remember correctly, a 24-bit RGB image has a latitude of only about nine f-stops.

[3delight]

Hello,

I thought High Dynamic Range simply meant the ability to reproduce a greater range of intensities than possible with 24-bit images.

Well that is a concise defintion that would be correct if your replace "24-bit images" by "low dynamic range images" or something similar. Because we can very well define a 2 bit data format that has more "range" than our usual 24 bits format. Here you go:

bits colors
---------------
00 : black
01 : 1
10 : 100
11 : 10000

Of course this format is useless because it has no enough precision and operations on such a format become impossible (adding two images of value "01" leaves you with the choice of using "01" again or going to "10" which is many times brighter ...).

If I remember correctly, a 24-bit RGB image has a latitude of only about nine f-stops.

Well, in a 8 bit word you can represent the doubling of intensities 9 times:
0, 1, 2, 4, 8, 16, 32, 64, 128, 255. I am not sure though if we consider going from 0 (black) to 1 as one f-stop and I am not an expert in f-numbers ... :)

-- 3Delight

[Bryan Y]

Because my Maya/3Delight machine is not currently available, I have not been able to run tests, but to clarify what I mean by HDR and gamma mapping and the sky texture is this:

Using an environment light, as in the 3Delight examples section which employs a "light probe", one can render a scene using the light probe and due to the fact of the variation in intensity in the light probe, you can get shadows cast from the "hot spots" which are the bright points in the light probe map.

Now, if we use tdlmake to generate a skymap, assuming it renders the sun in the map (I cannot verify that it does render the sun in the map at this point in time because that machine is not available), then the map, if it is stored the way a light probe is, then with no changes in surface shader or light source shader code, we should get shadows from the sun in the sky map as we do with the light probe examples.

But, as I have indicated, I believe this depends heavily on the gamma mapping of the skymap texture.

In short, is the skymap generated by tdlmake just like a light probe as if we went out and did bracketed shots with a chrome sphere of the sky and generated a light probe?

[Mauritius]

Now, if we use tdlmake to generate a skymap, assuming it renders the sun in the map (I cannot verify that it does render the sun in the map at this point in time because that machine is not available), then the map, if it is stored the way a light probe is, then with no changes in surface shader or light source shader code, we should get shadows from the sun in the sky map as we do with the light probe examples.
Exactly. The skymap feature renders the sun or the moon into the map, if either would be visible given the time & location provided.
In short, is the skymap generated by tdlmake just like a light probe as if we went out and did bracketed shots with a chrome sphere of the sky and generated a light probe?
Yes, it is a "true" HDR map just as if you had taken numerous RAW files and combined them or numerous JPEGs and combined them (after taking the gamma aka "camera response curve" out of each).

.mm

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.