Understanding Photometric and Radiometric units and their application to computer graphics

(Note: This post is 1st draft and will be updated and probably gain some figures and images, probably of gnomes.)

Or: "How to understand photo- and radiometry using only gnomes with basketballs"

Photometry. Ah.

The word alone have many people running for the hills. Going to the fine Wikipedia page in the subject isn't likely to clear things up much. Why so many units, why so confusingly similar, yet different, and how many candela is one lux anyway?

Even I - and I worked with this professionally for years - had to have this stuff gnawing on my brain for quite a while until I finally grokked it all.

I think a good 90% of the explanations out there simply lacks the ability to visualize the problem, or they start on a way too high level, mathematically speaking.

So we'll gonna make this really simple, and we're going to use gnomes and basketballs. But first we're gonna talk to per, and kick a candela out of the house.

Talking to our friend "Per"

If you ventured to the wikipedia page you've seen that many of the photo- and radiometric units is expressed in a this-per-that fashion (cd/m^2, lm/sr) ... lets let the meaning of this sink in, and lets take a familiar example to let it sink in.

Many people ask things like "how many candelas go in one lux", when the question has no answer. "But it's all light" people grumble.

Well, yeah, but It's like asking "how many miles goes into 20 miles per hour" - it absolutely makes no sense without additional information.

To fully understand this, we must study what we mean by saying "per" something. And lets take something familiar - speed - i.e. "miles per hour".

Location A and location B is 100 miles apart.

How many miles per hour? Well, we can't know yet. We need more information.

Ted drives the distance in two hours.

How many miles per hour? Well, now we can calculate it, but it'll be an average: 50 miles per hour.

However, Ted may have been at a rest stop for one hour, and drove the other hour at 100 miles per hour, and still make the same result. We don't know yet.

So while in one sense we can see "miles per hour" as an average, we can also, in a sense, see it as a miles as a function of time (hours).

I.e. one way to interpret "miles per hour" is to say that "how many miles had ted travelled at time T"?

The same goes for the photometric units. For example, lumen (lm) is a measure of power, but power going off in all directions. However lumens per steradian (lm/sr) is a measure of how many lumens go in a particular direction (Steradians is a measurement of an angle in 3D space).

Keeping this interpretation of "per" in mind, makes things a lot easier, and makes it easier to understand that just because you know the lumens, you do not necessarily know the lumens-per-steradian. Sure, you can infer an average, just like we did with Ted's speed, but without actual values, we can not say that there is a certain amount of lumen going in some particular direction.

If we do have values, however, conversions are possible, because just like you could measure Ted's speed every second of his journey, and sum up the distance Ted travelled that particular second, the result for the whole journey will be the distance travelled for the whole journey, so does the various lumen-per-steradian (lm/sr) measurement in all directions sum up (or, technically, the term is "integrate") to the total amount of lumens (lm)!

With us so far. Okay. Lets kick out a friend and explain why.

Kicking the Candela

Photometry and Radiometry is very much related. We'll get to exactly why further down, but lets make things simple for now, and say that the lumen (lm) and the Watt (W) are linked. If you know the spectra of the light, you can actually convert one into the other with a simple number, called the luminous efficacy. Whoah. Big word there. The key in that sentence was "know the spectra", though, since the efficacy is different for different spectra. But we'll get to that.

For now, just pretend the lumen and Watt are pretty much interchangeable. A good memory rule for this is that the luMen contains an M and an upside-down M looks like a W.

Now, a unit used a lot in photometry is the candela (cd). A candela is simply a lumen-per-steradian. We'll get to what that means in a second, but if you guessed "light in a particular direction" you are not far off.

The point is that even though cd is well used unit, it is more confusing to understand the units if we use it. It is actually much easier to understand the whole thing if we keep talking about lumens. Then, when it all sunk in, simply learn "cd = lm/sr" and you'll be golden.

A second reason is that on the radiometry side, there is no special unit for the equivalent watts-per-steradian. This makes the radiometry and photometry appear different when they really are not.

No, radiometry and photometry work the same way, it's just about how you weight your measurements. Simplified, Radiometry is about how much radiation (for example light, but not necessarily) there is. Photometry is about how much actual light there is, and how bright it appears to us humans.

So for now we'll just talk about photometry, but with the candela on vacation.

Sounds fair? Okay, lets introduce the gnomes with the basketballs.

How Gnomes Clarify Everything

Instead of talking abstractly about watts, photons, and whatnot, we'll use some much more imaginative imagery, just because it's more fun that way. If you ever find photometry boring, think of gnomes throwing basketballs, and all will clear up.

Imagine a candle flame. But instead of it emitting photons like in the real world, it's made up of a whole bunch of small gnomes, and each of the gnomes has a magic backpack of never ending basketballs. The gnomes grab basketballs out of their magic backpack, and throw them in all directions. Lets say the flame of the candle is about an inch high, so these are really small gnomes, and the basketballs are to scale.

Now if there is a hundred gnomes, each throwing ten basketballs per second in some random direction, this means that from this candle flame, a total of 1000 basketballs per second are thrown. (Also know this is done in zero gravity, so there is no basketball pile on the floor to worry about, basketballs travel in a straight line until hitting something).

So, the amount of basketballs leaving the entire light per second is 1000. To make this easy, lets leave out the "per second" part, and just consider a certain second of time... lets pretend the gnomes are only actually throwing for one second, and then stop, so we can concentrate on the number of basket balls and don't have to say "per second" all the time. It also saves me typing. I'm lazy that way.

Luminous flux (or power)

That which what we just measured is the luminous flux, or luminous power, in lumen. (Little Underground MEN throwin basketballs for one second, perhaps?). It was, to recap, the total amount of basketballs, from the entire light source (the entire candle flame, all 100 gnomes).

Many people are surprised by the fact that the lumen doesn't change by distance, having learned in school that light falls of by a "distance squared" rule.

This can be understood, because to "capture" a lumen (i.e. know how many basketballs in total are thrown) we would, in principle, have to put a bag around the whole contraption, capture the basket balls, and count them. No matter if we put the bag near, or far, the total gathered over this one second will be 1000. (The size of the bag will be different, though.)

But this was a total measurement. The whole light, in all directions. Lumen. Mkay.

Luminous emittance

What about light not leaving the entire candle, but a particular point on the candle? If the lumen measurement was a total for the whole candle, what about the amount of light per unit of area?

This is the luminous emittance, and is measured in lm/m^2 (lumen per square meter). Simplified, you can think about this as a measurement of how much basketballs one particular gnome is throwing, but in all directions at once.

Imagining a contraption to measure luminous emittance is difficult; You would have to rig up some form of sphere of sensors that exists in absolutely every direction, but yet only aim at one tiny point (one gnome). It's also not of such a large practical use.

Luminous intensity

Instead of considering what a particular gnomes i throwing, lets instead turn to which direction the gnomes are throwing the basketballs.

If we only care about the basketballs thrown due north (but by any gnome), we are concerned about the luminous intensity of the candle. I.e. the entire candle emits a certain amount of light in a particular direction.

The unit for this is lumens per steradian (lm/sr). Now since steradians is a measure of angle in space (if you imagine a normal flat 2D angle as a infinite triangle, imagine the steradian as an infinite cone).

Since any basketballs that started out going in a particular direction will continue to do so, any basketballs that were within this given angle when they started, will be within this given angle until they hit something.

So again, surprising to many, the luminous intensity does not change by distance! This can be trivially understood by a laser, which is basically a ruby crystal full of gnomes that are highly trained and throw their basketballs in exactly the same direction. The intensity of the laser ray is the pretty much the same for its entire length (although in reality it gets absorbed, scattered, and is never perfectly parallel to begin with etc, all of which we are ignoring here).

So: Luminous intensity is any basketballs in a given direction, and is measured in lm/sr (lumen per steradian). And yes, this is the "Candela" unit that we are ignoring for now, because when we write it as lm/sr it's much easier to remember that it is really 'light from some object in a given direction')

Luminance

Now remember how we contrasted the flux and the emittance as the former being from the "whole light" and the latter from a point?

The relationship between intensity and luminance is the same.

This is not just how may basketballs are thrown due north by all the gnomes. It's about how many basketballs are thrown due north by one particular gnome, i.e. "per unit surface area".

Since the "all gnomes in one direction" was lm/sr (lumen per steradian) the "one gnome in one direction" obviously is "lm/sr/m^2" (lumen per steradion per square meter).

Since we now understand the notation (and are avoiding the confusing "candela" unit) we understand that this means 'light from some point going in some given direction'. "How many basketballs is gnome 39 throwing due north"?

Amusingly, and still shocking to many people is that this unit too is stubbornly unaffected by distance. If something is a certain number of lm/sr/m^2, it is that at any distance.

But - I hear you yell - my mom told me when I was three that "light from a point source falls off by the square of the distance to the point source". Was mom lying?

No, she wasn't. Except of course that there is no such thing as a point source. Lets talk about

Illuminance

Now it starts to get interesting!

Lets stop for a second to think about those gnomes throwing the basketballs, and considering where these basketballs actually end up.... on some surface.

Illuminance is simply how many basketballs that hit a surface, from any old direction, over some given area. Since "basketballs in any old direction" was lumen, "basketballs in any old direction over some area" is lm/m^2 (lumen per square meter).

"Hey wait", you say, wasn't that "luminous emittance"?

Yes. True. The unit works out to the same, but the meaning is different (light is coming in, not going out). And while the emittance was pretty much useless and hard to measure, the illuminance is extremely useful and easy to measure:

- Draw a square meter
- Wait one second
- Count the basketballs
- Done.

As a matter of fact, this unit is so terribly useful they gave it their own name too. It's called "lux" (lx). But we'll stick with lm/m2 for simplicity, to remember that it's "basketballs in any direction, per unit area".

This is what you generally measure with your run of the mill light meter. Lux meters are readily available and used for a lot of things.

And now, finally, we are starting to get into the distance dependency.

The amount of lm/m^2 (= lux) received from some light depends on the distance to the light together with the lights emission profile.

"Ah" you say, "this is where the distance squared" comes in?

Yes. And... no.

Remember our laser? It most certainly won't follow the distance-squared rule, even when measured as illuminance, because it's light rays are (for all practical purpouses) parallel.

Same goes for light that come from a light that is - for practical purpouses - infinitely far away, which would include the sun.

"But" I hear you yell, "what about this distance squared thing"?

Well.... imagine a point light source. All gnomes, sitting throwing basketballs in exactly the same spot (those 100 gnomes will have it very very crowded). This means that all the basketballs will start at the same point, and fly in straight lines outwards.

Remember that figuring out the lm/m^2 (lux) was easy? Draw a square meter, wait a second, count the balls?

So lets draw a square meter on a wall one meter from our point light. A certain number of basketballs will hit it. Now lets move the light one more meter away. Since the basketballs all diverge from a central point, the basketball density will change as they move away from the light.

A square meter at double the distance will be hit by much less basket balls. As a matter of fact, it will - being 2 times further away . be hit by exactly 4 times fewer basketballs. Yes... distance squared... finally!

But please note this was only exactly true for a light that
- started in an infinitely small point
- emitted light exactly the same amount in every direction

Anything else is more complicated than that but can often be adequately approximated by a "distance squared" rule.

But lights are not infinitely small points, so there must be a different way to look at this?

Yes - there is.

Remember, "illuminance" was the amount of basketballs coming from all possible directions that hit a particular area, i.e. lm/m^2.

So, what if we summed up all the basketballs coming from all possible directions?

This would mean that we would have to look in every particular direction, look at the incoming light from that particular direction, and go over all possible directions and construct the sum (technically, the "integral") of it all.

Okay, so what is 'light from a particular direction' in this context? Is it the luminous intensity or the luminance? Both were "light in a direction"?

Well, we have to keep in mind that we are sitting at some given point, looking around. At every particular direction we look, we see some particular point on some object, which may or may not emit some light.

This means that what we are interested in is the light in a particular direction from a particular point. That was "Luminance", i.e. lm/sr/m^2 (luminous intensity was from the entire light, not just a point on it).

So we look in every possible direction. Most directions will see nothing, and some of those directions will see the candle flame. Now we said that our candle flames luminance was unaffected by distance. However, the distance to the candle flame makes it bigger (closer) or smaller (further). I.e. if it is closer, the candle flame covers more possible directions. The ratio of directions in which we see nothing to directions in which we see candle flame changes. So even though each particular "look" at the candle flame sees the same luminance, disregarding how close and far it would be, the number of "looks" that see it is much larger when closer!

(In tech speak, the closer object subtends a larger solid angle.)

This is what actually causes falloff from a lightsource. And funnily, for most moderate distances, an object twice as far away will show an area (subtend a solid angle) that is four times as small.... so the "distance squared" rule still holds as a good approximation!

Ergo: The illuminance at a point is created by integrating the luminances from all possible directions. For a flat surface, "all possible directions" is bound by a hemisphere above the surface (since the surface itself blocks the other hemisphere).

Now how do you look up "all possible distances" practically? There is an infinite number of them!!

Well, in a rendering context, such as, for example, mental ray's "final gathering", you do not look up an infinite number of directions, but you look up a set number of directions (this is what the finalgather ray count is!).

So final gather rays look around the scene and look for luminance samples, by simply probing the scene.

For direct light, the illuminance is calculated directly based on the lights luminous intensity (number of basketballs from the whole light in a given direction) and the distance-squared rule, because that is easier and more accurate for the renderer to do it that way.

So what about Radiometry, then?

All the photometric units (when expressed using lumen, and ignoring candela) has exact equivalents in radiometry, i.e. we have:

Radiant flux: W
Radiant exitance: W/m^2
Radiant intensity: W/sr
Radiance: W/sr/m^2
Irradiance: W/m^2

The principle is the same, and the basketball analogies work the same. As a matter of fact, the basketball analogy works even better on radiometry, and here's why:

There are different types of balls (wavelengths). There are balls filled with lead, so they are extremely heavy. And there are balls filled with helium, so they weigh nothing at all.

Radiometry is like we are counting the balls.

Photometry is like we are weighing the balls on a scale.

In Radiometry, a ball is a ball is a ball. In Photometry, it may be a heavy ball (green), a light ball (deep red), or a ball of no weight whatsoever (infrared or ultra violet).

... and finally bringing the Candela back

Also, as noted above lm/sr is the same as a candela. Generally, the units lm/sr are written as "cd" and lm/sr/m^2 as "cd/m^2", the latter being a value you probably hear a lot of as luminance measurement of all sorts of things. If you just keep in mind that "cd" means "lm/sr", you know now what that actually means. (Yes, basketballs from a particular point thrown in a given direction)

So what is computer graphics? Radiometry, or Photometry

Amusingly, it is both.

If you take a standard RGB color, you can see each of the R, G and B components as radiometric, but if you calculate the total intensity of the color (which are generally weighted at 21% red, 72% green and 7% blue) is photometric.

I.e. if you consider the white color (1 1 1) to have the intensity "1", then that intensity if photometric. (Had it been radiometric, the intensity of color (1 1 1) would have been considered 3).

Conversely, the actual R, G and B component can be considered radiometric.

Since a pixel value on screen can be considered a measurement of the light from a particular direction coming from a particular point, it means that a pixel value is a luminance (and each of the R, G and B values are radiances).

So the total value of the pixel will have some relation to an actual lm/sr/m^2 (= cd/m^2) value, and the value of each R, G and B component will have some relation to an actual W/sr/m^2 value.

The exact "conversion coefficient" depends on the application.

For 3ds max, the conversion factor between the total pixel value and the luminance in (cd/m^2) is the "physical scale" (found in the exposure control configuration) divided by PI.

Of course, the exposure control itself must be off or it will affect the pixel values. As a trick can be noted, that if you add an exposure control (but keep it disabled!) and set the physical scale to PI (3.1415) and render to a floating point frame buffer, the total pixel values reported when you right click on them (by the "Mono:" heading) are in cd/m^2.

/Z

mental ray Wiki

The folks over at mymentalray.com has launched a mental ray Wiki.

It's almost completely empty at the moment, but together we could load it up with a lot of mental ray info!

/Z

Max 9: Converting other materials to "Arch & Design"

If you want to have some cool tools for handling the Arch & Design material in Max 9 (including converting other materials - including vRay materials - into Arch & Design) you can use this script.

Save the file to your 3dsmax/scripts folder, and run it from the "MaxScript" menu.

Then go into the "Customize" menu and choose "Customize User Interface".

Go to "Menus", and on the left side open up the "mental ray" category.

On the right side, open up, say, the "Tools" menu (or any other of your choice).

Drag-and-Drop the "mr Arch Design Tools" to some cool place on that menu.

Voila - you have installed this nifty little add-on.

Note: A much simpler version of this script exists on the max 9 DVD in the sample scripts folder, but this variant is updated.

Enjoy! ;)

/Z

Clouds with mental ray sky

I keep getting requests from people saying things like "I saw you at SigGraph showing of the mental ray sky and it had clouds in it. How did you do that?".



To which I twirl my moustache and say, 'tis a deep secret....

....just kidding.

Here's the thing. The mia_physicalsky shader uses a 'haze' value to derive a sky color based on the sun position/angle. So a 'hazier' sky is more white/yellowish and a less 'hazy' sky is deeper blue. Okay fine, weather control, you say, but that's not clouds, is it?

Well... actually... it is... if you modulate the haze value across the sky!

Observe this video that I made... it's basically a collection of all test animations done during the development of the sun&sky. Some are bad, some are worse, some are nice, some has bugs in them, some use very low anti aliasing, and none is a peice of art. However they do demonstrate the cloud feature...

What I did was use this texture map (which is a slightly modified version of one I found from some old CD-ROM with public domain sky textures) as a spherical environment map plugged into the haze parameter of mia_physicalsky. That's basically it!

In Maya or XSI you can do this directly, in Max you need to drag&drop your "mr Physical Sky" from your environment dialog into the material editor, uncheck the "Inherit from Sky" and apply the map there.

What is important - though - is this; This is a normal run-of-the-mill LDRI .jpg image, which means it causes a "variation" in the range 0.0-1.0 ... this is way too little for being visible as "clouds" in the sky (the haze has a range of 0 to 15)

So to see results, you need to multiply the level of the texture. How you do this differs between the applications (in Maya you can use the Gain, in Max you use the Output rollout and turn up the RGB Level, etc etc) but setting it somewhere between 5 and 10 tends to look nifty.

Note that this is not a "physically correct" effect in any way, notably because it doesn't actually scatter light, or block light, or create any shadows, or anything like that. But it does simulate "light" cloud coverage very nicely (like high altitude cirrus clouds), and the cool thing is that the clouds coloring automagically follows the sun angle, making very nice sunsets possible....



/Z

Gnomon Workshop Skin Shader Tutorial

I just saw that the this very cool tutorial about my mental ray skin shader (good old misss_fast_skin), which I enjoyed very much, and I wholeheartedly recommend as a good tutorial on how to use the shaders.

Alex Alvarez has made an over two hours long video tutorial in three parts which can be downloaded from the Gnomon Workshop webpage. It's very informative and teaches many cool tricks.

A couple of details about the tutorial, though, that I thought was worth nothing:


Radii stuff

The tutorial started out by "trial and error" to find the various scattering radii. While this may be "good" as a "understand what does what" thing, I really missed my "rules of thumb" from my written SSS tutorial (available here) about the various values for the scatter radii (i.e. that the subdermal should be "about an inch" and the epidermal "about a third of an inch"). The defaults that are there are actually good if your scene is in millimeters.


Color mapping stuff

Generally, colors are not mapped in the "overall" unless you "know" what you are doing. Yes - as Alex finds out, doing it may make more intuitive sense, and may appear more "predictable" if one expects the "final color" to "look" as the "texture color".

However, the whole intended workflow of the shader is actually not to do that!

Because a lot of the "red tone" of skin should actually come from the subdermal and epidermal layers and actually hardly be present in the color map at all.

I.e. when the shader is "fully" utilized, the color map shouldn't "look" like skin at all; it should look like the skin would look if you peeled it off it's fleshy underpinning (yuck!).

It is true that some highly pigmented areas such as skin "moles" or the lip colors indeed map better in the "overall"... this is because they are a layer "on top" of the rest of the skin and actually "filter" the underlying light (blocking it) and for the lips or for skin moles, mapping "overall_color" indeed makes sense.

I fully understand that this "intended" workflow is very counter-intuitive to the lay person, but skin is such a complex substance with a lot of interaction of light between flesh, blood and the actual epidermal skin layer, it can't be as simple as "map a color map to a Blinn".

Bump stuff

I reall missed any mention about that the "appearance" of the bumps is strongly defined by the "balance" between the "diffuse" and "epidermal" layers... because the bump only applies to the unscattered "diffuse" layer, and the "epidermal" layer looks very similar to the diffuse layer, but slightly scattered and without bumps - hence one of the most important "look development" tools for the skin is to balance these two. I would actually want to see more of that rather than Alex's attempt to "blur" the bumpmap, which I do not think one should do.

Fresnel

Oh, I hate to break it to Alex, but fresnel is pronounced "frenell" [freɪ 'nel] - 'tis the name of a french dude. ;)


Reflections

The fact that Alex used something other than the build in reflectivity I can understand... but I pity the choice of the standard Maya "Blinn". I wholeheartedly suggest to use the mia_material for the reflectivity layer of skin, especially utilizing the "refl_hl_only" flag for superfast "skinny" reflections - more on that in a future post here.

I also strongly suggest to have a high "edge" reflectivity at all times, and generally let the specularity levels "follow" the levels of reflections (after all, "specularity" is really only just reflections of light sources...)

Specularities

The reason the skin shader has 2 layers of specularity isn't really to support different "areas" of skin, it's actually to change the shape of the specular "lobe". The traditional "phong" model with it's "cosine-raised-to-a-power" shaped lobe isn't really very suitable for skin, but by blending a couple of such lobes you can get a combined effect that is.



But all this whiny nit-picking aside, the tutorial is a fantastic piece of work, and I'm impressed with the time Alex took to make it (it's over two hours long!). It's well worth a download for anyone into skin shading in mental ray!

Thanks Alex for making it, and I hope you take my comments in a constructive manner!

/Z

Tricks and Tips for the mia_material (Arch&Design): Volume #1

Aaah, finally; my latest handywork is finally out on all major platforms!

The material known in 3ds max as "Arch & Design" is actually a shader from the architectural.dll library known internally as the "mia_material". ("mia" is a prefix for "mental images architectural"). It is now available in XSI 6 and Maya 8.5, known as "ArchitecturalMaterial" and "mia_material" respectively.



I had to wait writing tips about this material until now, because the shader hasn't been available to everyone (at least not "officially" ;) ), but now all that is history.

So what is this thing already?

As noted by the documentation, the shader is primarily "intended" for "product design" and "architectural" renderings. By this I mean that it, basically, tries to mimic "reality" of hard surfaced... well... stuff. Nobody is stopping anyone from using it in their next feature film... just because the DLL is called "architectural" doesn't really mean much... it's a general purpose material, no more, no less.

The shader has some cool features, and some "quirks" that can be worth knowing. This post is the first in a series of Tricks&Tips which may be useful when using it.


For example, the feature to disable reflections on the "inside" of objects was intentionally intended as a performance optimization to "quickly" render glass. I'm sort of kicking myself for defaulting that to "on", because:
- it doesn't actually help performance that much
- it causes some side-effects that may be... surprising.

I simply suggest... turn it off. The importance driven ray rejection takes pretty well care of removing truly "unimportant" rays anyway, so the feature is somewhat redundant. Secondly, while it's intent is to remove the "inside" reflections, it actually kills reflection on any flipped face (because, well, the side being hit is.. uh... the "inside"!). So if you have a scene imported from a troublesome CAD system (those LOVE flipping random triangles for no reason whatsoever... it's like it's a secret evil plot... oh no... you're only gonna get 75% of your triangles flipped correctly... ha ha... ) you could suddenly get NO reflections on some of them, which looks really weird... without any "transparency" being involved anywhere! Why? Because the "wrong" triangles are showing their "inside"... and hence.... no reflections... as per the option!

Thousand apologies for this "misfeature" ;)

More to follow, but let me drop a hint; Have you tried combining the SSS shaders with the mia_material's reflection feature?

Also, check out the refl_hl_only flag, and do read the docs there.... it's NOT simply a "highlights only" flag. If you use FG, it's a "super-quick fast fake for the ultra-mega-blurry reflections". Like those of... say... skin.

Stay tuned.



/Z

Stuff you never even knew about mental ray 3.5

One of the coolest features of mental ray 3.5 is the way the final gathering feature works.

It may deceptively seem to work the same way as before, but it doesn't. One really important point is that each FG point stored isn't just a color, it's a whole set of colors - with directional information (for the tech heads: think spherical harmonics).

What does this mean? It means a lot for bump-mapping!!

In earlier version of mental ray, bumps basically had to be resolved by the adaptivity of the final gathering, causing an extreme density of final gather points due to the variation in the bumps.

But in mr 3.5 it works completely differently; the final gathering is actually calculated on the un-bumped normal vector, and the result is stored including directional data... and then at render time, data is looked up into this directional data.

The result is:

• Much lower density of final gather points needed, the existance of bump maps does not increase the density!
  
• Very high quality of directional effects of indirect light on the bump maps, at levels previously impossible.
  

This makes bumpy surfaces render faster, and resolve in much greater detail, causing details in the bump maps in "dark" areas, i.e. areas only lit by bounce lights or other forms of indirect light such as photons.

The catch:

Some earlier shaders out in the wild intentionally tried to work around this problem. These workaround can potentially interfere with the "correctness" of the new method.

The good stuff:

The cool stuff is that due to this new FG storage format, it is possible to do directional lookups into the FG map. This is how the "Highlights Only" mode in the Arch&Design material works, which can give a very good "visual simulation" of extremely glossy reflections, without actually shooting a ton of rays and taking almost no extra render time!

/Z

RSS Feed added.....

An RSS feed has been added so you can plug this blog in your RSS catcher thingamabob. Enjoy. Or not. ;)

/Z

Public shader sources has been updated

The public shader source code available at the mental images FTP site has been updated as of today to the level of the shaders as-shipped with mental ray 3.5 - enjoy.

The public shader sources are available at
ftp://ftp.mental.com/pub/shaders/public-shaders-35.zip

/Z

Who took my "temporal contrast"?

I've received some questions about the "temporal contrast" option and who stole it from the 3ds max 9 UI.

Here's the deal:

In mental ray 2.1 and earlier, it actually used a temporal contrast, which worked very similar to the overal adaptive sampling contrast. However, this actually yeilds suboptimal motion blur.

So mental ray 3.0 or newer actually takes a fixed number of temporal samples for each spatial sample.

However, the parameter, as exposed in the .mi file format still is "temporal contrast" and is an RGBA color. However, this color isn't actually interpreted neither as a color nor as a contrast at all!

What happens is that a number of temporal samples is calculated from this color as such:

samples = 1.o / min(temporal_contrast)

So this means a "temporal contrast" of 0.2 0.2 0.2 0.2 really only means "5 temporal samples". Nothing else. There is no "contrast" comparisions being done between temporal samples at all!

So... since mental ray does this internally, this was propagated to the max 9 UI as a temporal samples spinner, rather than the old "temporal contrast".

It most likely will be changed in the .mi file format in a future version to a "time samples" instead of "time contrast" keyword.

Hope this is clear as mud... ;)

/Z

DOF and Sun & Sky issue

There is a known issue when using the Sun & Sky in max 9 together with depth of field. Objects turn out like odd wireframe-looking... things.

The cause for this is actually the long list of lens shaders that gets added by the "Aerial Pespective" feature built into Sun & Sky.

For now there is a workaround.

Proceed as follows:

1. Create a Sun & Sky system as normal, by creating a daylight system and choosing "mr Sun" and "mr Sky", affirming the pop up question of "do you want to ad a 'mr Physical Sky' environment" with a resounding YES.
2. Then, change the skylight option from "mr Sky" to "Skylight"
3. Change the Skylights option to "Use Scene Environment"

Now a nearly identical rendering (but without any Aerial Perspective) will result, since the standard mad Skylight will pick up the "mr Physical Sky" environment shader for the lighting. The net result is nearly identical to the normal rendering using a "mr Sky" and the depth of field will now work.

The difference is that now one needs to do any "tweaks" to the sky strictly in the "mr Physical Sky" shader, and to do this, one needs to "drag-and-drop" it (as an "instance") from the "Environment" dialog into a free slot of the material editor, then tweak away.

/Z

mymentalray.com

A new site has opened, www.mymentalray.com

It is not an "official" site in any way, but run by enthusiasts, but indeed contains a lot of information or links to "the best" info out there. (Which means lots of links to lamrug.org ;) )

/Z

mental ray sun&sky and rapid motion blur

There is an issue in the initially released version of max 9 (the one with mental ray 3.5.2.6) which makes the sun&sky system not behave with rapid scanline motion blur.

The workaround is to turn of the "Aerial perspective". Go to the "mr Sky" light and uncheck the "Aerial Perspective", and you will find the rapid scanline motion blur working fine.

/Z

Swedish Max/Maya launch

Tomorrow (Nov 7:th 2006) will be the launch event for 3ds max 9 and Maya 8 in Sweden. It'll be in Gothemburg (Chalmers) and I'll be there speaking about mental ray and...stuff.

So anyone around wanting to say hi, well, I'm the blonde swedish guy. Uhm. Which may not be so easy to find among all the other blond swedes. Well, I'm the only one that is mental.

/Z

Welcome to this new blog

This blog is a place for me to store "frequently asked questions" about mental ray and shaders; instead of having to reply to it multiple times, I create a blog post.....

...well that's the idea, anyway.

/Z