Perplexing SSS Anomaly

Another perplexing issue. I hope the solution is easy. I have a distinct band that renders across the chest of a character I am working on. It does not appear with just the diffuse map. Only when SSS is in play. I have checked all the materials very closely and not a single one of them has a hint of this band. I have sent the SSS node alone to the material output and it displays this odd band. None of my other nodes are causing this. I also superimposed the mesh over the render to see if anything matched up, and it does not. Furthermore, while I primarily work with self-compiled GIT Blender, I also tested in stable and even 2.73a with identical results.

Of course, this character will have a shirt so this is not a screaming disaster, However it is troubling - the flaw could pop up somewhere else that cannot be so easily hidden so I’d like to find the cause of it if that’s possible. Have any of you seen anything like this?

Render preview of flaw:

With the mesh superimposed:

My very simple SSS node setup:

It seems to be a terminator-style issue, I have never seen this with any of my models.

Have you tried checking for stray geometry around that area?

That was a good idea, but when I tried to remove double vertices from that area, it didn’t find any. Thanks for the tip, however!

You call it a “simple” setup but you have do have node groups nested 3 deep. That’s not a bad thing, but’s it not simple. What happens when you plug a colormap into a single sss node and straight to material output.

Bonus points for all quad!

Shot in the dark, you have both bump and normal. Usually to use them both you feed the normal output into the bump normal input. Sometimes I accidentally put it into the height and I see some weird shit fly at that point.

Nesting the groups helps me keep things organized. Definitely makes it more manageable. Nevertheless, I isolated just the SSS node outside the groups to test. Here is what I got, pulling the same texture and radius settings. Sans radius the flaw is still there just a little wider, oddly. I found that the lower the scale, the greater the flaw.

Scale set at .001

We already know what effect .020 has on Scale.

I cranked it to .7 and the flaw pretty much disappears. For this screenshot, I returned the output to my group, with a Scale of .7 and a fac of .020

The troubling thing is, I got it looking the way I wanted. I used the back-lit ears to help tweak the settings and now the entire dynamic has changed. The larger scale makes the entire ear more translucent rather than just the thinner parts, so that’s going to be a headache to solve.

I do wish we had better documentation on this node…

Hard to say without seeing it. Can you chop a section and post it.

And I’m not knocking the node groups at all, they are a good idea, just saying to trouble shoot go basic.

Second shot in the dark. Your signature mentions bleeding edge git, have you tried in latest stable version.

you are set to experimental.?

what about rogue geometry under it. Select a good vert, Ctrl l to select connected, Ctrl I for inverse, delete.

I usually leave it on Experimental. I tried it in 2.73a, 2.74, and GIT. Same issue. I also tried two other maps.

Well, come to find out, it boils down to something endemic to the G2 Male mesh generated by Daz Studio. I tried several diffuse maps on it with the same results. Even diffuse maps from Genesis 1 meshes. I also tested my nodes on Genesis 1 meshes as well as G2 Female meshes and nary a problem. So something in how the UV is set up in the G2 Male mesh is what is causing this. The original G2 mesh was from an FBX, so I imported an OBJ of the same mesh, with the same flaw. So definitely something peculiar with the UV settings of the G2 Male. I wouldn’t begin to know where to look at the moment. The flaw is very regular and symmetrical, and ends just below the figure’s pecks.

Latest from GIT, imported objects… Have you tried digging this direction:

Have you actually taken a look at the normals, I think there’s a good chance that each of those funky faces has 1 or more flipped normals per face. (in edit mode, prop panel (n) turn on vert normals. ) And when a ray hits the sss it is attempting to scatter outwards. That’s my Friday morning coffee theory anyways.

Thanks, I have indeed examined the normals, looked for hidden geometries, and cleared custom split normals data to no avail. I must expand the affected meshes - all of the G2 range, both female and male, are affected. I tested on an unmodified G2 male mesh and on a G2 female mesh I had previously worked with - both imported from FBX and OBJ. Furthermore, G1 meshes are not fully immune, but the flaws are less obvious than the G2 meshes. It would seem that there is an incompatibility in the SSS Shader and something in these meshes. I have flipped through several textures, even smudged textures to see if that would have any affect. I experimented in different export settings. I have imported FBX, OBJ, and DAE, all resulting in the exact same issue. I even duplicated the flaw on my workstation at work too. I’m kinda running out of things to try.

Genesis Male - minor but symmetrical flaws on side of chest

Genesis 2 Male - base mesh with no modifications and with default textures

Genesis 2 Female - from a character I had created

The license does not allow me to share the meshes, but I would appreciate it if anyone else with Daz Studio would be so kind as to independently confirm the flaw. I cannot tell if this is a subtle bug in the SSS code, or if something is screwed up with the meshes themselves, however.

Okay, I may be over-reacting. I noticed flaws cropping up in preview renders of the face while I worked on the settings and about had a cow. But… they did not show up in actual renders! All the images I posted here were from preview renders. It would seem that the preview renderer is different from the actual renderer.

Here is the preview render:

…and here is the actual render:

It is still perplexing, however. Would like to figure out where the flaw is - in the SSS code of the preview renderer or in my mesh. Not that it really matters since the actual render is what ultimately counts.