NASA-AMMOS
ImageOverlayPlugin: blurry texture at close range
When using the ImageOverlayPlugin / XYZTilesOverlay and zooming in or navigating close to the surface, then the rendered texture gets very blurry. I would expect that the next zoom levels are getting loaded earlier to improve the visual quality (similar to normal map tiles example). However, the closer you get to the surface, the later, it seems, the next zoom level is loaded.
How can the quality be improved? Or need the code/algorithm to be updated in this regard? Playing around with the errorTarget did not change that much.
I also noticed that, especially at rivers, there are many white/untextured triangles. This occurs at many places/rivers worldwide.
You can check on your Quantized Mesh with Overlays example, best with OpenStreetMap XYZ tiles.
Compared to the normal Map Tiles example
I would expect that the next zoom levels are getting loaded earlier to improve the visual quality (similar to normal map tiles example)
The issue is outlined in https://github.com/NASA-AMMOS/3DTilesRendererJS/issues/1278#issuecomment-3200824139, which boils down to the mapping of image tiles to tile geometric error being insufficient which can result in two very different resolutions of images loading next to eachother or data seemingly not growing detailed "fast enough" when zooming in (see this function). There's not currently a work around but I'm open to a contribution looking into addressing the problem if you'd like to take a look.
I also noticed that, especially at rivers, there are many white/untextured triangles. This occurs at many places/rivers worldwide.
I'll need a reproduction to be provided or whether any errors are being logged into the console. I'm not seeing any white tile triangle issues no matter how far I zoom in:
Oh, I missed the other issue. Some weeks ago, I dived into the code of the XYZTilesPlugin, so I understand how the tiles are defined and generated there. But I do not fully understand the ImageOverlayPlugin in order to update the code. If I understand it correctly, the loaded XYZ map tile corresponds with depth or errorTarget of the terrain tile. But it would actually need to loaded independently from each other?
Regarding the white triangles: I tested it on Windows/Ubuntu Chrome/Firefox, I always see some white triangles at some rivers/lakes. It doesn't matter if it's the satellite images or OSM. So, I don't know how to reproduce it otherwise.
Here another example (Grand Canyon):
But I do not fully understand the ImageOverlayPlugin in order to update the code. If I understand it correctly, the loaded XYZ map tile corresponds with depth or errorTarget of the terrain tile. But it would actually need to loaded independently from each other?
The ImageOverlayPlugin is unfortunately a bit more complicated than the image plugins by necessity. The ImageOverlayPlugin allows overlaying one or more tiled images formats such as WMS, XYZ, etc on top of an existing tile set - the projection used by that image likely will not align with the underlying tiled 3d data and so it's inevitable that multiple images may have to be loaded and composed into a single tile texture for overlay. Coupled with the ability to make edits on the fly make this a fairly complicated piece of the code base. But more or less it works like this:
- Tile is loaded.
- Image overlay level-of-detail necessary for the given tile is determined (right now this is naively based on tree depth).
- The extent of the tile mesh data in the image overlays projection is determined and a new set of uv coordinates are generated.
- All the covered images are loaded and composed into a single texture for overlay on the tile mesh.
If I understand it correctly, the loaded XYZ map tile corresponds with depth or errorTarget of the terrain tile. But it would actually need to loaded independently from each other?
The current XYZ map tile associated with the geometry is just based on tree depth at the moment, which as you're seeing is not ideal. A better way to handle this would be to determine the target "pixel size" across the covered region based on the tiles error target (and known pixel density of the total tiled image) and choose a level of detail to load that way. I don't think there's a silver bullet solution, though, because some of these overlays include text at varying resolutions which may impact the rate that a user wants the overlay to drape on the geometry LoDs. I think this pixel size metric would be an improvement over what's there currently, though.
Regarding the white triangles: I tested it on Windows/Ubuntu Chrome/Firefox, I always see some white triangles at some rivers/lakes. It doesn't matter if it's the satellite images or OSM. So, I don't know how to reproduce it otherwise.
Can you make a dedicated issue for this with all bug template fields filled out and your hardware setup. This looks like it may be something hardware-specific.