I had a model that heavily relied on SphericalEnvMaps. I see now that it is no longer supported. The reason is so completely vague. I “think” it’s something about “spherical envMap almost never does what people expect it to do…”? What? It worked great for me. I’m sure I’m just misinterpreting something. You guys didn’t just get rid of the ability to create spherical texture maps right? Can I add SphericalReflectionMapping back? Is it tucked away somewhere in the build? I just converted my models over to r128 and this is a big hit as they are heavy on spherical geometry. How would one go about recreating spherical textures now in r128? Does the MatCap solution support specular, emmissive, etc? I’m using a reflective meshPhong material with a map and envMap. Please help!
The reasons for the removal is explained here. The relevant part is:
As discussed here, sphere maps are camera view-dependent and are not appropriate as we are using them. Furthermore, SEMs assume the object is centered directly in front of the camera, which is generally not the case in three.js. Users can use
MeshMatcapMaterialinstead. I have seen users useSphericalReflectionMapping, but they are passing in a matcap texture, thinking it is the same thing. A spherical reflection map is not the same as a matcap.
three.js never supported the generation of such maps. Only the rendering by defining THREE.SphericalReflectionMapping as the value for Texture.mapping.
Only if you modify the shader code via Material.onBeforeCompile(). Or create a custom shader material.
You find the respective code in the PR. It was removed and is no part of the build anymore.
Like mentioned above you have to use a custom enhancement for spherical environment maps.
No since a proper material capture includes lighting and reflections. It’s a complete material definition.
sphere maps are camera view-dependent and are not appropriate as we are using them. Furthermore, SEMs assume the object is centered directly in front of the camera, which is generally not the case in three.js.
Sorry, this statement is based on the (wrong) assumption that when you make a spherical map there will always be distortion. Not true, if you take care to create a distortionless sphere-map.
Then it will be far more advantageous than a cube map, especially when you update it dynamically: for a cube map you need six 90 degrees cameras, while for a sphere map you only need two 180 degrees ones -that will make the sphere map 300% faster!
Back when I was programming in Flash, I made a shader that did this successfully (I have yet to translate it from Stage3D and AGAL, to three.js and WEBGL).
For static maps too, a sphere map is always simpler with fewer files.
Later I found out that some researchers invented a spherical reflection method that approximated distance-independent reflections like with a true mirror (which is amazing) -and they have published a paper. If that was implemented in three.js it would give it an incredible advantage!
So it’s not sphere-map the “old” technology as mentioned in Wiki and elsewhere, it’s the other way around…
Ahhh. I see. Yep, here’s the problem, this statement right here - “ As discussed here, sphere maps are camera view-dependent and are not appropriate as we are using them.”.
In fact the spherical map is not camera angle dependent in its most simple use-case: applying spherical textures to spherical geometries. Why do I want to create 8 spheres with 8 materials to create an effect that I can achieve by mapping 1 texture onto a sphere? How about uses-cases with virtual globes where countries may have been a “map:” on a transparent Phong material? You guys didn’t leave a lot of options for realistic “glass” or “neon” - (aka. - bloom post processing). The one answer I found to glass you ripped out. Spherically mapping a texture onto a rectangle allows for some pretty cool glass effects on spherical models that were extremely simple compared to the custom shader version.
Just bummed. You mixed the simple
Use-case with the disappointments of the more complex use-case IMHO.
Or, did it go something like this? (Devs will probably laugh):
Dev: “It’s broken. Should we fix it?”
Approver: “Hmmm. Honestly nobody uses it and it’s not implemented the way it should be.”
Dev: “It’s broken in the previous build too. If we fix it we will have to push to all those builds as well.”
Approver: “Ya, let’s remove it.”
Boom! Thank you.
Let’s not forget that they are not paid to contribute in the development of three.js or help us on this forum… Anything beyond a simple discussion would be unfair -we all do mistakes BTW.
Isn’t threejs development sponsored?
I have nothing but respect for these guys. Let me say that loud and clear. I have learned an immense amount from Mugen, MrDoob, Loeee, Pailhead, Prisoner and cowboy McCurdy… and many of the PR warriors who have discussions in their infiltrated release conversations. Im not being disrespectful. I am b*#$hing but I love ThreeJS. I was just surprised that something like this was removed and for the reason it was removed. It has some very awesome basic uses and, apparently, a fairly complex one that no one used but me.
Thanks for your feedback! I know that removing/deprecating features is a hot topic since it is more or less impossible to make every stalkeholder of a software happy. But sometimes stuff needs to be removed so the development team can focus on new APIs. Otherwise the complexity of the project would reach a point where only maintenance/support would be possible.
SEMs have of course their use cases but we have made the experience that they have a limited relevance for the average three.js user. Besides, the feature was not always used as intended. Guiding users towards matcaps seemed the better approach to us.