SSS bug in 4.15.1

General Feedback & Requests
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

1536×1030 229 KB

SSS Intensity = 10

1534×1040 249 KB

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: SSS is affected by Skylight. Shouldn't be - World Creation - Unreal Engine Forums

2

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.

3

Thank you for logging the report on the Answerhub. We will follow up there.

4

Seriously, why should fixing SSS be backlogged? Unreal Engine Issues and Bug Tracker (UE-44851)

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

http://image.prntscr.com/image/3ebcee3fbe9b44cca8e37d985e5d8965.png

How it looks like in newer builds (wrong):

http://image.prntscr.com/image/ecbcdf1be386455bb6135b48ff5e4776.png

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.

5

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.

6

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

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

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. :confused:

9

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…

10

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. :slight_smile:

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. :frowning:

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 [MENTION=2522]Nick Darnell[/MENTION] 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. :slight_smile:

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? :confused:

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. :eek: 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. :slight_smile: 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. :slight_smile: 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. :wink:

11

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

@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.

13

I understood you correctly, just tried to explain to others where we’re coming from if they see us too frustrated. :slight_smile:

14

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.

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,

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?

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)

15

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.

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.

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.

Very good suggestion.

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. :confused::confused::confused:

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.

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. :slight_smile:

16

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.

17

That’s a very precise statement. :slight_smile:
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. :slight_smile:

18

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

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.

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 :slight_smile:
As for bug report, the initial post was somewhat misleading, but the gist was about difference between baked and dynamic skylight.

20

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.