Clamp to a 3D Tileset

[lilleyse]

It would be nice to support clamping objects to a 3D Tileset, which would require getting the height of a tileset at an arbitrary location.

This has a been a common request on the forum lately, so I figured it deserves an issue. https://groups.google.com/forum/#!topic/cesium-dev/hMALmIsVn4U

[pjcozzi]

Might not be bad to render top down along the geodetic surface normal with the highest resolution tiles along the ray...or maybe ray cast the tree, and then do a ray / triangle mesh intersection on the GPU since we will not have the geometry on the CPU...could also take the same approach for terrain...and for collision detection.

[pjcozzi]

@lilleyse what are your latest thoughts here? In particular, how could we make this really efficient for the case, for example, if an agent is moving along a path in real-time and for its current longitude/latitude, we want to clamp it to the current LOD of the tileset?

[pjcozzi]

• VTF / WebGL 2 performance idea: Render the height to texture, then use VTF in a second pass to position the primitive on the 3D Tileset. The primitive's command's bounding volume will need to be conservative enough. I originally thought about doing this with transform feedback, but I think this is cleaner and more widely supported.
• Multi-query optimization: Just like tracing ray packets, is there any benefit in querying multiple heights at once since, if they are in the same area, they will traverse the tree in the same pattern. Or will readPixels dominate (ignoring the above optimization)?

[lilleyse]

Yeah a lot of stuff to think about here...

I think the tree traversal will be relatively quick. At least it seems like the easy part.

This is how I envision it, which includes your ideas:

• Tree traversal to find the tile the entity is contained in
• Render that tile to a 1x1 canvas using orthographic camera facing from the geodetic surface normal
• Get depth with readPixels or VTF. readPixels seems a lot cleaner if we can get away with it. If there are multiple entities we could write all the results before calling readPixels.

Edge cases:

• Point clouds: the 1x1 canvas is probably too small, we will need something bigger (like 10x10) to take advantage of attenuation and reduce the chance of rendering nothing. Or should we only support b3dm to start?
• Bridges: is the entity placed above or below? Maybe use the previous height value to set the near plane and help cut off any triangles from the bridge.
• Holes: photogrammetry can have holes too so we might need some sort of estimation of the next position when following a path.

@likangning93 had an idea to render a larger heightmap expanse. If the entity moves outside of that region or the LOD changes then a new heightmap is rendered. This works well if the entity is following a path but isn't great for random access.

For the path use case, we could also just render once every N frames and interpolate in-between.

Long term I kind of hope we can move all this to the CPU / web workers to build a more general purpose collision detection system, with the downsides that it takes up more memory and may require a per-tile octree or some other optimization data structure.

[pjcozzi]

All good ideas.

Or should we only support b3dm to start?

I suggest just starting with b3dm/i3dm.

Bridges: is the entity placed above or below?

To start, just the max height for the tileset at that longitude/latitude. So viewing it as 2.5D for now.

Holes: photogrammetry can have holes...

Can probably ignore it to start. Later, if the "ray cast misses" and hits the ellipsoid, you might render a larger region and blur to fill the crack.

@likangning93 had an idea to render a larger heightmap expanse...

Very good idea - basically cache all the heights for a tile - will work well for our initial use case.

Long term I kind of hope we can move all this to the CPU / web workers...

ha, I wanted the opposite - to move it all to the GPU to avoid the potential CPU memory usage. Let's see how things play out...and will also have to consider the role of web workers in real-time use cases.

[dminor112]

Hi, Will this feature be publishing at next release 1.49? We are very looking forward to it. Thank you!

[lilleyse]

@dminor112 thanks for your interest! That is the plan.

[dminor112]

Hi, I have got the version of 1.49. I want to confirm if this feature has be published at this release?

[lilleyse]

Unfortunately it slipped past 1.49 but we're actively working on it in #6934.

[dminor112]

Will this feature be released in version 1.50? Our project depends on it.
Thanks.

[dminor112]

Our problem is that, we have a latlng position and need to get the altitude of the position at the 3D tileset. What should I do, is there any solution?

[pjcozzi]

@dminor112 this will almost certainty ship in 1.50 and it is the exact query you are looking for. You could try it out now by testing the branch in #6934.

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/forum/#!topic/cesium-dev/hMALmIsVn4U

If this issue affects any of these threads, please post a comment like the following:

The issue at #6080 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

---

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏