User Tag List

Results 1 to 28 of 28

Thread: SSS bug in 4.15.1

  1. #1
    4

    SSS bug in 4.15.1

    Hello,

    I'm on 4.15.1 (But I think this bug is present in older versions too).

    Subsurface Scattering usually shows when it's hit with direct light. I.E:



    In UE4 However, I've setup a scene using only a skylight, with flat lighting or ambient lighting, you should only see the diffuse color, not SSS. BUT:

    SSS Intensity = 1



    SSS Intensity = 10



    Skylight influences the SSS way too much!

    Engine version: 4.15.1
    Repro Steps:
    1. Create a new map.
    2. Remove pre-baked lighting.
    3. Remove directional light.
    4. Add Skylight.
    5. Add PPV, disable auto exposure (just so you see the issue easier).
    6. Add a SSS material to a mesh and change the SSS multiplier.

    SSS shouldn't make a visible difference while in flat ambient lighting condition.

    Edit: https://answers.unrealengine.com/questions/591690/sss-is-affected-by-skylight-shouldnt-be.html
    Last edited by Maximum-Dev; 04-22-2017 at 11:05 AM.

  2. #2
    0
    Another test.

    Material:



    Direct + Skylight:



    Skylight only. Since Skylight has Lower Hemisphere being black, it's only casting light from above hence you see red on the bottom, but it should have been grey all the way since skylight is not a directional light source but is an ambient light.



    Lower Hemisphere is not solid black in this one, should have been grey all the way here too but it's not.




    Please fix this asap. All foliage look wrong in shadows.
    Last edited by Maximum-Dev; 04-25-2017 at 06:18 AM.

  3. #3
    1
    Unreal Engine Developer
    Join Date
    Mar 2014
    Posts
    1,264
    Thank you for logging the report on the Answerhub. We will follow up there.
    Stephen Ellis | Lead Engine Support Technician | Epic Games | @TheEpicStephen
    How to report a bug | >>Click here to report a bug<<

  4. #4
    2
    Seriously, why should fixing SSS be backlogged? https://issues.unrealengine.com/issue/UE-44851



    How SSS looked under Skylight in old builds (correct):




    How it looks like in newer builds (wrong):




    It's unfortunately too amateur to require votes for fixing something as important as SSS. Literally no new features can be a priority over broken SSS.
    Last edited by Maximum-Dev; 05-19-2017 at 09:55 AM.

  5. #5
    0
    This is definitely a bug.

    I would urge Epic to please have someone other than Andrew Hurley evaluate the AnswerHub post, as he has a track record of telling people that obvious bugs are in fact working as intended. More often than not he does not understand the repro steps and misses the point of an AnswerHub post. Definitely need a second opinion on this one.
    Last edited by DamirH; 05-19-2017 at 10:16 AM.
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

  6. #6
    2
    Not sure if is a bug or intentional but:
    1) SSS was not affected by movable skylight in earlier versions and it was fine.

    2) SSS should be affected by skylight, but as to its practical dynamic implementation, unlike for actual lights, object thickness is not considered, so in the essence it looks a bit fake. I think it is better to leave up to artist to crank base color instead, for you can always make up for lack of skylight SSS with basecolor, but you can't otherwise compensate overly strong SSS with a diffuse
    .
    3) If SSS is to be affected by movable skylight, it at least needs to weighted by material's opacity, which seems not be the case. This is actually the part that can be deemed as a bug.

  7. #7
    0
    Has Epic followed up on this? It's a little disconcerting that something that affects every piece of foliage in UE4 could be this broken and ignored

  8. #8
    0
    Quote Originally Posted by nickgalope View Post
    Has Epic followed up on this? It's a little disconcerting that something that affects every piece of foliage in UE4 could be this broken and ignored
    It's flagged as resolved, the issue is backlogged, and the repro steps are not correct! (Both Stationary and Movable skylight light give the same wrong result, you can only see the correct result with baked Static Skylight). Having broken SSS/foliage in 100/100 projects is the new norm now! VR here, VR there, VR everywhere.
    Last edited by Maximum-Dev; 05-27-2017 at 05:55 AM.

  9. #9
    0
    We ought to get the option to add comments to tickets. This whole situation is a disgrace and it's even more disgraceful that there hasn't been an official comment on it for a very long time now. I don't want this to turn into another rant about Andrew Hurley so to perhaps turn the topic onto a more positive direction - do you think that maybe it's backlogged because they're working on an alternative solution that will work with forward rendering?

    A fool's hope, I know...
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

  10. #10
    0
    Quote Originally Posted by DamirH View Post
    We ought to get the option to add comments to tickets. This whole situation is a disgrace and it's even more disgraceful that there hasn't been an official comment on it for a very long time now. I don't want this to turn into another rant about Andrew Hurley so to perhaps turn the topic onto a more positive direction - do you think that maybe it's backlogged because they're working on an alternative solution that will work with forward rendering?

    A fool's hope, I know...
    Okay since you mentioned the word rant, despite many believe there are usually people ranting around the forums, I haven't noticed anyone "starting" a rant, specially on these feedback forums.
    If you're giving constructive feedback but it's not of Epic's interest and you are ignored, then your constructive feedback is turned into a rant which in the end is not your fault to be blamed for. The rant is a product of how company treats feedback.

    Okay let's open this a bit. The day I joined this community I was a neutral community member slowly learning the engine. I had a very nice relationship with Epic staff be it MP guys, Rendering guys or anyone else. They even used to reply my PMs. But as time went on and started noticing "wrong things" kept happening around, and because I very much cared about this community and loved Epic, I started to give honest, constructive feedback as well as pointing out the system's faults and failures hoping to see improvements, because everyone knows, Epic seems to love feedback so much and I had the same impression in the early days. Today my relationship with staff of any department at Epic is just gone. During a week I'm ignored dozens of times by staff whether it's on AnswerHub, Forums, PMs, even where I @Mention or quote any of the staff whether it's MP forum, Feedback forum, Rendering forum etc. = completely ignored. And that's a trend with everyone who get's on the same path. Yes I can bring a dozen of well known and most reputable community members who'd vouch that's all true. So a person ranting isn't simply a stupid person posting out of lack of information. A person ranting on the forums is the product of the same company he's working with.

    Now to break down how a constructive feedback is turned into a rant (and it's not specific to this SSS issue, there are more instances):

    1. You create a bug report. They don't even acknowledge any bug exists to begin with. Report is flagged as Resolved.
    2. You go through heck of an explaining pointing out precisely what is wrong and why. Your detailed explanation is simply, ignored, and report is flagged as Resolved.
    3. More people chime in and confirm there's a problem. They reply is, the behavior is expected.
    4. You PM a rendering engineer and provide him the link to the report and explain there's comparison in there showing how X isn't working as intended anymore after some engine updates. The reply you get back from the engineer "Didn't read the report, it was too long bye bye".
    5. Even more people chime in and confirm there's a problem. Epic: Okay... maybe there's a problem.
    6. Bug ticket is created with wrong repro steps so the engineers fail to repro the issue.
    7. Bug ticket is backlogged upon creating it.
    8. Everyone sees their efforts in providing feedback and comparisons is wasted.
    9. When this repeats several times over, their view on Epic changes. They complain if they get the chance to.

    Look how well @BlackRang666 has described the bug fixing procedure here and on the other hand look how even better @Nick Darnell describes that it's not as simple as flipping a coin and takes some evaluation before deciding which bugs are priority and which ones are not.

    Though the bit that's unclear is A) How is it the person that's only responsible for creating the ticket, Always flags the new tickets as backlogged since the start? B) Why the coin is never stopping on the other side? why we never see any decision made to fix any of the highly critical issues? C) How can such important base features be not a priority? there are hundreds of fixes in every release that nobody cares about as much as they care to see some critical bugs fixed. In this instance, sub surface scattering is broken, the entire UE4 userbase is suffering from it. Now are we ranting or we was on the righteous path at #1 and we were unintentionally driven to #9?

    Another example is the recent spline decals thread.

    1. Create feature request thread.
    2. So many people shown interest in the tool.
    3. Feature request ticket was created, backlogged upon creation. No news or anything after a long time.
    4. More people chime in and show interest.
    5. Was asked by Epic to demonstrate the requested feature, which I did, along with a comparison. Didn't get any attention though.
    6. Was told by Epic votes determine the interest in feature and without votes nothing happens.
    7. Votes went up from 0 to 95 though, no attention from Epic. @Mention, Quote, no attention from Epic. Thread dies and the ticket with it.
    8. People's time is wasted and they complain if they get a chance to.

    Another example is tessellation ShadowDepths problem:

    1. Bug report is created by user, Epic doesn't acknowledge any issue exists.
    2. Tons of comparisons and in depth reviews provided by users, in return, a dozen times the report is flagged as resolved.
    3. Nine months later userbase is still fighting to prove the problem is there, the evidence is there, the behavior is unexpected. Epic: There's no problem, flagged as resolved.
    4. People complain when they see after 9 months time they have only wasted time left and right trying to help Epic improve something.

    Another example is my own tessellation base cost report more than a year ago:

    1. Create bug report, post comparisons tessellation is broken.
    2. Flagged as resolved.
    3. Bring detailed explanation tessellation base cost is +20ms with even 0 tess multiplier. Epic: Tessellation is expected to have a base cost. Flagged as resolved.
    4. +20ms for just enabling flat tessellation with 0 tess multiplier? +20ms is not an expected base cost!
    5. After months back and fourth the base cost was finally reduced from +20ms to ~5ms (which is still extremely high).
    6. Further feedback is not approved and report is flagged as resolved.

    Another example is Marketplace:

    1. People still get rejected without knowing why.
    2. Generic macro replies are used by Epic when people are expecting detailed replies.
    3. Most procedures that could be automated are intentionally kept manual.
    4. After 4 years still basic online store features are completely missing.
    5. Creator's Hub is abandoned due to lack of communication between sellers and staff.
    6. Staff left Discord (while having no active presence in forums either).
    7. While the only communication channel is through email, email tickets go missing left and right and people remain unanswered.
    8. In case ticket doesn't go missing, sometimes people wait more than 2-3 weeks to get a reply.
    9. Feedback is asked for, but not collected to act accordingly.
    10. People complain when they get a chance to.


    Now this turned into a solid +A grade essay and I'm not even being specific yet, so let's stop bringing examples, but yeah that's generally how Epic handles feedback here and there and no one rants unless they're unintentionally driven to that last point of unintentional complain.

    To stay on topic () @DamirH, having such history, I doubt the reason they are not fixing SSS is because they are working on an alternative SSS solution that'd work on forward rendering too. SSS, which is applied to every piece of foliage in every UE4 project, should be among the highest priorities for Epic to fix not to backlog. And if (big if) they are working on an alternative SSS solution, that wouldn't hurt to know people about it. I don't believe I've ranted here, I've wrote the facts as is. Though, still if staff think I'm ranting, I'm sorry on behalf of myself and anyone else who points their fingers to existing issues. And making this post I know I'm destroying even the slightest chance of seeing SSS fixed, because Epic doesn't have a process-oriented procedure for fixing bugs regardless of whether anyone rants or not, as Nick himself described very well in the other thread, it's a personal-oriented procedure where they make their own decisions regardless of community input and what is important to UE4 userbase "at the moment".


    All in all, if the repro steps on the SSS ticket could be corrected (having mentioned it twice on the report) that'd be great.

    Quote Originally Posted by DamirH View Post
    A fool's hope, I know...
    Last edited by Maximum-Dev; 05-27-2017 at 04:07 PM. Reason: Fixed typo.

  11. #11
    0
    The reason they aren't working on SSS is because they aren't actively using it in one of their own projects, or at least not on a project running on an engine version where SSS is busted.

    There used to be a time when I thought they cared about feedback.

    SSS, a major component of rendering is broke. This is something that should never make it into a shipped engine build.
    Blueprints still constantly reset their variables. This is something that has been around since early engine versions without being fixed.
    Marketplace still doesn't have tags. People can only find your content if you give it a very wordy and generic title. This affects revenue for both Epic and creators.

    (Yes, I recently spent a butt-load of time tweaking an SSS ice material, wondering why it looked like poo.)

  12. #12
    0
    @Maximum-Dev - I think you misunderstood me. What I mean by "another rant" is me repeating the same old bitter remarks about Andrew Hurley. I have seen half a dozen very serious bug reports swept under the rug because he's unable or unwilling to understand and follow repro cases, often times grabbing onto something completely unrelated to disregard the report. It's been infuriating to say the least.
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

  13. #13
    0
    Quote Originally Posted by DamirH View Post
    @Maximum-Dev - I think you misunderstood me. What I mean by "another rant" is me repeating the same old bitter remarks about Andrew Hurley. I have seen half a dozen very serious bug reports swept under the rug because he's unable or unwilling to understand and follow repro cases, often times grabbing onto something completely unrelated to disregard the report. It's been infuriating to say the least.
    I understood you correctly, just tried to explain to others where we're coming from if they see us too frustrated.

  14. #14
    0
    Quote Originally Posted by Maximum-Dev View Post
    Now to break down how a constructive feedback is turned into a rant (and it's not specific to this SSS issue, there are more instances):

    1. You create a bug report. They don't even acknowledge any bug exists to begin with. Report is flagged as Resolved.
    To be fair, It gets flagged as Resolved when the support guy "looks into it" or "tries something" and doesn't experience/notice the issue. Sometimes it gets marked as Resolved just when the support guy communicates his intention to look into it (which doesn't always mean that it will happen). "Resolved" only means the support ticket is not on Epic's hands anymore, be it because they need more info / repro steps, or any other reason.

    2. You go through heck of an explaining pointing out precisely what is wrong and why. Your detailed explanation is simply, ignored, and report is flagged as Resolved.
    A ticket cannot just be marked as Resolved without any reply/explanation/question, this goes against their own support policy. Ignored tickets are just left there, ignored (example).

    In general there's a confusion over AnswerHub posts and their status. By design, AnswerHub is based on support tickets and their status only represents the status of the support ticket itself. As such the word 'Resolved' in a support ticket wrongly leads the user to think that the issue itself is considered resolved.
    gonna quote myself (again) about a suggestion I made in 2015 regarding question statuses,
    Quote Originally Posted by Chosker View Post
    I wanted to add a comment about the status of questions.

    questions get marked as 'resolved' (I know, for tracking purposes). but this happens as soon as anyone from Epic comes in and says "we will look into it" (which might or might not happen). this is completely misleading and frustrating - it tells me you almost treat this post as you'd treat other posts that are fully and properly resolved.

    this loophole has been specially noticeable in this post - an editor crash that I've been following already for one year and two months. that's right, one year and two months of "we will look into it, marking as resolved", then I bump the thread, repeat.

    I'd suggest the following statuses for answerhub questions:
    - Open - happens when a question is created, new info is given, etc. basically what is now "not resolved"
    - Answered - Epic or someone else has provided an answer, and is waiting for input from the original user to see if that solves the issue
    - Pending Fix - the issue is acknowledged as a bug, and is waiting for a fix from Epic's side. here at least a bug tracking number should be provided (so we check the changelogs of new releases, in case the answerhub post is overlooked)
    - Resolved - The fix is applied and the user has confirmed he doesn't have the problem anymore, everyone is happy. really resolved. for real.
    There's also the issue that apparently UE4 is based on "community support", where the users are meant to help other users. AnswerHub is meant as another community portal where people get help from other users, and despite Epic always points everyone to report issues on AnswerHub we actually aren't entitled to any support as you can read in the Support Page:
    For developers under the default license, Epic Games does not provide individual support for development with the Unreal Engine,
    however expecting the community to fix real and legit engine issues is a bit too hopeful isn't it?


    as for your other points,
    6. Bug ticket is created with wrong repro steps so the engineers fail to repro the issue.
    This one is especially hurting because we, the users of their product, are being treated as QA staff (being told to provide detailed repro steps and all)
    Last edited by Chosker; 05-27-2017 at 06:06 PM.
    Help me back! follow me on Twitter

    Developer of Elium - Prison Escape

  15. #15
    0
    Quote Originally Posted by Chosker View Post
    To be fair, It gets flagged as Resolved when the support guy "looks into it" or "tries something" and doesn't experience/notice the issue. Sometimes it gets marked as Resolved just when the support guy communicates his intention to look into it (which doesn't always mean that it will happen). "Resolved" only means the support ticket is not on Epic's hands anymore, be it because they need more info / repro steps, or any other reason.
    Agreed. But most of the time it's that they don't notice/understand the issue, and then they even insist there's no problem. That's not an appropriate reason to flag it as resolved and move on.

    Quote Originally Posted by Chosker View Post
    A ticket cannot just be marked as Resolved without any reply/explanation/question, this goes against their own support policy. Ignored tickets are just left there, ignored (example).
    Yes. Even though there are usually replies, the initial reply often is "This is working as intended" and it get's flagged as Resolved based on that, which is not true, they don't work as intended.

    Quote Originally Posted by Chosker View Post
    In general there's a confusion over AnswerHub posts and their status. By design, AnswerHub is based on support tickets and their status only represents the status of the support ticket itself. As such the word 'Resolved' in a support ticket wrongly leads the user to think that the issue itself is considered resolved.
    There has been instances where we were asked for more information, repro steps etc. and there was no "Resolved" flag until we posted. So the intention from flagging a report as Resolved after posting a reply is... pushing it away and moving on.

    Quote Originally Posted by Chosker View Post
    gonna quote myself (again) about a suggestion I made in 2015 regarding question statuses,
    Very good suggestion.

    Quote Originally Posted by Chosker View Post
    There's also the issue that apparently UE4 is based on "community support", where the users are meant to help other users. AnswerHub is meant as another community portal where people get help from other users, and despite Epic always points everyone to report issues on AnswerHub we actually aren't entitled to any support as you can read in the Support Page:

    however expecting the community to fix real and legit engine issues is a bit too hopeful isn't it?
    Epic has no commitment to provide individual support, correct. But fixing broken tools that affect an entire userbase is not individual support. Individual support is when they support an individual. Look at this list and this list. But in fact, they are not supporting groups and ARE supporting individuals look at this fixed bugs list I got from Roadmap these fixed bugs have far less audience than those backlogged ones. They are literally supporting individuals and have left the larger audience behind, which is where all these issues originate from.

    Like look, Option to show empty folders in the Content Browser has so far been higher priority over fixing SSS. 4.17 couldn't be shipped without showing empty folders in content browser.


    Quote Originally Posted by Chosker View Post
    as for your other points,

    This one is especially hurting because we, the users of their product, are being treated as QA staff (being told to provide detailed repro steps and all)
    Agreed. Doing some free QA is fine though, the part that hurts is when you're asked to fix the an issue on your own using your own money and do a pull request = Why paying 5% only? fix the engine as well.
    Last edited by Maximum-Dev; 05-27-2017 at 06:48 PM.

  16. #16
    2
    Just want to point out that bashing features that made it into 4.17 (i.e. showing empty folders) or finding specific examples of "look, they did this instead!" isn't really productive as it's not a 1/1 correlation. There's probably far more developers who can make empty folders show in the content browser than there are those who can debug and fix SSS. If you have 3 features that take 10 hours each chances are that those will be done instead of one that takes 30 hours.
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

  17. #17
    0
    Quote Originally Posted by DamirH View Post
    Just want to point out that bashing features that made it into 4.17 (i.e. showing empty folders) or finding specific examples of "look, they did this instead!" isn't really productive as it's not a 1/1 correlation. There's probably far more developers who can make empty folders show in the content browser than there are those who can debug and fix SSS. If you have 3 features that take 10 hours each chances are that those will be done instead of one that takes 30 hours.
    That's a very precise statement.
    On the other hand, spending 30 hours on 3 features which happen to have maybe less than 1% actual audience waiting for it, is far less valuable than spending 30 hours on 1 feature that's affecting 100% audience so spending more hours on less, but more critical features should be valued more. It's wrong to break the hours between several far less necessary issues. If something is affecting 100% of userbase it deserves as many hours it takes to resolve it.
    Would you rather leave foliage looking wrong across all UE4 projects in cost of being able to say "Hey, I fixed 3 bugs instead of 1"? of course you wouldn't, and shouldn't.
    Last edited by Maximum-Dev; 05-27-2017 at 07:11 PM.

  18. #18
    0
    Champion
    Join Date
    Oct 2015
    Posts
    713
    Quote Originally Posted by Maximum-Dev View Post
    SSS shouldn't make a visible difference while in flat ambient lighting condition.

    Edit: https://answers.unrealengine.com/questions/591690/sss-is-affected-by-skylight-shouldnt-be.html
    You based the bug report on this wrong assumption which is probably why the answerhub thread went nowhere. It's better to find out a real root cause in order for the problem to get fixed, both for discussing what's actually wrong and to actually get some useful repro cases in the issue tracker posts.

    The issues I could find were:
    1. Changing opacity for SSS/two sided foliage shading models does nothing when using a movable skylight.
    2. SSS and two sided foliage shading have different results using a movable directional light. With a 0,255,0 subsurface color the SSS material turns super green, the two sided foliage material turns only slightly greener. I'm guessing the two sided foliage one is the one with a bug because you can get the same result with the SSS one by lowering the subsurface color, but you can't exaggerate the color of the two sided foliage model.

    I could buy that SSS itself was bugged if the SSS material was brighter with a black 0,0,0 subsurface color. But it isn't, it's the same. Which means that the thing you need to do to fix the SSS issues is to use a more reasonable SSS color than completely green or completely red or whatever. For the directional light SSS vs. two sided foliage example the SSS version is 10 times brighter, so if you want the two sided foliage result just make it ten times darker. This is the same for any SSS texture maps.

  19. #19
    0
    6. Bug ticket is created with wrong repro steps so the engineers fail to repro the issue.
    Gotta agree. Seen several of those with either important info lacking or irrelevant and wrong steps added. It also seems that materials, that are linked on the issue tracker, are not always being looked at either.
    The issues I could find were:
    1. Changing opacity for SSS/two sided foliage shading models does nothing when using a movable skylight.
    I actually added multiplication of SSS color by material opacity for dynamic skylight and additional weighting by env sample in response to my team's complaints about overly strong skylight effect on SSS. Everyone was happy, but I still feel somewhat strange about it. Frankly, every offline renderer allows you to separately tweak forward/back scattering and their contribution as compared to diffuse color.
    Ranting within scope of UE4 about if skylight should affect SSS or not seems to me more of a discussion about artistic control, because the final color of the object, that appreciably scatters lights, is always combined from both diffuse and subsurface color. Essentially, I don't remember seeing any material in real world, that would appear to scatter light in a such way, that scattered light color would be widely different from diffusely reflected light color. As applicable to UE4, when you enable subsurface shading model, you should be prepared to control final color of the object using both base color and subsurface color. And in regards to dynamic skylight, weighting it by opacity has the same effect as using lower value for color. For a proper solution Ideally, you would need to do a few dozen of samples in random directions and weight each of them by opacity and object thickness along the sample direction. That, however, is way beyond a concept of lightweight ambient light
    As for bug report, the initial post was somewhat misleading, but the gist was about difference between baked and dynamic skylight.
    Last edited by Deathrey; 05-27-2017 at 10:12 PM.

  20. #20
    0
    Quote Originally Posted by cyaoeu View Post
    You based the bug report on this wrong assumption which is probably why the answerhub thread went nowhere. It's better to find out a real root cause in order for the problem to get fixed, both for discussing what's actually wrong and to actually get some useful repro cases in the issue tracker posts.

    The issues I could find were:
    1. Changing opacity for SSS/two sided foliage shading models does nothing when using a movable skylight.
    2. SSS and two sided foliage shading have different results using a movable directional light. With a 0,255,0 subsurface color the SSS material turns super green, the two sided foliage material turns only slightly greener. I'm guessing the two sided foliage one is the one with a bug because you can get the same result with the SSS one by lowering the subsurface color, but you can't exaggerate the color of the two sided foliage model.

    I could buy that SSS itself was bugged if the SSS material was brighter with a black 0,0,0 subsurface color. But it isn't, it's the same. Which means that the thing you need to do to fix the SSS issues is to use a more reasonable SSS color than completely green or completely red or whatever. For the directional light SSS vs. two sided foliage example the SSS version is 10 times brighter, so if you want the two sided foliage result just make it ten times darker. This is the same for any SSS texture maps.
    To be honest, never in your life you're going to see any SSS on your hand when standing under overcast light so I don't think I've had any wrong assumptions with mentioning skylight shouldn't affect SSS and in case I'm wrong and it should affect SSS, the effect should be so minimal and hard to notice which makes it next to nothing.

    Thanks for the workarounds. But I think you didn't understand the issue correctly. It's correct SSS looks strong while under direct light. It just shouldn't look as strong under skylight. So your workaround of reducing SSS intensity and color in order to make it look acceptable in shadows on the other hand is bringing down the SSS effect while under direct light as well, making SSS look fine under skylight but wrong under direct light.

  21. #21
    0
    As it currently is, even under a cloudy dim sky SSS objects are blown out with their inner glow. Skylights are not intended to be used as direct sources of light, so they should have a multiplier that reduces their impact on SSS. This would be great as a parameter on the skylight itself.

    https://issues.unrealengine.com/issue/UE-44851
    If you look how its written there, the report has an obvious undertone of "f*ck the users, I think its fine."

    "Lasers and skylights both have photons so hur durr."
    Yeah, sunlight diffused through clouds and a 25 gigawatt laser shine with the same density of photons. #Sarcasm
    Last edited by BlackRang666; 05-28-2017 at 07:31 AM.

  22. #22
    1
    Champion
    Join Date
    Oct 2015
    Posts
    713
    Quote Originally Posted by Maximum-Dev View Post
    To be honest, never in your life you're going to see any SSS on your hand when standing under overcast light so I don't think I've had any wrong assumptions with mentioning skylight shouldn't affect SSS and in case I'm wrong and it should affect SSS, the effect should be so minimal and hard to notice which makes it next to nothing.

    Thanks for the workarounds. But I think you didn't understand the issue correctly. It's correct SSS looks strong while under direct light. It just shouldn't look as strong under skylight. So your workaround of reducing SSS intensity and color in order to make it look acceptable in shadows on the other hand is bringing down the SSS effect while under direct light as well, making SSS look fine under skylight but wrong under direct light.
    SSS is not some magical property that only affects direct light. In fact most of what you see of your hand/skin is SSS, direct light is only a small part. If you didn't see SSS from skylight humans would be way more pale and look more like vampires. You can also see SSS on stuff like leaves in real life too.

    In my tests reducing the SSS color to where it looks good in light made it look good in shadows too. The subsurface color generally has a way greater value range than you need for realistic stuff, but because it does you can also get exaggerated/stylistic looks from it. Basically you want the subsurface color to be closer to black than the real color of the object. And in general I don't understand why SSS having too much effect is an issue since you can reduce the effect by using a darker subsurface color. The sunlight opacity bug is real though.

    But if you have other results with SSS in light/shadow you can post those.

  23. #23
    0
    Quote Originally Posted by cyaoeu View Post
    SSS is not some magical property that only affects direct light. In fact most of what you see of your hand/skin is SSS, direct light is only a small part. If you didn't see SSS from skylight humans would be way more pale and look more like vampires. You can also see SSS on stuff like leaves in real life too.

    In my tests reducing the SSS color to where it looks good in light made it look good in shadows too. The subsurface color generally has a way greater value range than you need for realistic stuff, but because it does you can also get exaggerated/stylistic looks from it. Basically you want the subsurface color to be closer to black than the real color of the object. And in general I don't understand why SSS having too much effect is an issue since you can reduce the effect by using a darker subsurface color. The sunlight opacity bug is real though.

    But if you have other results with SSS in light/shadow you can post those.
    The general gist of SSS you described is correct, but game engine SSS only emulates the more obvious effect of "flashlight-through-hand". That is not something you get from skylight.
    Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

  24. #24
    0
    Quote Originally Posted by cyaoeu View Post
    SSS is not some magical property that only affects direct light. In fact most of what you see of your hand/skin is SSS, direct light is only a small part. If you didn't see SSS from skylight humans would be way more pale and look more like vampires. You can also see SSS on stuff like leaves in real life too.

    In my tests reducing the SSS color to where it looks good in light made it look good in shadows too. The subsurface color generally has a way greater value range than you need for realistic stuff, but because it does you can also get exaggerated/stylistic looks from it. Basically you want the subsurface color to be closer to black than the real color of the object. And in general I don't understand why SSS having too much effect is an issue since you can reduce the effect by using a darker subsurface color. The sunlight opacity bug is real though.

    But if you have other results with SSS in light/shadow you can post those.
    Okay let me put it in simpler words.

    Direct light intensity --> Is not equal to --> Indirect light intensity || Meaning || More SSS intensity under direct light --> Less SSS intensity under indirect light.

    By darkening/reducing SSS value --> SSS is uniformly reduced in both directly lit and indirectly lit conditions || While in fact || As I said in the line above, SSS intensity should not be the same under both direct and indirect conditions.

    It's about brightness/luminance/SSS opacity --> It's not about SSS color/saturation.

    The current issue is --> SSS intensity is the same under both Directional light and Skylight and there's no option to override how much Skylight influences SSS--> which is the same as saying a firefly emits the same amount of photons as an atomic bomb.

  25. #25
    0
    Champion
    Join Date
    Oct 2015
    Posts
    713
    Quote Originally Posted by DamirH View Post
    The general gist of SSS you described is correct, but game engine SSS only emulates the more obvious effect of "flashlight-through-hand". That is not something you get from skylight.
    Well, in the current design skylights do affect SSS and I don't see why they shouldn't, it looks good. The only thing that doesn't really affect SSS is ambient cubemaps.

    Quote Originally Posted by Maximum-Dev View Post
    Okay let me put it in simpler words.

    Direct light intensity --> Is not equal to --> Indirect light intensity || Meaning || More SSS intensity under direct light --> Less SSS intensity under indirect light.

    By darkening/reducing SSS value --> SSS is uniformly reduced in both directly lit and indirectly lit conditions || While in fact || As I said in the line above, SSS intensity should not be the same under both direct and indirect conditions.

    It's about brightness/luminance/SSS opacity --> It's not about SSS color/saturation.

    The current issue is --> SSS intensity is the same under both Directional light and Skylight and there's no option to override how much Skylight influences SSS--> which is the same as saying a firefly emits the same amount of photons as an atomic bomb.
    Reducing the SSS color value makes the material darker (closer to a normal material without SSS) so it's not only saturation. But if you want an option to override how much the skylight influences SSS that's not a bug, it's a feature request.

    You would probably have better luck with reporting the bug that opacity doesn't affect SSS for either SSS or the two sided foliage model using a movable skylight because it's easy to see that it's not working. You could also limit the skylight influence on SSS if that worked properly.

    But really if you want to not have SSS interact with the skylight at all, replace it with ambient cubemaps.

  26. #26
    0
    Quote Originally Posted by cyaoeu View Post
    Well, in the current design skylights do affect SSS and I don't see why they shouldn't, it looks good. The only thing that doesn't really affect SSS is ambient cubemaps.



    Reducing the SSS color value makes the material darker (closer to a normal material without SSS) so it's not only saturation. But if you want an option to override how much the skylight influences SSS that's not a bug, it's a feature request.

    You would probably have better luck with reporting the bug that opacity doesn't affect SSS for either SSS or the two sided foliage model using a movable skylight because it's easy to see that it's not working. You could also limit the skylight influence on SSS if that worked properly.

    But really if you want to not have SSS interact with the skylight at all, replace it with ambient cubemaps.
    If Static Skylight is working fine but both Stationary and Movable are giving flat results then there is a bug or it's a design problem and needs to change.
    Again, we need to control how much skylight influence SSS. Reducing Opacity in material would result in reduced SSS under both indirect and direct light.

  27. #27
    0
    I don't understand why we keep having to reiterate. Nobody is saying skylights shouldn't affect SSS at all. They should have a multiplier of some sort (or some other solution) so that they can affect less than other lights in your scenes. This is to suite the general usage of skylights. As it is, I can't have my SSS look the way I want it under a spotlight and the way I want it under a skylight at the same time.

  28. #28
    0
    Infiltrator
    Join Date
    Jul 2015
    Posts
    15
    I'm honestly quite angry that this is being backlogged without any kind of official comment. For outdoor scenes, properly functioning SSS is an absolute must, and at this moment it's just being blatantly ignored. You're not making it easier for people running outdoor scenes.

    And in response to this:
    Quote Originally Posted by cyaoeu View Post
    Reducing the SSS color value makes the material darker (closer to a normal material without SSS) so it's not only saturation.
    Nice idea, reducing the SSS brightness. The only not-so-minor issue there, is that it also gets rid of the SSS in direct lighting, meaning we might as well throw the entire effect out the window. The entire problem here is the lack of control for specifically one of the two kinds of light (direct/indirect), instead of both at the same time.

    Parameter on each light allowing us to dictate how much it influences SSS, anyone?
    Last edited by rarr4; 06-11-2017 at 03:27 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •