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

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?

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. 

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)

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

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.

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.

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

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

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

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.

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.

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.

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

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

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.

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

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?

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.

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.

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

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.

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.

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.

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.

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.

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 

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

bmk

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

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

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.

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

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

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

I didn't.

Wow...very interesting stuff. 

BM.

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?

*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.

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

Attached Link: A light meter for lighting experiments

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

Cool! thanks

*"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?

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

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)

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.

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)

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)

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.

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?

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.

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!

"gather" is still pretty slow in P7 IMVHO. not much point in using it, unless one hasn't got any other renderer.

Did you know that P7 actually has a Global Illumination feature in the renderer?

They didn't publicize it. There is nothing in the user interface to turn it on. But you can turn it on from the Python interface. I read something about this in the Python forum here. One of our Python gurus found these undocumented functions that actually make it do GI.

I guess it doesn't work very well, or they would have made it visible. If it had a good version of GI, I'd want it, even if it needed all night to render.

---

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)

Really?

Now that would be something worth investigating.

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

If the irradiance caching works, it won't take all night to render. Looking at what you said about the gather node's workings, coupled with the irradiance caching; it looks like they maybe trying to implement Final Gathering, which really only needs about 500 rays for production quality. Anything over 1,000 rays is insane. The cost (in render time) to return (in quality) ratio just isn't worth going any higher.
What kind of GI does Poser7 have hidden in it?
Is it photon mapping?
It would almost have to be to properly implement the Monte Carlo. With the Poser nodes, you could probably add various formulae to the Markov chain's probability sampling; and have a native MTL renderer. That would be a serious upgrade to the rendering quality, for the more patient users.
Maybe they just didn't get all the bugs worked out in the rush to put out a new version. That always seems to be the case with software.

Friends don't let friends use booleans.

Thanks bagginsbill, that was very informative, I appreciate your help!  So a Gather node would'nt work if there were no actual lights in the scene?

*"with a falloff based on distance. So it works like reflection. "
*What does Falloff do for a reflection, can it improve render quality, where is that controlled?

well, anyway, keep us posted on how to activate GI from the python interface. maybe that'll be a feature of sr4.

p.s. increasing the irradiance to 100% actually seems to speed up the "gather" render. increasing "gather" samples to 8 also helps, so it may be analogous to photon mapping. a quick render of the poser lo-res ball (with simple_colour node in both diffuse and alternate diffuse) above the ground (with gather node in ambient) showed that the floor demonstrates the "gather" effect with one lite at 0.000%. after deletion of the lite (no lites in scene), the floor still demonstrates the "gather" effect.

Miss Nancy - May we see the render, pretty please?

no lites, raytrace settings for higher quality, etc. it took about 10 seconds to render at 8 gather samples, 1.0 shading rate, 3 pixel samples vs. about 50 seconds at 16 gather samples. 0.2 shade rate, 8 pixel samples, but of course the latter results in better photon mapping.

This line of GI discussion should probably be another thread, as IMO, it deserves it's own topic as a very important (maybe the most important of all) photorealistic feature that is currently missing from Poser rendering.
Anyway...

---

Note that It isn't required that a surface be able to generate photons in order for there to be global illumination: Surface photon generation is a shader quality, GI is a property of the overall light model.
A simple standard test for CG light models is to set up a cornell box and observe the render.
Maybe someone with Python script experience will run a CB test or two with Poser's hidden GI feature?

The sphere is not generating photons, unless I'm mistaken. If the sphere were generating photons, then the ground could be a simple diffuse white and be affected by the sphere emmissions. The ground is pulling diffuse color from the sphere. Different concept altogether than GI.
The 'Gather Experiment' here reminds me of Bryce's True Ambience, with the addition of surface shaders. It definetly adds photorealistic qualities to renders; but isn't GI, and it's computationally expensive.
TA (NOT T&A) accounts for specular reflectance also.
Does the gather node pull in specular responses of a nearby surface?
Thats another piece of eye candy that adds realism to renders.
Take it for granted that it would probably increase render times to do so.

Friends don't let friends use booleans.

Ouh, thank you Miss Nancy, this is very nice!  I wonder why it is purple, I do'nt see anything purple, connected to the PoserSurface node?

Hmm, bagginsbill, what do we think?

angel, it's purple because the poser lo-res ball's got a simple_colour node (purple) plugged into both the diffuse and alternate diffuse channels. as mentioned by dv, it's not actually illuminating the ground, but rather the ground is pulling colour from the ball.

I can see where the inverse square thing is something I should keep in mind.  I'm really concerned about the diffuse lighting acting like specular lighting, though.  This just has to be a bug, and needs to be fixed.  I'll venture that it is the singular reason Poser renders can be so easy to spot to a trained eye!  Certainly I've fought against it without ever realising just what was amiss.

Indeed. And ironically, the specular lighting almost always SHOULD exhibit decreased reflection when facing the camera - i.e. the Fresnel effect. And yet it doesn't - we have to add it to the shaders over and over. In the Modo forums they say "fresnel makes everything look good".

I hope someone finds a way of unlocking the hidden GI....i will be keeping my eyes peeled

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

Baggins... a thought occurs to me. Rather than using the fresnel effect on all the object materials, in order to give more accurate specular effects; could it not be pluged into the specular channel of the lights themselves? By making the specular channel of the light behave properly, then it would save having to do it to each and every object we find in our scene.

Just a thought, and I realise it's entirely possible that this wouldn't solve anything.

JonTheCelt

Jon,

Absolutely - you could probably fix a lot of scenes by putting fresnel on the lights.

Since we've discovered that the diffuse light is inverse fresnel (i.e. it gets brighter towards the camera and darker away) then fresnel on that would improve things.

And so if you want fresnel on the diffuse (to cancel the inverse fresnel that isn't supposed to be there) and also fresnel on the specular (because its missing) then just stick it on the light intensity.

Of course, if you want to control the fresnel and anti-inverse fresnel separately, then you should put one edge blend on the diffuse and another on the specular.

Either way, I bet this would give you a lot more control that could be put to good use.

However, a word of caution. If you are using materials that already properly include fresnel on their specular response (like any of my shiny materials or my new skin shader) then the addition of fresnel on the light itself will accidentally square the effect and produce undesirable results.

---

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)

My head a splode...

Well, I haven't messed with the noodles enough to get to that anyway.  I've played with bump, and displacements (Damn, every material that looks good has values in the <.2 range...  Shouldn't they recalibrate those?) environments and ambient...  Pretty much mastered those, and moving to math functions and procedurals next.  It wouldn't cause me too much trouble to put fresnel (how's that pronounced anyway?) on the lights, though I'd never have thought of that by my lonesome.  Things is, originally I had some crazy fantasy of foregoing rendering altogether and just running some filters over the preview output. Now I'm wondering if the enhanced hardware preview will render the corrected lights properly? (I've temporarily  given up on that partly because I like bumps and displacements, but mainly everything looks too floaty w/out shadows.  I'm seriously hoping for GLSL bump and parallax displacements with shadow mapping in P8's preview)  

While I'm on that topic allow me to post my first ever image to the forum:

Yeah, that's just one polygon.

Some Experimenting with the Inverse Square node and the Global Illumination Python script First one is Standerd Poser 7 Spot Light + infinite

Next applying bagginsbill's Inverse square shader....

And finally Stewer's Global Illumination Python script scene = poser.Scene() if (scene != None): settings = scene.CurrentFireFlyOptions() if (settings != None): settings.SetGIIntensity(0.5) settings.SetMaxSampleSize(16) settings.SetGINumBounces(3) settings.SetGINumSamples(16)

Argh!, the forum didn't maintain the spacing for the script, it should look like this anyway,... copy and paste the script, name it "gi.py" and save it somewhere you can find it. You call it up just before a render and it'll add values to some undocumented firefly settings. You can experiment with different values such as the numer of samples and see how it turns out. It ain't perfect, but it could be fun. have fun jdc

jd, thx fr the info. is the GI script causing the lighting to bounce rays off the floor, thus causing the trousers to pick up the floor colour? lemme see if this attachment works.

That is correct. Also, forgot to add that the last pic uses bagginsbill's inverse square node together with the Stewer's GI script - putting those two things together makes a big difference. take care jdc

Oh my oh my - this is getting interesting. The GI actually is a big improvement in this scene. I"m noticing so many differences that are meaningful. 

Could you do more? If done right, then bright "sunlight" coming in the window should light everything in the room. You probably have to raise the infinite light so much that it blows out on the directly lit things, but that happens in real life too when you set you shutter speed and aperture to pick up the indirectly lit elements of the scene.

Here's my continuing saga with the Great Room setup - I'm very nearly at a point wher eI might slip a figure in and render it off as a finished image (how exciting, eh?)

I switched from point lights to spots, and set them to a 180 degree angle. When I did this, I noticed something that's worth keeping in mind for other users of this script - you need to set both angle start AND angle end to the same setting - don't keep angle start at the '0' level. If you do this, then the lights don't work properly. I would imagine this is because the light material now controls all the falloff, so combining the linear fallof of angle start/end with the inverse square falloff of the material causes curious things to happen... on the other hand, that might not be it at all: I'm sure Baggins can exaplin this better than I.

Removing the point lights meant that the ceiling was no longer lit at all which was unrealistic - in the real world, due to GI, the ceiling is lit indirectly by the light bouncing off all the other surfaces. To compensate for this, I disabled the floor's "cast shadows" option, and set an infinite light pointing straight up at 50% intensity to act as a bounce light. I turned the bounce light's shadow setting down to 0.3, and its shadow blur radius to 20 (the highest you can get on raytraced shadows). Without any furniture in the room, this is what you get:

I like this, but at the moment, the ceiling looks incredibly flat. So I added in some furniture, and increased the render settings (minimum shading rate down to 0.5, and bucket size down to 32). The following render took about 6 hours to complete (I am SO upgrading in the next month or so - only on an AMD Sempron 2300+ with 512 RAM at the mo):

Looking at this, I'm inclined to think that perhaps the ceiling is a little bright - in the next render, I might bring the intensity of the bounce light down to maybe 30-35%, instad of 50. I like the soft shadows projected up there from the furntiure, though, especially the subtleties captured in the dome (which looked horribly flat in the previous render). OH, yes... the only other material I dickered around with on this was the glass setting - I used BagginsBill's fresnel glass shader on the windows and door glass, in order to give the reflections in the glass and the ground/skydome outside. Other than that, all the materials are as they were in the original Great Room package, and I'm really pleased how they've come out. I love the reflections in the poished wood floor, and the edge effect on the sofa works beautifully, too.

The next step for em here, I think, is to get the ceiling looking right. For the moment, I think I'm going to forgo the GI script, although I have dutifully copied it and saved it away in my runtime for later use - I just don't thnk my computer has enough power in it yet to pack that kind of punch. So it's just a matter of tinkering with the bounce light's settings until I'm completely happy with what comes up.

Any feedback on these images, including sugestions on where to work on them, would be much appreciated.

JonTheCelt

in image 2, the ceiling is o.k. IMVHO. it's an excellent render. I found the GI script (sans bill's inverse-square node set-up) is causing artifacts along bucket edges that I can't get rid of, trying the usual fixes. but the GI fx are very striking and interesting to see for the first time in poser, for me at least.

Jon that looks excellent. It seems the approach you're taking is worthwhile, as that looks very very good.

---

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)

Yeah, those artifacts in the GI render are a real pain - I guess that's why the feature isn't officially supported. The markings are very specific and don't change under different lighting conditions, so it may be more of an issue with the 3D mesh. Oh well, like I said it ain't perfect but it might be fun to tinker with. Hey jon, that room is looking good. later jdc

in the attached image, all the objects have 0 specular, 0 ambient, 0 reflection etc. 2 white spotlites at 37.5%; nonstandard cornell box. procedure: 1. load all objects and render (ray-tracing, medium settings) - top image 2. run GI python script 3. re-render with no change in any settings - bottom image stefan said to turn off AO, and depthmap shadows caused p7 to crash, hence I was limited to ray-trace shadows. perhaps somebody will have suggestions on how to eliminate the artifacts, e.g. add a variable to the script for "no interpolation", add a variable to the script for "photon count", etc.

Thank you MN - very interesting. Hmmm. Hmmm.

Is there a way to use this gi script to light a scene without using any lights at all? Something like in Lightwave.

same props as above renders, but no lites. all surfaces have 0 specular, 0 ambient, 0 gather, 0 alternate diffuse etc., excepting the lo-res ball, which has grey alternate diffuse. still awaiting word on how to get rid of artifacts. dunno about lightwave, but in poser, it seems as if the gi script is causing the lo-res ball to illuminate the box surfaces.

Here's a scene without lights as well. Just a nice, bright quartz texture plugged into the Alternate Diffuse of a crystal prop. I bounced the light about 9 times - the more bounces the brighter the illumination. The whites of the eyes get blown out, so the eyeball texture may need to be darkened for the next run later joe

it almost appears that AO was on. there are several more variables that may be of use in the script, but I dunno what the variables control:

        useRenderer p5
        settings 
                {
                shadowRenderShadingRate 16
                hairShadingRate 8.000000
                useSumAreaTables 0
                rayAccelerator 0
                occlusionCulling 0.000000
                maxError 0.500000
                maxICSampleSize 16.000000

Could be, I'm still pretty new at this, Thanks for your help. jdc

Quote - Jon,

Absolutely - you could probably fix a lot of scenes by putting fresnel on the lights.

Since we've discovered that the diffuse light is inverse fresnel (i.e. it gets brighter towards the camera and darker away) then fresnel on that would improve things.

And so if you want fresnel on the diffuse (to cancel the inverse fresnel that isn't supposed to be there) and also fresnel on the specular (because its missing) then just stick it on the light intensity.

Of course, if you want to control the fresnel and anti-inverse fresnel separately, then you should put one edge blend on the diffuse and another on the specular.

Either way, I bet this would give you a lot more control that could be put to good use.

However, a word of caution. If you are using materials that already properly include fresnel on their specular response (like any of my shiny materials or my new skin shader) then the addition of fresnel on the light itself will accidentally square the effect and produce undesirable results.

 

So much info...  Fresnel cancels inverse fresnel, does it have to be increased then I wonder...

bm

Anyone else have Poser hang at render-time with this GI script?  Renderbar just won't move.

That could be down to the fact that GI renders in Poser take approximately forever. 

My Freebies
Buy stuff on RedBubble

it's not practical to attempt large renders with IL enabled and hi-quality settings
if scene contains complex poser figures.  all known desktop computers will be
very slow.  enabling depth-mapped shadows and/or AO (in lite properties) may
cause the machine to freeze/crash/slow to a crawl.

Ah.  Sigh.

I tried out the script, but I'm having the same problem.  It seems to make Poser lock-up just when it would start rendering.  Either that, or it just takes a ridiculously long time and I just got impatient.  I did make all shadows ray-traced.  Any ideas?

It takes a ridiculously long time to render.  GI calculations are quite intensive even for software that's designed to use it - the GI in Poser is an unsupported hack

My Freebies
Buy stuff on RedBubble

bookmark

Let me introduce you to my multiple personalities. :)
     BluEcho...Faery_Light...Faery_Souls.

the developer used OS X, hence maybe these variables are in a more stable environment
in OS X than in windows.  I can usually finish a poser GI render, but it's mind-numbingly slow.
however, if ya jack up all the GI settings in Carrara to the max, that renderer is also real
slow.  that's why 3d users take various shortcuts when they're on a deadline.  it can look just
as good without all the settings at the max, if one follows the various lite/shadow/shader tips
posted here by baggins et al.

in movies they actually dont use GI a lot of times. i was shocked to found this. ok not when i found out how long it takes to render.

pixar is stylized. but did you know that they are using in some shots like 100 lights?

That's how they fake GI - take a look at [Digital] Lighting and Rendering some time - gives lots of good ideas about CG lighting

My Freebies
Buy stuff on RedBubble

i wonder if bagginsbill's inverse square law shader will be written inside poser 8. lights should be updated when you move them around. we should not always writte numbers .
i was using yesterday 6 lights. it was really hard to update everytime every light to make it looks right.

they should writte the shader inside so that it updated automatic.

I see ... something I can't talk about.

---

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)

Quote - I see ... something I can't talk about.

thank you for your answer he he :) 

o.k. then - it's good to know they're gonna incorporate that and the other various items into P8.

p.s. to speed up GI render, drop IC to 0.  this means maxError is 1, causing low photon count and blocky-looking IL fx, but will allow a quick perusal of the GI result to decide if it's gonna be worth a longer render.  then make sure the final render is the first one done after starting up poser.

Quote - Here's a scene without lights as well. Just a nice, bright quartz texture plugged into the Alternate Diffuse of a crystal prop. I bounced the light about 9 times - the more bounces the brighter the illumination. The whites of the eyes get blown out, so the eyeball texture may need to be darkened for the next run later joe

what was the material room settings for that cause that is the effect i want to make =)

bm