As for value settings, the Subsurface value is set to 0.015 in the post. To be honest, 0.01 seems to be better than 0.015, too much will cause 'glowing' and a strong reaction. This recommendation comes from Blender. The Subsurface Radius value, hidden, is 1,0.5,0.1, although 1,0.2,0.1 gives a better expression. The Subsurface radius value is a breakdown of how each RGB channel is expressed. By default, each value is 0.1, so if you want more red expression you need to increase that value to at least 1. Below is a render of V4 as Cheetara with the nodes above. Note the ear and the nails. That little hot spot on the ear can be reduced by changing the Subsurface value to 0.01.

Afrodite-Ohki posted at 12:16PM Sat, 26 December 2020 - #4408588

-I'm avoiding to use Cycles root and nodes specifically because they preview all white, which is a bummer because I spent this entire year in blender and got quite comfortable with Cycles nodes meanwhile. But from what I understand, the Eevee realtime renderer has different terms of use than Cycles so we probably can't ever hope for nice previews of cycles nodes anyway because they can't add Eevee to Poser. Which makes me wanna stick to PoserSurface and PhysicalSurface.

Even if all we got was Poser picking the most likely diffuse map and using just that by itself, or reverting to the Firefly materials for preview purposes, it would still be easier to work with than all white. (Sometimes I switch the renderer back to Firefly so I can work, but it's slow to switch and then inevitably I forget and accidentally do a Firefly render.)

Failing that, the root nodes could add a "Preview" option the way they currently have Superfly and Firefly, so you could explicitly define the preview materials.

An accurate preview would be even better, or maybe a preview that required a "pre-bake" step to do a partial render, but how are you supposed to point eyes correctly when the eyesurface material is all white? Impossible. A mini-render button would be pretty useful in the material editor, too -- maybe I can't get a live preview as I adjust the nodes, but how about clicking a button and having Poser calculate them? That would be an improvement.

Keep your render settings simple and use the Raytrace Preview. In the Material Room set the Auto Refresh on and whenever you make changes in the Material Room it will automatically refresh. I have it pinned in the Material Room but Auto Refresh off.

Ghostship Uber 3. I have to admit, this is a custom shader that can be found at Sharecg.com and works very well. I really like it a lot. This node arrangement is rather simple, I'm only using a texture and bump map. Again, it's a creature character but I use the same workflow with tweaks for regular models. This is Grotto's Vampire for Michael 3, something I was playing around with that has no base texture with the exception of Michael 3 original map. I omitted that map and worked with what I had.

Again, the arrangement is simple, I used the CombineRGB as part of the subdermal texture and connected that to the SSS Color of the Main Node. Since I am working with the original character map, I connected a BrightContrast node between it and the red channel connector of the CombineRGB. The purpose was to brighten original map and lose some background detail. On the Main Node, the SSS Radius was set to 1,0.2,0.1, I don't deviate much from those numbers unless it's a fantasy character with different subdermal properties. I believe the SSS Scale determines how much subscatter is emitted through the base skin, I actually need to research the connector further. Anything over 50% is too much; I think I settled on 0.5. The Diffuse/SSS Mix is sensitive, 0.1 to 0.15 seems about right. Over that and things just don't look right.

This is what I rendered:

If you notice, my HSV node values are high to compensate for the lack of detail in the skin due to SSS in previous renders.

@ghostship2: Thank you! I'm up from my (failed) nap (attempt), I'm gonna give your shader a try here and see how well it works on my hair!

@Rhia474: My pleasure, and my quality control I impose on myself demands that I can let go of versions that are too old but won't get stuck in previous versions - I wouldn't simply ignore P12 users just because things are changing. Though I am learning now to probably only update things once the renderer is stable! And I'm glad you like my stuff <3

@ChromeStar: god, being allowed to define which root is the preview would be a godsend. Though I'd also be happy if Poser automatically picked up whatever root is NOT CyclesSurface for the previewer.

@hborre: every time I tried using the Raytrace Previewer, I'd crash my system. Not sure if it's more stable now in P12. Also, that tiny window doesn't allow for noticing much in the sense of issues in a scene's setup.

Using the Uber 3, here is a Vulcan. Green subdermal Subsurface scatter.

BTW, I just remembered, if you are not using the eyebrows zone for any eyebrow texturing, do not apply any SSS to it. The zone will glow.

hborre posted at 1:49PM Sat, 26 December 2020 - #4408651

BTW, I just remembered, if you are not using the eyebrows zone for any eyebrow texturing, do not apply any SSS to it. The zone will glow.

It's glowing without any SSS in the eyebrow zone - just SSS on the underlying skin is enough to make it glow.

Anyway, trying ghostship2's hair shader - I think I'll adjust a little, but I do like where this is going~~

Checking with other lights before I change anything.

Oh god, Anuli's skin is looking like varnished plastic in P12. LMAO

I tinkered a bit. Perhaps too much. xDDD

On to the PhysicalSurface. In this last set, I used a simplified version that works. In this case, I used a SeparateRGB with a Diffuse Map and ScatterDist_mm values for the following: R=5, G=4.5, B=0.9. I don't deviate from these numbers unless it's for fantasy characters.

This is the result:

Don't mind the lips, that needs some work.

I duplicated Ohki's skin shader by introducing a CombineRGB between the Diffuse map and SeparateRGB. The Diffuse map got plugged into the red channel and rendered without any further changes.

The results.

I think I like this better.

You're not getting the problem I had because you have no purples in your scatter map :)

I actually used the Diffuse map to generate a scatter map within Poser. Did you create the Scatter map in 2D software? Try my set up and see if it works for you.

Yep I painted the map. I have tried the setup, long before, when I was making that character - the thing is, there's a bug in the scatter. It needs to be fixed. I know how to work around it for characters, but it's not how I intended the skin to look like - and anyone who needs a purple scatter can't do it properly, at least with the PhysicalSurface root.

Do you want a purple subdermal scatter?

For specific areas - yes. That's why I painted the subsurface texture in that character. AND - no matter what I need for my characters specifically, the purpose of this thread is trying to figure out what's bugged and what we'll have to adapt in our materials because they've changed :)

I've just submitted two support tickets: one to report the purple scatter bug, and the other to suggest that they make the previewer pick up non-CyclesSurface roots so we have better previews other than pure white.

I understand now. I went over all the posts in this thread to get an idea of what you wanted to accomplish. There has been a recent update uploaded recently, 12/22, version 12.0.340. Are you working with this version currently?

hborre posted at 4:44PM Sat, 26 December 2020 - #4408668

I understand now. I went over all the posts in this thread to get an idea of what you wanted to accomplish. There has been a recent update uploaded recently, 12/22, version 12.0.340. Are you working with this version currently?

Yep, that's the one I have :D

I have managed to get some purplish SSS in the ears by ramping up the R and B channels to around 20, leaving the G channel at zero. I think the values are too high because the texture there is blooming. Also, there is an overall softening of the rest of the model due to the higher values but this is the best I can do. No purple around the eyes from what I can observe.

There is a bug on the PhysicalSurface SSS as reported by Chromestar, I believe. If all the SSS channels are set to the same value, they negate each other and you get no Subsurface scattering. At the moment, I am just as stumped as you are. Maybe that's the way it should be but until a tech says otherwise we'll need to sit tight and figure out a workaround for your particular needs.

hborre posted at 5:19PM Sat, 26 December 2020 - #4408671

I have managed to get some purplish SSS in the ears by ramping up the R and B channels to around 20, leaving the G channel at zero. I think the values are too high because the texture there is blooming. Also, there is an overall softening of the rest of the model due to the higher values but this is the best I can do. No purple around the eyes from what I can observe.

From my tests, it gets green where it's directly front-lit - perhaps it didn't happen in your test because you don't have a direct strong light?

There is a bug on the PhysicalSurface SSS as reported by Chromestar, I believe. If all the SSS channels are set to the same value, they negate each other and you get no Subsurface scattering. At the moment, I am just as stumped as you are. Maybe that's the way it should be but until a tech says otherwise we'll need to sit tight and figure out a workaround for your particular needs.

Oh, so that remains. That bug seemed to be discovered in P11 when BB was trying to help me make a PhysicalSurface skin for Mayu, in the thread I posted earlier in this thread. You'll notice I add tiny fractions in some of my values in my tests because of this :) so that's not what's at play here.

Also, my bug report got a reply already - they have confirmed the behavior and that it also happens with the Cycles native BSSRDF Subsurface Scattering node. Apparently it only happens if the green Subsurf value is at 0, so supposedly we can work around it by adding something like 0,001 to green there. I'll test here. But they're gonna write it up as a bug anyway. I'll test the workaround here to see if we can use that meanwhile - if it works, I'll be able to issue an update to Mayu soon.

(Anuli will likely take a bit longer - her skin is lit everywhere, the poor babe.)

Workaround confirmed - add a bit of green when you try to have purple in your scatters.

Will see how to use this on Mayu's shader soon.

Okay, that makes some sense although I have tried offsetting the green channel value to something other than zero. Nothing on my end. And yes, I am getting the green as you are.

Hmmm I'm not sure what to make of Mayu's skin - her lips get yellowed even though the ScatterDistG is at 2.0015.

If I unplug the scatter map, it renders the correct color, but very blurry - I take it it's because P12 needs lower scatter values.

Lowered values, almost no green value, still yellowed lips.

No map, lowered values, lip is pink.

I'm annoyed. xD

This is as purple as I can get her without turning her into a grape.

Supersaturated skin map instead of my painted SSSMap.

Lips are the correct color. I'm twenty shades of annoyed. Poser, why do you hate me.

You won't believe what the Material Room looks like.

hborre posted at 5:46PM Sat, 26 December 2020 - #4408677

This is as purple as I can get her without turning her into a grape.

Not a grape perhaps, but she's definitely looking fruity xD

I must confess I'm completely puzzled; in my tests everything had a super strong orange or red tint. @hborre--what lights and background are you using, and are you testing in other environments than what your base setup is? I have EnvSphere, a neutral colored backgound drop and one light. Unusably orange or red, everything I tried from your setups.

I usually use a Studio lighting set created by Ghostship that comprises 3 area lights. I think you can download the set from Rendo or Sharecg.com. I use no background whatsoever when testing; that eliminates any unwanted reflected surfaces and color that can influence the results. I want a natural response to the existing lights. Once I determine that the texture settings are to my liking I proceed to introduce other props and environmental background. If I need to tweak I will but that is seldom the case. I wind up tweaking and testing in preproduction a lot. If you are using SSS and those settings are unusually bright or just don't look right then the values are totally off somewhere. Of course, whenever I start introducing props and environments those also get the same treatment, tweak until they look right in the scene.

There is a bug on the PhysicalSurface SSS as reported by Chromestar, I believe.

Wasn't me, but I'm glad it's reported.

@hborre What's the rationale of separating the RGB channels before sending them to the ScatterDistR, G, and B inputs? Don't those scatter channels already only look at their respective color channels without having a node explicitly split it?

Bagginsbill was the individual who suggested the separation node when Ohki began exploring the option of using an SSS map. I wish I bookmarked that discussion for future reference, maybe Ohki has it archived somewhere. I believe it cleans the signals better without having to rely on huge values for SSS activation. It also makes it convenient to plug the map into one connector rather than 3.

I use those lights too. Are you saying you just popping the lights and the figure into an empty scene and render? What causes scatter and Sss then if it is an empty universe? What am I missing here?

Also, even when I only use the Construct, or nothing whatsoever but figure and light, the orange/red highlights are there and making this unuseable. None of your setups work for me and I am really not suyre what I am missing.

For now I just give up until EZSkin is fixed. Thank you.

Take her to the squeezing room to be juiced.

@hborre I think the separate RGB node is used to separate skin from eyebrows and pubic hair on the map. you don't want SSS on hair parts. you take the red portion out and use that to drive the SSS. This is why I use a natural map on face and body so that tattoos are included as skin.

That's why I use a pristine base map if I can find one.

@Rhia474: you inquired about an environment around the model with ambient light. I quickly threw an HDRI onto the background, just something simple and basic. The first creature I was playing with still has the lights in place and on. The second image is just illuminated with ambient light from the HDRI.

Ambient light.

I think the background image might be upside down but you get the idea.

ghostship2 posted at 12:00AM Sun, 27 December 2020 - #4408695

@hborre I think the separate RGB node is used to separate skin from eyebrows and pubic hair on the map. you don't want SSS on hair parts. you take the red portion out and use that to drive the SSS. This is why I use a natural map on face and body so that tattoos are included as skin.

But assuming you don't have tattoos to worry about (or use a separate map without them), doesn't the ScatterDistR_mm input on the PhysicalSurface root node already only look at the red channel? Isn't that the point of having separate ScatterDistR_mm, ScatterDistG_mm, and ScatterDistB_mm inputs with their own parameters?

If the answer is "we don't trust that the ScatterDistR_mm input is correctly only using the red channel", I accept that. It just looks redundant to me to separate out the red channel and then feed it into an input that I think is only going to look at red anyway. It's also possible I misunderstand what ScatterDistR_mm is doing. But after teaching myself Poser for many years I've accepted that there are people who actually know what they are doing and I should try asking them. :)

On the Separate RGB thing: they use the node to separate the color channels because the PhysicalSurface root has one definition for each color channel - so to correctly use the colors of an image map, you have to plug each color into its scatter channel.

And the discussion on that skin shader can still be accessed on Rendo, I linked to it earlier on in this thread, here: https://www.renderosity.com/rr/mod/forumpro/?thread_id=2935202

Ok, so the answer is I misunderstand ScatterDist. That's good. :) For the sake of my own understanding, it's helpful for me to restate it:

Scatter Inputs expect values not colors. It's not that you're feeding it the color that should be scattered, but the distance that a particular color should be scattered. It's not that ScatterDistR_mm is taking the input red light and scattering it, but that it is taking in a value that says how far red light should be scattered. If the color isn't present (i.e. in the diffuse), it doesn't matter how far light of that color will be scattered, because there still is none of it present and scatter won't add any of its own. If you feed the color map into the ScatterDist inputs directly, the scatter distance will be proportional to the total brightness of a given point, but it will be the same distance for all three color channels (unless you change the numeric parameters for those inputs). That might work to a degree because the light available to be scattered is also getting that color from the diffuse map.

Separating your component map with the SeparateRGB node and feeding those into the ScatterDist inputs tells Poser to assume for areas with more of a given color that light of that color should scatter more, and colors that are less present should scatter less. That's a bit redundant because the available light to be scattered already has those colors more or less present according to the same map, but it might magnify the effect. It becomes most obviously wrong when the surface color is different from the desired scatter color, e.g. a colored tattoo or makeup shouldn't change the fact that we've got a lot of red under our skin.

Also, the bug appears if the parameters for the three ScatterDist?_mm are all the same. Regardless of the input values coming in from different nodes. Different inputs don't fix it.

ChromeStar posted at 1:11PM Sun, 27 December 2020 - #4408723

Also, the bug appears if the parameters for the three ScatterDist?_mm are all the same. Regardless of the input values coming in from different nodes. Different inputs don't fix it.

What you said before this was what I had figured from that past thread, but this part here confused me - not sure I get what you mean.

I'm glad it matches what you got from that thread, that means I probably understand it now. :) On that last point...

If the issue was that the distance light is being scattered in the red, green, and blue channels could not be the same, then you would be okay setting those channels to the same value (e.g. set them all to 1.0) if you had different maps or other data plugged into them (e.g. perhaps from the SeparateRGB node). Because then for each point, the scatter distance would still be different.

But that's not the case. For whatever reason, if you set them all to the same numeric value (e.g. 1.0) even with different inputs, the bug still occurs.

ChromeStar posted at 3:23PM Sun, 27 December 2020 - #4408739

I'm glad it matches what you got from that thread, that means I probably understand it now. :) On that last point...

If the issue was that the distance light is being scattered in the red, green, and blue channels could not be the same, then you would be okay setting those channels to the same value (e.g. set them all to 1.0) if you had different maps or other data plugged into them (e.g. perhaps from the SeparateRGB node). Because then for each point, the scatter distance would still be different.

But that's not the case. For whatever reason, if you set them all to the same numeric value (e.g. 1.0) even with different inputs, the bug still occurs.

Yeah that's why this is annoying me to no end. The greenery on the purple scatter goes away with any amount of green set to the scatter, but then there IS green being added ther with my shader and it still makes my purple-colored parts all yellow - if and only if I have a map with purple in it set up. I don't know what to make of this arrrrrgh

Figured out a workaround for my SSSmap.

Rhia474 posted at 11:36AM Sun, 03 January 2021 - #4408622

I can confirm the eyebrow bug is alive and well with very old GTX cards as well, guys. I posted somewhere weeks ago about it. For us not inside the node cults: should another bug report be filed or is this already being worked on please?

Hiya, I've found it's reduced or goes away completely by not using the OptiX option in the card drop down! This is being worked on but they are not there yet!

I am not having an OptiX card and I still have it. My card is a lot older than those fancy options.

OK. It was something I noticed was smoothed out when I wasn't using OptiX so thought I'd mention it. I'm hoping this week we testers get a new beta with that fix working. Fingers crossed!

I tried with Optix, with no-optix gpu and with cpu render and had the issue, sadly we can only wait for them to fix the thing...