If I turn the magnification up on my difference magnifier, to 10000, and render, I can see a lot of not-black show up. Which means my calculation and the Diffuse node are disagreeing by something on the order of 1/10000. I'm not sure why. There is no theoretical reason for this.

But now you know more about the Diffuse node than even the authors of Poser know.

This thread has already grown to a point where finding stuff is becoming burdensome... could I get you to give me that difference magnifier formula again, please?

I think that's enough for now.

You have enough knowledge now, that you should be able to make some important predictions about what will happen when you move the light around.

You should also be able to predict what happens if you add another light to the scene, or change the intensities of these lights.

Remember always, that you cannot see numbers bigger than 1, but they are there. If you put too many lights together at high enough intensities, you'll be trying to render numbers bigger than 1.

The difference magnifier is this:

Given a and b are two unknown quantities (nodes) that you want to compare:

M * Abs(a - b)

is the difference magnifier. It let's you visualize how much they differ.

I second the motion (about having enough on my plate)... I'll go digest whilst you sleep... and thank you for this!

Coming soon in a blog near you... it'll be the digested, diluted for Dummies version and will most definitely need your proofing for accuracy...

Cheers, Bill....

Quote - Thank you Bill... just confirming your previous offer.

Just looking at the candle shader. Good job I have a bit of programming background, or this whole thing would be Chinese to me. Question:

        # y = Distance from top of candle - anything above Vtop will be
        # considered to be at the top for diffusion purposes, thus the
        # Max with 0.
        y = Max(0, Vtop - V)

Where is V defined? Is that an internal Poser constant?

I forgot to answer this. That is the V_coordinate node. It is not a constant. It is the V coordinate of the point currently being shaded by the shader.

In matmatic, I use these a lot. I mean a lot. Really a lot. I did not want to type U_coordinate and V_coordinate over and over. So in matmatic they are simply U and V.

Think of them as global variables, read only, not constants.

BKMK

Printed out... annotating and digesting... will endeavour to submit a synopsis (regurgitation) within the next few days, to confirm my understanding of this, or illustrate where the holes are.

Thanks again, Bill.

Managed to read the first page of this discussion so far. Thank you Robyn and Bill, you have helped me (a very thick dummy) understand a bit more about this. Looking forward to catching up on this now. Bring on page 2 :)

I have been struggling with maths.

Now, what makes this incredibly difficult is that I DO know a bit about coding functions in a number of languages, which ALL have an IF statement of some sort. But, that ain't gonna work, here. I have to come up with a math-based solution which Poser will then form into a nodal thingie to perform the processing on colour I need.

And my knowledge of math functions is shocking. Or even, how to problem-solve in maths.

I mean, I look at simple maths such as x = (x + 1) / 2 (okay, it was f(x) = (x + 1) / 2 but for all intents and purposes, your function was defined in "= (x + 1) / 2", the averaging bit, and your purpose was, in your words, to "find a straightforward manipulation of the two colors such that I'd produce new colors that were not hidden colors, and were visibly different from each other. Thus you would see that you got two different results" which you did using a formula where basically did averaging. To come up with that sort of solution would mean to go back to remedial algebra word-problem solving.

For instance:
Solve for 1 or less than 1 but not less than 0.

This is what you are asking with:
"How would you detect a hyper color ( > 1) - a color with a component greater than 1? (Remember you cannot directly "see" hyper colors - 1 is the brightest your monitor will go.) There are many ways - I'll wait for any of you to figure one out. Show me with math, and with nodes."

Right?

Clueless.

I looked at MOD(x)... now, if I read this correctly, modulus turns any number into a real number, right? which is great, at least we can rule out negative numbers, but then I want to solve for 1. This is the key next step. Define where I am here, and I've laughin'.

I so did try. And came up with:

x = MOD(x - (x/1 x 1/x))

Rubbish. Not a solution at all! Might as well have said 1 instead of (x/1 x 1/x)). Like I'm trying to do a clamp or something.

Anyway.... lost but persevering on...

x-1

I do need to say here that those detractors that feel maths in art is a bit overkill or theoretical: have a look at Bill's work.

Kills that notion.

I'm also into pure music. Bach or Saint-Saens, anyone?

Gotta say it, mate: you love simple solutions for complex problems. You have any idea how long I struggled with this?

Yep. See it. Thanks. Sheesh.

Hey, but I was close, wasn't I?

Given that
x/1 x 1/x is 1... why bother solving for x here, anyway?

and then, MOD(x - 1) is sorta like x-1 except solving for negative values. Which is valid? No?

This is a little like asking: do negative values exist in Poser after postulating that since green minus red equals green because heck, I don't seen anything but green. Gotta know what parameters you're working with.

But Bill, my biggest challenge is having to do with "IF".

Well there are two node things that are like an IF.

One is a specific test to see if one number is less than or equal to another. It is the math function Step.

Step(a, b) is 1 if a <= b. It is 0 otherwise. If used in Color_Math, as usual each channel is processed separately. So if the red in a is <= the red in b, then the result will have red = 1, else red = 0. Same thing for green and blue.

There are certain situations where the Step function is very handy. There are others where it would not be wise to use it, because it is too abrupt. But for purposes of the test for a hyper color, it would be very good.

Step(x, 1) would be checking where x is less than or equal to 1. In such cases, the value would result in a 1. So a non-hyper color (such as .8) would yield a 1 here. But a hyper color, such as 1.1, would not meet this test, and so it would return a 0. So another way to test for hyper colors is just that: Step(x, 1).

This test would not tell you anything about how hyper is it. It would simply tell you it is or isn't hyper. So where you have a hyper, you'd get 0, and were you have a normal, you'd get 1.

Now if you wanted your result ot actually be the reverse, i.e. hyper is 1 and normal is 0, you just do the "complement" function on that. The complement function is one I use a lot. It is not a node, per se - there is no complement node. You build it from a subtract node.

complement(x) = 1 - x

So the combined tester would be 1 - Step(x, 1)

A gradual version of step can be built from Clamp. Consider that x - 1 is 0 for any value where x is <= 1. It is greater than 0 for any value where x is greater than 1. With me?

Now consider if x is only slightly more than 1, say perhaps 1.1. But we want to make that produce a value of 1. Well then 10 * (x - 1) will do it, right? But what does 1.05 get us? 

10 * (1.05 - 1) = .5

Interesting. What about 1.02?

10 * (1.02 - 1) = .2

Hmmm! So as x goes above 1 on its way to 1.1 this function will gradually increase towards 1. In fact the rate at which it increases is 10 in this case, but we could make the rate faster or slower by using 20 or 3, see?

So suppose we want the function f(1) = 0, and f(1+delta) = 1? Simple:

f(x) = (x - 1) / delta

See that? Imagine I want a function that gradually goes from 0 to 1 as x goes from 1 to 1.01. The delta is .01. So:

f(x) = (x - 1) / .01

which is the same as

f(x) = (x - 1) * 100

Now what happens to that when x is 1.02?

f(1.02) = (1.02 - 1) * 100 = 2

Hmmm - maybe I don't want this function producing hyper colors. I just want that gradual rise from 0 to 1, and then after that don't change. Clamp time!

f(x) = Clamp(100 * (x - 1))

I use this all the time. Really I'm not making this up. Any place I'm doing color work and I have some pattern driving the color and I want a shift in color to occur as the pattern value crosses a threshold, this is what I use. The width of the threshold can be easily adjusted with that multiplier, and the threshold itself is whatever I subtract from x.

But we still haven't come to the big winner for IF. So far, we've been doing variations on testing whether something is above or below a particular value. But how do you actually implement the "then" and "else"? Meaning, big whoop I found what I'm looking for and I have a function that gives me 0 for "no" and 1 for "yes" (and perhaps numbers in-between for "maybe" or "sort of").

How do we connect that to something like IF foo then Clouds(...) else Image_Map(...)?

The answer is Blender. If you were to count up all the nodes I've ever used and see which one was used the most, I'd bet it is Blender.

The math behind Blender is actually assembled from more primitive ones. We could build Blender functionality into shaders even if it didn't exist, but we'd have to assemble 5 nodes every time to get the same thing done. Here is the equivalence formula for Blender

Blender(a, b, f) = (1 - Clamp(f)) * a + Clamp(f) * b

Or another way to look at it is:

Blender(a, b, f) = a - Clamp(f) * a + Clamp(f) * b

Or another way to look at it is

Blender(a, b, f) = a + Clamp(f) * (b - a)

Basically it works like this. If f is 0 or less, you get a. If f is 1 or more, you get b. If f is between 0 and 1, you get a mixture of a and b, with the proportions following the transition of f between 0 and 1. When f is .5, you get exactly half of a and half of b added together, which is to say, you get the average of a and b.

Wow. That's a lot of things you get with it.

I use Blender to:

1) Choose among two values or colors based on the "truth" of some other value.
2) Softly mix color in exact proportions

1. Apply decals and tatoos
   4) Shift values toward or away from 0 or 1
2. Give me an easy way to control the strength of an effect that otherwise has no control, by simply mixing unmodified data with modified data.

As in: doing it in maths. So, gotta do a bit of re-thinking. Can anyone - any brainiards from planet Maths point me to a remedial site?

Hey, I'm NOT contesting the necessity for maths anymore: I just want a means of understanding it, assimilating it.

I'm a speller. I have a natural gift for that. I naturally pick out grammatical errors, spelling mistakes, I'm a high-schooler's worst nightmare. Ya want an editor for your book, Bill? I'm your girl! However, fat lot of good it does me here. I'm illustrating a point.

Whilst I'm NOT good at maths, I do embrace the idea that an intimate enjoyment and sense for maths is key here. I see the need for getting enthusiastic, focussed, bloody obsessed about the mathematical side of all this. I don't object to any of it. Just don't tell me to do experiments. Your introduction to Algebra wasn't: "here's the quadratic formula... sort out its significance."

Collection of math goodies: I can deal with that idea. I had that same concept with VB and functions. And when I needed one, I could eventually pull it out of a hat. "Wait, hang on... I know what will solve this! it's... SHEESH.. gotta look for it..." but I got it, eventually.

Ah! WOW! Cross-post but WOW, what did I miss whilst I was typing rubbish!

Thanks, BILL!!!

There is no book like this. I think the relentless application of +, -, *, and / are just not going to be examined that closely in any book.

That's all I'm using here. I've not even got to exponentiation, or square roots, or sines and cosines, or modulus, or anything remotely beyond 5th grade arithmetic.

That's the trouble really. This is a whole new way of thinking about arithmetic. Mostly it was taught in terms of how to add two particular numbers together.

What I'm talking about is how to visualize/imagine an entire function added to another function, or worse, an entire image full of numbers being added to another entire image full of numbers. There is no book on that. It's a whole new application of arithmetic.

There is something like it, taught as a pretty advanced math course in university, called Linear Algebra. This deals with arithmetic of whole functions.

Example, when I write a + b, you are able to generalize that into specific cases like 2 + 3, 4 + 7, etc. You understand that the little expression, a + b, stands for an infinite number of actual additions, without actually naming any of them.

Well in Linear Algebra, those letters can not only be any number you like, they can be any function you like. What?!? How do you add functions together?

It's really pretty much the same. If I have function f(x) = 3 * x + 9 and g(x) = 100 * (x - 1) then

f + g = 3 * x + 9 + 100 * (x - 1)

Now in Algebra you are taught how to actually reduce that. But in Linear Algebra you are taught how to reason about f + g without actually working out exactly what f + g is. It's a fascinating subject, and was one of my favorites in college.

The concepts are incredibly useful for designing new functions from existing functions. This just so happens to be 90% of what I do when I design a shader. I have a function I want, but I only have these Poser nodes to implement them. So I have to figure out how to mix and match from this finite set of functions to produce any other function I want, like a skin shader, just from the four basic arithmetic functions plus exponentiation. (Yes that's actually how it is built, nothing else is used.)

For example, I know that if I have two functions where f(0) = 0, f(1) = 1, and the same holds true for g, then a new function h = f * g  will also obey that rule, i.e. h(0) = 0 and h(1) = 1. Even if I don't know any details about f and g, i.e. what they actually look like, I am still certain of this. This is my favorite rule for shader functions. I have a giant bag of these from which I assemble new ones. The fact that the new ones meet the same criteria as the ones I made it from is important. Why? Because the new one goes right into the bag with all the others, so I have an ever-growing collection of them.

But as I said, the approach taken in Linear Algebra books is anything but remedial. Quite the opposite, it assumes you are already facile with Algebra, and then takes it to new levels.

Quote - ...the approach taken in Linear Algebra books is anything but remedial. Quite the opposite, it assumes you are already facile with Algebra, and then takes it to new levels.

First of all, printed that last post out to read in the bus whilst I go to pick up my car from the servo.

Just wanna explain my confusion. In math terms:
Consider that:
a: I want to learn (this math as it applies to Poser) and
b: I'm 57, a full-time nurse and home-maker so Uni is not an option
c: don't wanna be bugging the heck outa ya Bill - yeah, what you say is gold, but you have your limits too!

What do you suggest as a good approach to getting my head around linear Algebra? or is simple arithmetic going to do 90% of what I need to do?

Thanks, mate....

I will apply simple maths and learn how to problem-solve in maths. That's it, hey?

Oh you don't need linear algebra. I was just saying that's the first place I saw a book talk about systems of equations.

Mostly what we do in shaders is basic arithmetic. It's going to be the same as learning a language. There will always be a point where you can understand a sentence someone says to you, but you could not have assembled that sentence yourself. Then you get better, and that sentence you can make, but there's another one you can't make on your own.

I think the math will come with the study of specific applications. I presented a lot of somewhat abstract (free of any particularly useful scenario) math here, but only because it was really necessary to understand that there are numbers outside of 0 to 1 and we have to be able to deal with them. You cannot approach sophisticated shader development based on a "painterly" approach. There are many people in the community who feel you can, but they have never produced an accurate looking glass or water, IMO. They think that messing about with Edge_Blend, looking at what it does visually, will reveal the correct approach. It won't. I thought so too, until I went and looked up the Fresnel reflection equations and implemented them in a Poser shader.

If you only deal with what you can see in Poser previews or test renders, you are limited to the manipulation of numbers only from 0 to 1. Anything outside that cannot be visualized with colors on your screen. So the first step is to learn how to transform data to fit into the visual range of 0 to 1, and how to know when you still have data outside that range.

I think you've got the point of that now. So we can move on to actual building of shaders.

Probably you should really learn how to work the Diffuse node.

What is this?

It looks like a yellow disk, right?

In the previous render, I had my light turned up really high. This resulted in hyper colors.

My orange [1, .5, 0] multiplied with my crazy hot light (intensity = 10) resulted in the hyper color [10, 5, 0]. Even in areas of the sphere which were lit less because of the angle, we still had colors like [3, 1.5, 0]. All of those look the same as [1, 1, 0] which is yellow.

Now you know why.

My light combined with my shader has resulted in some hyper colors and some ordinary colors. So we see some yellow in the brightest parts (those facing the light).

Somebody who has no clue about the math of the Diffuse calculation and the impact of hyper colors might start theorizing that the Diffuse node can actually shift your hues. It cannot. The hue shift is because you are not seeing what is there.

But if I tell you up front that the math is simple multiplication, and you look through that, then you'd know without even testing it that hue shifting is impossible. So if you saw any, you'd check for hypercolors right away. You'd then adjust your Diffuse_Value immediately, without any faffing about.

Bookmarking. :)

Must be something wrong, I could actually follow the above and understand it.

I've been having a sticky-beak here and there, searching for examples of code (math functions) solving material problems with the intent of fleshing out my collection of math functions and illustrations of nodes thus created. Renderosity and RuntimeDNA are rich with this sort of thing. At this point in time, I feel it's clearly the best strategy for getting my head around how they're made.

My Material room is quickly starting to fill up - stuff I've been looking for like non-repeating sand and water and all kinds of lovely materials tend to side-track me from what I'm really after: math and the nodes that that math creates. Like the stuff we covered earlier in this thread.

I'm at that point in my exploration where I want to understand how a math process like:
f(X)
= f([-1, 1, 0])
= ([-1, 1, 0] + [1, 1, 1]) / 2
= [0, 2, 1] / 2
= [0, 1, .5]

can be expressed in nodes like the upper half of:

...hope you don't mind I borrowed your image and your function, Bill... it illustrated perfectly what I wanted to say. To that end, these functions and associated node sets are ending up in this fine little collection. Understanding the association between math and node set-up should save you having to teaching remedial Poser nodes, so you can get to the exciting stuff, like what all is contained in the Diffuse Channel.

Unless you'd like to shed some light on it: this is after all a "For Dummies" thread.

BTW, other readers, am I alone in being unclear how to translate math into nodes? If so, let's do move on... hate to be the monkey that stops the show.

Speaking of sand...

Maybe I'm not the pickiest artist in Poserdom, but I'm like REALLY happy with the sand, here:

...much much better than stuff one can BUY! Found it here... don't forget to set units to inches, though.

Quote - Understanding the association between math and node set-up should save you having to teaching remedial Poser nodes, so you can get to the exciting stuff, like what all is contained in the Diffuse Channel.

Have you thought about using matmatic in this process? Matmatic is a script that automatically converts math (Python mathematical expressions) to Poser nodes. Quite often, it may help you to see how to do something with nodes. Quite often it will find a simpler way than you realized was possible. And, unlike you using the material room manually, matmatic can take advantage of hyper colors and hypo colors, colors you cannot enter by hand because of how the material room editor is restricting you.

For example, try typing:

Surface(2 * Spots(BLACK, (GREEN + WHITE) / 2) <= 1.5 * Clouds((RED - GREEN + WHITE) / 2, WHITE)

You might be surprised. The nodes are actually more powerful from matmatic than from direct manual manipulation.

The only problem with using it to see how things work is that sometimes it will collapse the nodes (optimize) because they are not needed.

For example, the upper half of that node setup computes (GREEN + WHITE) / 2. However, matmatic would do that directly and produce Color(.5, 1, .5) wherever you were using that expression.

Quote - Speaking of sand...

Maybe I'm not the pickiest artist in Poserdom, but I'm like REALLY happy with the sand, here:

...much much better than stuff one can BUY! Found it here... don't forget to set units to inches, though.

I barely knew what I was doing when I posted that. I'm glad you like it.

I now know why I was struggling so badly with that sand shader. It is exactly the type of thing where gamma correction is going to really really matter.

Robyn you're fine. I think I'm picking up things, but you're more incisive brain is asking questions that are leading to more enlightenment.
BTW  I agree about the sand, it is so much more realistic looking

Quote - I barely knew what I was doing when I posted that. I'm glad you like it.
...
I now know why I was struggling so badly with that sand shader. It is exactly the type of thing where gamma correction is going to really really matter.

Barely knew what you were... WHAT??? Sheesh, do you have a Poser-node-secreting tumour? How could you not know what you were doing? This procedural texture is brilliant! Looking at it and looking at it and jeez, it all makes such perfect sense.

I've looked at so many procedural textures all claiming to create realistic sand, and none even come close to the sophistication of this set... not even close. One even used Tile plugged into a Spots node.

I'm using Poser 7 (not Pro) so gamma correction isn't an issue yet? is that right?

Attached Link: You need to gamma correct

What I've been saying over and over is your (and everybody's) renders suck.

If you are not gamma correcting your renders they suck.

You are generating renders in Linear color space, using Poser 5, Poser 6, Poser 7.

Your monitor displays images in sRGB color space. Only Poser Pro can generate an image directly in the target color space for your actual monitor, printer, or projector. All visual devices today are calibrated for images encoded in sRGB color space.

So it is in issue, until and unless you are using Poser Pro and you enable Poser Pro's built-in gamma correction in render settings.

I have discovered that it is possible using nodes to generate images in the proper color space even in Poser 5, Poser 6, and Poser 7. Anybody who has been using my VSS shaders has been enjoying renders (of the figure at least) that are properly encoded to be viewed as they are supposed to be on actual real-life computer monitors, as opposed to imaginary idealized monitors that do not exist.

I have been trying to make everybody understand that all versions of Poser prior to Poser Pro were rendering perfectly well, with the lighting being quite good really. Many people think Poser's lighting is not good. This is incorrect. What has been missing all along is that you are looking at images not designed to be looked upon with a computer that actually exists.

In order to prepare images to be viewed on your actual real-life computer monitor, you must gamma correct it.

It turns out that linear color space images look similar to sRGB images, but they are not the same. But they are close enough that 300,000 Poser users have been struggling with lighting trying to make up the difference.

The issue is not lighting. The issue is you need to convert your render to sRGB color space.

The conversion is simple:

linear color to the power (1 / 2.2) = sRGB color

SImilarly, any incoming images used in shaders, such as skin textures, must be converted from sRGB to linear space, as follows:

sRGB color to the power 2.2 = linear color

These two conversions are performed automatically for you by Poser Pro if you enable them.

If you do not enable them, Poser Pro does not do this for you.

Many people bought Poser Pro and believe that gamma correction just makes their pictures ugly.

Actually, their pictures are ugly to begin with, and Poser Pro reveals this when rendering them with gamma correction.

Hundreds of thousands of Poser users have been bamboozled for years into thinking they need to throw dozens of extra lights into a scene to get the darker areas to look right. They think it is not possible to light a scene with only one spot light adequately. They are wrong. They only need to actually "see" a render correctly encoded for display on real-life computer monitors.

(Sigh. I've only been saying this every single week and it still isn't clear, apparently.)

I have written in DP Hoadleys thread about the same thing.

Last month I wrote a thread called "Friendly Reminder - You need to gamma correct".  It is in the link above.

I guess I should write it again.

Attached Link: sRGB

Sorry Bill... this is all new information to me. I remember there was some discussion on gamma correction or the VSS Skin Shaders thread, but since I didn't have Poser Pro kinda glossed over it.

I can see now that was a mistake.

Now, I need to study up to understand exactly what the difference is between linear colour vs sRGB. I did read up on Wikipedia on sRGB some time ago (probably remembering about a tenth of it). However, the discussion on Wiki regarding linear colour brings into focus: yes, gamma:

"We’re all computer users whose primary interface for viewing images is the monitor. Everything about monitors, including their aspect ratio, comes from their ancestors: old television sets.

Old television sets were bad - it took a lot of voltage to make them bright. That’s the thing to remember - that images on a monitor are “darker than they should be”, which we’ll need to know later in order to debug what’s going wrong.

Monitors have a gamma of about 2.5, which looks like the graph shown here**
**

Monitor Gamma of about 2.5

**. As you can see, with a voltage of 50%, you’re nowhere close to getting 50% brightness.**But when we watch videos, look at pictures, and work on our computer, the images look the way we think they should, don’t they? For display on television sets, video cameras compensate by producing images that are slightly “brighter”, so the result is a gamma of about 2.2."

There's that magical number you mentioned: 2.2.

But we still haven't defined what "linear colour" actually is. So, I read on, hoping:

"In Windows, the sRGB standard** (http://www.w3.org/Graphics/Color/sRGB) for the web (any operating system) is used to give you the experience of having a monitor with a gamma of 2.2. In other words, the monitor profile applies a very small gamma correction of about 1.1 to brighten things up a bit. Our eyes do not want a linear response, and it is pleasing to have an extra gamma applied to images. Linear images appear washed out and we have difficulty seeing the important details.**

Since the images you usually work with (photographs taken with a digital camera, for example) look the way you expect them to, they have obviously have been encoded with a gamma correction that compensates for the darkening the monitor’s response.

What kind of encoding is used? Well, the digital camera captures data from its CCD in some device-specific format. It then copies the pixel values directly to the graphic card buffer, assuming that the graphic card is connected to a device that will respond to these values with a gamma curve of about 2.5, producing a jpeg image that is meant to be viewed on a computer monitor. In other words the jpeg images we work with are, like most other digital images, designed and encoded to be seen on a monitor. They are not linear.

However, when you render an image using a CG application, or paint something in PhotoShop (without any color management setup) no such color encoding happens. Shaders, compositing algorithms, paint brushes, and so on simply poke numerical values without considering what perceptual effect it will have when the image is displayed on a monitor. It's all pure and perfect math, and it doesn’t account for the "impure" way that digital cameras reproduce images.

These calculations all happen in linear space, which means that if a value needs to be twice as bright, the CG application multiplies the value by two, regardless of the fact that the result will in fact not be twice as bright when displayed on a monitor.

While 3D rendering done with Gouraud shading is, by definition, completely linear, things get muddier when you apply image textures to your 3D objects."

Got this from this Wiki on Gamma, Linear Colour Space and HDR.

Looked up linear images, which got me to a page on how a video signal is thrown on to the phosphor screen, and I kinda started to get the idea that linear images are defined by how they are processed (and in this processing somehow gamma is affected) in order for it to be displayed on a television monitor (that interlacing thing).
Which differs only slightly from how a PC monitor displays images.

So if what we are producing in Poser -x (where x=7Pro) are linear images (no gamma), they are going to look like crap on any device that isn't Poser.

Going to go read YOUR dissertations on the subject: hadn't appreciated either their significance or importance. But then, I'm but a neophyte surfer in this ocean of light waves, and I'm being pushed in as they're breaking 20!

And yes, I rendered that beach scene above with obscenely high light levels. Obviously crap... now to read on how to gamma correct.

Was quite chuffed with the texture that I did get... now, let's see what can be done with proper lighting AND gamma correction.

And Poser Pro is way out of my reach at the moment, so I'll have to do it with shaders. Or lenses or...

I tried to gamma correct my monitor but don't know if it worked.
At least the images look better to me but not sure how they look to others.

I really, really don't understand anything that uses math, I'm a math dummy :)

Quote - I tried to gamma correct my monitor but don't know if it worked.
At least the images look better to me but not sure how they look to others.

I really, really don't understand anything that uses math, I'm a math dummy :)

Uh - you're not supposed to gamma correct your monitor. You should calibrate you monitor so that it conforms to sRGB specifications for color rendition.

You gamma correct your images. That's what cameras do. A photograph looks right on your monitor because it is gamma corrected. A render can look wrong because it is not gamma corrected.

Gamma correction: I'm setting up your Artistic Lens on the above scene, Bill. It's a valuable exercise even if Keven Rudd is going to contribute towards a new PC and Poser Pro.

About that original scene... the lights were:
Main Inf 95% intensity, 1,1,1, Ray trace shadows, blur radius 6.0, min bias .2, nil amb occl
Rim Inf 65% intensity, .9,.9,.9, nil shadows or amb occl
IBL 20% intensity, 1,1,1, no shadows or anything

IBL was xRot 9, yRot -15, zRot 0 (my ignorance about this light prevents me from seeing the significance of IBL light placement... might need to run some close-ups to see if there any changes, although I've kinda picked up now that just because I can't see it, doesn't mean it isn't happening).
Rim xRot -109, yRot 56, zRot -406
Main xRot -59, yRot 25, zRot 2
Shot with the main camera focal (and perspective) set at 120mm.

The subjects in this image are really YOUR sand procedural shader, Bill:

...on a plane I made in Blender. I mucked around with a few values - some would call it "adjusting" a few values, but that would imply I actually had a full grasp of what each node did and thus which values to change to arrive at my desired outcome. I did get what I thought I wanted: sand the colour and texture of what you'd see at Spenser Park to the south of Kawaihae harbour on the Big Island of Hawaii.
Did I leave anything out?

Probably did. Now I'm going to render through that "lens"... going to do this step-by-step. It's have to wait till tonight, since my patients won't be happy having to wait for me...

BTW, I'd like to clear something up here. Contrary to your thinking, I do embrace maths as they pertain to colours and managing them in Poser. Being ignorant of maths and hating maths are two different critters. I was told when I was little to stay away from any career involving maths as I didn't have the aptitude for it. Big mistake. Never tell a child that. I may not have it naturally as some do, but it doesn't mean that I don't see its validity in what we're doing here: I DO and so am keen to learn. It's just that since I haven't wrapped my head around trig and algebra since high school, the concepts sink in slowly.

Next instalment tonight.

You should calibrate you monitor so that it conforms to sRGB specifications for color rendition.

Most monitors have standard sRGB settings, (at least mine have), you can find them under the colormenu of the monitorsettings.

just some extra info.

Bopper.

Quote - > Quote - Understanding the association between math and node set-up should save you having to teaching remedial Poser nodes, so you can get to the exciting stuff, like what all is contained in the Diffuse Channel.

Have you thought about using matmatic in this process? Matmatic is a script that automatically converts math (Python mathematical expressions) to Poser nodes. Quite often, it may help you to see how to do something with nodes. Quite often it will find a simpler way than you realized was possible. And, unlike you using the material room manually, matmatic can take advantage of hyper colors and hypo colors, colors you cannot enter by hand because of how the material room editor is restricting you.

For example, try typing:

Surface(2 * Spots(BLACK, (GREEN + WHITE) / 2) <= 1.5 * Clouds((RED - GREEN + WHITE) / 2, WHITE)

You might be surprised. The nodes are actually more powerful from matmatic than from direct manual manipulation.

The only problem with using it to see how things work is that sometimes it will collapse the nodes (optimize) because they are not needed.

For example, the upper half of that node setup computes (GREEN + WHITE) / 2. However, matmatic would do that directly and produce Color(.5, 1, .5) wherever you were using that expression.

Took your advice, Bill, and have actually written my very first successful Matmatic script. I was looking at existing scripts to get an idea how the whole thing flowed, and kept generating errors about ltype and all that, so I decided to go with as simple as I possibly could, and in a blank text file named BasicsBase01.mm1.txt entered the following line:

Surface()

Compiled. Felt the thrill of accomplishment because this simple thingie didn't generate the errors that :
def makeSurface():
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(RED)
  return s

outputs += makeSurface()

did. Come to find out outputs+= doesn't really apply here. All ya gotta do is call the makeSurface() function by naming it.

So:
def makeSurface():
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(RED)
  return s

makeSurface()

creates this real flash material, where this SimpleColor node with a color value of RED is plugged into the Alternate_Diffuse channel. Yeah, I know, exciting. But hey, it is. Basic math generates nodes, and the assignment operator ( = ) connects them to whatever channel is to the left of that = sign. Oh, and those zeros arguments for Surface? Actually result in black for color and 0 for value for Diffuse_Color/Value, Specular_Color/Value and Ambient_Color/Value.

Now that I have the basic idea of how this works, I can can start making more interesting materials.

Just to demonstrate how incredibly slowly I'm going to proceed through this, I'm going to do slight variations on the theme. As in:

def makeSurface(x):
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(x)
  return s

makeSurface(RED)

generated the same material. makeSurface() now has an argument... x. Tried:

def makeSurface(x):
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(x)
  return s

makeSurface(GREEN)

generated the expected material with the expected changes. Time to branch out a bit.

def makeSurface(x, y):
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(x) * y
  return s

makeSurface(GREEN, .5)

Compiled just fine... a titch worried, because "complied fine" doesn't imply "valid results". Having a look at the shader tree to see what the multiply operator does... well, SImpleColor(GREEN) seemed to stay green, but the RGB colour value in the alternate_diffuse channel on the PoserSurface node has gone from 255,255,255 to 127,127,127.

Interesting.

Might try other operators. Lets get simple and just use the addition + operator.

def makeSurface(x, y):
  s = Surface(0,0,0)
  s.Alternate_Diffuse = SimpleColor(x) + y
  return s

makeSurface(GREEN, .5)

Well!!!

Where the multiply operator appeared to affect the alternate_diffuse colour channel itself - halving the RGB value - the addition operator creates this material:

The .5 seems to somehow affect value_2 of the Math_Functions(add) node. Well, makes sense because we are adding that value to 1. So, the actual color is GREEN  (0,255,0) + 127,127,127? A super color?

Gonna have to sleep on it. I'm certainly not going to let what I see in preview affect what I think it is, because the math is telling me differently. I really think I AM looking at a super-color...

Good job!

Yes, that's a super color (or what I earlier called a hyper-color). The resulting color is Color(.5, 1.5, .5) - thus it's a hyper-color.

In Poser (internally) and matmatic, RGB intensities are always represented as unit range, i.e. fractions or multiples of 1. Remember there are two common systems for color element intensity. One is the 8-bit integer format 0 to 255. The other is the unit range format, which is a floating point number from 0 to 1.

The Poser user interface is showing you colors translated into the 8-bit representation, but that's just an approximation. The correct and precise true valule is actually a floating point number.

Using the 8-bit system, it is impossible to represent the true value known as mid-gray, or .5. The reason is the value needed is half of the maximum value. The maximum value is 255. What is half of 255? Is it 127? Nope. It is 127.5!

So Poser is lying to you. The mid-gray you see is actually .5 expressed as a decimal fraction of the unit maximum. When it shows you 127,127,127 it is not the truth. The truth is 127.5, 127.5, 127.5, but it can't show you that because the integer representation is, well, an integer.

Furthermore, a hyper-color intensity (a value greater than 1) cannot be represented in the 0 to 255 range either. Do not try to read out such values in the material room - you can't. You can't see them either. They show up all random and funky. Just trust that they are there when you use them in the script.

Now back to the script.

You made a node with this: SimpleColor(GREEN)

You then added a node and a number with this: SimpleColor(GREEN) + .5

Matmatic noticed that you were using a node that returns a color. It saw that you were trying to add a number to a color. The rule there is to promote the number to a color first. So the .5 becomes Color(.5, .5, .5). To add colors where at least one comes from a node, it must use another node; a Color_Math node. So that's what you got. Matmatic called it a Color_Add because it is helpful like that. ;-)

The first argument is your SimpleColor node, so it just connected that to Value_1. Now why did it put white in there? Because the parameter color gets multiplied with the plugged-in value. All I want is the original value, so the way to do that is to multiply with 1. The color equivalent to 1 is white. Voila. The value to be added was your .5, but I need the color version of that, which is Color(.5, .5, .5).  In 8-bit form that would be 127.5, but 127-and-a-half is not allowed in that format, so the RGB readout says 127. No big deal. The real value is .5

So the net is you have WHITE * SimpleColor(GREEN) + Color(.5, .5, .5) which is equivalent to what you said, but expressed correctly using poser material room nodes.

Now you may be curious as to why there are two nodes at all. The reason is because you explicitly asked for a node when you said SimpleColor(GREEN) instead of just saying GREEN. The usual reason for this sort of thing is because you may be trying to separate the GREEN into a single node, so the user can further edit the resulting nodes easily. That SimpleColor(GREEN) might be connected to several other things later, so matmatic leaves the node as a node.

If, instead, you had said GREEN + .5, then matmatic would have immediately reduced that to Color(.5, 1.5, .5) all by itself. Anywhere you used that, it would be just a color, not a node.

However, the Alternate_Diffuse channel does not activate with just a color in it. There has to be a node plugged in to make it wake up. So that's why you want to use a node here, even if the value is a constant. Usually we only use nodes for things that change, and just use a plain color for things that stay the same everywhere. But, again, Alternate_Diffuse MUST have something plugged in to wake it up.

Notice how the Alternate_Specular channel is "sleeping". It shows a dot with a question mark in it. That means it's the sort of channel that requires a node to activate. There really is a color there, but it isn't active yet - not until you plug something in.

Now back to a previous test case: SimpleColor(GREEN) * .5

Matmatic is very smart. It tries to find simpler ways to do things. You asked for multiplication of a node with a number. So first, it promoted the number, .5, to a color, Color(.5, .5, .5). Then it noticed that you were plugging that product into a color channel. Since the color channel Alternate_Diffuse has a color multiplier in it, there are two ways to accomplish this goal. One way would be to create a Color_Math:Multiply node to combine the SimpleColor(GREEN) * Color(.5, .5, .5) and then connect that to Alternate_Diffuse with a WHITE value in the channel color. But the channel color value is multiplied with whatever is connected. So why bother with another multiply node, when there's already a multiplication with a constant involved in the channel itself? So that's what matmatic did. That is why you saw RGB 127, 127, 127 in the Alternate_Diffuse channel color. It was saving one node. (Remember, the real color intensity there is 127.5, not 127, but you can't read that out using the Poser GUI.)

So when you said +, you got an Add node because there was no cheaper way to do it. But when you said *, you did not get a Multiply node, because there was a cheaper way to do it.

Regarding the error:

outputs += makeSurface()

This is very simple. You were trying to add a surface to a list. Python doesn't want that here. It wants a list of surfaces. The correct syntax would be:

outputs += [ makeSurface() ]

And as you discovered, you don't really need this here. For a script that only produced one surface, you don't have to do anything but make the surface. If the script actually does make more than one surface, and you do nothing else, the last surface made will be what is produced.

The reason to use the outputs += business is if you want the single script to generate multiple output surfaces - i.e. multiple material files.

So, for example, if you go to your parameterized version:

def makeSurface(x): ...

Suppose you want the script to generate three surfaces in different colors. You could do:

outputs += [ makeSurface(RED), makeSurface(GREEN), makeSurface(WHITE) ]

You could instead say:

outputs += [ makeSurface(RED) ]
outputs += [ makeSurface(GREEN) ]
outputs += [ makeSurface(WHITE) ]

That would do the same thing.

Now in either case, matmatic would have to decide what to call these surfaces, since you didn't say. So it would just number them for you. It adds a suffix to the name of the script, so if the script is foo.mm1.txt, the results would be foo-1.mt5, foo-2.mt5, and foo-3.mt5.

This could get confusing, so you want to take advantage of the ability to specify the suffix yourself.

outputs += [ "Red", makeSurface(RED) ]

That would produce foo-Red.mt5.

outputs += [
   "Red, makeSurface(RED),
   "Green", makeSurface(GREEN),
   "White", makeSurface(WHITE),
]

That would produce the three variations with nice names.

Quote - Using the 8-bit system, it is impossible to represent the true value known as mid-gray, or .5. The reason is the value needed is half of the maximum value. The maximum value is 255. What is half of 255? Is it 127? Nope. It is 127.5!

So Poser is lying to you. The mid-gray you see is actually .5 expressed as a decimal fraction of the unit maximum. When it shows you 127,127,127 it is not the truth. The truth is 127.5, 127.5, 127.5, but it can't show you that because the integer representation is, well, an integer.

Shouldn't mid-gray be 128,128,128 ? True, the max val is 255, but the min value is 0, so there's a range of 256, so half of that is 128.

128/255 is not 1/2

Study this material. I have a tile node connected to the bump channel. Since I set the bump scale to 10, even the tiniest amount of variation is visible. So if we can see little squares, it means that the value in Tile_1 is different from the value in Tile_2.

The Tile_1 value is connected to a Color_Math:Divide node labelled "WHITE / 2". That node is dividing WHITE (255) by 2. So it is precisely half the maximum intensity.

The Tile_2 value is connected to a Simple_Color node labelled "GRAY 127".

My claim is that half the maximum brightness is not RGB 127,127,127. Look at the PoserSurface preview. Do you see the squares? That proves that 255 / 2 is not equal to 127.

Observe the squares. Proof that 255 / 2 is not equal to 128, either.

Observe that the preview is now smooth - there are no squares anymore.

This shows us that color arithmetic in Poser is actually performed using floating point numbers, not 8-bit integers. If this was not true, then WHITE / 2 would have to be either 127 or 128. Since it is not equal to either of those, it must be something else.

Half of 255 is indeed 127.5 so by definition mid-gray is 127.5.

This also shows us that you cannot directly enter the color mid-gray into a color editor in Poser, but you can construct it in several ways using nodes.

Using matmatic, you can type it directly as .5.