Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide dedicated skin and hair shaders for creating realistic human characters #27283

Closed
mysticfall opened this issue Mar 20, 2019 · 20 comments
Closed

Comments

@mysticfall
Copy link
Contributor

mysticfall commented Mar 20, 2019

Godot version:
master / ff318d9

OS/device including version:
Manjaro Linux 18.0.4

Issue description: (This issue is a feature request)
As we can expect more users would be interested in creating 3D games with a more realistic style, it'd be better if we can provide dedicated shaders to render human skin and hairs.

As I described in another issue(#26891), there are many obstacles that prevents one from creating a realistic human character in Godot and lack of such dedicated shaders is one of them.

Moreover, a human skin material within an environment with a GI probe would either look completely dry or soaked in oil, depending on how it's shadowed, thus making it practically impossible to achieve even a remotely realistic result as is described in #19561.

And if we can accept what is discussed in that issue, it's apparently an expected behaviour and we would need a dedicated skin shader to fix such a problem, so I think this would give this issue a bit more of importance than it would otherwise.

Currently, both Unity and Unreal provide their users such dedicated shaders to create a character with decent looking skin and hairs by default. In comparison, we give our users a generic spatial material with which they can spend much time to make a plastic looking skin that looks completely broken when it's shadowed, and they wouldn't find a clear remedy for the problem, unless they are well versed in writing custom shaders (that is, provided #19561 can be actually solved by writing a shader, without any engine modification).

Eventually, we may be able to provide our users something like this, so they can produce photorealistic result.

But in the meanwhile, I think even a much more primitive shader that can at least mitigate such a problem like #19561 would help those who try to create games with a more realistic style with Godot for now.

@CptPotato
Copy link
Contributor

CptPotato commented Mar 22, 2019

I don't think customized shaders that work around this issue are the way to go. If the parameters work correctly things should work just fine if setup right.

About the environment light bleeding "through" objects: this is a problem for 3d engines in general. Other large engines have this problem aswell. There are some ways to work around this, like limiting the environment specular intensity on dynamic objects or using specular maps to reduce it (could be a simple AO-map).

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

@CptPotato In that case, I think this issue can be considered more of an enhancement for those who want to create realistic characters on par with that can be achieved in other popular engines than a workaround for the problem that was mentioned in the description.

But in that case, I'd encourage you to share your insights in the discussion of #19561 to reopen the case. I seriously doubt if other engines would have a similar problem with such a severity, otherwise I simply can't imagine how anyone can create even remotely decent looking human characters using them.

I also can't see how a simple AO map could address such an issue, since it doesn't happen with any specific part of the body, like inside the nostrils or ears, but simply any skin part which is under a shadow will look extremely glossy and I certainly can't mark the whole skin as a 'dark area' in an AO map.

@CptPotato
Copy link
Contributor

So I gave it a shot and I think you can get a somewhat decent look with what's currently available:

This is a medium quality 3D scan which I reduced, baked a normalmap and painted/generated albedo, roughness and AO maps.
grafik

However, I noticed a few things:

  • the subsurface-scattering is not very good in it's current state but it makes skin look at least a little bit better
  • specular lighting seems to be broken: direct light sources have way too little specular lighting, compared to the diffuse component

I'll probably create an issue regarding the specular problems.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

@CptPotato Thanks for taking your time to test this issue. By the way, did you use a GI probe in your scene? From the screenshot, I suspect either you did not use one or at least one with a skybox.

However, the symptom which I described in #19561 can only be reproducible if you have a GI probe with a skybox. I mentioned this in one of the comments but probably it's a bit too easy to miss.

Could you check if you can reproduce the issue when you have a GI probe? The problem I described in the other issue is that it apparently looks to be impossible to make a skin material that looks moderately glossy whether it is under a shadow or not, if there is a GI probe with a sky texture.

As I understand it, the reason why this haapens is that when a mesh with such a material is under a shadow, only the direct light source is blocked, and the reflection the GI probe remains just as strong, resulting it looking extremely glossy. In order to counter that, I couldn't find any other way than either crank up the roughness value as to make it look completely dry when not under a shadow, or reduce the GI probe's influence to such a level that would make it useless.

@CptPotato
Copy link
Contributor

CptPotato commented Mar 22, 2019

@mysticfall it looks pretty okay to me with an environment map:
grafik

I'm using a fairly rough material, though. If I decrease the roughness it almost looks like the specular is ramping up too much, but I can't tell for sure.

The problem you have is that the reflection you're seeing comes from the environment, not the directional light you're using - the shadow won't affect it at all. I'd recommend you to use a rougher material and an environment map with less extreme highlights.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

The problem you have is that the reflection you're seeing comes from the environment, not the directional light you're using - the shadow won't affect it at all.

Yes, this is exactly what I commented above, and also what others have been discussing in the other issue.

The problem with a shadow is that, as I have explained above, the extreme glosiness may not look prominent if there is no shadow because the overall surface looks bright anyway. If you look at my screenshots in the other issue, you may notice it doesn't look glossy at all when there is no shadow.

But when the same material under the same environment goes under a shadow, the direct light is blocked so the surface becomes darker which leaves only the reflected light from the environmental map from the GI probe, thus making it look much more glossy than it looks otherwise.

I can see that the environmental map you used looks considerably darker than mine and the object is not under a shadow, so I can't really tell if that really proves my problem doesn't exist.

(For a reference, the HDRI map I used can be downloaded from here)

And I don't think we should tell people not to choose an HDRI map that depicts a bright sunny day, because I believe it's something they should be able to choose based on what they want artistically, not because they need to avoid such a problem.

@CptPotato
Copy link
Contributor

And I don't think we should tell people not to choose an HDRI map that depicts a bright sunny day, because I believe it's something they should be able to choose based on what they want artistically, not because they need to avoid such a problem.

True, but what I mean is that the maximum brightness has to be limited. The sky you referenced works great for renders but because it captures the full brightness of the sun it's not so great as a realtime environment map. Optimally, you'd limit the brighness to something much lower and add a directional light where the sun is supposed to be.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

I already use a directional light as the Sun (otherwise, there'd be no shadow that blocks any direct light).

Anyway, I confess that I don't have much experience with 3D art or gamedev in general, so maybe I'm asking about things that are common knowledge among game developers. But do you mean an HDRI map like this cannot be used without causing such a problem in video games, and I would run into the same sort of the problem if I used other popular engines?

From the amount of extreme glosiness I got with that HDRI map, I doubt I'd be able to completely eliminate such a problem if I used different textures which look slightly less brighter than that. And I thought the whole point of using HDRI map was to capture the full dynamic range of the environment, so it feels a bit suprising if I can't use it without causing such an issue.

So, my question is, is using such an outdoor HDRI map is something not feasible in any game engine? Or if I should limit the maximum brightness as you suggested, how can I achieve this without abandoning using an HDRI map entirely?

@CptPotato
Copy link
Contributor

The HDRI itself is fine. It's more about having a brightness limit option, for example in the import settings when enabling HDR mode.

@mysticfall
Copy link
Contributor Author

Sorry, but I can't seem to find any relevant option in the import settings. Could you tell me where I can find the brightness limit option you mentioned?

image

@CptPotato
Copy link
Contributor

This was more of a feature suggestion, there's no such thing right now 😅.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

Ok, I just installed Unity and created a minimal scene to see if I can reproduce it in a different environment, as more than a few people have suggested it's something inevitable in game engines.

Please consider that my knowledge of Unity is very limited, and I certainly don't want to spend too much time creating a sample project in that engine, so it looks quite horrible as it is. But I hope it's sufficient to show the difference between the two engines.

First off, this is how my character looks in Unity, with the standard shader with 0.5 roughness. And the scene contains a single directional light and the same HDRI texture I linked above as a skybox, and I used 'Progressive CPU' lightmapper to generate the GI data:

unity

The shadowed area shows highlighted reflection, but I think it still falls within a reasonable range.

However, the same model looks like this in Godot, with the same HDRI map and a single directional light again. I had to use the 'sqrt' trick I mentioned in #26891 on roughness value, since it'd make the whole body literally glow with specular light if I don't do that.

godot

As you can see, the lighted area doesn't look too glossy, but when it's shadowed it looks almost like it's soaked in oil.

I'm not excluding the possibility that I may have done something wrong while creating that scene. However, it looks pretty clear to me something is not right with how GI affects shadowed areas in my scene, and so far I have been unable to figure out how to fix that problem without effectively disabling the GI and none of the suggestions from other users seem to help.

And if it's indeed a problem on my part, I wish someone could point out what exactly I am doing wrong in Godot, and what we could do to prevent people from doing a similar mistake, since it's apparently not so easily reproduced in Unity, even when the user doesn't know much about the engine and didn't do anything special to prevent such an issue (like limiting the maximum brightness of the HDRI map, as suggested above).

@CptPotato
Copy link
Contributor

Again, the reflection you see is the extremely (and I really mean extremely) bright sun in the HDRI. Find a way to filter that out or probably look for a different environment map which works better without editing it.

I'll stop discussing this now, not trying to be rude but I think github is wrong place to discuss this and there's other things I'll have to do now, good luck.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 22, 2019

@CptPotato // The point is, the very same HDRI image with the same extremely bright sun worked just fine in Unity, even when I didn't do anything special to prevent such an issue.

I appreciate your efforts in trying to help, but I simply don't understand how it could be a problem with the HDRI texture itself, or something happens in every realtime engine as you suggested, when the same setup only causes such a problem in Godot alone.

@Megalomaniak
Copy link

Megalomaniak commented Mar 23, 2019

I think unity might be tone mapping(or doing something similar) your HDRI, as @CptPotato alluded to, that is controlling it's brightness in unity.

Might be you can maybe do something with the HDRI import settings to alleviate the issue perhaps?

Also I think your SSS is too strong, hence the candle wax like glow-y look.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 23, 2019

@Megalomaniak I could even reproduce the same symptom using a plain non-HDRI png sky image I found on internet, after getting another suggestion that my HDRI could be the culprit from a Discord user.

And I can confirm that tweaking SSS does not affect the problem. Actually, it's not even possible to overuse SSS in Godot as I described in my tracker issue. For now, increasing SSS only results in a blurry image and nothing more (no change in diffuse color, or transmittance), so the effect you mentioned could be from transmission effect which I'm using to compensate for the rather weak SSS features. But again, I can confirm that it doesn't have any effect on the problem at hand.

As to the tone mapping, I've already tried various different tonemappers before I settled down with ACES. I don't know if Unity has a special tonemapper that would prevent such a problem. And I have no idea what import settings I could tweak to avoid having such an issue, as HDRI texture doesn't offer too many relevant options in its import settings as you can see from the above screenshot.

At any rate, I'd appreciate if you could suggest some specific tonemapper or import setting I could change, in case you suspect it could be what is causing such an issue in Godot.

@Megalomaniak
Copy link

I see, no wonder then, transmission like this does not work well for SSS indeed, makes things look like old hollow plastic toys that tend to "glow" like this.

Could you perhaps provide a basic/cut down project file that showcases the issue/s? If your assets are licensed in a manner that allows you to do so, of course.

@mysticfall
Copy link
Contributor Author

mysticfall commented Mar 23, 2019

@Megalomaniak The whole project is available from this repository: https://github.com/mysticfall/AlleyCat

It could be a bit large to download though. In order to see the problem, you can run the main scene and try to walk around and see how various parts of the skin (e.g. neck or upper arm area) looks under a shadow.

In case it's not feasible to setup a Mono envrionment, you can also see the problem in the editor view by rotating the character mesh without actually running the scene.

@Calinou
Copy link
Member

Calinou commented Apr 9, 2020

I think those shaders would be a better fit for the Asset Library, rather than a core feature. We generally try not to add features that are specific to a game genre or art style, especially if they're complex.

@clayjohn
Copy link
Member

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants