i set my r/t bounces between 10 and 20.

i'm using hdmi to my tv/monitor, which is brighter than vga.

i don't want to prove / disprove the difference is not worth the render wait time.

just want to prove / disprove a difference exists. or why have the option for 20 bounces at all?

Thanks.!

cheers

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

I am honestly pretty much clueless on these type of lighting things, so Idk if my response is even worth giving. But I'll try anyway.

Could you do two different renders of the exact same scene - change nothing but the raytrace bounces and then open those images up in photoshop.

If you go to adjustments - curves, a graph is shown that I assume represents the levels of light in the image. SS your graph for each and then lay the SS over each other. If there is a difference in the graph, maybe that is the proof of difference.

Now mind you I could be WAY off the mark on this. Hopefully BB sees your thread.

I am: aka Velocity3d

What I am about to state is my understanding based on reading a large number of posts by bagginsbill and others. I may be wrong and will gladly be corrected... but this is how I understand it.

The number of raytrace bounces that will be used depends on the number of reflective/transparent/translucent surfaces in the render.

Given that, once the needed number of bounces occur, it become irrelavant what you have the bounces set to. Try it yourself. Set up a render with a mirror in it. Set bounces at 4. Render, using the timer function in the d3d script. Now increase bounces to 20. Render again. What result do you get? Should be the same.

I leave my bounces set at 5, because I don't ever set up scenes that need more. It does not seem to impact my simple scene renders, at least not so that I notice it.

If BB reads this, I hope he will comment to either verify or correct what I'm saying here. I THINK I'm right.

download BB's cornell-type box scene for poser, then render with 2, 4 and 16 IDL bounces. ye'll see the difference. in typical empty poser scene with girl or android, bounces won't matter.

(Edit for typo's)

100 years ago I made this one in Bryce. Each mag glass is made of two glasseous sphere-parts, so each mag glass requires 4 bounces to have the light pass through (in/out front part in/out back part).

So to have a light ray pass through all five looking glasses, max raytrace bounce should be at least 20. For this image, it was set slightly less, and as a result the last looking glass is not transparent any more - when looked through via the front one. That's causing the black pit midleft.

In general: a light ray is allowed to bounce around, it gradually dies along the way, but when it's still alive and the limit is met, it gets killed anyway. When you don't have that amount of bounces in your scene, rendertime is not going to suffer. In the other way around: when your render times boosts with lower values, then that amount of bounces was used indeed.

Which does not mean that the result is visible, you might have an object in the scene that has a lot of reflections between parts, which hardly show in the final image on screen. Then it pays off to lower the limits. And during test renders. I needed that when making this one (Mirror in Mirror with shiny cars):

http://www.main.artbeeweb.nl/?p=4003

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

More you have better is yout render, but longer too.

Test with a really simple but famous scene, firts 1 bounce, you can view the limit of the reflection.

Génération mobiles Le Forum / Le Site

Two bounces, it's a bit better, floor now reflect, but look at the ball reflection.

Génération mobiles Le Forum / Le Site

4 bounces, it begin to be interesting. It's generally my settings

Génération mobiles Le Forum / Le Site

8 bounces, render time now is a bit longer for a simple scene, but good result.

Génération mobiles Le Forum / Le Site

And 16 bounces, totally useless IMO but great result.

Génération mobiles Le Forum / Le Site

yes, useless in empty scene (as mentioned above), but valuable in fully enclosed scene. we encourage users to try more enclosed scenes.

All that is said here is correct. Just want to point out that some of you are talking about reflection/refaction bounces and some of you are talking about diffuse bounces (for IDL).

These are not the same, and statements made about one are correct while also false about the other.

In a nutshell:

Reflections will stop when a non-reflective surface is encountered, regardless of what you set the raytrace reflection limit at. Thus - if you have no Reflect nodes in your scene, the render setting means nothing at all. If you have one object that can reflect, then the render setting may still have no meaning at all. It depends on how many times your objects try to reflect. Anthanasius set up mutually reflecting closely-spaced spheres so, the number of times it tried to reflect was very high. The limit would matter there.

Refractions follow the same rule as reflections. aRtBee showed an example - using glass lenses to see through other glass lenses. If you had only one glass lens, then after two refractions, it would stop on its own, so setting bounces = 2 or bounces = 2000 would make no diffence.

The raytrace bounces is there to HALT the reflections and refractions. Imagine a ceiling set to 8 feet, to stop me from jumping that high, only because I'm unable to jump above 7 feet, the ceiling height makes no difference. That's what you guys are talking about. However, when Michael Jordan jumps, his head hits that ceiling. Then it mattered.

As for IDL, it's a totally different thing. The number of bounces will nearly always be used, so it's not a limit - it's an actual setting, and with all settings that consume CPU, the higher it is, the more accurate the lighting, and also the longer it will take.

Having your IDL bounces too low will cause the simulation to fail to include some bounced light that really should be there. Having it too high will always cost you render time.

Having your reflection/refraction bounces too low may cause a reflection to disappear. Having it too high will rarely cost you render time. It will cost render time if you set up mutually infinite reflective surfaces. (Think of mirrors in the beauty salon on both sides of the room.)

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)

That info is helpfull BB. TTY

Even for my "empty" Poser scenes, I use a "hidden" envirosphere. Not just for reflection, but the sphere actually "catches" the un-bounced rays that otherwise would vanish into the big grey Poser void beyond the ground plane.

And that actually makes the render finish faster.

:-)

Maybe I'm doing it wrong all along but I leave mine at 1 and go by the help text when mousing over the Raytrace bounces item. If I'm doing something for production that has minimal reflections, I go with 2. I roll it up to 4 depending on what else is in the scene, mirrored surfaces or whatnot.

Pretty much for all the settings, I try to go with the lowest possible number that gives good results.

.

set up an "infinity mirror"

you'll see the diff or your comp will leave home for cooler climates ;-)

hi all,

this weekend I performed some additional research on this Raytrace Bounces. Some results were unexpected (to me at least) so I'd like to share them right now. In Poser, there are differences for reflect, refract and IDL.

Reflect: in sync with my earlier assumptions, killing the light rays early will make artefacts which show the contents of the Background slot in the Reflect node. At its default black those spots are quite visible but when one makes it white and plugs in an image, the raytrace bounces slider works as a discrminator between raytraced and mapped reflections (the first ... bounces are raytraced and then the map kickes in). But reflection is efficiently done in Poser, so increasing the slider hardly causes much pain.

IDL: in sync with my earlier assumptions, killing the light rays early will reduce the brightness of the IDL portion in the scene lighting and eventually might leave dark spots in the corners, as trhe rays are just not granted the time to get in there. Increasing the slider will reduce those spots, will brighten up the scene but also wil distort any previous balance between direct and IDL light used, as only the latter is brightened up. So it's not just about artefacts here. Note that via de D3D Render window, raytrace and IDL bounces can be set separately. Increasing the slider does raise rendertime but - in my opinion and findings - not to alarming levels.

Refract: here all my previous assumptions went off. In most software, like the early Bryce image bove with the looking glasses, killing the light ray implies that no light is passing through the image any more, and we might run into the artefacts we see with reflections. Not in Poser.
In Poser, Transparency and Refraction are treated as separate features, and only the refraction, the bending of light when passing a surface, is the raytraced thing. The Transparency is always there and is not affected by the raytrace bounces setting, and when the light ray gets killed it still passes through all the surfaces, it just stops bending only.
As a result, any artefacts when looking through a stack of glass objects like the looking-glass image above, will be hardly visible for the less trained observer. In other words: there is not that much gain from increasing the slider.
But... the pain is incredible, and render times almost go up exponentially when slider values are increased. And no gain, so low values are advized. This also holds for the Fresnel node equivalent.

So, raising the bar is great for reflections, brings some good some bad for IDL, and is a sure rendertime killer without much benefits with Refract or Fresnel nodes around.

I'll post some testrenders below. This study will be part of my large Material Room investigation, published this month.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

reflection, bounces = 1.

Instead of using black, one ball has green in the background slot of the reflect node, the other has yellow. Background color (or image) will show when the render-pixel can't get a color from the scene itself because the light ray involved does not hit an object before it dies / gets killed. Either because there is no object, or because the ray gets killed early.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

refraction, passing four glass plates, transparency 90%, IOR=2 for strong effects

Bounces = 0, light passes through thanks to transparency, but no bending.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Bounces = 1, still rendering fast

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Bounces = 2, rendering is slowing down noticebly (poor coffee and drink it)

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Bounces = 4. Rendering is slow now (walk the dogs, make breakfast, make coffee, etc). Note that the middle part is still brightening up a bit as it handles more light.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Bounces is 12 (max). Rendered overnight (2 hours, I guess) for just four simple glass plates on a 12-thread @ 4GHz cpu.

Actually, I have to push Photoshop to its real extremes to find any differences whatsoever with the 4-bounce result above. And even then I'm not sure whether these are caused in the render or by the export to png / jpg image formats.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Just for illustration, a regular and a refractive object. The mid-section produces refractions of refractions of... and serves as rendertime killer. Bounces = 12 with reflective wall and ground, full IDL lighting.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

now left pawn is transparent only, to illustrate refraction as such. Nightjob again.

I tried to do the same for Fresnel, but I had to kill the render after no progress within 48 hours at 100%. Bounces = 12, with reflection and IDL as above.

(I then set the materials for the ball-heads only instead, which rendered in an hour or so thanks to lacking complexity).

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Don't know if you have Bryce, but if you do, you can switch on the Report Render Time feature and you'll get a very detailed explanation of what the raytracer did during that render. All you'd need to do is render some comparison scenes and check the results of both.

The activity listed in the render report data might be able to help you out.

aRtBee,

It sounds (and looks) to me like you're using transparency and refraction on the same object. That's not how you do it, and it is why your render times are exploding.

You either use transparency because you don't need bending of the rays, or you use refraction because you do need bending of the rays. You don't use both, unless you have an object that needs multiple behaviors in the same material, one area for "nothing here" and another area for "glass here". (Example - at the theatre box office, there is a glass, with a circular hole cut out of the middle. You might use a mask and have refraction where the glass is, and transparency where the hole is. You could then make this prop from a simple Poser primitive.)

Here is an image where I use transparency + reflection on the first prop (green ball behind it), refraction + reflection on the second (red ball behind it.)

When you show experiments you should show the shader so we (I) can evaluate your words against what you did.

I will post my shaders next.

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)

Here is the transparency shader. This is also called a "thin glass" shader. Thin glass is unable to significantly bend light rays because they enter and exit the glass almost in the same spot. The exit bend cancels the enter bend before the ray is much displaced. So we can cheat and not use refraction at all for thin glass. Some renderers also call this material "architectural" glass - again they just mean that it is safe to ignore bending refractions and you can use a fast shader.

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)

Here is my refraction shader. This is not the only way to wire it up and it's a bit inaccurate because it is a perfect reflector and perfect refractor. But I was trying to keep things simple because the amount of light that we bounce or pass through, for this thread topic, is not important.

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 previous image was rendered with raytrace bounces = 2.

This has raytrace bounces = 1.

Obviously reflections still work, but refraction fails, because we need two bounces to see through a solid object, and I stopped it at one bounce.

Transparency is unaffected because that isn't done with raytracing.

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)

With bounces at 0, I've lost all reflections and I have no global illumination (IDL) at all. Raytracing is effectively shut off.

This has no impact on the transparency.

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)

Now as I said, when using refraction on a solid object, the MINIMUM useful raytrace bounce limit is 2. Without at least 2 bounces, your object appears black.

However, some important bounces happen from internal surface reflections. So you have a ray enter the glass (refract), bounce off an internal surface (reflect), and then exit the glass (refract). To make this work you must allow at least 3 bounces.

Compare this to the first and you'll see the difference.

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)

With bounces set to 4, a small number of additional pixels have lit up. These were involved in refract, refract, refract, refract interactions, where the ray entered and exited the glass twice. (At the back of the raised circular step forming the pedestal and neck of the sphere part.)

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)

BB, you saved my day, thanks for that.

I just used 90% transparency + refract node (IOR 2) only, as fresnel is not that relevant for addressing the raytrace bounce limit against a stack of glass panes at quite a straight angle (and because fresnel is just a recent addition to Poser).

For whatever reason I never tested the refract node combined with 0 transparency, entirely my mistake. So it's either transparency (for lace etc) or transparency + reflection (thin glass, architectural glass) or no transparency + refraction / fresnel.

It also explains why I didn't get the amount of bending I actually expected from 4 panes with that high IOR. I'll re-test my previous findings against that.

thanks again, I'll be back...

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Cool.

For the sake of completeness, I did a 20-bounce render. Very few pixels were actually affected by this, but it cost a lot in render time. This is because Poser is missing an important feature in a raytracer. It does not understand or recognize that some bounces are just unimportant. This is easily worked out when a reflection is only 1% and the next interaction is also 1% - the resulting ray will only be returning 1% of 1% of whatever it finds. Unless that is a super bright object, it will be a waste of time as the pixel will be the same with or without this bounce (and any that follow!).

So - this is your job as production manager. You decide how many bounces to allow it to use, and it will either work well or it won't, and you have to judge your outcome.

I always allow 2, and frequently allow 4. I rarely go above 4 but when it is needed, it is needed. There's no other way to say it without writing a book of all the scenarios.

Render times of my scene:

1 bounce = 43 seconds

2 bounce = 70 seconds

3 bounce = 92 seconds

4 bounce = 113 seconds

20 bounce = 31 minutes

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)

One more time, I want to point out that the raytrace bounces you set does not guarantee that it will be used. If your scene has only a few opportunities to do two bounces, then it's really not going to matter if you allow 20.

I changed my props so that they have no opportunity to allow a ray to enter either prop, by removing the transparency and the refraction. So the only bouncing is reflection.

There are no other reflective objects in the scene. Almost all bounce paths are single bounce. A small fraction are double bounce where one prop reflects the other prop into the camera. That's two bounces.

This same scene, still rendered with 20 bounces in render settings, took only

21 seconds

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)

hi, back again, and still sort of clueless on the Refract node. Does it substitute for Transparency, or what?

My test scene: ground plane, back wall, red cube to have an intersting object around, big cube which is going to change materials. Single infinite light, raytraced shadows, IDL on, raytrace bounces 12.

First material: everything off, refract only. No reflect, no fresnel. That's not good glass, but it supports a clear investigation. See screengrab (1), and render result (2). My conclusion is that the reflect node has a clever way of mapping the environment onto the object surface, but the object itself remains opaque as can be seen from the shadows. The solution of using refract with no transparency might work well with reflection/fresnel added and no direct lights, but to me it presents a dark and heavy glass look and feel. Refract does mimic transparemcy but it's not a substitute.

Render (3): transparency 100% and refract only. Now the shadows are sort of right but the transparency is dimming the refraction effect. Nice but looks too fragile, too transparent. Transparency and refraction are both sending their results to the render, which is too much and unbalanced as well.

Render (4): transparency 100% and no refraction. Just for illustration, with reflection its nice for window panes (archecural glass), but not what we're looking for.

Photo (5) what are we looking for? well, just an attempt, with the real thing so with reflection, fresnel and the 'cube' is not solid. From this I infer that I do need the transparency to handle the direct light but I also need a stronger refract effect than render (2).

So what about using the refraction slots in PuserSurface, and pumping up the Refraction value. Render (6) shows the result and screengrab (7) the material settings. That's something, shadows are not effected and refraction is increased, but how do I implement this for fresnel?

I'm still wondering. Your opinions please...

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

no one?

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Poser refraction is broken. I try not to say that. I don't know why they coded it this way, but it only participates in what the camera sees. It does not participate in what the shadow calculator sees. As you pointed out, the only way to let light pass through and illuminate what is behind or on the other side of the refracting surface is to use transparency. But transparency combined with refraction will produce double images, one image bent, the other not. There is no solution. I hate it. I try not to talk about it because it is a long time now with no attention and I can't explain why my friends at SM display no interest in fixing this after so many years. The people showing great looking glass from other renderers make me sad, because this is not a rocket-science type of rendering problem. It's pretty basic.

Furthermore, refraction in Poser behaves on entry and on exit as if both ray intersections are entering. On entry, you go from air to the object's material, and the IOR applies. To exit and go from high IOR back to air, it should produce a reversal of the original bend. (Back of polygon to front, it's supposed to use 1 / IOR, not IOR). Instead, Poser double bends the ray, and the visual effect is as if the glass is super dense and weird - not even possible in real life. I compensate for this by decreasing the IOR value - most people don't notice the deviation from reality when I do this. For example, instead of glass 1.54, I might use 1.1 for the refraction (but still use 1.54 for the reflection!!).

The third thing wrong with Poser refraction is that it has no respect for distance traveled through the medium. A colored glass shows deeper, richer color in thick parts than thin, according to a simple inverse exponential relationship. This is easily modeled using a color coefficient that is then exponentiated by the distance traveled. I could do it myself if Poser had a refraction distance node to tell me how far the ray traveled.

The fourth thing wrong with Poser refraction is that it does not obey total internal reflection, which is directly a consequence of not obeying the inverse IOR on exit. TIR means that refraction stops altogether below a certain internal angle of incidence. Again, this is pretty trivial math for somebody who is building a renderer, even if ordinary users can't describe it. The Fresnel_Blend node (a fairly recent addition) should have taken this into account. I cannot offer any explanation why it doesn't.

TLDR Summary: Wrong shadows, wrong bends, wrong color.

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 - Poser refraction is broken. I try not to say that. I don't know why they coded it this way, but it only participates in what the camera sees. It does not participate in what the shadow calculator sees. As you pointed out, the only way to let light pass through and illuminate what is behind or on the other side of the refracting surface is to use transparency. But transparency combined with refraction will produce double images, one image bent, the other not. There is no solution. I hate it. I try not to talk about it because it is a long time now with no attention and I can't explain why my friends at SM display no interest in fixing this after so many years.

I'd be preaching this one from the mountainside.

This makes a huge impact on how realistic a scene can look, and prevents Firefly users from achieving true realistic results with refractive materials. The disheartening part is that SmithMicro know about this for a long time now, and do nothing to fix it.

Tools : 3dsmax 2015, Daz Studio 4.6, PoserPro 2012, Blender v2.74

System: Pentium QuadCore i7, under Win 8, GeForce GTX 780 / 2GB GPU.

BB, yeah, agree, thanks a lot for replying. So I still might be insane, but not for this reason :-)

Well, you know, in my personal opinion - and I can't look into the actual code - Poser is not tracing rays at all. It seems to apply some Consequetive Environment Mapping (CEM) instead. This means that each surface element builds some projection of the environment onto itself. For reflection this projection is mapped into its front (outside to outside, inside to inside), and for refraction its mapped onto its other side (outer to inner, inner to outer) while applying a spatial shift to mimic the bending. And it does so stepwise, to get reflections of reflections ... and refractions of refractions etc. I programmed that once, it's pretty efficient.

For the effect itself it's very hard to tell the difference from raytracing, but the object stays opaque, its easy to blur, easy to do something like raybias and easy to do some quality vs speed, and you can't do any kind of volumetric effect this way. Sounds familiar.

In Poser, it only takes the light diffused from surrounding objects into account. So reflections have to be accompanied by specularity to handle the direct lights themselves, and for refractions one has to work with transparency to get the shadows right and some light behind the object. But unfortunately transparency also deals with the light from surrounding objects too, so combining it with refraction means we get those objects twice, as you state.

Like we have to find the balance between reflection and specularity, we also have to find a balance between refraction and transparency. And a way to loose that object-doubling somewhat.

When some CEM is used indeed instead of raytracing, then nothing is really broke, and SM can't repair anything. Its just the algoritm itself which does not deliver what we like. They can add real raytracing instead, that's something different. And they can look into that double-shifting issue, which is just a matter of using the surface normals (pointing outward) properly. I'll run a test against that.

Now let's see how I can put all this into the New Great Material Room Missing Manuals.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

The environment mapping technique was introduced to enhance an object's reflections without tracing the secondary rays. Instead of intersecting secondary rays with objects, an environment map is computed from the normal, and angle of incidence. If this were the case here, then increasing bounces beyond a certain point would initiate the CEM, and render time wouldn't increase exponentially beyond a certain point either.

So wouldn't this mean Poser should render reflections a lot faster than it does, if it were actually using this reflection "cheat"?

I am pretty confident there is no CEM here. It's raytracing.

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)

I do have a technique to solve the shadow problem, but I don't like it because it is very slow.

Here's the technique.

A refract node with IOR = 1 basically computes what transparency sees.
Use transparency as you want, but never 100%. (This is to let light pass through, but still use some of the shader node values, not just what's behind.)
Compute the inverse of your opacity. For example if at a given point the opacity is .02, then the inverse opacity is 50.
Plug in a Refract IOR=1 with negative inverse opacity - for my example the amplitude would be -50.

The resulting image transparency data is exactly counteracted by the Refract IOR=1. We now have an object that is black, but lets light pass through as if it is transparent.

Now you just add in the shader you would have used (such as my simple glass shader). Yes that means a second Refract node, now with IOR > 1.

It's a hack but it works.

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)

I was also thinking about something like that (but was dragged away by customers for a while). I'll do some tests in the evening (which starts in an hour or two, its Amsterdam / Paris time)

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

BB can you render a result with that? I don't get any proper result that way and I can't explain the results I'm getting. New day tomorrow.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

Not a good one. I can do it, but there are subtle differences in the refaction versus the transparency. The delta shows up as artifacts. It used to work better. There must be recent changes in refraction.

I started to put one together but I got a call from work people and I threw it away. I'll have to start over, but I'm not sure it's worth the trouble.

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)

would like to see these refraction/shadow hack nodes, when you got free time.

Interesting thread. It's too bad Poser doesn't have a render engine to match the supreme material structure it has. Firefly does the material room very little justice unfortunately.

Tools : 3dsmax 2015, Daz Studio 4.6, PoserPro 2012, Blender v2.74

System: Pentium QuadCore i7, under Win 8, GeForce GTX 780 / 2GB GPU.

okay, tested for the double-bend-error as flagged by BB. Result: confirmed.

This is how it looks. Red cube, looked at through a bar with all material settings zeroed/blacked out, only the Refract node, IOR 1.5.

Top-right: bar at 0 degrees angle, to locate the cube (cross-hair).
Bottom-right, bar rotated 30 degrees. The cube appears shifted to the right and rotated as we can see the side of it as well.

Theory, scheme at the left.
Red lines: what the camera sees when the bar is transparant only and no refraction takes place.
Light blue lines: due to refraction, the path to the camera gets shifted. First bend to the left into the bar, then bend to the right leaving the bar to the camera.
Dark blue lines: as a result, the camera sees the cube displaced to the right, and that's it. Not rotated or so.

As you can see, the theoretical shift is quite minor compared to what Poser is showing us in the renders.

Green arrows: this is the path light has to follow to make the side of the cube visible to the camera. The light has to bend the same way twice. When it had bend forth and back instead, light from the side would never have reached the camera in any way.

Both effects demonstrate that Poser refraction is bending light the wrong way when it leaves the glass/fluid into the air again. Its bending forth and forth instead of forth and back. It should take the surface normals into account to determine inside and outside. Seems easy to fix to me.

Next issue: can we fix the non-transparency issue as BB suggests? New day tomorrow.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

**
@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!

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.

Tools : 3dsmax 2015, Daz Studio 4.6, PoserPro 2012, Blender v2.74

System: Pentium QuadCore i7, under Win 8, GeForce GTX 780 / 2GB GPU.

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

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)

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.

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)

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)

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)

And here it is rendered. Observe the bent view through the object and also the transmission of light onto the floor. Success.

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)

View from the other side. This is slow to render so I won't be doing a lot of these.

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)

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.

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)

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.

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)

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.

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

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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

okay, back again.

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

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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?

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

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.
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.
I have demonstrated that KS_Microfacet is flawed in certain rim-lighting situations, and Blinn is not.
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.
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.

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)

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

raytrace bounces =12, rendertime 8 min 40

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

bounces = 4, so rays that have to pass 3 or 4 objects (6 or 8 surfaces) are killed early. Rendertime 5 min 40. More bounces, more rendertime - but not dramatically - less artefacts.

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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

My Store My Gallery Contact

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

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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!

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

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)

And after SR4 - now it bends back on the way out!

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)

Look at this! TIR! Thin glass slabs acting like real window glass!

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)

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?

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

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)

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

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)

Here is my setup. The black square is the glass. You see its shader on the right.

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)

Here is the render with GC 2.2. Measure the color of the "glass" square. It is RGB 125, 0, 32. Bingo. Right on the money. (sans rounding, anyway)

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

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

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)

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.

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

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)

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.

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 - Rendered with default gamma, result measured in Photoshop: 82% brightness.

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.

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)

This diagram from the Pixar article is EXACTLY the math used in Poser, and what I have been showing in my calculations.

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.

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

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)

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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.

- - - - -

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though

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!

Poser 12, in feet.

OSes: Win7Prox64, Win7Ultx64

Silo Pro 2.5.6 64bit, Vue Infinite 2014.7, Genetica 4.0 Studio, UV Mapper Pro, UV Layout Pro, PhotoImpact X3, GIF Animator 5

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

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

Forum: Poser - OFFICIAL

Subject: how can i prove / disprove the results of increased ray trace bounces?