-
-
Notifications
You must be signed in to change notification settings - Fork 35.4k
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
Different environment with ENVMAP_TYPE_CUBE_UV - NodeMaterial #17102
Comments
It is to be expected that PMREM and non-PMREM will produce different lighting.
I do not have a strong opinion on that. Feel free to propose a refactoring.
@jsantell will have to help with that issue. /ping @jsantell @sunag You do need to add support for |
My main issue is when I should use material.environment = mix( premCube, traditionalCube, .5 ); In this case, Maybe it should be ever enabled in material with a property:
Ok I will add 👍 |
Does @bhouston have any thoughts about this? |
One only needs a single PMREM map per object. It is much more accurate than a standard envMap. Having envMapIntensity would be useful in my opinion as unfortunately cubeMaps are usually unitless -- although I wish there was a HDR/light map standard that had units. envMapIntensity is basically the intensity of the light.
The above case is a bit weird. Generally one does not interpolate cubemaps used for specular reflections as the reflections do not line up between the two positionally different cubemaps. Usually one just picks between a series of different cube maps and assigns one to a particular object, per: https://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/ https://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/ |
Thanks @bhouston.
The example of mix two type of cubemaps is only a paradigm to illustrate that we have a compatibility issue. To be more specific, if add It would not be possible move this code to three.js/src/renderers/shaders/ShaderChunk/lights_physical_pars_fragment.glsl.js Lines 121 to 123 in 1128d60
Code Example var material = new Nodes.StandardNodeMaterial();
// affect global light not only envMap (PREM)
material.defines['ENVMAP_TYPE_CUBE_UV'] = true; |
As I understand it,
@WestLangley I would like to make a refactoring but first I would like to know if you support I implement this as default in Physically-Based Material or add a property in material as |
|
I do not blame you for being confused. There have been a lot of changes, and it is confusing to me, too. An environment map is treated as a source of light. Some of that light is reflected specularly (indirect specular), and some is reflected diffusely (indirect diffuse). When As a result, PMREM was supported. When There are some other minor differences, but those are the main ones.
I am not aware of a flag that enables energy preservation. I think it is automatic if PMREM is provided. Unless I am missing something, I see no reason for such a flag. |
@WestLangley Thank you very much for the explanation. I will create a PR with this refactoring and try to justify with the base on PBR articles and NodeMaterial. |
Really looking forward to this one. For now, it is not possible to properly decouple the environment intensity and the light object strengths. That is something critical to produce great custom scene lightings. |
I think that var intensity = new Nodes.FloatNode( 1 );
var envMap = new Nodes.CubeTextureNode( cubemap );
var envMapIntensity = new Nodes.OperatorNode( envMap, intensity, Nodes.OperatorNode.MUL );
material.environment = envMapIntensity; |
I did not have time to test but I imagine that this is a bug related with this:
Apparently only the indirect light remained here... Maybe I was a bit naive implementation of this @njarraud thanks too for the test. |
If you tweak the metalness value from 0 to 1 in my example, it will slowly get darker until it is all black for 1. |
Fixed! I modify an example to support intensity. |
That’s correct. I'm not terribly familiar with how the node system interacts with the traditional shaders. The materials support two types of environment maps: a cube map that provides indirect specular ( That being said, with the context of supporting node materials, it makes sense to me to decouple sampling logic (cubemap vs PMREM-specific UV packing) from whether or not indirect diffuse is used (energy preservation), assuming that there is another way to provide the data necessary to generate the indirect diffuse via the node material (via LUT? SH?). That being said, what is the scenario in which |
I tried to know more about through some references cited here and found it energy preservation is a characteristic of BRDF class, thus being is a correct the implementation used today in global light. The issue is that there are other lights in threejs besides IBL PREM that also generate indirect diffuse and specular, and in the specific case of NodeMaterial it cannot get stuck just in the PREM approach although it is the best threejs approach to IBL today. This example can be reproduced as follows:
var material = new Nodes.StandardNodeMaterial();
material.defines['ENVMAP_TYPE_CUBE_UV'] = true; For this reason I see the need to become energy preservation a feature independent of PREM. |
A JPG texture can be an environment map, but it does not have units. It is true that some environment maps can have implied physical units (radiance or luminance), however, they are also sometimes normalized, in which case the |
@jsantell Yes, @sunag is correct. The |
PMREM can be used with LDR. It is not HDR-specific. |
I agree with In case the user needs adjust intensity he can add this: material.environment = new OperatorNode( envMap, new FloatNode( 1 ), OperatorNode.MUL ); Like this example: |
Yes, we are in agreement. |
Description of the problem
Adding
ENVMAP_TYPE_CUBE_UV
in physical-based material or the propertyenvMap
is a PREM affect significantly the light calculation in material, e.g:It probably is related to this:
three.js/src/renderers/shaders/ShaderChunk/lights_physical_pars_fragment.glsl.js
Lines 121 to 123 in 1128d60
ENVMAP_TYPE_CUBE_UV
: https://jsfiddle.net/5wfoc7na/I think that none
ENVMAP...
defines should be inlights_physical_pars_fragment
chuck./ping @WestLangley
Three.js version
Browser
OS
The text was updated successfully, but these errors were encountered: