Just check out the file I linked earlier. Specular and camera sees the light through the SSS window. Plain old SSS node, changed the radius and maybe the color, nothing else. No idea how long it’s been the case-- I’d expect it’s an optimization for diffuse that’s been around for as long as there’s been a SSS node. Would be easy to miss, because in most situations the light contribution from going through SSS is essentially zilch, and at least your 0 roughness mirrors echo what your camera sees, even if you diffuse floor doesn’t.
I see. Ok. Well, then my suggestion to @akej74 for the time being would still be to use render layers then. It’s good practice anyway. Keeps things clean where you dont need to do as much processing. Some glass with roughness on another render layer and just steal the spec from the ground plane and layer it over it should do the trick. Youll have a lot of control over how much transmission gets through without effecting the shader it’s self that way also.
If the application is on a door, I’d just mix diffuse with translucency, then with refraction if needed, finally fresnel mixing in glossy. If the thickness doesn’t change, why even bother with sss?
Anyone in position to test this behavior in other software?
You could try using a full volumetric SSS shader
That’s what I did for the legos above. Principled volume made it very easy but render times went up around 600%. I did this just for close up beauty shots that should be 100% physically accurate so I don’t mind too much. But for his window I still think render layers will be the cleanest way of doing it while maintaining good render times
I’ll test in maya/Arnold today and post. Just got up
I did a test with multiple settings in cycles aswell as multiple render engines. Here are all the results. Seems SSS is definitely broken in cycles, and sampling isn’t all that great either TBH. All tests were done at 500 Samples. Times are recorded below, or on the photo.
in this example the volumetric example is the most “accurate” but not nessecarily the most visually appealing. I was able to get it to look more like the SSS results but it began breaking the rules of PBR to do so. One could argue that if it looks right it is right, but my main focus here with this test was JUST the numbers. The other question in that instance to ask is, is it right as is because the numbers are right or are the numbers wrong and SSS looks technically more right, in which case, which is broken?
Volume rendering for all 3 windows took 00:01:07.31
SSS with renderpasses took 00:01:10.27 seconds. Only a few seconds difference. Not really faster but certainly better lit in relation to the window pane and has a lot more control in post production if you wanted to make the cast less bright.
For the final test I ran SSS in Cycles, Luxcore, and Arnold for Maya. These are the results side by side. Note that Arnold does not use a static number of render samples but rather a range. Even with adaptive sampling turned off, it prioritizes brighter areas in terms of sample count. It certainly shows in the render time. It is also probably the most accurate IMO to what I would expect to see in real life. It feels much more dynamic and alive without blowing out colors so I, as usual, am going to be fangirling over Arnold for a little bit. I will note that Lux core seems to have limited options in terms of controlling the bounce count compared to arnold or cycles so luxcore is lit a lot more which likely contributed to the long render time.
The wall facing the camera on the Arnold render is pure black. Do you have GI turned on at all?
The Cycles render should also have a pure Translucent material mixed with a SSS node. As was said before SSS in Cycles only does the surface. To get rays to go through you need translucent. The rays in Arnold have to be calculated the same way. It would be a better comparison.
All things in a computer is a simulation. It’s up to us to make it look real. SSS does not work the same as in real life. If it did it would take infinity to render.
The purpose of this test is solely to answer the question asked on this post of, how does SSS compare to other engines SSS. I also stated that SSS on its own should not typically transmit light. What you are seeing in cycles is, well, I dont actually know. Light bouncing off the surface and back I guess because all of these were rendered in a pure black world… As for arnold. I set the same number of light bounces on a pure black background as everything except lux core which still is a little touchy (at least in the version im running). And as far as I am aware after 6 yeas of using Arnold, arnold is a GI engine by defult. You dont have a WHOLE lot of choice in the matter. The only option I am aware of is to turn your ray depth down on diffuse to 0. This was shot at 3 bounces so that should not even be an issue. 3 is enough for most simple renders. As I pointed out. The test is, number for number, entry for entry, what are the results. Also, I didn’t have to do any such thing to Arnold. All I did was turn random walk on and drive the SSS. Do you care to elaborate on your concern of how rays are passing through? Ive never heard this in my time using it.
EDIT: It’s black because of it’s color space. I work in EXR format. The image in the test was set to match the filmic color of the blender tests. I changed the color to a different one so you could see, it’s not black, its just handling light differently.
@CarlG asked to see a test of what SSS is like in other engines. This is a test. Arnold having a lack of bounces which can be addressed with some tweaks to the settings has NO impact on the result, you can clearly see light is being transmitted through the SSS window. If there are extra steps involved in making that work in blender when according to others this is only due to a current bug, then the issue isn’t with an arnold render, this is a bug with blender.
Bouncing light is what GI is all about. In the Cycles and Arnold render there are edges that have a tiny strip of light that should bounce and light up to the wall. I didn’t see that in the Arnold render so I though maybe you had GI off. Diffuse of zero should be the same as GI off.
As for comparing SSS to other engines I’m not sure SSS in Cycles is a bug, so it’s probably better to assume it’s not a bug. In a computer a ray tracer, like Cycles, Arnold, LuxCore all function basically the same way. Light rays are traced. When the ray hits a polygon the program has to say what the ray will do next, like bounce, reflect, diffuse, go right through without changing anything like if it was a 100% clear alpha, spawn additional rays, or basically could do anything a programmer wanted it to do. In a true volumetric material it would trace the light paths as it went though the material, but would eventually see the edge of the polygon volume and have to decide what the ray does when it hits the edge of the polygon. True volumetrics are expensive in this way as it’s calculating a ton of paths as a single ray of light diffuses into other rays that spawn yet more rays. It does not matter how great their tracer is it will take a lot of calculations. There is no way around it. For that reason many ray tracers go with a more simple calculation that looks the same in most situations. This simplification comes by separating the SSS from the Translucent. In addition a simplified equation is used for both the SSS and translucent light. The Arnold material seems to combined the two processes of SSS with translucent. LuxCore probably takes so long because it is doing something closer to the real deal volumetric calculation. Cycles does not combined the two because it’s node based and they know people can change it however they want with nodes. This is why I say if a Translucent was mixed with a SSS node it would be closer to the same result as Arnold. To look more like Lux volumetrics would have to be used. Can’t know if it is exactly the same unless we looked at the coding of each program, but from tests we can change the materials until the look is as similar as possible. With light not coming through the SSS on Cycles it is obviously not as close as possible. To match the materials as close as possible tests should be done that include different lighting, objects, in addition to the doors all rendered at different angles. It is a really hard process if one wants to do it right. If the materials and lights match perfectly the renders should look exactly the same. The difference in calculation between different render engine materials is actually the biggest reason it is so hard to properly compare different render engines. I was trying to match a color in both Cycles and Octane and they were rendering as different colors. The RGB value was the same, but rendered as different colors with the exact same white light on a plane diffuse material because they ramp the color values at different rates. It’s crazy.
Well I appreciate the thorough reply. Sorry if I seemed a little ticked off. Just didn’t like the question about GI when I ran every setting I was able to change 1-1 including bounces. Except li core cuz their setting are a mess, but everything got 3 diffuse. Oh how I would love to crack open the code of Arnold if I could… I know I could do it for Cycles but tbh except for this SSS question I’m not that interested. I did think of one other thing that could be the problem. In Arnold, Arnold prefers Arnold lights to maya lights. That’s just sort of the way it is. They look better. The problem is I used a directional light in blender and Arnold doesn’t have a directional light, it has either an IBl light or a “sky” which has a sun but there is blue light from other directions and not a whole lot of control over temperature and light angles because that is then controlled by “time of day” so I had to use a maya light with the value cranked to like 50,000 to get even what you saw there.
With SSS in cycles, supposedly, more than one source has now told me, this used to work in older versions of blender. So I’m gonna drudge up an old copy from maybe 2.6 and see if it’s an issue there. If I have to look harder from the 2.6x builds then I don’t think it’s worth digging deeper unless someone else is inclined to debug an unbuilt build of 2.8x or 2.9 and see if they can figure out at least if it’s a big or not.
I also agree about testing multiple scenes with multiple different lighting‘s but I wanted to do a comparison based on the original post from the thread starter Specifically to see how their scene would interact differently in different engines.
Doesn’t really matter for what I was asking. I was wondering if “energized surfaces” through sss gets converted into direct lambertian light source in other software, similar to how translucency becomes a direct lambertian light source in Cycles. Translucency and sss are both part of the diffuse absorption term, and light independent. Is that the case with sss?
I did try it out in 2.79 (yuck, damn that was hard to use now :D), and I didn’t get any from it there either. I’m “pretty sure” I’ve had luck with it somewhere in between, but now I’m starting to wonder if it was just due to rough specular showing up. I have no issue using translucency for the effect, I was just curios. Didn’t mean to start a war. 
1 Like
Yeah I never recalled it happening before, because although @watercycles and I have a disagreement over how a study on this single variable should be tested, we both agree that SSS on its own typically does not transmit any light through. But I will admit I use it so infrequently in a position where I NEED it to cast light onto something else that I never really payed much mind to the fact that Arnold and lux did it and cycles doesn’t.
For the argument that cycles is great because it’s node based and all that and you can customize it to transmit lite…, I feel like that’s very true for the normal node sets, but for the principled set it is sort of illogical given the purpose, at least how it’s presented, is to be physically accurate and I do hope they implement it soon. Or at least give me a checkbox to turn on sss transmission so doesn’t have to be blended in top of other principled parameters and can be stacked in its proper place.
1 Like