You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#783 adds support for querying heights from a tileset at a point. However, it reports a warning - and doesn't find intersections - when the position falls within a tile that uses EXT_mesh_gpu_instancing.
Implementing support for height queries against instanced models on CPU will not be very efficient. We'd probably have to compute a bounding box for each instance, test the ray against that, and then for each hit, test the ray against the instantiated triangles. A GPU solution is going to be much more performant, but that raises lots of new challenges in the platform-agnostic environment of cesium-native.
A hybrid solution might be viable. cesium-native finds and loads the tiles that need to be tested against the height query ray, but then hands it off to the "renderer" (i.e., Unreal, Unity, etc.) via some interface to determine the actual intersection point. Within game engines, we could implement this via rendering and reading the depth buffer (as CesiumJS does), or we could use the game engines' physics engines.
The text was updated successfully, but these errors were encountered:
I'm currently using https://github.com/madmann91/bvh to do this as I can't loop through every triangle. I delete the mesh data from the CesiumModel after it has been constructed to not duplicate data.
#783 adds support for querying heights from a tileset at a point. However, it reports a warning - and doesn't find intersections - when the position falls within a tile that uses
EXT_mesh_gpu_instancing
.Implementing support for height queries against instanced models on CPU will not be very efficient. We'd probably have to compute a bounding box for each instance, test the ray against that, and then for each hit, test the ray against the instantiated triangles. A GPU solution is going to be much more performant, but that raises lots of new challenges in the platform-agnostic environment of cesium-native.
A hybrid solution might be viable. cesium-native finds and loads the tiles that need to be tested against the height query ray, but then hands it off to the "renderer" (i.e., Unreal, Unity, etc.) via some interface to determine the actual intersection point. Within game engines, we could implement this via rendering and reading the depth buffer (as CesiumJS does), or we could use the game engines' physics engines.
The text was updated successfully, but these errors were encountered: