Forum: Poser - OFFICIAL


Subject: A light meter for lighting experiments

bagginsbill opened this issue on Jan 05, 2006 ยท 34 posts


bagginsbill posted Thu, 05 January 2006 at 3:51 PM

Sure I can explain it. I have no idea what the equivalent of any of these is in LW, but if you know how LW works you may be able to translate the steps.

The best way to explain this is bottom up.

But first, notice that I turned off all of the built-in diffuse and specular on the main PoserSurface. That's because I don't want the object to respond to light with any of the default behavior. So I set Diffuse_Value and Specular_Value to 0. No other options are on by default so the PoserSurface is done.

Now look at the bottom right node - Diffuse. This is just the built-in node that calculates, based on the lights in the scene, how much diffuse light will be sent from each spot on the figure. Because I wanted to test diffuse light, that's what I used. To test other kinds of lighting models, just replace this node with the appropriate generator. In any case, what this node should do is make a value from 0 to 1. But sometimes it makes a value GREATER than 1. This is if you have too many or too strong lights in the scene. It also turns out it can make values less than 1, but we don't need to worry about that for this material.

One thing that might turn up with other programs is integer vs. floating point math. Poser converts from integer math, such as colors from a texture image, to floating point numbers. The integers are usually from 0 to 255. So if you are dealing with integers, this may be a pain.

Anyways, the diffuse node (or whatever other node(s) you want to test) is plugged into the "hsv" node. This is not a requirement unless you intend to plug in a test node that generates colors instead of just shades of gray. For example, the Poser "skin" node by default generates skin tones. The math we're going to do will get confused by that, so I use the HSV node with Saturation = 0. What this does is turns the test node into a black-and-white generator, even if it would otherwise produce color.

Next the HSV goes into the Math_Functions:Ceil node (just above the diffuse.) The Ceil function is short for "ceiling", which means to round fractions up to the nearest whole number, i.e. 0.0 stays 0.0, .00001 becomes 1.0, .9 becomes 1.0, 1.0 stays 1.0, 1.001 becomes 2.0, etc. Now this wouldn't be useful here because the input is already at most 1.0 right? But notice the factor on Value_1 is 6.0. That means multiply the value times 6.0 before calculating the ceiling. So now our number is 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, etc. If the input was a 1.0, the output is 6.0 which means we're at maximum. So a properly exposed image only has values JUST UNDER 6.0 at most.

Ok now look above the Ceil node at the ColorRamp with black,red,orange, and yellow. A ColorRamp takes its Input and chooses a color from the 4 you enter. 0 gets black, .3333 gets red, .6666 gets orange, and 1.0 gets yellow. Values between those get interpolated - a blend of two colors is chosen, with appropriate fractions of each color based on the input. However, our input here is whole numbers from 0 through, 7. I want 3 to be yellow. So if I divide the input by 3, then 3 becomes 1, which is yellow. If the input is 2, it becomes .6666 which is orange, etc. Since the ceiling function already rounded the test nodes output to whole numbers, it means this node will produce EXACTLY the colors I typed in, without interpolating. Which is why the ceiling was used. Now a ColorRamp can't divide its input by 3, but it has a multiplying factor, so I multiple by 1/3 which is roughly .3334 (I round up slightly to guarantee I hit the yellow full on.) Of course values 4, 5, 6, and 7 are going to be yellow here too, but we'll take care of that later.

Poser's ColorRamp only comes in 4 color versions, and I need eight colors. So what I'm going to do is start another calculation and peel off the 4, 5, 6, and 7s. To do that look to the left of the Ceil. It is a Subtract math node. It takes its Value_1 and subtracts 4.0 from it. So 4, 5, 6, 7 becomes 0, 1, 2, 3. Now I do the divide by 3 trick again and feed that to the second color ramp, mapping 4, 5, 6, 7, to green, blue, purple, white. With me still?

Finally the tricky part - combining the two ramps. In the upper left is a Blender node. This takes two inputs, and blends them based on the "Blending" value. A Blending=0 chooses 100% of input_1 and none of input_2. A Blending=1
chooses 100% of input_2 and none of input_1. Values in between would proportionally blend between the two colors. But again, I don't want proportional blending, I want all of one ramp or the other, depending on which one is in the right range.

This is the job of the Math_Function:Step node. A Step function examines two values. If the first is LESS than the second, it returns 0. If the first is GREATER or EQUAL to the second, it returns 1. At least that's what the documentation says. But when I tested it, I found what it actually does is if the first is LESS than or EQUAL to the second, it returns 1, and otherwise 0!!! So with a value from 0 to 3, it generates a 1. Plugging that into the Blender, I need the Blender Input_2 value for the black->yellow ramp when the step gives a 1, because that means the value was <= 3. For step inputs >3, it produces 0, so Blender Input_1 is used, which is the green->white ramp.

Finally, this is all plugged into the alternate_diffuse input of the surface. It turns out the alternate_diffuse input just draws the color - it does NOT apply diffuse lighting to the result. So this is really just the same as the Ambient input, but without a value multipler. Which is why I plugged it in there instead of Ambient_Color - I was saving the step of having to set Ambient_Value to 1, LOL!


Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)