In video games tears weren’t noticed due to ‘smearing’. Such as http://quakewiki.org/wiki/gl_clear , set ‘gl_clear 0’ and screen pixels simply retain the color they had previously if not painted this frame. This hid small tears well because it ‘smeared’ neighboring pixel colors so one doesn’t even notice the tears. When nocliping you’d set ‘gl_clear 1’ to disable smearing, if a pixel isn’t painted it will get painted with a default color.
Is this smearing technique possible in Cesium instead of using skirts? One problem is that it can’t simply be the entire view-port, you don’t want mountain edges smearing where sky should be drawn, for example. Somehow it would have to distinguish tile edge tears from terrain/sky edges, which might be difficult.
Actually this can already be tested underground, as being underground you would never render the sky anyhow. Just reverse normals and don’t render skirts while trying the smear technique to hide tears.
It’s funny you mention smearing. In the early days of Cesium - before we had terrain - we used a screen-space blur technique that I would basically call smearing to fill cracks between ellipsoid tiles with different LODs. We wrote about it in a chapter in GPU Pro 4. However, the screen-space technique can only reasonably fill cracks that are a few pixels wide. With terrain, sometimes cracks can be quite large while loading so we switched to skirts, which are quite common with the LOD approach we use.
I suppose not to the point where smearing/blurring could adequately cover for. It does appear that quote was before skirts were implemented.
So basically the cracks only appear when neighboring tiles are using different LODs and are due to vertical differences, not horizontal difference (meaning a vertical vector couldn’t fit through a crack, only a tilted one) I take it neighboring tiles at the same LOD level don’t have any cracks between them? Are skirts rendered even when neighboring tiles are at the same LOD level?
Instead of skirts, is it feasible to dynamically calculate a triangle mesh to fill in the cracks, or would the calculations required to do this be excessively taxing on performance?
No, cracks can appear even when adjacent tiles have the same LOD. They should be small, though, less than the screen space error (2 pixels by default). So in theory we could get away with blurring in this case.
Tiles always have skirts, no matter the LOD of the tiles around them. Dynamically hiding and showing them would be costly.
Dynamically calculating a mesh to fill the cracks is possible, but likely to be very expensive. Someone once told me they did this in World Wind with decent results, though. If you need translucent terrain and you need it to be completely seamless, perhaps it’s worth the cost.
“Dynamically calculating a mesh to fill the cracks is possible, but likely to be very expensive.”
But wouldn’t it only be done once per LOD change, rather than every frame? Keeping track of LOD changes could be a pain though.
If all of the vertices of a tile edge were higher than the vertices on it’s corresponding shared/adjacent tile edge it could be done with a single multi-sided-polygon. If not it could end up being a jagged mess.Translucent terrain would be a cool feature to see underground tunnel systems from above, but the overhangs might obscure the view.
Yep, you’re right, the stitching meshes would only need to be computed on LOD change. Plus you’d need extra draw calls to draw those stitching meshes. That’s an every frame cost.
Terrain tiles in Cesium know which vertices are on the edges, and even have a sorted list of them (at least the quantized mesh tiles. Finding the sorted edge vertices of heightmap tiles is trivial). So I think it would be straightforward to compute the triangles necessary to fill a gap between tiles.
I’ve been observing the skirts in wireframe mode. It seems that on just one skirt side (4 per tile) each verticie jump creates 4 triangles. Perhaps doing dynamic mesh stitching might even reduce the triangle count in some cases? I could be wrong, it is difficult to get a good view of the wireframe model.
Each pair of vertices on the edge should create two triangles, which is roughly what you’d get with stitching, too. In any case, twice as many triangles is almost certainly better for performance than twice as many draw calls.
Since performance is a high priority for Cesium, which is a good thing, using skirts by default is a good idea. Though it would be nice have tile gap stitching as an option, even if it did reduce performance a bit. Perhaps even a hybrid option that uses stitching for big gaps and smearing for small gaps. That is if the algorithm that detects gap size itself doesn’t cause a large performance hit.
While traveling through cliffs surrounding deep winding rivers
While inside the terrain perhaps:
-not show skirts.
-render yellow-orange magma instead of starry sky underneath, or something else that contrast with most terrain. Starry sky does, but it looks strange.
-render translucent textures of surfaces whoms normals’ face away from the camera. (this might cause confusion though, I’m not sure.)