can anyone from community please help me solve this weird patches
Unreal’s SkyAtmosphere assumes that the Earth is a sphere, which of course it is not. Artifacts like those will pop up when the radius of the atmosphere sphere is too small, and so the globe surface pops through a bit. The CesiumSunSky attemps to avoid that problem by dynamically adjusting the atmosphere radius based on camera position.
So my guess is that it’s not working in your case for some reason, but it’s hard to say why. A few things to try in order to help diagnose it… If you remove the CesiumSunSky and add a new one with default parameters, does the problem go away? If you create a new level and add only your tileset and the CesiumSunSky, do you still have the problem? Do you still have the problem in the Cesium for Unreal Samples project?
janine
October 2, 2024, 2:10pm
3
I think this thread is a repost of a Github issue we’ve been triaging here:
opened 04:53AM - 27 Sep 24 UTC
I have tried to put up most basic level with cesium3dtileset actor with two raster overlay component and cesiumsunsky. I have tried to adjust solar time and time zone suitable. When I play it is showing the patches in the globe imagery. Can anyone from community please guide me with this issue?
I have tried to adjust maximum screen space error default 16 to 2. In that can it is not showing patches. But its is taking too much time to load.
In any case, @Kevin_Ring has opened a PR to address this behavior. Thanks to everyone who has been helping us diagnose the issue thus far!
CesiumGS:main ← CesiumGS:normals-and-atmosphere
opened 11:15AM - 02 Oct 24 UTC
I originally set out to fix the clearly-incorrect normals for tilesets with `KHR… _materials_unlit` (#1528). The immediate cause of the bug was that it wasn't taking into account the scaled positions introduced in #1465. But the code was also set up to compute one normal for the entire tile, based on the ellipsoid surface normal at the bounding volume origin. This was sure to create lighting discontinuities at the edges of tiles. So I decided to change that. Meshes with `KHR_materials_unlit` are now given a per-vertex normal which is the ellipsoid surface normal at that position, which looks a lot better. (note: the meshes already had per-vertex normals, the change is only to how they're computed)
I also noticed that we were unnecessarily duplicating vertices for unlit meshes. glTF requires generation of flat normals when normals are not included in the mesh. So, whenever we saw a mesh without normals, we were de-indexing it so that each triangle could have a consistent normal. But this was pointless and wasteful in the `KHR_materials_unlit` case. Fixing this reduced the mesh memory usage in the default Google Photorealistic 3D Tiles scene in the Samples from 33.3MB to 18.8MB, and should reduce the vertex transform load on the GPU by a similar amount.
With all of that fixed, I still noticed weird splotchy artifacts from the atmosphere when zoomed way out with Google Photorealistic 3D Tiles (Cesium World Terrain looked fine). A user also reported this recently in #1525. This is caused by the kind of surprising way the Google model is constructed.
A low detail mesh representation of the globe is, of course, extremely inaccurate. Any given point on the surface of the low-detail model can easily be kilometers from reality. But it doesn't matter - we usually can't even tell - because it's viewed from so far away that kilometers map to less than a pixel.
In Cesium World Terrain, the vertices on the low detail mesh are at relatively realistic locations, usually at or near peaks. Then these are connected by large triangles, so the least accurate parts are near the centers of the triangles, where the height will be much lower than reality. In Google Photorealistic 3D Tiles, the pattern is very different. Vertices can be drastically higher than any realistic height on Earth. Some low-detail vertices in GP3DT have a height above the ellipsoid of over 30km. Since Mt Everest is less than 9km about the ellipsoid, this is a bit surprising. And it caused artifacts in the atmosphere because these peaks (which could be in decidely non-peaky places like the middle of oceans) poked up through the atmosphere and hence were not shaded by it at all. Splotches.
To be clear, I'm not claiming Google is doing something wrong here. The vertex positions are presumably still falling within the geometric error bounds for the level-of-detail.
A general solution to this problem is tricky. But we can provide the tools that users need to solve it when they know they're using a tileset like this. To that end, this PR introduces a new `CircumscribedGroundHeight` property.
> The height at which to place the bottom of the atmosphere when the player pawn is above the CircumscribedGroundThreshold. This is expressed as a height in kilometers above the maximum radius of the ellipsoid (usually WGS84). To avoid dark splotchy artifacts in the atmosphere when zoomed out far from the globe, this value must be above the greatest height achieved by any part of the tileset.
Setting it as follows produces nice results with Google Photorealistic 3D Tiles (the highlighted properties are changed from their defaults):
This PR also cleans up the `CesiumSunSky` Details panel by hiding the `CesiumGlobeAnchor` properties. It's almost never useful to change these, and it was annoying to scroll past them to change the useful properties.
## Before
## After
Fixes #1528
Fixes #1525
1 Like
