Welcome to the Poser Forum

Forum Moderators:  Boni, Kendra    Forum Coordinators:  darknewt, Jules53757, SpookieLilOne, gmm2

Poser F.A.Q (Updated: 2016 Nov 29 4:50 pm)


 Subject: How do I make a surface a light?

Pagrin opened this issue on Jun 19, 2007 · 107 posts

Top of Forum Print

  Pagrin    ( ) ( posted at 3:25AM Tue, 19 June 2007 

Well the suject says it all really.
I'm just starting to learn a few bits and pieces with Poser. So I'm not the most skilled user on the block. However I want to make a surface within a set give off light.
Do I need to put a scene light in the right location?
Can I make a surface glow using textures?
Thanks in advance :-)
Pagrin :-)


  jonthecelt    ( ) ( posted at 3:44AM Tue, 19 June 2007  · @3007140

Within Poser, you need to do two things - make the surface give the appearance of giving off light; and set an actual iight object by it to light the objects around it.

The simplest way to give something the appearance of giving out light is to turn your diffuse and specular settings down to 0, your ambient settings to 1, and your ambient colour to white. Your surface now glows white. If you want it to give off a colour, or perhaps use a texture map to drive the colouring of the light area, then you need to add a texture map, just as you would with most object in Poser (but add it to the ambient colour channel, not the diffuse colour).

Depending on the kind of light you're looking at, I would recommend either point or spotlights to be used for your actual light source. Spots are good for giving a definite directional light, but can only have a maximum of 180 degree of arc. This is fine if you don't want to illuminate anything behind the light, but doesn't look too realistic in some situations. If you want a more natural look to the settings, then a point light is the better way to go. Either way, set them just in front of the light source surface, so that the surface doesn't interfere with the spread of light.

Hope this helps,

JonTheCelt

P.S. As I wrote this, I found myself wondering something which has cropped up a couple of times in the past for me. Is it possible to use the various math nodes to create a proper inverse square decay on the lights within Poser? Since the parameters for setting the lights angle and distance are in th parameters box, rather than the materials settings, I'm not overly hopeful, but maybe I can be pleasantly surprised. The obvious person to tackle this would be BagginsBill, if he's not too busy. Or can anyone else 'shed light' on this question for me?


  Angelouscuitry    ( ) ( posted at 9:59AM Tue, 19 June 2007  · @3007272

Attached Link: glow effect in poser help! - Thu, May 17, 2007 5:17 pm

Currently surfaces render as Glowing fairly well, but the actual Emmission of light is another story.  Very little detail is rendered for an Object receiving only it's emmission, as far as I've seen. 


  bagginsbill    ( ) ( posted at 11:32AM Tue, 19 June 2007  · @3007338


Jon,

BRILLIANT - ABSOLUTELY BRILLIANT! I can't believe I never thought about this. I believe this may be the single most important reason that Poser indoor scenes look fake. The lights do not obey the inverse square law!

Be more than pleasantly surprised. Be very surprised. For I have figured out how to add this to any spot, point, or infinite light in Poser.

The screenshot above shows how this is done. You must put this shader network INTO THE MATERIAL FOR YOUR LIGHT! I have attached an actual Poser 6 material file, RSquaredLaw.mt5. I had to add the filename extension .doc to it to be allowed to upload it here in the forum. When you download the material, MAKE SURE YOU REMOVE THE .DOC from the name. 

Some of you have your PC set up to not allow you to do this. Before you click the attachment to download it, you must make sure your PC is configured to not hide the file types from you. Go into any explorer window - just click on your "My Computer" shortcut to bring one up. Choose the menu item "Tools" then "Folder Options...". Click on the "View" tab in the Folder Options dialog. Look in the "Advanced settings:" listbox. There is a checkbox labelled "Hide extensions for known file types". TURN THAT OFF. You will no longer be treated like a baby by Windows. You can now choose to rename files as you see fit.

OK with that out of the way, download the attached material file and save it in your Poser Materials library somewhere. Be sure you notice where you put it. Go into Poser. I suggest you drop down to just one light for your first test. Pick a light and set it to Infinite, Spot, or Point. Point is best to see the effect. Decide where to place your point light in your scene. Do a test render so you know what it looks like.

You must do a little setup on the shader. I designed the shader units to work in Inches, so if your Poser Display units are not inches, change them to inches. On the light Parameters tab, look for the "Transform" section. You can read off the exact coordinates of your light in the xTran, yTran, and zTran parameters. Write them down on a piece of paper. My light was at 20, 60, 100.

Now select your light, and go into the material room. MAKE SURE YOU SEE YOUR LIGHT THERE. Double click the file I gave you to download. It will load this shader into the light.

There are two nodes you need to edit. The first node is Unit_Distance_V1. The parameter Value_1 is going to be the "Unit Distance" - in other words, this is the distance from the light where the intensity will be exactly the value you put in the Light Intensity. I chose 60 inches, which is 5 feet. So I get to set the light intensity at a radius of 5 feet. 

Now look at the node Light_XYZ_Position. I know you think that's for colors, but it is also for vectors. In the Red, Green, and Blue parameters, type in the X, Y, and Z position of your light that you wrote down earlier. I'm sorry I can't do this for you in the shader but Poser shader nodes cannot get that information.

That's all you have to do. The light is now configured to implement the correct inverse square law. For my settings, that means that anything that is 5 feet from the light will be lit exactly as before. At 10 feet, it will be only 1/4 as bright. At 20 feet, 1/16th as bright.

Also, anything closer will be brighter. At 2.5 feet (30 inches) the light will be 4 times as bright.

That's all you need to know. Remember, if you move your light, enter the XYZ position again in this shader. Otherwise, you don't have to come back in here again. You can manipulate the light intensity and colors as you've always done with any of the Poser gadgets you want.


For those of you who want to know how it works - here is the explanation.

Starting from the lower right, there is the "P" node. This node gives me the position of the surface that is currently being lit. Not the position of the light, but the position of the point in a mesh prop or figure that is being lit. This is a very cool undocumented feature. Now the position is in some wierd variation of Poser Native Units. I want Inches. So I set the multipliers up with the value .0969. This is not EXACTLY the right multiple, but the next non-zero digit is way out there and its good enough for this shader. (Not good enough for precise displacement shaders, but that's another topic.)

Now just above that is a node called BugFixUserDefined. That is actually a Color_Math node. What I'm doing there is taking the square root of the light xyz position. This is because there is a bug in the UserDefined node. The Light_XYZ_Position is actually a UserDefined node. The UD node erroneously squares any numbers you type in. Who knows why. Anyway, I correct that by square rooting the values coming out of the node, so they are restored to the correct numbers.

Now, the node Distance_To_Light (actually a Color_Math node) takes the difference between the mesh position and the light position, computing the distance in each channel correspondingly for x, y, and z. So now we have delta x (dx), delta y (dy), and delta z (dz).

The next node, R_Squared (also a Color_Math node) multiplies these with themselves, one for each channel. This is actually R squared, which is what we need for the falloff.

Now go up and look at the Unit_Distance_V1 node. That node is actually a Math node. It is raising your unit distance to the 2nd power (squaring it). 

The next node Ratio (a Math node) computes the ratio of the unit distance (Unit_Distance_V1) with the distance to the light (R_Squared). Voila! That is the falloff light intensity ratio. That is plugged into the Light Intensity channel. This correctly modulates the light intensity over the distance you specified, completely automatically.

No modifications to mesh shaders is required at all.

I hope you enjoy this trick. I will be using it for all my indoor lighting from now on.

I have been keeping my mouth shut for days because I'm approaching my 1000'th posting at Renderosity. This post is #999 and I'm glad I held back because I just had to post on this issue. It's amazing what a difference it makes. I would post you some more renders to demo this, but I'm saving my next post (#1000) for the announcement of my Apollo Maximus skin shader. It is almost ready. After I post that, I'll come back here and show you more cool stuff. I'm also EXTREMELY busy at my real job releasing our latest version of software, largely written by me alone, so you can imagine what I'm dealing with. I've fixed over 40 bugs or enhancmenet requests in the last week.

Remember, you must put this shader on each light that you want to obey the true physical inverse square law. If you use several point or spot lights, attach it to each light, and make sure you type in the correct light position in each one. INCHES people. Remember the units are Inches.

After this, I will not be answering a single question until I finish the AM shader.

So if somebody has questions, maybe someone else can help out. I'm staying mum.

Angelouscuitry - I saw your other posts, but for reasons I just explained, I'm not going to answer just yet.


Renderosity forum reply notifications have been wonky in the past. I'm testing the waters to see if it's working now. If you ask me something and I don't come back, it probably isn't. (Updated January 17, 2017)

  AnAardvark    ( ) ( posted at 1:20PM Tue, 19 June 2007  · @3007400

Quote - Within Poser, you need to do two things - make the surface give the appearance of giving off light; and set an actual iight object by it to light the objects around it.

The simplest way to give something the appearance of giving out light is to turn your diffuse and specular settings down to 0, your ambient settings to 1, and your ambient colour to white. Your surface now glows white. If you want it to give off a colour, or perhaps use a texture map to drive the colouring of the light area, then you need to add a texture map, just as you would with most object in Poser (but add it to the ambient colour channel, not the diffuse colour).

 

You can also make part of an object appear to glow by using a mask to set the ambient valuess


  stewer    ( ) ( posted at 2:08PM Tue, 19 June 2007  · @3007444

Quote - I'm sorry I can't do this for you in the shader but Poser shader nodes cannot get that information.

You could write a Wacro that does that.


  Miss Nancy    ( ) ( posted at 2:23PM Tue, 19 June 2007  · @3007451

o.k., bill, thx fr the light intensity modifier. ya seemed to have covered everything in yer msg above, but we'll try to answer in case the others have questions on the technique. good luck with yer new software and the apollo skin shader.



  carodan    ( ) ( posted at 5:04PM Tue, 19 June 2007 · edited on 5:09PM Tue, 19 June 2007 · @3007590

For Spot and Point lights there is a Dist Start and a Dist End dial in the Parameters for the light which can be adjusted for falloff. I have no idea if this is another way of achieving what bagginnsbill's inverse square node setup does, but the dials are there all the same.

BTW - very excited about the Apollo Max skin shader!

 

PoserPro2014(Sr4), Win7 x64, display units set to inches.

                                      www.danielroseartnew.weebly.com



  jonthecelt    ( ) ( posted at 5:21PM Tue, 19 June 2007  · @3007608

No Dan, the dist start end end dials are quite different.

Dist start tells the light when it should start to fade, and sit end tells it when it should reach an intensity of zero. The progression from one to the other is linear. For example, I could set start to 10, and end to 10.5 inches. This means that the light would be at the full intensity I have set it at from the source all the way to the 10 inch boundary, and then would rapidly diminish to zero within 0.5 inches.

This is not how real light works. A light source in the real world is at its brightest at the source (no surprise there), but begins to diminsh as soon as the light waves have left the source. It does not diminish linearly, though, it obeys the inverse square law which BB has explained perfectly eloquently in his post, so I see no need to mangle it here with my confused mumblings.

Thank you somch for coming up with this solution, BB - although I'm shocked and surprised at you that you hadn't considered this problem before! It's always been something I've noticed, but figured there was little I could do about it. I do have one question for you, however (which I will gladly wait until you have completed the AM shader before answering) - how can this be applied to infinite lights? Due to there nature, there is no co ordinate data for these light types, and so I'm not sure how we can input the x/y/z data required by this shader.

I await your reply patiently, but with bated breath. :)

JonTheCelt


  carodan    ( ) ( posted at 5:30PM Tue, 19 June 2007 · edited on 5:31PM Tue, 19 June 2007 · @3007612

Ah, I see. I think I even asked how to do this ages ago at RDNA and got fobbed off with 'you don't need to worry about that sort of detail'. The lights in other apps I use have options to use different falloff calculations so this is very hndy to have for Poser.

 

PoserPro2014(Sr4), Win7 x64, display units set to inches.

                                      www.danielroseartnew.weebly.com



  Miss Nancy    ( ) ( posted at 8:44PM Tue, 19 June 2007 · edited on 8:45PM Tue, 19 June 2007 · @3007746

bill's set-up works for an infinite lite, but AFAICT one must move the infinite lite around to the approximate xyz-orientation given in the Light_XYZ_Position node. if a point lite is analogous to an infinite lite with xyz-trans and xyz-falloff, then there's probly no need to use an infinite lite in cases where fall-off is desired. if a lite (e.g. sunlite) is a large distance away from the scene it illuminates, then all the objects in the scene are within approximately the same radius, hence no inverse-r-squared effect.



  dvlenk6    ( ) ( posted at 9:55PM Tue, 19 June 2007  · @3007779

If the Dist. end works like it does in some other render apps I have (they call that 'far attenuation'); setting a value for it can signifigantly reduce render times by effectively limitting the number of intensity fall-off calculations.
For a linear fall-off, zero can be reached mathematically and the light will 'end' at some point; but...
For a quadratic fall-off formula, if there is no 'cut-off' distance supplied, the fall-off calculations will continue on into whatever passes for infinity in Poser; as the light's intensity will not ever reach zero mathematically.
Scenes with more area that is not confined by geometry (to stop the light rays); are more succeptible to this phenomenon.
I do not know if this is true in this case, as I do not render w/ Poser; but it might be worth looking into with some simple controlled timing tests.

Friends don't let friends use booleans.

  AnAardvark    ( ) ( posted at 11:44PM Tue, 19 June 2007  · @3007836

Quote - No Dan, the dist start end end dials are quite different.

Dist start tells the light when it should start to fade, and sit end tells it when it should reach an intensity of zero. The progression from one to the other is linear. For example, I could set start to 10, and end to 10.5 inches. This means that the light would be at the full intensity I have set it at from the source all the way to the 10 inch boundary, and then would rapidly diminish to zero within 0.5 inches.

This is not how real light works. A light source in the real world is at its brightest at the source (no surprise there), but begins to diminsh as soon as the light waves have left the source. It does not diminish linearly, though, it obeys the inverse square law which BB has explained perfectly eloquently in his post, so I see no need to mangle it here with my confused mumblings.

Thank you somch for coming up with this solution, BB - although I'm shocked and surprised at you that you hadn't considered this problem before! It's always been something I've noticed, but figured there was little I could do about it. I do have one question for you, however (which I will gladly wait until you have completed the AM shader before answering) - how can this be applied to infinite lights? Due to there nature, there is no co ordinate data for these light types, and so I'm not sure how we can input the x/y/z data required by this shader.

I await your reply patiently, but with bated breath. :)

JonTheCelt

 

Why would you want it to work with infinite lights? Generally, they are used for sun, moon etc. lights, and the difference in distance from one end of a poser scene to another is pretty minimal compared to the 10,000,000 poser units form the sun to earth.


  Pagrin    ( ) ( posted at 2:24AM Wed, 20 June 2007  · @3007878

Thanks for the fast responce. I'll see how I go with lighting and let you all know.
Pagrin :-)


  jonthecelt    ( ) ( posted at 8:55AM Wed, 20 June 2007  · @3007996

You're quite possibly right, AnAardvark - infinite lights probably don't need to use the inverse square law, as much because of the intensity of their original supposed source (sun, moon, etc), and the relative distance changes within the scene are ngeligible. But Bagginsbill said it would work with infinite lights, so I was just questioning how it would do so.

JonTheCelt


  BagginsFrodo    ( ) ( posted at 10:07AM Thu, 21 June 2007  · @3008812

Hello people - This is BagginsBill. I created another account so I can talk without bumping my post count as BagginsBill. :rolleyes:

I sent this as a site mail to jonthecelt, and suggested he could post this here, but either Jon didn't read it, or didn't feel he should post it. So now I'm posting it.


It is absolutely correct that when using an infinite light you are probably doing so because you're simulating a very distant light source such as the sun or moon. Such sources do obey the inverse square law but they are so very distant that over the small volume typically encompassed by a Poser scene, the amount of light is effectively a constant.

Nevertheless, for an infinite light it is possible you'd want to do this, with a slight twist that I did not address in the shader. Suppose you have a ceiling with dozens of small lights, like recessed lighting, or perhaps many flourescent lights spread over a large area. A proper and accurate simulation would require that you place a spot or point light up there to model each and every one of them.

Or - you can cheat. Use an infinite light pointing straight down and put some fall off on it. For the falloff origin (Light XYZ position) you LIE and put in a value that is in directly over the center of the ceiling, maybe 10 to 40 feet above the actual ceiling. This will modulate the light intensity so that things that are near the ceiling will be brighter than things near the floor.

We're cheating anyway so it is perfectly reasonable to accept that this is not physically accurate, but it is certainly MORE accurate than not doing any falloff at all.

One thing to note on this subject. A light source that is an infinite plane does not obey the inverse square law. Rather the falloff is inverse linear, 1 / R, where R is the distance to the nearest point on the plane.

Now a ceiling with hundreds of individual lights is not a point source (K / Power(R, 2)) nor is it an infinite plane (K / R), but something in between (K / Power(R, x)) where x is more than 1 and less than 2. It would be very reasonable to change the shader to have an exponent parameter and compute the linear ratio (instead of the square ratio) and then raise that ratio to the specified power. This would provide a very easy means to approximate a bounded planar light source such as a ceiling full of lights. More expensive renderers or some free renderers (such as POVRAY) typically have such light sources built in and they are called "area" lights.

Again, this would only be an approximation, but the level of inaccuracy may be sufficiently small, and it is certainly better than nothing. The few times I've tried to use 16 point lights to do this right, Poser slowed to a crawl.


  jonthecelt    ( ) ( posted at 8:13PM Thu, 21 June 2007  · @3009141

Hi, BB - sorry I didn't get your sitemail, been busy all day. Cunning workaround, though.

I seem to have come up against a problem with the light shader. I don't know if I'm misusing it, broken it, if theres a problem with it that I've discovered, or whether P6 and P7 work differently. Here's my findings, though.

I'm using the Dream Home: Great Room set from DAZ3D, and placing a point light in place for each of the light fittings in the ceilng (there are 11 in total). I decided that I wanted the lights to reach about 50% intensity by the time hte light reached the floor - 128 inches from the light fitting. Here's my results, using your shader:

I'm almost happy with this - I especially like the soft shadows on the walls - but there are a couple of issues. Why is the ceiling so dark, for one? the light traveling upwards from the pointlights at that close range (the lights are actually 8 inches below the fitings, to allow for the ceilng to be lit) should hit the ceilings with approximately 800% intensity. The other question is, if the ceiling is so dark, how can the domed area be so well-lit?

Anyway, here's where the breaking comes in. As an experiment, I thought I'd half the intensity, and double the unit distance - so no the lights are set to intensity 25%, and the distance is set to 256 (twice 128, gettit?). According to the inverse square law, if I understand it correctly, the end results should be the same, right?

As you can see, this clearly isn't the case. The lighting here is much brighter, leading to a hot spot in the breakfast nook wall. So why is this happening?

I do ave both light sets saved as .lt2 files on my computer, so I can send them to anyone who wishes to rplicate my work here. Whilst to truly replicate it, you would need the Great Room as well (which I obviously CAN'T supply), you can check the light falloff within something as simple as a rescaled box, to check this out.

Anyone who can help - whether it be 'BagginsFrodo' or anyone else - would be much appreciated. This is an innovative approach to indoor lighting that deserves to be tweaked and corrected until it becomes a valuable part of our toolkit.

JonTheCelt


  BagginsFrodo    ( ) ( posted at 8:57PM Thu, 21 June 2007  · @3009163

Let's address your last question first. You wanted to change the unit distance and intensity so that there was no net change, right? So you doubled the distance in order to enter half the intensity? I get it, but its wrong. When you double the distance, the corresponding intensity is 1/4 what it was, not 1/2. Remember - it's R SQUARED? You should have entered 12.5%.

As for why the ceiling is dark, it sure looks to me like the ceiling color is a very very dark gray. Did you look in the ceiling shader? What color is the celing? If you place an ordinary spot light shining up on the ceiling what does it look like?

Perhaps the dome is lit because you have not enabled shadows? Did you enable raytrace shadows on the point lights? Did you enable ray tracing?


  BagginsFrodo    ( ) ( posted at 9:02PM Thu, 21 June 2007  · @3009165

It sure doesn't look like there are lights in all of them, either. The ones near the window should be making a blazing light on the nearby wall.

And you know if you DO get them below the fixtures and they shine on the ceiling, that's not going to look real at all. Recessed lighting cannot directly light the ceiling AT ALL. In a room such as that, the ceiling is lit by bounced light from the rest of the room, or from light coming through the window.

I would place spot lights at each fixture, since they form a cone in real life. Then I'd use IBL to take care of the rest, or maybe one soft upward spotlight without shadows.


  Miss Nancy    ( ) ( posted at 10:27PM Thu, 21 June 2007  · @3009209

with point lites, the r-squared falloff actually works on any single flat surface which they're illuminating, even without using frodo's node set-up. try it with a point lite above the ground, and no nodes in the light material. you'll see that the point lite shows increasing falloff with the distance along the ground from the point directly below the lite, even tho no fall-off has been set (by default). of course, the point lite will still have incorrect fall-off when illuminating opposing surfaces at increasing distances. that's where frodo's node set-up comes in. what would be useful for ceiling illumination and such, is to have a renderer in poser which calculates reflections like most other ray-tracing renderers. altho an IBL inside a room would be counterintuitive (at least to me), for some wacky fun, try adding an image map to the diffuse channel of the point lite. for some reason, an IBL causes the projected lite to be soft and blurry, almost like in real life, but the point lite doesn't.



  jonthecelt    ( ) ( posted at 3:33AM Fri, 22 June 2007  · @3009294

Thanks, BB (or should I say BF for the moment? 😉)... you got me on both points. My logic on the calculations was flawed, although as soon as you corrected me, I realised what a numpty I was being. And yes, I know that with recessed lights such as this, there wouldn't be any actual light spill from the fittings onto the ceiling - it would be all GI that lit the ceiling. But that's why I was so confused about the ceiling dome. Yes, I had shadows set (as you can tell by the shadows in various places on the wall) and since all the lights in the scene are point lights, they must all be raytraced shadows, so I also had raytracing on. so where the illumination for the dome is coming from is beyond me.

As regards the colour of the ceiling... looking at the texture map, it's meant to be a creamy kind of colour, similar to the walls and the dome that you can see in my images. So not sure why it's coming out the colour it is in my versions. And yes, I'm also sure that all the lights present are in the correct place - I made all parts of the room invisible apart from the light fittings, and then used orthogrpahic views to place the lights correctly. So I do'nt know why some lights seem to be interacting with the ceiling more brightly than others.

'Tis a mystery, as they say.

JonTheCelt


  BagginsFrodo    ( ) ( posted at 9:48AM Fri, 22 June 2007  · @3009448

Miss Nancy,

I don't agree with your statement: *with point lites, the r-squared falloff actually works on any single flat surface which they're illuminating, even without using frodo's node set-up.
*What I do agree with is the observation that there is some kind of falloff built into Poser already. However, it is NOT because of the r-squared law.

It is because Poser (and all renderers) take into account the angle of incidence between the light source and the surface. Given a point light in front of a rectangle near the center, the angle formed between the surface normal, and the vector to the point light is small. Whereas, the angle out near the edges is large. It just so happens that those edges are also farther away, but that is not the reason they are darker. 

The Lambertian reflectance model says that the amount of reflected light will be in proportion to the cosine of the angle between the vector to the light (L) and the normal vector of the surface (N). See: Lambertian reflectance at wikipedia

If we define the following:

L = a normalized vector pointing from the surface to the light soruce
N = the surface's normalized Normal vector
C = the color of the surface
I = the intensity of the light
alpha = the angle formed between N and L

Then the rendered diffuse reflectance is:

(L dot N) * C * I

and since the magnitude of L and N are both 1, the dot product is just cosine(alpha) so the equation becomes:

cosine(alpha) * C * I

Under normal circumstances, Poser says I (the intensity of the light) is a constant. But it isn't really. So our introduction of the r-squared law changes the equation, because I is now scaled by the falloff rule (k/r)^2:

cosine(alpha) * C * I * (k/r)^2

where k is our unit distance.

This is more accurate the the simpler Lambertian equation. However, it is far more expensive to compute. In the old days, nobody would bother with this, but Poser is plenty fast at this calculation so I think we should use it.

So we've established that the diffuse reflected light drops off with increasing alpha, even without the shader. But what about viewing angle?

It turns out, based on my testing, that there appears to be an additional term in the equation that is influenced by viewing angle. Letting C represent the normalized vector from the surface to the camera, I believe there is an additional term in Poser's diffuse lighting equation.

Letting:

C = the normalized vector to the camera
R = the normalized mirror reflectance vector for the incoming ray of light

There are two possibilities of what is going on. One is that the whole thing is multiplied by 

C dot R

and the other is 

C dot N

I would have to do some seriously complicated experiments to confirm which one (if either) of those is correct.

The C dot R (raised to a power) is definately used in the specular reflectance calculation. It is not supposed to be used in the diffuse calculation, but I know that the diffuse reflectance in Poser is most definately affected by viewing angle.

I have been told that Poser Diffuse and Specular implement the Phong Reflectance Model but the evidence is against that.

I have also been told that the Poser Clay node implements the Oren-Nayar diffuse model - it may indeed.

I will show you why I think the diffuse is influenced by viewing angle in my next post.


  BagginsFrodo    ( ) ( posted at 10:09AM Fri, 22 June 2007  · @3009460


Here are 30 renders of a simple little setup from various angles. This is with an ordinary point light, located at the position indicated by the little white ball. The light is not generating any specular component as I set that to black. I also set the shader on the box so that there was no specular. So we're only seeing the results of the diffuse calculation built into the Poser root node.

Some key things to observe:

Most of the ceiling is dark - clearly the influence of L dot N is at work here. Jon - this supports your results where your ceiling was not lit very well, if at all. You're not going to be able to light up the ceiling, accept where the alpha is very small. We can see that in your render just fine.

Look at the blue arrow. Compare the wall's brightness to that of the render marked by the white arrow. Those arrows are pointing to the same spot, yet the white arrow one is clearly much darker. The only difference is viewing angle. This is why I suggest there is another term we don't know about. By the way - this issue of viewing angle has troubled me from the first time I used poser. Walls always look wrong to me, because in real life (as well as the definition of Lambertain reflectance) there is no difference between one viewing angle and another. My office walls look the same brightness no matter where I stand.

Finally I've discovered a bug in Poser. Observe the yellow and red arrows. There is an abupt increase in brightness despited only a tiny change in viewing angle. This is most disconcerting when viewing these images as an animation. In a still, you wouldn't notice it, but in animation it is incredibly obvious. It looks like the light suddenly got stronger. This is a bad bug.


  BagginsFrodo    ( ) ( posted at 10:10AM Fri, 22 June 2007  · @3009463


Here are the same renders, but using the inverse square law. Much different and much more accurate.

However, there is still this issue of viewing-angle dependent reflection, and the abrupt brightness change is still there.


  BagginsFrodo    ( ) ( posted at 10:40AM Fri, 22 June 2007  · @3009499


By adding an Edge_Blend node into the light shader, I was able to cancel out most of the viewing-angle dependent changes. 

I plugged the Ratio node into both Inner_Color and Outer_Color of the Edge_Blend. The Inner_Color was set to RGB(47, 47, 47). The Outer_Color was WHITE RGB(255, 255, 255). The Attenuation was 1.

The Edge_Blend is then plugged into the Light Insity, where the Ratio node used to go. As compensation, I had to rais the Intensity. Where before it was .05, now it was .18.

These settings are not exactly right, but directionally correct.


  Miss Nancy    ( ) ( posted at 12:46PM Fri, 22 June 2007  · @3009599

yeah, bill, that's what i suspected. it was the angle of incidence, and not inverse r-squared drop-off. that's why any surface normal to the vector of the light from a default poser point lite has the same apparent brightness, no matter how near or far it is. but once the angle is changed from 90 degrees, the surface will start to appear less bright in poser.



  XENOPHONZ    ( ) ( posted at 12:56PM Fri, 22 June 2007  · @3009607

Bumping your post count?  Hey -- compared to some, even I'm a piker in that department.

Post away, that's what I say.........

Something To Do At 3:00AM 



  jonthecelt    ( ) ( posted at 1:49PM Fri, 22 June 2007  · @3009653

Do you think it could be the difference in viewing angle - although slight - which is causing the difference in brightness of the lights against the ceiling in my images? I'll try slotting in the edge_blend fix, and see what it does (not tonight, though - I promised my good lady we'd sit down and watch a DVD, and I wouldn't come to the computer afterwards!)

JonTheCelt


  shedofjoy    ( ) ( posted at 8:14PM Fri, 22 June 2007  · @3009922

bmk

I post forum coments from my phone,woe is the pace of technology, now where is poser for android?

  jdcooke    ( ) ( posted at 3:31PM Mon, 25 June 2007  · @3011908

Hello Thanks bagginsbill for your hard work on this shader. I've been doing some experimenting with this shader and I've found that the fall-off become less predictable when negative values are used for the light's coordinates. That may explain some of the problems that jonthecelt is experiencing. jonthecelt, if you move the "Dream Home" so that it rests in the positive area in the world space then all the light will have positive values for their XYZ coordinates - that should produce a much more uniform fall-off for each light. take care jdc


  BagginsFrodo    ( ) ( posted at 3:46PM Mon, 25 June 2007  · @3011920

jdcooke,

Oh darn, you're absolutely right. The node "BugFixUserDefined" will not work for any coordinates that are negative, because I'm trying to take the square root of a negative number. Doh!

I hadn't considered that problem. Hmmm. It may be necessary to drop the use of UserDefined node for the light coordinates. I thought I was clever in dealing with the Poser bug that squares your typed-in values.

Here's a workaround. Change the parameters in the UserDefined node to 1,1,1. Connect each of those to a Math_Functions:Add node. You'll need 3 of them. Use THOSE to type in your light coordinates. (Enter your value in Value_1 of those adds. Leave a 0 in Value_2)  Then delete the BugFixUserDefined node and connect the Light_XYZ_Position node to the Value_1 input on Distance_To_Light. Then you should have no more problems with negative coordinates.

The reason this will work is that the UserDefined node does not square the values plugged into it. It only squares the numbers you type into its parameters.


 To create a post you must first sign in or register an account.

Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.