Thu, Nov 28, 6:32 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 28 11:20 am)



Subject: How do I make a surface a light?


Pagrin ( ) posted Tue, 19 June 2007 at 3:25 AM · edited Thu, 28 November 2024 at 6:31 PM

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 Tue, 19 June 2007 at 3:44 AM

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 Tue, 19 June 2007 at 9:59 AM

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 Tue, 19 June 2007 at 11:32 AM

file_380599.doc

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 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)


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

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 Tue, 19 June 2007 at 2:08 PM

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 Tue, 19 June 2007 at 2:23 PM

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 Tue, 19 June 2007 at 5:04 PM · edited Tue, 19 June 2007 at 5:09 PM

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 Tue, 19 June 2007 at 5:21 PM

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 Tue, 19 June 2007 at 5:30 PM · edited Tue, 19 June 2007 at 5:31 PM

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 Tue, 19 June 2007 at 8:44 PM · edited Tue, 19 June 2007 at 8:45 PM

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 Tue, 19 June 2007 at 9:55 PM

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 Tue, 19 June 2007 at 11:44 PM

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 Wed, 20 June 2007 at 2:24 AM

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


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

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 Thu, 21 June 2007 at 10:07 AM

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 Thu, 21 June 2007 at 8:13 PM

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 Thu, 21 June 2007 at 8:57 PM

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 Thu, 21 June 2007 at 9:02 PM

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 Thu, 21 June 2007 at 10:27 PM

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 Fri, 22 June 2007 at 3:33 AM

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 Fri, 22 June 2007 at 9:48 AM

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 Fri, 22 June 2007 at 10:09 AM

file_380830.jpg

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 Fri, 22 June 2007 at 10:10 AM

file_380831.jpg

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 Fri, 22 June 2007 at 10:40 AM

file_380833.jpg

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 Fri, 22 June 2007 at 12:46 PM

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 Fri, 22 June 2007 at 12:56 PM

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 Fri, 22 June 2007 at 1:49 PM

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 Fri, 22 June 2007 at 8:14 PM

bmk

Getting old and still making "art" without soiling myself, now that's success.


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

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 Mon, 25 June 2007 at 3:46 PM

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.


jonthecelt ( ) posted Tue, 26 June 2007 at 1:03 AM

Just as an update - I reworked the scene, moving the point lights up closer to the fittings, and using the edge blend fix that BB had discovered for the viewing angle problem. This seems to have taken care of the two major problems: the dome is not longer light up where the ceiling is dark (because of the more correctly placed lights) and all the lights appear to be the same brightness (now none of them bloom on the ceiling). As BB said, I've had to ramp up the intensity somewhat to get the same light levels I had previously, but that's fine. The other thing I'll do, which I haven't done yet, is to add a non-shadow casting infinite 'bounce light' pointing up from the floor to allow the ceiling to have some illumination. Having looked at the lights in our kitchen at home, which are a similar style to these, the ceiling does not remain dark, due to indrect and bounced lighting. While a completely accurate simluation of GI is probably beyond Poser's abilities, I think adding in a bounce light should create the illusion nicely.

Un;ess someone can think of a better suggestion?

JonTheCelt


jonthecelt ( ) posted Tue, 26 June 2007 at 1:06 AM

Cross-posted with ye, BB (or Bf, or whatever) - I'll give this a try and post the results.

Incidentally, whilst I know I've said it before, thank yo so much for having xome up with this solution. To me, the lck of Inverse Square faloff in Poser was one of the biggest hindrances to getting a believable look to my work. If we can nail this, then this deserves to become part of everyone's toolbox!

JonTheCelt


Angelouscuitry ( ) posted Tue, 26 June 2007 at 1:33 AM

bagginsbill - How did you get the light, of your first image, to be Cone shaped?


BagginsFrodo ( ) posted Tue, 26 June 2007 at 8:06 AM

file_381233.jpg

I didn't.


Robo2010 ( ) posted Tue, 26 June 2007 at 8:30 AM

Wow...very interesting stuff. 

BM.


Angelouscuitry ( ) posted Tue, 26 June 2007 at 9:03 AM

Thanks BagginsFrodo!

Hmm, I still did'nt expect the light, itself, to be visible.  Is it's current shape the default?   Could you change that much, with Matmatic; maybe make it a sphere?  I'm wondering if a Matmatic Sky Dome could cast light internally, with any quality?


BagginsFrodo ( ) posted Tue, 26 June 2007 at 10:47 AM

*Hmm, I still did'nt expect the light, itself, to be visible
*The "light" is not visible. I don't understand what you're talking about. There is a candle prop floating in the air. That is not the light. There is a cone prop on the floor. That is not the light.

If you place a sphere exactly where the light is and turn off shadows for that sphere, then the sphere will look like it is the light. That's what I did in those black-and-white renders of the striped room.


jdcooke ( ) posted Tue, 26 June 2007 at 10:49 AM

Just to clearify. The light source element itself is never visible. The candle simply represents the position from which the light source emanates. The cone on the floor is a standard prop and it appears to be bright because it is sitting so close to the light source. The inverse square ratio dramatically changes the nature of the standard Poser light source - and by using it you need to change the way you handle light in any given scene. You have to deal with the same problems and obstacles that a Photographer or Cinematographer would have. Any object too close to the light will blow out the exposure and any oblect too far away will be too dark to see. The light source and the subject have to be arranged correctly in order to provide the desired mood - just like in real life. It's more difficult but the upside is that the final render should look much more natural/realistic than ever before. hmmm, we might need a Poser Light Meter..... :) take care jdc


BagginsFrodo ( ) posted Tue, 26 June 2007 at 10:57 AM

Attached Link: A light meter for lighting experiments

I have a light meter! Check out the linked thread!


jdcooke ( ) posted Tue, 26 June 2007 at 11:03 AM

Cool! thanks


Angelouscuitry ( ) posted Tue, 26 June 2007 at 1:50 PM · edited Tue, 26 June 2007 at 1:54 PM

*"The light source element itself is never visible."*That's not true?  Allthough not tradition Lights, Poser can add Glow and then Gain, to any Geometry.  Glow would make an object Visible, and Gain would cause it to emmitt light.  But objects that receive only Gain'd Light, are'nt usually very attractively detailed?


Miss Nancy ( ) posted Tue, 26 June 2007 at 2:40 PM

bill, the mt5.txt file attachment appears to be missing from that light meter thread.



bagginsbill ( ) posted Tue, 26 June 2007 at 2:43 PM

Crap messed up my post count. Oh well.

The mt5 is there. I uploaded it when you could only attach images. It looks like a broken image, but its actually the meter.mt5 file. Click it.


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)


Miss Nancy ( ) posted Tue, 26 June 2007 at 3:52 PM · edited Tue, 26 June 2007 at 3:53 PM

o.k., got it, bill. the broken pict didn't show in netscape, but it showed in safari. oops! I seem to have missed yer post 1000.



bagginsbill ( ) posted Tue, 26 June 2007 at 4:11 PM

I tried to undo my post count by deleting the post, but it didn't drop. So oh well.


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)


bagginsbill ( ) posted Tue, 26 June 2007 at 4:17 PM

Allthough not tradition Lights, Poser can add Glow and then Gain, to any Geometry.  Glow would make an object Visible, and Gain would cause it to emmitt light.  But objects that receive only Gain'd Light, are'nt usually very attractively detailed?
Huh? You can make a shader draw any colors regardless of lighting by plugging things into he ambient, alternate_diffuse, or alternate_specular, reflection_color, refraction_color, etc. inputs on the root node. This can simulate the appearance of the object glowing. But no objects actually "glow" in the sense that light is emitted into the environment and appears in the diffuse or specular calculations of other objects.

There is a "Gather" node that is basically a super-blurred reflection but it is not at all the same as the Global Illumination features you have in other renderers such as Modo. Modo can make any prop truly emit light. It is possible to make a scene with absolutely no "lights" whatsoever in Modo.

In Poser I can make any object show any color I want, and theoretically I can write enough math into every shader that it seems to be reacting to some prop that glows. But that's not built into Poser at all.


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)


Miss Nancy ( ) posted Tue, 26 June 2007 at 5:19 PM

bill, is that lite-meter-prop a torus, 8 spheres and 1 oblate spheroid? there may be a way for them to host the file, if so.



Angelouscuitry ( ) posted Tue, 26 June 2007 at 6:49 PM · edited Tue, 26 June 2007 at 6:51 PM

Gather!  That's it, not Gain, sorry!

Check out my post, in glow effect in poser help!, on Thu, May 17, 2007 5:17 pm, Edited Thu, May 17, 2007 5:21 pm

(Especiall Raven's Green Ball scene!)

And, The Gather node?, at RDNA.

So Gather can emitt light, it's just very lousy.  I'm hoping there is some good reason behind that though?


BagginsFrodo ( ) posted Tue, 26 June 2007 at 6:59 PM

Gather doesn't emit light. It gathers light. It is an extra step they added to Firefly that you can invoke using node. It is poorly implemented - the way it works is that it shoots out random rays and looks at what it hits. Then it asks what it hit to compute its shader value and uses that to color the object its on, with a falloff based on distance. So it works like reflection. However, unlike reflection which shoots a ray in a well know direction every time, these rays are in pseudo random directions with a well defined probability distribution. This is called a Monte Carlo simulation. The true "gather" effect would require hundreds of thousands, or even millions, of rays before it becomes accurate (and smooth). Because no Poser user would ever tolerate a 15-day render, nobody uses enough samples to get it to look good. So it never looks good. It actually can look good, but I'm not willing to wait that long.

Other renderers speed things up with something called "irradiance caching" - which basically means cutting the world up into little voxels (3-D volume chunks, like pixels are for 2-D). As rays ask for gathered light info, the consult the enclosing voxel. The next ray that hits the same voxel does not need to calculate much since that voxel has already been calculated and cached. But making the voxels larger, you cut way down on calculations, but get smeared blurry results. Make the voxels smaller, and you get more accurate approximations, but much slower results.

Poser 7 has a render parameter called "irradiance caching". Unless they made that up, I believe they use it for ambient occlusion performance improvements. When you adjust that parameter, you're adjusting the voxel size, trading speed for quality. It may be that the Gather node uses it as well in P7, in which case you may be able to get better faster results now. You should try it. I don't have P7, and have no plans to get it. Everything I care about is either broken or just the same in P7 versus P6.


ClawShrimp ( ) posted Tue, 26 June 2007 at 8:30 PM

I'll have a swing at testing the gather node in Poser 7, but like everything else in the Material Room, I doubt anything has changed since Poser 6.

Amazing that they can call 7 an entirley new version by simply adding three things. The morph brush, 'faux' HDR, and a freaking undo button.

Sad as it is, I actually love all three! :P.

If we can hit that bullseye, the rest of the dominos will fall like a house of cards...checkmate!


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.