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

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.

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.

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

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

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

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.

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.

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

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.

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

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.

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.

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.

This has no impact on the transparency.

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.

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

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

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

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

no one?

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.

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.

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.

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.

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.

1. A refract node with IOR = 1 basically computes what transparency sees.

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

3. Compute the inverse of your opacity. For example if at a given point the opacity is .02, then the inverse opacity is 50.

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

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)

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.

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.

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.

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.

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