The global environment map doesn’t work well on materials that don’t reflect it much. It burns out.
If I apply the exact same HDRI map to the material itself directly it works fine. But that is not good, because global changes to the environment map don’t change the materials.
My question, is this a 3JS bug or is it something I’m doing wrong, thanks!
What version were you on previously? I know that lighting values changed in r155, I had to do a bit of tweaking to strengths when I updated my project to latest.
Note – if it’s an HDR map (such as .hdr or .exr formats) then it is unlikely to be sRGB, you would probably want:
texture.colorSpace = THREE.LinearSRGBColorSpace;
But the HDR texture loaders do this automatically, so you shouldn’t have to change it for them.
In other formats (PNG or JPG) it’s mainly a matter of knowing whether the texture is used for color (.map, .emissiveMap, …) or non-color data (.aoMap, .normalMap, .roughnessMap, …) and using SRGBColorSpace or NoColorSpace accordingly.
Hi. I was going from Release 161 to 166, a couple of directional lights, nothing else. Its really strange becuase when I apply directly to the material with envMap it has the same/desired effect as before - but when a material inherits it from scene.environment it burns out badly and you cannot see the shadow. Its fine on materials the reflect the map back.
Here is when the map is coming from scene.enivornment…
I see there is a new scene.environmentIntensity, and that material envMapIntensity does not work any more for scene environment map applied to parts. This means you cannot individually decide how much of the global scene map gets applied to each part (you have to manually set a map for each part you wish to override). That seems to be a step back if I’m right. Would be good to know if this is the new way of working or its a bug. I have a library of preset materials that repond different to the overall scene map.
Ah ok thanks, that is probably then where things have gone wrong for me. So my feedback…
Imagine I’ve got objects with different materials in a scene. Some of those materials reflect the scene, and some not (between 0 and 1). E.g. Metal 1, Matte 0. But I change scene, say from Beach to a Room and want to see the change effect. This used to work a dream.
But now you cannot control on a material basis how much that overall scene map applies. That is a bit strange I’d say, and quite fundamental from a 3D materials perspective. You cannot just blanket apply the global scene map in the same proportion to different materials.
The work around is to apply local maps, but then they don’t sync with the global map, and you’d need to update them all each time you change the global map. Thats not so pretty.
Would be great if a material could have a property to use its local envMapIntensity overriding the global - I think something like that would be logical, and would allow backward compatibility.
As it stands, i’ve got to recode and rebuild all my materials.
Let me know what the possibilites are ??! Thanks!!
Effectively scene.environment (in my case, and I’m sure for others) is now redundant. I have to apply maps individually to each material so I can control the map intensity. Then if I wish to change the map, I have to go through and update all the materials.
I think the philosophy here is that this is the wrong approach. There is only one sky and one sun and it affects the world the same. If you want something to receive more light, make it lighter in color. So one could argue that doing it on a per material basis is just wrong.
It is my understanding that three also doesn’t have to guarantee you anything since its in a sort of development stage.
Just because something used to work a certain way doesn’t mean that there is some kind of a contract that it has to keep working like that. Before it was actually wrong, now its right.
I see where you are coming from, but the logic does not hold up.
I don’t think THREE is supposed to be a Real Life Simulator. If it were, we would also not be allowed to change AO intensity and tonemapping per material, or cast/receive shadows per mesh, or mix BasicMaterials with PhysicalMaterials, etc.
DirectionLights are - according to the docs - meant to simulate sunlight. Yet I can add 10 of them as if there were 10 suns.
On top of that, we can still change envmapIntensity (or envmaps as a whole) on a per material basis. It just requires an extra hoop to jump through now.
As for the use case. Simulating things like glass or retroreflective materials often require their own envmap intensity, among other factors.
That said, one can easily set material.envMap = scene.background for all materials that need envmap tweaking. (Though this require manual updating if the global intensity is ever changes, as @Duncan_B said.)
I’m just not sure how much this affects performance or memory. Maybe @mrdoob can speak to that?
I tried and tried, but with the new setup and global environment intensity I was unable to create a full dynamic range of materials from matte to glosy to full mirror. There was no way to control this unless you reverted to local maps. At the end of the day the coding for the fix to do this wasn´t too bad and I´ve been able to keep my nice material set working as before and bring in new properties like dispersion - so all cool.
I think this is where you’re failing. What you think is pretty irrelevant. Three has a set path regardless. If three thinks that lights should be uniform and model the real world, it doesnt matter what you think <3
I wouldn’t count on this. Three takes an enormous amount of effort to develop and its being done by a handful of people. If you look at npm, over a million people download three every week. If each person had a question like this, specifically for mrdoob, all mrdoob would do in life is answer these questions and probably would only manage to answer maybe 1% of them.
So two things here.
Historically, no one “speaks to that” in the official three.js world. Ive been around for a while and ive never seen a blog post from a contributor. It’s just a different style of development than say react, where they very loudly advertise and discuss the road map and new features changes. IMHO, with three it’s best to just follow this forum, ask questions and try to keep up.
It would be wise to become open about accepting help from people other than @mrdoob. It’s true that they know everything about the library, but as mentioned, their time is quite limited. Consider though that three.js has over a thousand contributors, there is a small chance that other people may be privy, at least to certain parts of three and can give you somewhat useful information. There is also a whole ecosystem independent of three and these people tend to have interesting experience which they often share with the rest of the community. Eg someone may have run into this while developing for that drei thing.
My guess is that you would see zero performance impact. Memory wise, what changed? You’re storing pointers/references to some objects, you probably have things in there that hold orders of magnitude more of those so pretty insignificant hit.
It’s the same texture, it just looks like each draw call has a different uniform value. None of this would cause any significant impact.
