Quote - @bagginsbill
It's a shame you don't write a book on the subject of how to use the nodes in FireFly, something with two examples of each node in use.

I'd buy it in a heartbeat.

Fantastic thread, and I sincerely hope SM will eventually listen to reason and fix refraction!

Seems like they need to fix a LOT of things in Firefly, but refraction is such a basic element of raytracing, it's an absolute must.

Whoops - I posted the transmitting-refracting shader with a mistake. Revising ...

While I'm waiting for the render, I'll describe how I derived this shader.

The transparency parameter, when using a plugged-in node, is actually not transparency. It becomes opacity. It means that (for the most part) the node value in transparency determines what fraction of the shader input is actually emitted. The complement of that amount is transmitted from the other side of the object.

So, assuming that, as usual, we want a Fresnel effect for reflection (which will be among the things produced by the shader) we can get a simpler shader if we start with the assumption that the opacity (what we plug into the transparency channel) is going to be given by a Fresnel_Blend node set with the desired IOR for the material reflection effect.

Letting F denote the Fresnel reflection coefficient, R denote reflection, T denote transmission (from transparency) and C to denote the desired refraction (had to pick some letter), we're trying to make a shader that emits the standard fresnel glass:

FR + (1-F)C

When we use transparency for F and plug in reflection plus some unknown thing, X, we'll get:

F(R + X) + (1-F)T

The quest for the correct shader would have us somehow convert the latter into the former. What we seek, then, is:

F(R + X) + (1-F)T = FR + (1-F)C

Now we solve for X.

{ divide by F }

R + X + (1-F)T/F = R + (1-F)C/F

{ subtract R}

X + (1-F)T/F = (1-F)C/F

{ isolate X }

X = (1-F)C/F - (1-F)T/F

{ or another way to say it by factoring }

X = (1-F) (C - T) / F

{ or another way to say it by addition }

X = (1-F)/F * C + (-(1-F))/F * T

Recognizing now that T can be generated using a Refract with IOR=1, and C is the desired Refract that we actually want, we can see several ways to construct this. We can compute C-T (subtract the two refract nodes) and then scale this by (1-F)/F, then plug this into the root node.

Or - we can use the Poser Surface root node to do the addition. This is what I chose to do since it saves a node or two.

Note: I specifically avoid the Reflection_Color input. That has additional unpleasant math on it when transparency is activated. Just stay away from it.

Instead I use the Alternate_Diffuse, not because I'm sending diffuse info, but because it will send exactly the data I connect and nothing else. Ambient_Color also does this. So does Refraction_Color. I took advantage of all three here to do the sum of three node groups.

Since I set Ambient_Value to -1 (yes that's legal) I am actually subtracting the Ambient_Color from the ensemble. That is what is removing the T term. (unbent transmission due to transparency)

Earlier in this thread I said that you're not supposed to use transparency and refraction together on the same pixel. And now, here I am showing you exactly that.

There's a difference, though, in the approach. Here, I'm using transparency only because Poser doesn't implement transmission with refraction correctly, and if I need to deal with shadows of glass, then this is a way to do it. Further, I didn't just guess and guess and guess about nodes to assemble and what values to use. It was derived from requirements to final shader with no guessing along the way. It's OK to do crazy things if the math says that's how you do it. It's not OK to waste your time doing crazy things you think might work but don't.

Another note. You may notice that I have the refraction IOR set to 1.15. This is to compensate for the stupid double entry bending. If the exit bend was correct, I'd set it to 1.5.

Yet another note. I based my equation on perfect reflection and equally perfect complementary transmission. This is for idealized clear glass or water.

What if I want right transmission for a colored or dark glass? Well now I have to start over and do a more complicated equation, because the transmission amount and the complement of the reflection amount will not be equal in the equation. Maybe I'll show you that another day.

Quote - **
@bagginsbill**
It's a shame you don't write a book on the subject of how to use the nodes in FireFly, something with two examples of each node in use.

I'd buy it in a heartbeat.

Fantastic thread, and I sincerely hope SM will eventually listen to reason and fix refraction!

Which is about what I'm doing at the moment. My Missing Manuals site soon will get enhanced with a Material Room section, also available in PFD's (over 200 pages A4 at the moment and encounting), and when Rendo management finds a new forum moderator it might also become available as Rendo Poser FAQ, and it's all free. I'm also dedicated to make all BB's contributions to this forum more accessible, and so on. Just unlocking the treasury, that's what it comes down to.

These Refract issues are the ones waiting to be dealt with to start publication.

**
@maxxxmodelz**
Whatever is wrong needs fixing, no matter how many things.  The renderer is the final part of the Poser workflow so it has to work properly.  I love the results I get out of FireFly and I'm only doing basic stuff, but I'd hate to come across problems such as these when I get better at it.

@aRtBee
I wasn't aware of the manuals, sounds great and thanks for pointing it out, I'll take a look :-)

BB's math, shader and things tested: confirmed, correct and work as expected. But as they include reflection, fresnel, and desired refraction as well, the question still was; is there a simple way to take out from transparency the part which is also dealt with in refraction.

Just a null shader which lets pass direct light for shadowing according to transparency.

That's just about reducing BB's input till its ultimate simplicity, and here it is.

Scene: no IDL, one infinite light, raytraced shadows. Red cube for object, large bar for mat testing.

Upper left: bar is 90% transparent

Upper right: bar is 90% transparent and includes the refract portion taken out. That leaves a 100% opaque black diffuse surface for it. Now one can start adding reflections, refractions and anything to that.

Lower left: frontal look, the red cube was there and it taken out. Some artefacts remain (whiteish stripes).

Lower right: the shader. You can pick Ambient for entry as well. You can pick any transparency you like, but the corresponding correction value (now in Refraction_Value) should equal -T/(1-T).
So T=0.9 will need -0.9/(1 -0.9) = -9.0 for correction, as shown.
And T=0.5 (more shadow) will need -0.5/(1- 0.5) = -1.0 for correction
And T=0.999 will need -0.999/(1- 0.999) = -999.0 for correction.
Pick any transparency you want, including an ange dependant fresnel-like as in BB's proposal, make sure the proper values land at the right PoserSurface slots, and you're there.

Now you can build any node-tree on top of that. Note that both Diffuse and Alternate_Diffuse are filtered by transparency (anything else is not), and that transparency = 1 means transparent, but when a node is connected is serves as just a multiplier, and BLACK (=0) means transparent.

About the artefacts: these are reduced somewhat with higher settings for render quality, and they reduce even more when the bar is rotated towards the camera. At 0 angle the artefacts are gone except for the lining around the cube.
Usually, the artefacts will be hardly visible when the bar is dressed up with reflections, refraction, fresnels and whatever.

So we can have refractive objects that let direct light shine through it as well, and deliver the softened shadows which come with that. It;s not perfect, the direct light itself is not refracted etcetera, no way to do caustics of volume effects or anything else that on can expect when raytracing, but at least we've made a serious step in the right direction.

Let's Render

BB, two questions

Q1 why did you pick Blinn in your proposed shader?

As I would be inclined to use Blinn for specular effects on porous, soft materials and Glossy (or KS_microfacet) on hard, smooth, nonporous stuff like glass.

Q2 what about your remarks on the Reflection slots in PoserSurface, what's wrong with them?

As I woud be inclined to use Value for reflectivity as long as Color has a 100% brightness and provides Hue/Saturation only (for metals, that is). And Value is just a multiplier to Color anyway (besides gamma which is affecting Color but not Value). No?

thx fr new shader, bill!  will try it ASAP.

Quote - BB, two questions

Q1 why did you pick Blinn in your proposed shader?

As I would be inclined to use Blinn for specular effects on porous, soft materials and Glossy (or KS_microfacet) on hard, smooth, nonporous stuff like glass.

1. Because I don't need the automation offered by KS_Microfacet - I know how to configure Blinn to produce numerous different roughness values and match it to the correct brightness.

2. I have carefully matched Blinn to reflect softness over thousands of experiments. I would have to start over with KS_Microfacet since I don't know its parameterization.

3. I have demonstrated that KS_Microfacet is flawed in certain rim-lighting situations, and Blinn is not.

4. I have demonstrated that KS_Microfacet is flawed with high blur - it does not pick up what might be called secondary facet-to-facet reflections in areas away from the hot spot.

5. Blinn is available in all versions of Poser.

(Before you point out that I used Fresnel_Blend which is also not available in all versions of Poser, I have a 5-node substitute for those that need it. I was trying to keep things simple so 1-node trumped backwards compatibility in this demonstration.)

Note: Glossy is not about gloss - it's about pretending the point light sources actually have dimension. The correct setting for Glossy would depend on many factors, but would basically be applicable when pretending that a point light is actually a circle - you would then be configuring it to produce a specific circular diameter for your pretend light source. No real life material actually behaves as Glossy does when exposed to a point source. Blinn does behave as real life when exposed to point sources.

I include the infinite light as a point source in my explanation. Since I was doing sunlight, Glossy would not be applicable.

There is also a flare or halo around the Blinn specular that is correct and is missing in Glossy when you need Glossy to produce a small dot of light. Most people don't know this because they operate Blinn with too low a reflectivity value. Note that I combine the super high Blinn reflectivity with the reflectivity reduction found in a Fresnel shader (whether by Fresnel_Blend or more nodes - if it obeys Fresnel's law, it's a Fresnel shader.). If you just do one without the other, you're going to get confused.

Quote - Q2 what about your remarks on the Reflection slots in PoserSurface, what's wrong with them? As I woud be inclined to use Value for reflectivity as long as Color has a 100% brightness and provides Hue/Saturation only (for metals, that is). And Value is just a multiplier to Color anyway (besides gamma which is affecting Color but not Value). No?

When you set a surface to 100% transparent, it still emits some of the data from Reflection_Color. At other percentages it emits more Reflection_Color than would be justified by the opacity. The amount is unclear to me, as it is undocumented and I have not done any experiments to extract that detail. Since I'm trying to produce exact amounts of reflection, under my control, that match reality based on the Fresnel effect, I prefer to have no hidden magical incantations in my shaders.

got this using bill's shader settings.

no luck yet on faking transmissive colour nor light concentration in shadow zone, but there may be some way.  as stefan mentioned, these are not shadow fx, but caustics, which they are still reluctant to add to FFRender.  at least it's no longer doing shadows of refractive obj as though it were opaque.

@Miss Nancy: looks fine, thank you. Since refract and reflect can't deal with direct light, we will never have caustics or volumetric coloring this way. But just having somewhat believable shadows is something at least.

@BB: thanks for the reply.

#Blinn: I just wondered what your arguments were. I could have run a forum search instead, you're pretty consistent on this for some years now. Sorry.

#Reflection: running some testrenders right now. My current theory (to be tested) is: like refraction, reflection ignores transparency as well. So when light from an object (A) hits a surface at the front of object (B) then part R will be reflected while part T will be transmitted at the same time (and Poser is quite happy to do both at 100%).

Then that reflected part will be reflected again at the back of B, and passes the surface at the front while being reduced by transparency T again. And also, it will bounce back at the backside of the front and so on and on.

As a result, the output at the front of B will be R( 1+ T^2 /(1- R^2) ).

When I do the output at the back the same way, and demand that together they remain <100%, then R^2 < (1- T^2) to stay within physical limits.

But actually one would expect R = r (1-T) as r is the reflectivity 0..100% for the non-transparent part, as the transparent portion of the surface should not reflect at all. As in: when the surface lets 50% of the light pass, it can't reflect more than the other 50%. But one should set that oneself, Poser is not doing it.

Let's see what the tests bring us. Combining partial transparency with reflection is a real rendertime killer. In the meantime, I'm open to alternative theories.

okay, ran a bunch of tests again.

Let's summarize, from the original question on. What's the net effect of (additional) raytrace bounces, is the pain worth the gain?

We've got two areas of concern: IDL and raytracing (reflection/refraction/fresnel).

First: IDL. When bounces go up, lighting levels go up and to some extent, dark splotches in problematic areas, especially right corners at wall/ceiling joints and the like, will get reduced.
As every value for bounces introcudes it's own balance of the IDL with non-IDL lighting effects (ambient glow, specularity, direct light and shadows thereof, ...), every change of value will only affect the artefacts but will also distort that balance.

In order to handle ID bounces separate from raytrace bounces, one has to use the (Scripts > Partners > Dimension 3D > ) Render Firefly route instead. On top of that, one can enter any value in the value-box, while all sliders (and the value box in the regular Render Settings) max to 12.

Larger values make longer rendertimes, as far as the IDL rays bounce around indeed.

Second: raytrace, and for the sake of it: without transparency (T=0 or white) for the moment. Actually, these processes are quite efficient. Each surface affected takes one bounce, so reflections take one per object and refractions take two. Refraction caters for the 100% transparency itself. As the value is a max one, Poser only takes what's required and higher settings do not present larger render time.

So, for reflections of reflections of ... as well as refractions of refractions ... (and reflections of refractions ...) low settings might introduce artefacts. And as demonstrated in various posts, one can have scenes with lots of mutual reflections, or complex shaped object with lots of self-reflections, or stacks of glasseous objects with lots of mutual refractions.

So in those cases, it's completely up to you to balance render time with artefact reduction as some reflection-intensive areas may be at the backside of objects not visible in the final result at all.

As the mutual ... thing is demonstrated so ofted for reflections, here are some refraction samples. No transparency, no IDL, just refraction.

And again, the Bounces value in Render Settings addresses both IDL and raytracing ans maxes to 12 even in the value box, so one has to use the D3D script instead for anything different.

Edit: in the meantime, be aware of the double-bend error in raytraced refraction. Refraction should bend a ray to the left then to the right or vice versa, but is Poser it bends the same direction twice which is wrong.

note bounces = 8 produces exactly the same result (4 objects x2 = 8 required) in exactly the same rendertime. Higher settings make no more gain, but no more pain either.

for the sake of it: bounces = 1 takes 1 min 20 but doesn't show any refraction effects any more (rays can enter the objects but can't leave as that would take a 2nd bounce)
and raytrace off takes 0 min 40 sec producing just 4 black boxes.

From 1 to 4 bounces adds 240 sec that's 80 sec/bounce, from 4 to 8 bounces add 180 sec = 45 sec / bounce on the avarage which is reasonable since the affected surfaces are smaller. Hence, departing from a non-raytraced scene, the extra rendertime seems just directly proportional to the amount of surface affected and directly proportional to the amount of bounces actually required.

Conclusion: when handling IDL separately (D3D script), and when surfaces are completely non-transparent, there is nothing that stops you from using high bounce values for raytracing, especially for high res / low artefact render result.

Thing however complete change when transparency kicks in for the same surface. One has to sometimes, as refractive objects only mimic transparency and behave completely opaque for any direct light, and effects from it (specularity, shadows / lighting levels, ...)

Take reflection.

When the surface is transparent, say 60%, then only 40% can bounce back directly from reflection and diffusion. Poser caters for the (alternate_) diffusion, but not for the reflective part, you have to do that yourself.
Then the transmitted ray bounces back from the inner side of the back of the object, again for 40%, and hits the surface at the front. Again 60% of it will pass through, and 40% gets reflected and so on.

So on top of the explicitely required adjustment of the surface reflectivity, transparency introduces the frightening stream of infinite amounts of reflections within the object. And as we saw, this has a serious impact on rendertimes as well as on the effect of the raytrace bounces value versus artefacts.

Hence I did some tests, simple ball refelected in semi-transparent and reflective cube. From the above, with transparency T and reflectivity R, and the requirement that R < 1- T as the effective reflectivity could not exceed the opaqueness, my theory was a resulting reflection of R* (1+ T^2 / (1- R^2) ) without adjusting for eventual gamma effects in the render. Then I put the results in Photoshop for brightness measurement.

T 100% R 100% result 100% theory 100%
T 050% R 050% result 063% theory 067%
T 070% R 030% result 043% theory 046%
T 090% R 010% result 19,5% theory 18.5%

So as far as I am concerned, my simple theory serves a fine job, I could not confirm any flaws in the Reflection-color swatch as flagged by BB, and I did experience extreme render times: each render of this simple scene required about 4 hours with raytrace bounces maxed to 12.

Note: although result matches theory, it does not imply that theory matches physical reality. In Poser, transparency only takes out light when it passes a surface, and while bouncing around internally only 2 surfaces are passed. In life, light is taken out (and colored) while travelling through the object continuously. So Poser reflections are (far) too strong when transparency is introduced, compared to life or to photorealism. Let's discuss that correction later on.

Take refraction.

As transparency let's the light shine through from lights and objects but without bending, while refraction let's pass the light from objects only but at 100% transparency and with (erroneous) bending, the objects shine through twice. So here the issue is to take that doubling out, and the solution was discussed in an earlier post above.

After that, the proper refraction has to adjusted for transparency explicitely as - like reflection - Poser is not doing that for us. A 70% transparant object can be at most 70% refractive (and 30% reflective), for example.

At the moment - not tested for yet - I presume that mixing transparency and refraction does not lead to infinite amounts of refractions of refractions of ... so that will not cause extreme rendertimes as such. Without the reflections that is.

Take fresnel.

That's a clever mix of reflection and refraction. But when mixed with transparency, the reflection has to be adjusted relative to opaqueness (and for realism, even more), while refraction has to be adjusted relative to transparency. And reflection will lead to infinite rendertimes and/or artefacts depending on max bounces, while refraction will bend each reflection of reflection of ... that comes out as well (and will do so with the wrong amount too) increasing render times even more.

Let's say: mixing raytracing and transparency might introduce far better lighting behind the object, but may introduce new nightmares in its own right when approaching photorealism.

Is the pain worth the gain? That just will depend on you, your machine, your patience, and your requirements for the result.

But at least we know where we are, and at least we've got the D3D setup for FireFly when we want high bounces for IDL and low ones for raytracing. We can demand, require or apply a different renderer instead, but that was not the issue of this thread.

Most recent issue, as said above. Reallife transparency is a volume effect, so internal reflections of reflections of ... will give

result = R (1+ T^2 / (1- (RT)^2) ) for transparency T and reflection R, with R< 1- T

while Poser transparamcy is a surface effect, with

result = R (1+ T^2 / (1-R^2) )

ans so my question was: how far is the Poser result off (too bright, as a relative percentage). I did run a pack of scenarios in Excel, and found that Poser is at most 7% off (that is: the rendered result is 7% brighter than real life) at 30% transparancy and 70% reflection. Lower reflectivity for that transparency, of deviating transparencies with their (even max) reflectivities, give less and less relative errors. For T>50% or <15%, deviation is less than 5%. For T>65% or <7% deviation is less than 3%.

I can't decide for you but I can live with that, so for me this issue is not really an issue any more.

Finally, I'd like to flag an issue on transparency. It reduces the brightness of reflections and refractions, relative to the brightness of the original reflected/ refracted object. At the end of the render process, when having gamma correction enabled, both will be corrected (brightness increased). But thanks to gamma, the intensity reduced reflection will be corrected (relatively) more than the original object.

For instance (the extreme). Transparency 30%, reflectivity takes the maximum 70%. Real life internal reflections will make it to 76,6% while Poser will present 82,3% (the just mentioned 7% up, relatively). Gamma will enhance this to even 90%.
If I want to adjust the reflectivity to cater for all of this, I have to bring it down from 70% to 50%.

Essentially (now I'm writing and thinking about it) it has nothing to do with transparency. Any reflectivity < 100% will be pumped up by gamma correction, as will any brightness reduction due to partial refraction or transparency. It's like brightness which is reduced by shadow, and so is pumped up by gamma. Now brightness is reduced by reflection (etc), and so it's pumped up as well. Photorealism anyone?

happy rendering.

Quote - So here's the transmitting-refracting shader.

Note: I specifically avoid the Reflection_Color input. That has additional unpleasant math on it when transparency is activated. Just stay away from it.

Instead I use the Alternate_Diffuse, not because I'm sending diffuse info, but because it will send exactly the data I connect and nothing else. Ambient_Color also does this. So does Refraction_Color. I took advantage of all three here to do the sum of three node groups.

Since I set Ambient_Value to -1 (yes that's legal) I am actually subtracting the Ambient_Color from the ensemble. That is what is removing the T term. (unbent transmission due to transparency)

i'd like to try this on the whole chess set.  will prolly take a while to render.

I would not use more than 4-6 in any scene.

well, i bought a chess set from the daz store (Glass Gambit: Chess Set)  
didn't come with any poser files so there'll be no cheating, lol

just have to get this thing exported out as .obj 

I just tested a beta release of SR4 and it's fixed!

Here's the "before", from SR3. With IOR 1.5, the amount of bending is absurd.

that's something, thanks for the heads up (and thanks to SM as well).

The issue I'm facing right now is that transparency, reflection and refraction when not being 0 or 100% but something in between, are affected by Gamma Correction while - in my opinion - they should not. That can be compensated for to some extent although mixtures of those are pretty complicated, but thats for static situations only. When the mix becomed say angle dependant (Fresnel), compensation for unjustified gamma correction is about impossible.

does anyone has an opinion on this?

I'm not following what you mean by reflection and refraction being affected by GC.

I don't think they are at all. The equations of reflect and refract and transparency (which I have confirmed over and over as being individually what I expect, minus the issues detailed earlier) are unaffected by GC.

Incoming material (color maps, light colors, color chips on nodes) are all converted from gamma-corrected values to linear values. Then the rendering equation applies in the correct proportions. For example, Fresnel_Blend calculates the (linear) contribution of what you see at any given point based on a mix (or linear weighted some) between what is bounced by the surface and what passes through the surface. Then the final result, which is a linear luminance, is converted to screen color space (i.e approximately sRGB) by the final gamma correction.

I can demonstrate any of this, but it's quite a bit of work. Can you identify, with math, the part that isn't working the way you expect? If you can, then I can identify where one of is is imagining it works differently than the other, and we can assemble a specific scenario to show what is happening.

I will pick an example. I will create a thin glass polygon (one-sided, not a slab) which is at a 45 degree angle to the camera. I will place a color source behind it of a known color, as well as beside it, also of a known, but totally different color, and we shall see what the fresnel_blend gives us.

For the glass material, I will choose an IOR of 1.5.

For the color behind the glass, I will make a simple self-lit surface with RGB 128, 0, 0. (screen color space)

For the color beside the glass, I will make a simple self-lit surface with RGB 0, 0, 128. (Again, screen color space)

I will use the Orthographic camera so that all points on the slab will have an angle of incidence of 45 degrees.

According to this Fresnel calculator:

http://www.calctool.org/CALC/phys/optics/reflec_refrac

the amount of reflection for parallel and perpendicular polarized light are given and if we average them we get (9.20134% + 0.846646%) / 2 = 5.023993. This says I should see about 5% of the blue and about 95% of the red.

Given that the color components at 128, converted to linear space, is an intensity of 0.21951971807, I would expect that my red (refraction component) should be

(((1 - .05023993) * 0.21951971807) ** (1/2.2)) * 255 = 125

and that my blue (reflection component) should be

((.05023993 * 0.21951971807) ** (1/2.2)) * 255 = 32.86 (will it round up to 33?)

I have not yet tried the experiment. I'm honestly just telling the math up front. Assuming I did not make a mistake (which I may have) the resulting color of the glass will be RGB 125, 0, 32 (or 33).

My point: GC is meant to reduce highlights and brighten up shadows to correct for the various shortcomings of a (Poser) 3D render. Unfortunately, the way it's applied in Poser, also affects transparency and fresnel, and can affect reflection/refraction, while in my opinion it should not.

transparency set to 80% for a block, white ball behind it. Expected: light passes 2 surfaces front and back, that's a 80% x 80% = 64% brightness reduction by the block. Rendered with default gamma, result measured in Photoshop: 82% brightness. Which matches the 64% reduction corrected with GC. It should not, it should remain at 64%.

in math: object color C, gamma g, transparency T.
expected result: C * T^2
render result: ( (C^g) * T * T ) ^ (1/g) = C * T^(2/g)

reflection, plugged into Reflection_Color, Reflection_Value set to 80% for a block, white ball in front of it. Expected: 80% brightness reduction. Photoshop: 90% brightness. Which matches the 80% corrected with GC. It should not, but remain at 80%.
Reflection Value 100%, Reflection_Color reduced instead. Now Photoshop measures 80% brightness as it should - as the color-swatch is involved in GC. Same when reflection is plugged into Alternate_... which offers a color-swatch only.

in math, reflectivity R
expected result: C * R
render result with value: ( (C^g) * R ) ^ (1/g) = C * R^(1/g)
render result with color:  ( (C^g) * (R^g) ) ^ (1/g) = C * R as it should be 

refraction, plugged into Refraction_Color, Refraction_Value set to 80% shows the same behavior as transparency: 80% resulting brightness. When Refraction_Color is set to 80%, or refraction is plugged into Alternate_... with 80% the resulting brightness is 64% as it should.

So when a color_swatch is used to set transparency, reflectivity or refractivity, all is fine. But when a Value is used instead thing go wrong with GC. As is the case everywhere: a diffuse-only material with 50% white in the color and 100% in the value will render different from 100% white in the color and 50% in the value. in Poser, when GC is applied.

Unfortunately, transparency has no color-swatch to use. One can adjust the value for GC, but then its shadows will go wrong. When using swatches, the ratio between reflection and refraction remains okay as well. When values are used instead, the ratio is distorted as well (as transparency and refraction reduce brightness twice, reflection reduces brightness once, and GC is nonlinear).

And now I wonder how Fresnel will behave, because it mixes a reduced reflection and reduced refraction depending on the angle to the camera. Which to me seems value-based and not color-based. When turning the block mentioned above into Fresnel, the brightness ratio between the refracted and reflected balls as measured in Photoshop is extremely sensitive to the gamma value used. Which it should not be. I don't have a clue yet how to correct for it, as its angle-dependant.

And still we need to mix those raytracing nodes with transparency, to get decent shadows behind the block from a direct light. That's where the aspirines kick in :-)

BB about your posts.

You are accurately calculating what you expect from Poser, and afterwards you find that Poser has indeed performed that way. Which is good as such.

But in the meantime, you apply GC to the 5% reflectivity and 95% refractivity (100% together) while in my opinion you should not. Your blue reflects 33/128 = 26% while your red refracts 125/128 = 97.6% (113.6% together) and the ratio 5:95 now reads 26:97.6 so the reflection compared to the refraction in the result will appear five times stronger than nature will show. And when this ratio gets distorted, internal reflections will be done wrong too.

Throw in transparency for the glass to get decent shadows from a direct light, and complexity increases even more.

So in order to come close to photorealism using Firefly, balancing transparency, the raytracing nodes and GC is an "interesting one" to say the least. In my opinion that is.

Quote - GC is meant to reduce highlights and brighten up shadows to correct for the various shortcomings of a (Poser) 3D render

Whoa whoa. I didn't even read the rest. This is completely wrong. Gamma correction has to do with color spaces of images shown on computer monitors, recorded in cameras, printed on printers, versus the linear color space used in the rendering equation. It has nothing whatsoever to do with renderer shortcomings.

The data you put on a screen is designed to be represented using a number system called sRGB. You have completely misunderstood what gamma correction is, or why Poser (and other renderers) apply unapply it on the way in, and then apply it on the way out.

Clear your mind.

Grasp this very important concept.

The display you stare at all day is intentionally non-linear. It is done this way for many reasons, but we don't need to know them. All we need to recognize is that 100 is not half the brightness of 200. It is nonlinear.

Read this:

http://en.wikipedia.org/wiki/Gamma_correction

The purpose of gamma correction has NOTHING to do with renderers and was invented decades ago.

The purpose is this:

Quote - Gamma encoding of images is required to compensate for properties of human vision, hence to maximize the use of the bits or bandwidth relative to how humans perceive light and color

It is a way of compressing more useful (from a human perception point of view) information into 8 bits. Otherwise the dynamic range (smallest representable change versus largest representable brightness) would be much smaller.

Failure to understand its role in computer displays and image technology is why renders look bad. The process of recognize the role of gamma encoding in rendering workflow, how our inputs colors are represented, converted to linear, operated on, and the result converted back to gamma encoding, is a common reason renders look wrong. Taking all of that into account is how we get realism because naively pretending that the pixels in an image are linear is - well - naive. Taking gamma encoding (not correction - but the way numbers are represented in 8-bits) into account in your workflow is called "linear workflow" and it's super important for equations to actually produce realistic images.

Quote - transparency set to 80% for a block, white ball behind it. Expected: light passes 2 surfaces front and back, that's a 80% x 80% = 64% brightness reduction by the block. Rendered with default gamma, result measured in Photoshop: 82% brightness. Which matches the 64% reduction corrected with GC. It should not, it should remain at 64%.

Wrong! You are making the totally incorrect assumption that 64% brightness is 64% of 255. You are totally ignoring the sRGB color space.

Your monitor displays the 8-bit integer 255 at the brightest it can deal with. Now you're making the incorrect assumption that a pixel showing 64% of that brightness would be .64 * 255, or 163. That is incorrect. The number system used by monitors (sRGB) has a gamma of 2.2. That means the output brightness is equal to the fractional value you supply raised to the 2.2 power!

A brightness 64% of the maximum is not 64% of 255. It is (.64 ** (1/2.2)) * 255 = 208. The number 208, in sRGB integers, stands for the value 64%. Any other interpretation results in errors and that is why the linear workflow is so, so important.

Read this. Pixar uses linear workflow now and so do we.

http://renderman.pixar.com/view/LinearWorkflow

Understand it well, or you're not playing with the pros.

Quote - Linear workflow refers to a rendering workflow in which image gamma is carefully taken into account in order to assure proper light computations in a render.

Image gamma <<<<< this is the key - when we work with images or computer colors, we must understand the role of gamma encoding in what those numbers mean. They don't mean what you think they mean.

We all agree that 14 is brighter than 7, and that 57 is brighter than 50. But by how much? That's where the difference comes into play.

Right here, you went totally wrong. The value is not 82% - let's be explicit. The value is the integer 208. The luminance represented by this number, 208, is not 208/255 - that would be a linear interpretation, and the colors on your screen are NOT LINEAR. Your monitor does not agree with you that it should emit 82% of its max brightness given an input integer of 208.

Instead, the brightness is exponentiated by 2.2.

The brightness emitted by a pixel set to 208 is (208 / 255) ** 2.2. That would be .64 of the maximum brightness.

Given that the source (max white box) is transmitting here through an 80% transparent box, the resulting 208 is absolutely correct to cause 64% of that whiteness to show up on your computer screen.

Incoming JPG, PNG, and other 8-bit sRGB images, and material room sRGB color swatches, are assumed to be encoded with gamma = 2.2. They must be converted to linear.

Incoming EXR or HDR images are already linear. They were designed for use in computer graphics. So they were designed to not require extra steps before we can use them.

If you ask Poser to produce an HDR output (render option) and save as EXR or HDR, it will NOT apply the final gamma correction. The linear values will be recorded straight into the file.

If you ask Poser to ignore gamma, it will do the same for sRGB images such as JPG or PNG and that is just wrong. When you display them, the display software assumes they are already converted to gamma 2.2 encoding, and since they are not in that case, they look darker.

All the linear numbers besides 0 and 255 mean something else and are represented as something else in a gamma encoded image.

Quote - Your blue reflects 33/128 = 26% while your red refracts 125/128 = 97.6% (113.6% together)

No no no no no no no.

My reflection was 5% of whatever it encountered, and if another reflection would be examined from there, it would still be 5%. The gamma correction happens AT THE END.

It does not happen during each bounce.

The reason it is 32 is that in gamma 2.2 encoding, the integer 32 is 5% of the brightness of the integer 128. I already gave the reason that is so.

But, during the rendering, that 5% was .05. During the rendering of bounce to bounce to bounce, each value is kept and used linearly. That's linear workflow. The calculations are done linearly. The final final final result is converted to 0-255 using gamma encoding.

There is no conversion to these 0-255 numbers during the internal intermediate results. Everything internally during the render steps is done with full floating point linear values.

BB

first things first.

As calcalated by you, your Fresnel setup has 5% (blue) reflection and 95% (red) refraction at the surface. Thanks to internal reflections within the glasseous object, the resulting final blue reflection is R(1+T^2/(1-R^2)) = 9.5% and the same way, the final red transmission is 90.5% (two surfaces 95% x  95% and a minor contribution from internal reflections as well). Rounding off, nature will show a 10 blue : 90 red ratio and these numbers together make 100% from the assumption that no absorption takes place.

Since Poser applies GC on colors but not on value entries, putting those 5%/95% in the Value slots (or have them calculated by Fresnel) give the 25.8% blue : 97.6 red as you measured, and those exceed 100% when added up. So whatever you argue, your reflections will be far too strong compared to your refractions, the finally produced red/blue color will be off and the glasseous object will be too bright.

This can be compensated for by using the color-slots instead, but transparency does not have one - and whenI adjust the value, it affects the shadow intensity. And the Fresnel(_Blend) internals cannot be accessed.

second issue. This might be an eternal disagreement, but at least let it be clear for the sake of it.

In image engineering, GC was "invented" to increase the brightness of images and movies to compensate for the darkening that occurs when these are just dumped on a newspaper sheet or on a TV screen, whithout additional correction. GC is embedded in formats for MPG and JPG for that reason, and it's still relevant for dumb devices (including Windows before the turn of the century)

For modern intelligent devices, images can be read correctly and are presented to the application in the proper way, even including embedded profiles. And images are displayed correctly, thanks to the mechanisms build into drivers and video cards. It's in the Mac for a long time and it's in Windows since XP (partially) and Vista.

You can check it yourself: save a colorful image in BMP and JPG format, use a dumb passive device to get them on your TV screen (great difference) and use your PC to show them on the monitor. Some programs will reveal minor differences (as they read JPG with the industry standard and ignore the embedded profile) and some programs - like Poser!! - do not.

From a device perspective, Poser can be considered linear, as long as GC is not applied.

Then why GC in Poser?

Because we want to brighten up the shadows, to compensate for the lack of radiosity, the lack of scattering in the air (dust particles etc) and more like that. So what does Poser do?

For a regular coloring C, and an effect of shading and shadowing S, and a gamma value g, it first adjusts all images and colors to C^g, then it applies (renders) the S to C^g * S, and then it readjusts the render result to ( C^g *S ) ^1/g = C * S^(1/g). And since G>1 and S 0..100%, S increases and all shading and shadowing brightens up,  while original colors go un-adjusted.

(Un)fortunately, Poser can chosen to use the GC function from image engineering to do so, and (un)fortunately, the industry standard value of g=2.2 presents very nice results in shadow brightening. So now everyone confuses the Poser GC with the image-engineering GC. Bad luck. They could have used another mechanism instead, with similar results, but they didn't.
Unfortunately too, Poser applies its GC to all kinds of brightness dimming. Not only shading and shadowing, but also semi-transparency, limited reflection and the like are altered by it. While it should not, as these do not require any adjustment for the lack of environmental lighting abilities in Poser.

Other consequences are:

 - when Poser is part of a larger workflow, and componenents (difusse, shadows, ...) are obtained separately (or as PSD layers in the export), then one should not apply GC but make the adjustments later on. As it's GC which de-linearizes the render result. It's like image compression (save as JPG) which should be postponed to the latest stage as well.

 - when IDL is used, radiosity is 'ON' and one does not need the large adjustments from gamma = 2.2 as part of the problem is solved in IDL already. Far lower values - combined with reduced shadow intensities - produce more realistic results. And have far less effects on transparency and raytracing as well.

= = =

to all: my opinion, please do PROVE me wrong so I can learn from it, but do note I'm not fooled or convinced that easily for being into computer HW, SW, images, optics and physics for some decades now. As is BB, by the way.

on BB's posts

 - labelling GC as an image engineering thing: correct

 - having nothing to do with render shortcomings: discussed that. In Poser the function and values are just (ab)used for that. Poser does not have to compensate for my monitor, my graphics system does. So Poser doesn't (besides using OpenGL for preview, which sort of takes care of it).

 - my monitor etc affect my brightness judgement: correct. That's why I'm not using it for that purpose. I color by numbers using Photoshop, render in Poser, export the result and re-read the results in Photoshop again. I only need my monitor to position the mouse, but any monochrome device, audio or even my blind cousin could have done the same for me, it's just cumbersome.

When I input 100%, set the filter to take 20% away and measure 80% in the result, it's working as it should.  When I measure 90.45% the filter has been affected (by GC with gamma 2.2). Then Poser alters my filtering, and it should not. In some cases, I can adjust the filter strength, in some cases I won't (transparency) or I can't (fresnel).

For precision, I can use HDR format.

about mixing up colors and affecting hues:

when I've got A% red (for refraction) and B% blue (for reflection) and in the proposed test-setup, and nature makes C% refraction and D% reflection - both taking internal reflections into account, then

C+D < 100% (or equal to 100% without absorption)

and the result should be RGB(1) = (AC, 0, BD)

when Poser applies GC the result will be RGB(2) = ( A^g * C, 0, B^g * D) ^ (1/g)

in which ^(1/g) will leave the hue undistorted and works on the brightness only.

Comparing RGB(1) and RGB(2), the Poser GC process will affect the hue of the outcome, unless A,B,C or D = 0 (like when studying pure refraction of reflection but no mix) or when A=B as in BB's test setup (set to 50% aka 128).

Note: for A and B in the same order of magnitude and C>>D as in the test-setup, the hue for RGB(1) will be about (1, 0, (B/A)*(D/C)) while the hue for RGB(2) will be about (1, 0, (B/A)^g * (D/C) ) . So for C (95%)>> D (5%) > 0 the hue only will remain unaffected when A=B als 1^g = 1 for all g.

Which illustrates that GC affects Fresnel (etc). The results are too bright, the relection to refraction ratios are distorted, and I don't have a clue how to correct for it. 

BB  > Quote -   I have great news! SM fixed one of the refraction problems - the inverse IOR and total internal reflection.I just tested a beta release of SR4 and it's fixed! 

  That is great news!

radiosity refers to light bounces?  i thought radiosity was more mysterious