When setting material.side = THREE.BackSide; for a shpere and the directional light is positioned at camera’s position (i.e. at viewer’s position), it’s the far side of the material that gets lit and the near side is in shadow. Is there any way to invert that thing outside a shader code so that the far side of the material is in shadow and the near side is lit? I tried using material.shadowSide = THREE.BackSide to do it but it appears to not do what I want.
Additionally, how can I get the actual normals for a back side material in the shader code? I read somewhere that for back side materials all the normals point in the same direction, but then how can I color things in the fragment shader based on the angle between the normals and the light position (to simulate light, for example) or the camera?
Ok, got on the right track on this one as well by my own, making vec3 normal = - normalize(vNormal); in the normal_fragment_begin chunk, based on this post. Basically I’m just flipping the normals of the back side rendered material so that the material is lit just as if it was rendering its front side, while still rendering its back side.
I imagine this small change in the shader doesn’t flip the faces or geometry (like for other non-shader methods) and it isn’t affected by transformations on the object (like those of TransformControls, for example).
Other than that, I like how things work on this forum: I get no replies to my questions, while answering my own ones … and those of others in the meantime (well, at least the objective is achieved, so I guess it’s not that bad).
Completely agree, I do too - it stimulates thinking and learning by experimenting (which is the most effective learning). At the time of posting though, I felt that I exhausted most choices I could think of and would have welcomed some help, even if it was just an idea. In the end it turned out well and I managed to do what I wanted (now I only have to play with the colors to get things reasonably realistic).
My existing two questions here were both with the aim of creating the “inside” (i.e. the sky as seen from the ground) of my globe’s atmosphere material, with the “outside” of it (i.e. how it looks from outer space) being already done quite realistically in 30 vertex + fragment shader lines some time ago (also by myself).
By the way, I have to thank you for your great examples. Some of them helped me find a solution to creating terrain on the globe by adjusting vertices in the direction of the normals according to a “height map”, so that a raycaster can detect intersects based on that - something that doesn’t happen when using a .displacementMap. Keep producing the great stuff that you do!
Yep, your question was actually among the posts I had been reading before posting mine, but for some reason (e.g. differences in objectives, materials used, name of the variables) I thought it wasn’t quite what I needed at the time. But yeah, the principle is more or less the same, albeit applied in different places and on different variables / varyings / whatever - so if I was more focused I could have probably taken some inspiration from there as well.
Indeed, the shader code was unintelligible for me as well when I started with Three.js a couple of months ago, I had to progress with the understanding in the “solo” mode, so to speak, therefore I get what you’re saying, there aren’t many “experts” on that, and those who are, are probably busy with maintaining and improving the library in the first place.
I still have lots of question marks when it comes to matrices, quaternions and such, and what some operations actually mean, fortunately I can deduce various bits via the basic math I learned in school and the rest comes from making breakthroughs like being able to understand how a night / city lights shader system works for Earth and applying that to other areas like the atmosphere and so on. It’s an adventure and a challenge in itself, but I like those as they motivate me - and after all, I’ve been able to do things in Three.js that I didn’t manage to do (or at least not completely) in Blender and the like, so I guess the positives are there…