Support for borehole geometry (implicit surfaces?)

[mzschwartz5]

What

Render borehole geometry data sets. These data sets may consist of 30K individual boreholes, each with 1-1k segments. May be curved / deviate from the vertical.

Alongside borehole geometry, there are more densely-measured attributes (things like diameter, composition, etc.). These attributes data points may not be sampled at the same locations as each other. They also may only exist over certain regions of the borehole.

Requirements:

• The geometry of boreholes is the basis for rendering.

• The diameter of borehole segments can be adjusted as a function of a defined attribute. (does it need to be interpolated to vary smoothly?)

• Changes in direction / orientation / diameter should be interpolated (optionally?).

• The color of borehole segments can be changed as a function of a defined attribute.

• All attributes of an entire borehole as well as of boreholes segments should be pickable.

Other requirements:

• Works with other features (both current and future) like voxels and time-dynamic tiles
• Do boreholes need to automatically act as clipping planes for the terrain surface? Or is that done in user-land, if wanted.

How

Options: (for the CesiumJS implementation, not considering tiling changes)

1. As a mesh polyline volume
2. Via GPU instancing
3. As implicit polyline surfaces

In choosing an implementation method, there are several criteria to consider:

1. Performance (considering memory consumption and run time complexity)
2. Extensibility (is it specific to boreholes or does it have other uses)
3. Complexity (both in implementation and potential maintenance)
4. Feature compatible (does it work with other features like lighting, picking, etc.)

(Of course, all approaches must satisfy the base requirements).

Here's my estimation:

Approach	Performance	Extensibility	Complexity	Feature Compatibility
Polyline volume mesh	Low - Med	Medium	Low - Med	High
GPU instancing	Med - High	Low	Medium	Low - Med
Implicit surface.	High	High	High	Low - Med

Polyline Volume Mesh

This approach would utilize the existing Polyline volume construct in Cesium, but would require a custom "borehole" fragment shader to support some of the requirements.

Cesium PolylineVolumes already support smooth curves, but do not support varying diameter. We would not want to add more vertices to support varying diameter, as that attribute varies on a much finer granularity than the overall geometry of the borehole. Instead, this approach introduces a custom fragment shader that adjusts fragment position in world space based on a diameter texture.

In terms of performance, because the borehole geometry itself is sparse compared to the attribute data, this might not actually be that bad. On the worst case side though, some boreholes are 1k segments long, which could be 10-20k vertices. That's a decent amount of memory consumption (could be alleviated though via frustum culling / tiles loading out, or maybe some LODs approach).

In terms of extensibility, we might be able to roll up the spec work for this into a broader definition of vector data? (Maybe?)

In terms of complexity, it's very low - mostly just a new fragment shader + JS class to shepherd the data.

GPU Instancing

This approach would treat each segment of a borehole as an instance of a cylinder volume. It would work similarly to the mesh approach, using a fragment shader to dynamically adjust borehole diameter based on attribute data, but would need extra consideration to support blending segments smoothly.

The upside here, compared to meshes, is that a lot less data gets stored and sent over the bus to the GPU. Just the transforms of each cylinder segment, not all the vertex data.

It's not particularly extensible to any future use cases I know of. A pretty bespoke solution just for boreholes, but it works on top of existing CesiumJS infrastructure and would be relatively easy to implement and would probably be relatively performant.

Implicit Surfaces

In this approach, each segment of a borehole is rendered using a screen-space quad + fragment shader. The shader would use a mathematical representation of a cylinder to determine whether to discard or shade fragments of the quad. It would need to do some fancy math to blend segments together smoothly (each segment's quad + shader would need info about adjacent segments).

Performance:

• Memory consumption is low. Just quads.
• LOD is done automatically. When the quads are far away, they take up fewer pixels on screen -> less work for shader. When they're off-screen, they're culled automatically.
• Low amount of work for vertex shader.
• Fragment shader has more work in this approach compared to others, but typically memory transfer dominates performance on the GPU anyway.

Extensibility:

• The framework we develop can be extended to other types of implicit surfaces (what are the use cases?)

Complexity:

• Relatively high if we want to support arbitrary implicit surfaces. Lower if we simply create a solution for boreholes alone (could be a good proof of concept / prototype)
• Could be a bit tricky to get the blending between segments right (one concern that comes to mind is that the screen space quads would have to be artificially inflated to make sure they overlap enough for curves).

Feature Compatibility:

• Since we never have a mesh at any point, that could be limiting in terms of other features. For instance, the camera currently does collision detection against the terrain as it moves around by picking against the CPU terrain mesh. Boreholes would be excluded from that since they have no mesh. That's probably OK, but what other features require a mesh?

[mzschwartz5]

Elaborating on implementation details of the implicit surfaces approach (since it's been the top contender offline):

• As the camera moves, that changes where the corners of the screen space quads go. Rather than recomputing these on the CPU every frame, each quad's vertices should just be sent to the vertex shader at the center of its cylinder segment in world space. The vertex shader will be responsible for projecting and repositioning the four corners of the quad each frame, based on the cylinder geometry and the camera position.
• Since cylinders have a closed-form solution for intersections with rays, the fragment shader can render cylinder segments directly via ray-casting (not ray marching, which would be iterative and much more expensive). Shadertoy example by IQ. The question is- how extensible is this to arbitrary implicit surfaces?
• But how to handle varying diameter? Do we need a quad for each subsegment (each time radius changes), or do we do a single quad per segment, and then each fragment of that quad does a ray test against each subsegment cylinder + chooses the closest to render?*
• The color attribute requirement should be straightforward (just as you can determine the intersection analytically, so can you determine normals and UVs at the intersection point, and apply colors based on user-supplied styling and the borehole attribute data)

* varying diameter: I do think we have to have a quad per borehole sub-segment... which could be a lot of quads. By comparison, the other approaches do not have this need for sub-segment instances or vertices. They can simply adjust fragments in the frag shader directly. Why? Because they have world space information from the vertex shader. The pure implicit surface approach has no world-space information, and has to get it from ray-cylinder tests.