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