There will be a problem with the display,when I am far away from 3dfileset
error
normal
What’s the reason and how should I modify it
Hello @zrkcode,
Do you have multiple tilesets in the scene, or a tileset and another water mesh? It looks like one mesh is clipping through another in the water area. If that’s the case, you could try fading out the material of one of them when the camera is far away, or even hiding one altogether. If it’s all just one tileset, there may be other things to try - just let me know.
Hello @agallegos ,
It’s just one tileset.
The coordinates are 114.370093,30.503758
The Tileset needs a Material to display.
NanHu.zip (37.0 KB)
Thanks for sending over your tileset - I’m working on looking into this, and I’ll let you know what I find.
Hi @zrkcode, thanks for your patience.
I checked out the tileset and I’m not able to exactly replicate the issue. I am guessing it is caused by the material you’re using on it sometimes clipping through Cesium World Terrain. You may want to test this by assigning a default material to it and seeing if the issue is still happening.
If it’s the material, there’s a few things you can look at to fix it -
Is the material you are using on the tileset using a World Position Offset at all? If so, that node could be causing it to clip through the tileset in places.
If the material is transparent, that also may be causing problems as Unreal tries to determine the order of loading.
If you want to try to modify Cesium World Terrain instead of the material, you could use a Cesium Cartographic Polygon to clip out the area of terrain that is under the tileset. Or, you could try decreasing the Maximum Screen Space Error of Cesium World Terrain to force it to load higher-resolution tiles.
As a side note, the tileset is generating the following errors:
[Tileset.cpp:574] The tileset contains a gltfUpAxis property. This property is not part of the specification. All glTF content should use the Y-axis as the up-axis.
[GltfContent.cpp:44] Warning when loading binary glTF from file:///C:/Users/AGallegos/Downloads/NanHu/0/0/0.b3dm:
- A double value is not allowed and has been ignored.
While parsing: .materials[1].pbrMetallicRoughness.baseColorTexture.texCoord(expecting an integer)
From byte offset: 2179
- A double value is not allowed and has been ignored.
While parsing: .materials[2].pbrMetallicRoughness.baseColorTexture.texCoord(expecting an integer)
From byte offset: 2370
I don’t think these errors are causing the problem, but I was wondering if you are getting the same errors on your end.
Please let me know if any of this helps.
-Alex
I had a short look at this. From the screenshot in the first post, it looks like this was rather an issue of z-fighting, and not a general “rendering error”.
If this was the case, then the workaround/solution could be to just move this tileset a tiny bit upwards.
A cleaner solution would be to use some sort of clipping, to remove the geometry data of the water body from the tile data that is displayed under the water. There recently has been some work related to “clipping”, but I’m not entirely sure about the latest state of this, or how it could be applied in this case. (You might need a curve that defines the exact shape of that water body? But maybe @Nithin_Pranesh or @Kevin_Ring can give some hints on how to tackle that…)
The following is therefore somewhat unrelated to the observed rendering issue, but may be worth mentioning nevertheless:
The warning that is printed there does not cause a problem in this particular case, but it may cause a problem in other cases: The value that it is trying to read is 0.0, and this is ignored because it should be ain integer value (0 instead of 0.0). In this case, this will just cause it to use the default value (which coincidentally is 0), but if the texture coordinate value was 1.0, then this would be wrong, and could cause rendering artifacts or even crashes.
More generally, the glTF data that is contained in the B3DM has some issues. Here is the extracted GLB…
0.glb (98.8 KB)
It can be displayed in a glTF viewer, like https://gltf-viewer.donmccurdy.com/ , but it reports some errors. Throwing it into the glTF-Validator at glTF Validator causes the following messages:
"messages": [
{
"code": "UNEXPECTED_PROPERTY",
"message": "Unexpected property.",
"severity": 1,
"pointer": "/samplers/0/wrapR"
},
{
"code": "UNEXPECTED_PROPERTY",
"message": "Unexpected property.",
"severity": 1,
"pointer": "/samplers/1/wrapR"
},
{
"code": "BUFFER_VIEW_TARGET_OVERRIDE",
"message": "Override of previously set bufferView target or usage. Initial: 'VertexBuffer', new: 'Image'.",
"severity": 0,
"pointer": "/images/0/bufferView"
},
{
"code": "BUFFER_VIEW_TARGET_OVERRIDE",
"message": "Override of previously set bufferView target or usage. Initial: 'VertexBuffer', new: 'Image'.",
"severity": 0,
"pointer": "/images/1/bufferView"
},
{
"code": "IMAGE_FEATURES_UNSUPPORTED",
"message": "Image contains unsupported features like non-default colorspace information, non-square pixels, or animation.",
"severity": 1,
"pointer": "/images/0"
},
{
"code": "IMAGE_FEATURES_UNSUPPORTED",
"message": "Image contains unsupported features like non-default colorspace information, non-square pixels, or animation.",
"severity": 1,
"pointer": "/images/1"
}
],
Two of which are errors. I don’t think that our glTF reader classes even check this, so this might also not be a problem. The following is the JSON part of the GLB:
0.json.zip (1.0 KB)
and when looking at this, the errors refer to the fact that the buffer views 10 and 11…
...
}, {
"buffer" : 0,
"byteLength" : 2881,
"byteOffset" : 92456,
"target" : 34962
}, {
"buffer" : 0,
"byteLength" : 2881,
"byteOffset" : 95340,
"target" : 34962
} ],
both define a target, even though they are later used for the image data. (Removing the target causes the validation to pass without errors, but still with warnings).
1 Like
@agallegos @Marco13 Thank you for your answers，The material I use is ‘/Water/Materials/WaterSurface/Water_FarMesh.Water_FarMesh’.