It would appear that backFaceAlpha values are not functioning. Only way to get it working is via test case 1. This is with Cesium 1.70.1.
//this is set for all test cases
globe.translucency.enabled = true;
//test case 1
globe.translucency.frontFaceAlpha = 0.1;
//result: front face translucent when outside of globe (as expected)
//result: back face translucent when inside globe (BUG?)
//result: front face not translucent when inside globe (looking out from inside a high mountain)
//test case 2
globe.translucency.backFaceAlpha = 0.1;
//result: neither front nor back faces are translucent (BUG?)
//test case 3
globe.translucency.frontFaceAlphaByDistance = new Cesium.NearFarScalar(1.5e2, 0.5, 8.0e6, 1.0);
//result front face translucent, back face not (as expected)
//test case 4
globe.translucency.backFaceAlphaByDistance = new Cesium.NearFarScalar(1.5e2, 0.1, 8.0e6, 1.0);
//result neither front nor back faces are translucent (BUG?)
I think this is working as expected. The back faces of the terrain are those triangles that are facing away from the camera. It is not the surface of the Earth when looking at it from under the ground.
Here’s a Sandcastle example I used to test these cases.
- Setting frontFaceAlpha = 0.1 reveals the back faces
- Setting backFaceAlpha = 0.1 looks just like no transparency, because the backfaces are hidden by the front faces (usually these can be culled)
Oh ya, even on that sandcastle. I put this under var globe at the top
Also I I just changed 0.1 to 0.5 just to make it easier to see translucent textures. By inside globe I actually meant under the terrain, not necessarily under the ellipsoid.
Test case 1:
-Above terrain: front faces translucent, back faces not
-Under terrain: back faces are now translucent and front faces are not (swapped)
Perhaps it’s the terminology, maybe I’m not using the proper graphics terminology.
By front face I mean the the side of terrain exposed to sunlight (top)
By back face I mean the side of the terrain never exposed to sunlight. (bottom)
Back faces aren’t usually rendered with textures (only seen from places you’re normally not supposed to go), such as going outside of a map via noclip in video games. But for this new underground feature they are, which is very useful to see where underground structures are in relation to above ground features.
I thinking that by front faces Cesium means surfaces that are in front of other surfaces from the viewpoint of the camera. If that’s the case, perhaps there can be some other settings:
Yes, we’re talking about two different things. Any surface in the scene whose normal vector points towards the camera is a “front face”.
Although I’m not sure why the front front faces flip when you move the camera under terrain:
That mountain is still facing in the direction of the camera, but it’s now considered a back face when you move the camera underground and there is another front face in front of it? @sean_lilley do you know why this happens?
There is a note about this nestled in the
Conceptually I think of it as closest layer vs. next closest layer. But that’s not completely accurate either if both values are < 1.0 alpha and there are multiple layers. I agree that the front face / back face terminology is confusing.
If we go with the strict definition of front face and back face, a system that offers full control would have four properties:
A common case is for
backFaceTranslucencyUnderground to be the same value which is why the code does what it does now.
The deep windy narrow canyon of Little Colorado River (just east of the Grand Canyon) is an excellent place to test translucency, especially with many layers.
(for instance -1909988.978 , -4802239.799 , 3727801.556)
Being able to have different values for when the camera is above and under ground would be useful. I suppose front face is just for the first layer from the camera, then the back face value applies to all the layers behind the front layer (easy to get many layers at that river.)