For reference material and more detailed examination (from 2007!) check out this thread.

http://forum.runtimedna.com/showthread.php?26024-Diffuse-Clay-Skin-and-Velvet-nodes/page2

There is also this cool thread on the exploitable difference between front-lit and back-lit materials.

http://forum.runtimedna.com/showthread.php?37161-Rendering-single-faced-polygons-differently-on-the-back-facing-side

Thanks bagginsbill, nice explanation and demonstration - I'll have to read through it all a few times to make sure I've got it correct. And those other two threads you linked - all good stuff.

I'll throw my useless observation in here... the only thing I use translucence for is for illuminated signs that use an image map or for computer monitors. Plug the image map there rather than diffuse, ambient set to 0, translucence set to 1, get the image lit like an LCD monitor.

I'll throw my useless observation in here... the only thing I use translucence for is for illuminated signs that use an image map or for computer monitors. Plug the image map there rather than diffuse, ambient set to 0, translucence set to 1, get the image lit like an LCD monitor.

On the very rare occasions I've tried computer monitorsor TV screens in my renders I've used ambient. Any specific reason you use translucence instead? Back to the leaves - I tried the back-lit front-viewed and front-lit back-viewed experiment on the ivy I'm using with its default shader, and with the translucence connected as bagginsbill noted. Lighting was just an infinite (with ray-traced shadows - the translucence/shadows didn't seem to work with depth-mapped shadows) and IDL:

(bottom right caption should of course be "Back-lit front-viewed with translucence")

And here's the shader with translucence (I noticed as I was posting this that I used 1.0 for diffuse/translucence strength, whereas bagginsbill used 0.8.And the diffuse colour on the shader I used wasn't quite white):

In case you were wondering, front-lit back-viewed IDL doesn't do a shadow either.

I noticed that there appears to be some translucence near the inverted pawn. But I'm guessing from the shape of it that it's actually an IDL 'glow' coming back from the inverted pawn?

thx fr info on translucence, BB.

i agree with 3dch: if leaf in above case doesn't cast shadow, then it must be IDL bounce off upside-down pawn.

"On the very rare occasions I've tried computer monitorsor TV screens in my renders I've used ambient. Any specific reason you use translucence instead?"

No, they seem to be identical in brightness and projected light. It mainly came about because I made a mistake once setting up a monitor to render (the image was linked to diffuse so I just set ambient to white and gave it a low value. Needless to say the image didn't 'glow' that well and washed it out so I plugged it in to translucence, turned off ambient and it worked). I'm sure ambient is more technically correct, but to date translucence has worked as intended, and that's as much as I ask.

I know this has diverged a bit from the original "waxy leaf surface shader" topic, but I think it's best to continue posting to this thread rather than a new one.

My main interest is getting a nice leaf shader that I can use on all those old plant and tree models (and XFrog OBJs) that use one-sided transmapped squares for leaves.  This is a quick summary of what I think I've learnt over the past day:

• bagginsbill's scatter-based leaf shader doesn't seem to have a noticeable effect when applied to the leaves of the ivy in my render. Two likely reasons: (1) the scatter node requires a mesh with volume to work properly, and this ivy is one-sided transmapped squares; (2) my particular scene and lighting isn't a very good test.

• leaf translucence (assuming infinite lights with ray-traced shadows) is automatically handled by the basic diffuse channel, EXCEPT if the leaves are back-lit and viewed from the front.

• the translucence node of the Poser surface can be used to add leaf translucence (assuming infinite lights with ray-traced shadows) for back-lit front-viewed leaves.

• the leaf translucence effect seems to require a basic Poser light with ray-traced shadows (I've only tried an infinite light so far). bagginsbill notes that it doesn't work with IDL. I've only tested with an infinite, so not sure about point/spot/diffuse IBL. It doesn't seem to work with depth-mapped shadows (I read somewhere that depth-mapped shadows are required for the fastscatter node, so that might be an option?)

And here are a couple of observations on problems with the standard leaf shaders - some might be easy to improve in the shader:

• most plants use a single leaf texture image (maybe two), so every leaf looks the same. Something in the shader to add a bit of randomness might be good?

• the bump image for most leaves is usually just a greyscale version of the texture image, so the veins appear raised, which is (usually) correct for the underside of a leaf, but wrong for the upper surface. Using a math subtract node, or GIMPing the image can correct this.

• the transmapped squares used for leaves are usually flat (i.e. the four vertices are coplanar). It may be possible to use displacement to warp each leaf slightly?

• the underside of a leaf is often very different from the upper surface. You really need a 3D mesh for this. But just maybe, the exploitable difference between front-lit and back-lit materials thread that bagginsbill linked to... ?

I know this has diverged a bit from the original "waxy leaf surface shader" topic, but I think it's best to continue posting to this thread rather than a new one.

My main interest is getting a nice leaf shader that I can use on all those old plant and tree models (and XFrog OBJs) that use one-sided transmapped squares for leaves.  This is a quick summary of what I think I've learnt over the past day:

• bagginsbill's scatter-based leaf shader doesn't seem to have a noticeable effect when applied to the leaves of the ivy in my render. Two likely reasons: (1) the scatter node requires a mesh with volume to work properly, and this ivy is one-sided transmapped squares; (2) my particular scene and lighting isn't a very good test.

• leaf translucence (assuming infinite lights with ray-traced shadows) is automatically handled by the basic diffuse channel, EXCEPT if the leaves are back-lit and viewed from the front.

• the translucence node of the Poser surface can be used to add leaf translucence (assuming infinite lights with ray-traced shadows) for back-lit front-viewed leaves. If used, it also seems to brighten up the leaves from other viewpoints (maybe some balancing of diffuse/translucence strengths required)

• the leaf translucence effect seems to require a basic Poser light with ray-traced shadows (I've only tried an infinite light so far). bagginsbill notes that it doesn't work with IDL. I've only tested with an infinite, so not sure about point/spot/diffuse IBL. It doesn't seem to work with depth-mapped shadows (I read somewhere that depth-mapped shadows are required for the fastscatter node, so that might be an option?)

And here are a couple of observations on problems with the standard leaf shaders - some might be easy to improve in the shader:

• most plants use a single leaf texture image (maybe two), so every leaf looks the same. Something in the shader to add a bit of randomness might be good?

• the bump image for most leaves is usually just a greyscale version of the texture image, so the veins appear raised, which is (usually) correct for the underside of a leaf, but wrong for the upper surface. Using a math subtract node, or GIMPing the image can correct this.

• the transmapped squares used for leaves are usually flat (i.e. the four vertices are coplanar). It may be possible to use displacement to warp each leaf slightly?

• the underside of a leaf is often very different from the upper surface. You really need a 3D mesh for this. But just maybe, the exploitable difference between front-lit and back-lit materials thread that bagginsbill linked to... ?

I tried using separate cloud nodes with global coordinates to control saturation/value of the texture, and the displacement. Also included translucence, although with no back-lighting (sun behind and above camera) it's probably not contributing anything in this render. Here's the latest render (same setup as previous renders - only the leaf shader has changed):

And here's the shader:

I just had to try combining that "Rendering single faced polygons differently on the back facing side" with translucence. Two infinites with ray-traced shadows, one in front, one behind;  a one-sided transmapped leaf with its front facing to the front; an upward pointing thingy in front of the leaf, and a downward pointing thingy behind.Here are my results:

So I've clearly got something messed up with the back-lit back-viewed part of it.

Here's the shader I cobbled together. Obviously I've made a mistake somewhere - or maybe it just can't be made to work?:

What puzzles me most is that it's NOT the back-lit front-viewed part that's wrong - so the translucence seems to working correctly to bring the back lighting to the front view.

Hmmm... just noticed that if I disconnect translucence, set Translucence_Color=black, and Translucence_Value=0 I get the same problem for the back-lit back view. I thought I'd checked all that before adding translucence?  :oS

Even if I disconnect everything from the Poser surface and just use its diffuse colour the one-sided square renders black for back-lit back view. I'm missing something really obvious, I can tell... 

Of course, it's all to do with Normals_Forward, Ticking that on the Poser surface of that latest shader makes the back-lit back-view look right - but of course that messes up the front view... don't think I can see a way around this...

Remember I repeatedly used the word "dedicated" - connecting a Diffuse to the translucence channel changes its meaning. Since you are also using a pair of Diffuse to detect back-side rendering, but they eventually feed the translucence, you are doomed as it's no longer "dedicated". It stops working as expected.

This would be so much easier if there was a node to tell you which side you're rendering. There are so many trivial one-line-of-C++ things i could build if the node system was extensible via DLLs.

Thanks bagginsbill, indeed you did! And you warned that it's buggy. And you advised against using it! And all in your first response to my translucence query.

"...and you must not send the data from that diffuse node to any of the other channels in any way. It must be dedicated to the Translucence channel.

I must add that it is buggy as hell. As far as I can see it is doing its thing as designed for directional lights and a dedicated Diffuse node, but for IBL or IDL, it doesn't behave like real translucence under those lighting conditions. I still advise not to use it, unless you first study it completely and understand how it will burn you if you go where it cannot go..."

I'd also noted your observation in post #29 of the RDNA "Diffuse, Clay, Skin and Velvet nodes" thread about the bizarre behaviour if you use the output of the diffuse node for something else as well.

But I hadn't expected that adding a couple of additional diffuse nodes upstream would mess things up.

Like I said, it was just something I felt I had to try... a little bit of burnt fingers is sometimes a good lesson! ;)

(Also found an earlier post by you explaining the same precise way to use translucence)

Hang on a mo' (it takes a while for things to filter through the morass I call a brain :) )... that compilation of six renders I posted at the top of this page - it was only when the one-sided transmapped square was back-lit and back-viewed that there was a problem. But even if I just use the most basic material (e.g. a Poser_Surface with Diffuse_Color only) on a one-sided square it will render completely black if it is back-lit and back-viewed (unless of course you check Normals_Forward on the Poser surface)...

As far as I can see the Translucence bit seems to be doing what it should be, i.e. conveying BACK lighting to the front - the 3rd and 5th of my renders...

Regarding the mysterious glow from pawn to leaf:

It's an IDL bug - a new one. I investigated it some more.

IDL thinks the pawn is recorded as fully lit and bouncing lots of light, and in a strange rectangular pattern that doesn't match the pawns shape exactly. I performed the following changes to see if the artifact remains.

1. Change the leaf to black - gone
2. Change the pawn to black - gone
3. Change the leaf to not be a light emitter - remains
4. Change the pawn to not be a light emitter - gone
5. Turn off the infinite light - gone
6. Turn off irradiance cache - remains
7. Turn off IDL - gone
8. Turn off cast shadow for the leaf - artifact gone, but now there is real bounced light, in the correct pattern

The last test indicates it's not quite the same as if the shadow was turned off.

Took off the leaf shader (now it's just a square) and just made it simple Diffuse with a magenta (red and blue) color. I made the pawn a yellow (red and green) color. The two colors only have red in common. If we see red, it's bounced between both objects.

This is what I got with shadows off for the square - this looks right

This is what I got with shadows ON for the square - this is completely bogus

All these issues that BB has been finding with IDL and other stuff recently really has me considering the jump to Daz. :/

All these issues that BB has been finding with IDL and other stuff recently really has me considering the jump to Daz. :/

Doesn't DS have bugs then?  (Just kidding!  :D ) I think the only real solution is to be a 50/50 Poser/DS user - you get the best (and worst) of both worlds!

Regarding my attempt at the top of page 4 of this thread to use quinlor's 2008 idea to get different images on the front and back of the leaf. As bagginsbill said "The Translucence channel has only one job - to convey BACK lighting to the front. It is not responsible for conveying FRONT lighting to the back. As we can see this is already performed by the completely ordinary lighting of the built-in diffuse node (or any diffuse node).". So plugging an additional copy of quinlor's nodes into the diffuse node was totally pointless. All I should plug into the diffuse node is the texture map that I want the translucence channel to use when it's conveying back lighting to the front - it's a moot point whether this should be the leaf back image, the leaf front image, or a blend of both.

Also, While rooting around in the forum I came across another translucent leaf thread and noted willyb53's suggestion to use fastscatter with translucence, so I gave it a whirl. Here's the adjusted shader network:

And here's what I got:

So with a Diffuse node plugged into translucence (as at the top of page 4) the back-lit back-viewed leaf renders black, but with a FastScatter node plugged into translucence I see the leaf texture and the correct shadows.

Using primary colours instead of textures with quinlor's network plus the FastScatter => Translucence...

(I haven't labeled each of the six renders as the shadows and position of the leaf-tip should make that clear. In case it isn't - top to bottom: both lights; front lit only; back-lit only. Left=front view, Right = back view)

Maybe...

buggy translucence + bodged fastscatter = asking for trouble ?

But I get a feeling that I'm almost at a "good enough for my purposes" stage - it's just the other side of that crocodile-infested river with the trolls underneath the bridge... ;)

Well, I've started crossing the bridge and I don't hear any "Fee, Fi, Fo, Fum!" yet...

This looks promising. I added the duplicate of quinlor's node back and plugged that into the Fastscatter, after swapping colours in the blend node.

(Blue is the colour I want on the Back, Red on the fRont)

I noticed that with both lights on only the area where the front shadow and back shadow overlap appears as shadow. I have a hunch that reducing Diffuse_Value and Translucence_Value further may resolve that...

Before reducing those values I decided to do a test. Exactly the same as the previous post, except that I tried to use just one copy of most of quinlor's network, with an extra Blender node with colours swapped to plug into the FastScatter>Translucence bit.

Guess what? I get completely different results. Just as a bagginsbill already mentioned!

But the shadows for the both lights on case look correct again.

It definitely looks like doing anything other than what bagginsbill expressly suggested for translucence is... interesting ?!?@!

And back to the version with two quinlor networks, but with Diffuse_Value and Translucence_Value reduced to 0.33

Now the shadows look right with both lights on as well. So now the biggest problem I see is that the back-lit only renders both seem to be darker.

(Note: also seems fine with depth-mapped shadows. I'm using Poser 9 Firefly)

Seems to work when released into the wild.

Now with a bit of colour variation and unflattening...

I suppose asking for different bump maps for the back and front of a one-sided leaf is taking a step too far... ?  ;)

(unforeseen problem - that ivy on the right. Loads of leaves are upside down - that'll be the plant mesh...)

Following with much interest.

I note that you have boxed yourself into the front-back paradigm when you don't even want that. The "front" of your leaf seems to be facing down at times, and this isn't what you are after. Instead, you should be shading one way or another based on up or down. The top of the leaf is whichever face is on top, right?

To detect up or down, top or bottom, use the N (normal) variable node, configured with a huge Y multiplier. Now connect that to your blender to decide which input to take.

Here I configured my blender top use Input_1 for top, Input_2 for bottom, which I got by configuring -1000 in the y component of the N node. I demonstrate on my mat pawn, to show that this works with any shape, not just a one-sided square.

This is off-topic for a leaf, but I'm sure that after seeing the top-bottom shader, some will wonder if you can get a gradient out of it. Yes, with the addition of one math node. Note that this technique is at the heart of the snow and dust shaders I've posted in the past, which found its way into SnarlyGribbly's snow machine.

I suppose asking for different bump maps for the back and front of a one-sided leaf is taking a step too far... ?  ;)

Not at all - just connect them to a top-bottom blender. If you need a different multiplier on each, then premultiply them with a math node. (Don't try to multiply with shades of gray - too finicky and if you decide to change render gamma, it will change meaning.)

If you're using bump maps properly as I've taught, then you already have a math-subtract .5 node involved. Set each one up to do what you need for each map.

Note that multiply on a math subtract, whose job is centering the bump map around the 0 value, can be accomplished in one node - just multiply your input_1 and your input_2 by the same value. For example, if you want the map centered on .5, and multiplied by .16, then on the Math:Subtract set Value_1 = 1 * .16 = .16 and Value_2 = .5 * .16 = .08.

i remember when you unlocked gradient magic for dynamic hair strands. rainbow hair. :)

I note that you have boxed yourself into the front-back paradigm when you don't even want that. The "front" of your leaf seems to be facing down at times, and this isn't what you are after. Instead, you should be shading one way or another based on up or down. The top of the leaf is whichever face is on top, right? ...

Now that you've pointed it out...

Using the N node rang a very loud bell - Eventmobil's 'dust-on-top' [nudity warning - not that post, but the thread, which was about "slightly soapy water"] and snarlygribbley's snow machine. I've even used the N-node like that myself, but never thought it could be relevant here. I'll try that tomorrow.

I've run into a separate problem with back-lit one-sided meshes (as opposed to single faces, like my leaf). The mesh lines appear in the render (back-viewed or front-viewed) but only if I use ray-traced shadows. Depth-mapped shadows seem okay. I'm sure that must have been covered many times, but I can't find anything.

(P.S. I don't seem to be getting notification messages for new posts now.)

For raytrace polygonal self shadowing artifacts either 

1 raise shadow min bias to higher value (diminishing returns in shadow quality though, with corresponding gradual elimination of artifacts).

2 disable smooth polygons (completely eliminates artifacts but is really only useful if model is higher res and not so dependant on Poser smoothing).

3 In recent Poser version, raise SubD level of mesh.

Observation; Raytrace mesh artifacts as above must be specific Firefly bug as I've yet to see similar in other Raytrace renderers.

Observation; Raytrace mesh artifacts as above must be specific Firefly bug as I've yet to see similar in other Raytrace renderers.

Yes, I'm using Firefly (Poser 9). I see the mesh-line artifacts regardless of whether Smooth Polys is checked. Bizarrely, adjusting shadow min bias has the opposite effect (i.e. increasing it makes them bigger, decreasing it makes them smaller), but only for the mesh-line artifacts on the back-lit mesh. Mesh-line shadow artifacts on other objects behave exactly as you say.  :oS Definitely seems to be a back-lit + one-sided-mesh + Firefly + ray-traced-shadows specific problem

(Edit time ran out on that post, so an additional note...)

I also think that the rather cobbled-together shader I'm using (posted recently, with back and front leaf images, two of quinlor's networks, plus fastscatter driving translucence) might be an additional condition for seeing this effect. Just going to do some checks...

Hmmmph. I'll keep an eye out for that particular problem. I must say that I've experienced quite a bit of frustration over the years with said artifacts. With manifold geometry I generally disable smoothing, here's hoping that I don't run into the one sided geom version of the bug. :)

Actually, now that I think of it I have encountered those artifacts on one sided geometry. In this instance a morphing high res plane that I created. the artifacts would only show at higher morph levels though, when the polys were extremely attenuated. I always had a nagging suspicion that non planar polygons were a contributing factor. Who knows?

This particular version of the mesh-line artefact problem appears to be caused by plugging Fastscatter into Translucence...

So it appears to be:

one-sided-mesh + back lighting from a Poser light + ray-traced-shadows + Fastscatter node plugged into Translucence_Color + Firefly = mesh line artifacts

Using a Diffuse node (which is what bagginsbill said to do), not a Fastscatter node, the mesh line artifacts don't appear. But the shadow from the downward-pointing thingy behind the leaf doesn't appear on the leaf if you do this.

I'm thinking that these one-sided plane problems should continue on a new thread, so I'm just going to start a new thread (linking back to this one of course).

Here's the link - "One-sided face/mesh problems, tricks, workarounds, stumbling blocks, etc.."

So far following this thread has been most illuminating. Using the various methods shown here, I've improved the leaf shader for my Dryad character:

The first is without translucency, using the wax like shader described in this thread

and the second is a back lit translucent shader

Still trying to work out how to dampen the translucency a bit so its not quite so strong.

and here's the nodes for the translucency

And what the translucency shader is like without back light

Very nice... the Dryad is looking great. Perhaps you may want to lower the reflectivity on your blinn? I think a lower value might give a more pleasing sheen to the leaves.