I don't have a theory that makes a prediction. At this point, all I know is we were seeing different things and arriving at different hypotheses. I used a huge dome or sphere. You used a "small" box. (Small being relative. The surface area of my dome is 3.5 million square feet.)

One-sided polygons don't behave the same in these two scenarios.

I also found in poser 7 that FFRender works better with GIVariables activated if walls/floor are made of poser boxes rather than planes.  it seems to prefer an object with thickness to bounce off of.

Quote - You're not talking about AO? 

Did I say I was talking about AO?  AO = AO, Shadows = Shadows.  I don't know why you would read "shadows" and interpret it as "AO".

Quote - Load a one-sided square. ...What is your theory?

The one-sided square prop is a single polygon, and it's a common thing in GI rendering in other apps that polygon density will affect accuracy of how GI is applied.  It has to do with the number of samples being allocated on a per-polygon basis.  I would expect a higher poly object of the same shape to behave differently (more accurately).  I'm not sure of the point you were trying to make, but this is still useful information even if it doesn't have to do with what you're getting at.

bagginsbill -> Quote -

Are you using GC shaders with IDL? I haven't tested extensively, but I think you really can't. The data that GC shaders reutrn is for how to make that luminance on a screen. For light measurement purposes, those numbers are way too high. That would cause over-exposure for sure. That's why linear rendering is so important.

With Poser 8 and IDL, dump GC shaders altogether. Use linear output only from shaders. Make sure all diffuse calculations throw less light than arrives (Diffuse_Value < 1). Use HSV Exponential Tone Mapping at 2.2 for the final adjustment (approximately) to sRGB color space.

Oh, brother, I wish you hadn't said that. It had crossed my mind once but I'd firmly repressed it. IF this IDL is really working in linear space, then the "right" answer would be to un-GC the input color maps, but not GC the shader outputs; Tone Mapping at 2.2 would then properly, I think, GC the final image. BUT, what about the direct light hitting the same shaders? I doubt that part got rewritten to work in linear space - it would break everything - and direct lighting probably dominates in lots of scenes. I don't think you can have both right at the same time if IDL is really linear.

Whichway
[Trembling in fear of a divine thunderbolt.]

Quote - > Quote - You're not talking about AO? 

Did I say I was talking about AO?  AO = AO, Shadows = Shadows.  I don't know why you would read "shadows" and interpret it as "AO".

Because I know you're good with CG. In my mind, directional shadows on IBL is nonsense.

So, I did not even begin to imagine you'd ever make the mistake of using a directional shadow system on an omnidirectional light source. That makes no sense. So I didn't see why you'd even bring it up, when discussing how IBL works. it wasn't relevant to even discuss directional shadows on IBL, when the IBL is used for ambient lighting, which is 99.99% of the time.

Quote - > Quote - Load a one-sided square. ...What is your theory?

The one-sided square prop is a single polygon, and it's a common thing in GI rendering in other apps that polygon density will affect accuracy of how GI is applied.  It has to do with the number of samples being allocated on a per-polygon basis.  I would expect a higher poly object of the same shape to behave differently (more accurately).  I'm not sure of the point you were trying to make, but this is still useful information even if it doesn't have to do with what you're getting at.

Now you seem combative. I dont' know why. If I do the same demonstration with a wall made of 10,000 polygons, does that change anything? Further, how does a denser set of vertices come into play, when simply duplicating the single polygon suddenly produced a completely different outcome?

Attached Link: http://www.hsmespanol.com/IL-Tests.jpg

From top to bottom:

IBL-based ambient lighting with shader-based GC and AO, no HSVE

IL-based ambient lighting with shader-based GC and AO, no HSVE

IL-based ambient lighting with light-based AO and HSVE

Well the oversaturation comes from the fake SSS factors. When we build shader-GC, the effect of the fake SSS is pretty weak, because the final GC step severely desaturates. Most of the anti-GC'd incoming material is hypersaturated so it comes out right. But I at least never bothered to put an incoming GC on the shade of red I use for SSS.

Basically, the fix is to simply use a less saturated and less bright red for faking SSS. Then HSVE works fine.

But I have to say, #2 looks GREAT.

Quote - So, I did not even begin to imagine you'd ever make the mistake of using a directional shadow system on an omnidirectional light source. That makes no sense. So I didn't see why you'd even bring it up, when discussing how IBL works. it wasn't relevant to even discuss directional shadows on IBL, when the IBL is used for ambient lighting, which is 99.99% of the time.

And I don't know why you brought up AO, since Stefan explained that when indirect lighting is enabled, light-based AO is skipped.  I'm assuming he knows what he's talking about, but assumptions can be perilous things.

Quote - Now you seem combative.  I dont' know why.

I don't know why it seems that way to you either.  I suggest you re-examine my posts and check your conclusion.

Quote - If I do the same demonstration with a wall made of 10,000 polygons, does that change anything? Further, how does a denser set of vertices come into play, when simply duplicating the single polygon suddenly produced a completely different outcome?

You're in a much better position to find out for sure, since you're in regular communication with Stefan.  Ask him.  Since I don't know the internals of Poser's GI algo (even if I did, I wouldn't really understand them) it is likely that he will give you a better answer.

You both can come off like pompous asses.

For some reason Pjz seems to think the more of an ass he is the more people will take him as a force to be reckoned with, yet he wastes BB's valuable time in another thread rendering w/ poly smoothing "on". Rookie mistake.

I think BB is a misunderstood genius dork. Very, very good at math but tends to talk down to some, not communicate with others, and is pleasant to those he chooses to be.

You both should shack up together! lol.

It is very important to me that random people on an internet discussion board think that I am a force to be reckoned with.  I demand that you all bow and kiss my pinky toe.  Not fucking around here.

Well I've done enough experiments to confirm a working hypothesis. It may not be 100% correct yet - there could be some exceptions. I did not do extensive experimenting with polygon density - just a handful of cases involving objects from 1 to a few hundred polygons.

Given a subject, such as a sphere in the middle of the scene, and you want to know how IBL or a self-lit surrounding prop such as the environment sphere or a box will affect the subject, here is the answer. IBL is effectively an infinite virtual sphere, so the analysis is the same as for a glowing prop that surrounds the scene, even if that prop isn't spherical.

Given any point on the subject, imagine a line passing from there to all the points of the glowing environment. If any given line passes through two opaque polygons, then the IDL contribution to lighting the subject from that area of the glowing environment is zero. Period. Doesn't matter which way these polygons are facing, or if shadows are off for the occluding polygons.

If there is nothing in between, the full effect of the glowing light source will be used.

If there is exactly ONE polygon between, then the amount of the glowing light source leaking through that polygon depends on the distance of that occluding polygon from the subject. If the distance is less than 1 inch, as I showed with props on the Ground or one-sided square as a wall, nearly 100% of the light will leak through. I tested this with a box, too, although it was difficult to get the camera inside a small box. If the distance to the occluding polygon is on the order of tens of feet, about half leaks through. If it is 750 feet (my EnvSphere radius), only about 6% leaks through. I could never get it to go to zero.

That's it.

Props that represent bounded volumes will reliably block IBL 100% because IBL will not leak through two polygons on the same line. In order to leak through a bounded volume, it has to go in and go out - that's two polygons. So a nearby box or cylinder always throws an occlusion shadow.

However, even a pair of parallel squares, perfectly in alignment, will block the light, although technically there is no inside/outside in this case. It's a simple matter of passing through two, even if simultaneously.

Any time you have only a single surface between the subject and the diffuse light source, the diffuse light will leak through. This is even true of nested spheres.

If you place two nested spheres around your subject, and you make them both black, your subject will receive no light from IDL. If the outer one is glowing red, the amount of red that leaks through will depend on the radius of the inner one, because the inner sphere is the only polygon between the subject and the outer sphere. The inner sphere glow will be used 100% in either case. The total diffuse luminance will be the inner sphere glow plus some fraction of the outer sphere glow.

If you have 3 nested spheres, the outermost, even if glowing, will not light the subject, because to reach it it would pass through two polygons.

I have demos, but I'm getting pretty tired. I'll post them another day.

By the way, I'm just ignoring the bullshit. This is really interesting to me and it explains a lot of things, like why the ground doesn't work right.

You seem to think it necessary to be in control, or a teacher...when no one has really asked you to be.

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2778765
*"I told you this at least twice, and in general I explained this 6 or 7 times to various people who asked.."

*So this person wanted to share what they have learned, so what? You felt it necessary to demean them with your snotty, "I told you so comment?"
You need help.

well, anyway, we appreciate bill's input here.  his genius includes being able to investigate and explain all these items in a logical and scientific manner.

Quote - Props that represent bounded volumes will reliably block IBL 100% because IBL will not leak through two polygons on the same line.

I get the same thing also.  Very unexpected (you see, assumptions are perilous).  Although, when foremost normals are facing away from the camera (as in, a clear line of sight to the camera), the renderer appears to do something very different from when normals are facing towards it, even though the Normals_Foward property is set for all materials.  This is probably not good.

edit: err, the very different thing when rendering back-facing normals is "go very slowly"

Not good to view the back side of a polygon - takes forever to render.

I'm off to bed, but I did do one good demo render.

Ground plane, two dark one-sided squares, very large, and two spheres.

Light is uniform white IBL, 80% intensity.

Observe the differences in the spheres. The one on the lower right is occluded by two polygons to the left, so its left edge is strongly occluded. The ball on the left is only occluded by one wall on either side, so both left and right edges are bright. The ball on the left, being sandwiched is picking up some occlusion from the more distant parts of the walls.

Observe the bottoms of the spheres. The upper left is 15 inches from the floor and the bottom is somewhat occluded by the ground plane. The one on the right, being only 5 inches from the floor, is experiencing very little occlusion from the ground plane.

The ground plane is experiencing strong occlusion where it is hidden by both walls, on the right side. I didn't include it in this composition, but the to the left of both walls it is also strongly occluded.

Between the walls, there is very little occlusion on the ground, mostly from the distant (higher) parts of the walls and some mutual occlusion between the left ball and the ground. The right side of the ground is also experience proper strong occlusion from the nearer ball.

Quote - But I have to say, #2 looks GREAT.

While there's probably still loads more I could learn from you, BB, I can't help but feel incredibly vindicated having received an oughtright compliment from the Great Poser Guru himself!

I got this by duplicating both walls, and adding a large one-sided square below the ground.

OK now I'm really going to sleep.

Quote - I got rid of the light leak between the wall and ground by lowering the walls two inches below the ground.

That's an interesting discovery. It at least opens up workarounds for the problem... but there obviously shouldn't need to be any.

Quote - IS:

Are you using GC shaders with IDL? I haven't tested extensively, but I think you really can't. The data that GC shaders reutrn is for how to make that luminance on a screen. For light measurement purposes, those numbers are way too high. That would cause over-exposure for sure. That's why linear rendering is so important.

With Poser 8 and IDL, dump GC shaders altogether. Use linear output only from shaders. Make sure all diffuse calculations throw less light than arrives (Diffuse_Value < 1). Use HSV Exponential Tone Mapping at 2.2 for the final adjustment (approximately) to sRGB color space.

if we dont use IDL and only normal IBL and AO we also shouldnt use GC on shaders?

Ice-boy,

You already know the answer. Before IDL (before last week) we did not use IDL, only normal IBL and AO, and we used GC shaders.

If you are not using IDL, then the values produced by a shader are not used by lighting calculations so it's ok if the value is non-linear.

However, I take this into account in my use of reflections. I assume that everything in my scene is a GC shader, and producing an sRGB color. So I anti-GC what comes from a Reflect node before adding it to other things.

The problem with shader GC + IDL is that the output of a shader is not only used to color a pixel in our image. It is also used to decide how much light reaches other parts of the scene. Therefore, we must not lie about that, or the IDL calculation will be biased towards being too bright.

If only we could tell the IDL to do that, then we could use GC shaders even with IDL.

Quote - ... that's when IL washes out the AO and oversaturates the character.

Possibly you missed this point: using IDL does not 'wash out' the light-based AO, it switches it off completely. It's no surprise you can't see any AO in picture #3 - there is none.

I agree, picture #2 is superb. 

Quote - Ice-boy,

You already know the answer. Before IDL (before last week) we did not use IDL, only normal IBL and AO, and we used GC shaders.

If you are not using IDL, then the values produced by a shader are not used by lighting calculations so it's ok if the value is non-linear.

However, I take this into account in my use of reflections. I assume that everything in my scene is a GC shader, and producing an sRGB color. So I anti-GC what comes from a Reflect node before adding it to other things.

The problem with shader GC + IDL is that the output of a shader is not only used to color a pixel in our image. It is also used to decide how much light reaches other parts of the scene. Therefore, we must not lie about that, or the IDL calculation will be biased towards being too bright.

If only we could tell the IDL to do that, then we could use GC shaders even with IDL.

thanks.
so HVS tone mapping is not like GC. but i think you said it still pretty good.

do you think we should from now on use only tone mapping since its easier to use the same shaders all the time?

Absolutely.

Quote - > Quote - ... that's when IL washes out the AO and oversaturates the character.

Possibly you missed this point: using IDL does not 'wash out' the light-based AO, it switches it off completely. It's no surprise you can't see any AO in picture #3 - there is none.

I agree, picture #2 is superb. 

I suspected as much.  Still, even if I applied material-based AO, #3 would still look a little too Oompa-Loompa-ish for my tastes.  Further testing shows that the settings which produced #2 yield similar results on a consistent basis, so I think I'll stick with what works...at least for now.

As another example, here's a nude shot I did of V4 using only BB's Environment Sphere and one infinite light to simulate the sun.

In case anyone's interested, the shader that I used in all three test images and the gallery image can be recreated using this tutorial.  The advice given on lighting doesn't apply to P8 when using IL (there's no need to change the Diffuse Strength of each non-IBL light), though, and I'll probably add a "P8 Update" page soon.

Thanks for your comments!

Quote - Absolutely.

my english is not good enouhg . so that i am 100% sure i will ask again :)

if we have poser 8 we dont need to use GC shaders anymore? because hsv tone mapping is good enough?

if true then would we have to change a lot from your VSS skin shader to make it more practical for tone mapping?

You have it right, except the last part about VSS shaders.

On all, change the gamma to 1.0.

On the skin shader, change the SSS color to be a less strong red.

Done.

All the demos I showed for Poser 8 were done with Poser 8 HSVETM and VSS and those two small changes.

See:

http://poser8.smithmicro.com/gallery.html

Anything that says Bagginsbill or Ted Czotter is me.

All VSS.

thanks. i will  get poser 8 this week.

but to be honest on those renders the fake SSS from the shader looks very strange. i dont know if this is from the GI bouncing. for example on the body on the right. on the edge you can see a lot of red color. i think it makes it looks very fake.

Quote - You have it right, except the last part about VSS shaders.

On all, change the gamma to 1.0.

.

i think it would be better if we delete some nodes that we dont need. that way it would be easier to look at the nodes and do changes.

Quote - thanks. i will  get poser 8 this week.

but to be honest on those renders the fake SSS from the shader looks very strange. i dont know if this is from the GI bouncing. for example on the body on the right. on the edge you can see a lot of red color. i think it makes it looks very fake.

I applied the same settings to all, as it was only a test render. I was planning to adjust them better, as the amount of SSS really must be matched to each texture set. I hadn't yet posed them or clothed them how I planned. My plan was to do 16 figures, 8 Ryans and 8 Alysons, in many variations, all in one image. I wanted them dressed different ways, talking to each other, like at a party.

I sent that test render to SM, just to show them what I was up to. I did not know anything about the release date, and like most people I assumed it was a few weeks away. Turned out it was only 3 days away at the time! They liked the image enough to publish it, and before I knew what happened, Poser 8 was shipping!!!

So there's the back story.

ok

we will tweak.

we like to tweak :)

ice-boy:

Have a look here:

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2779121

I demonstrated taking an existing studio portrait with a VSS character, starting with IBL and GC shaders.

I flipped on GI and got blown shaders. Too much light, and also shows the problem of using GC shaders with GI.

Then I disabled the output GC on the shaders, but I left the input anti-GC as always. I used P8 Exponential tone mapping (not HSV Exponential) to perform the final GC. It works the same as the output GC on our shaders. So we get the full benefit of anti-GC, linear shader calculations, linear GI values, and sRGB final pixel values. All with 5 minutes work on an existing scene. 

didnt you say some days ago that HSV is like GC? ?

p.s. i am now waiting for Carodan to show some renders. in my honest opinion carodan always has one of teh best lighting in hes renders. and not realistic. but artistic with emotion. i think renders with GI from him will blow my mind.

Carodan is out of town on a job.

Yes I said HSV Exponential is like GC, but not the same as GC. There are two different tone mapping options; HSV Exponential versus Exponential. Exponential does the same Pow function as the final GC step. The thing that is missing is the incoming anti-GC, but we can do that in the shader.

what will you always use? hsv exponential or just exponential?

For little shader and lighting demos, with balls and boxes and simple shaders, HSV exponential.

For high quality renders, I'm now thinking Exponential + anti-GC shaders.

When I first saw the Exponential option and tested it, it seemed really dumb. Why do half the GC job? But then it dawned on me that I already had a solution for GC in Poser 7. All I have to do is just use half of it. Problem solved.

aha.

thanks.

Quote - Carodan is out of town on a job.

I've been home for a while (after working on a very interesting non related art project ). Unfortunately I got side-tracked again so I'm pretty much lurking (frustrating!) until I can get back to a little Poser rendering.
I will say this much though, although there are still improvements to be made, the IDL looks to be working so much better than when I made my Ralphling render for the SM promos - things have moved quickly. 3 or 4 weeks ago the inverse square falloff on lights produced awful light and dark artifacts with IDL - that Ralphling scene literally looked like a 70's disco until I rendered with inverse linear.
(Edited to correct myself)

carodan:

i hope you will do a render with apollo with IDL

he he ;)