You may want to use the same "adaptive resampling" method that d3-geo uses when you are rendering spherical polygons into 3d space (see bost.ocks.org/mike/example).

I fail to see how to apply the adaptive resampling method to a 3D geometry. Can you explain? As far as I understand the adaptive resampling method, it only works when you actually know the projection, and then choose the points along the path such that you minimize the distance between the line through the points and the path. But I don't know the projection when I'm constructing the 3D geometry. The only improvement over my current code I see is to choose the geoGraticule precision based on the max zoom level that is expected, to strike a balance between size of the vertex buffer and rendering accuracy. The default precision is 2.5 (one vertex every 2.5 degrees along both axes). With this precision the vertex buffer is ~14k elements, which is not big at all. Increasing the precision to 1 makes the vertex buffer 36k elements, and with precision 0.1 the vertex buffer is 360k elements. Even at that size, every decent GPU should be able to handle that just fine.

You are starting here with a spherical polygon (edges are great-circle arcs), and trying to render it using some approximate 3d "polygon" (edges are chords of the sphere in Euclidean 3-space). You have some kind of error metric for how close your approximation must be to the original spherical polygon to have acceptable rendering. One way to accomplish that approximation is to use d3-geo's adaptive resampling method.

Of course if you know the resolution you need to target it is even easier (doesn't require recursive bisection, and results in fewer segments) to take the arclength of the great-circle arc and break it into n equal pieces where n = ceil(arclength / min_arclength), and you know min_arclength is close enough for your needs. Alternately if your 3d rendering setup can handle circular arcs directly, you could just use those instead of straight segments.

The GPU works in terms of vertices, lines, triangles. It doesn't not have any concept of arcs. Arcs have to be constructed out of individual line segments (which, incidentally, is what the geoGraticule function does). I still don't see how the adaptive resampling would improve rendering quality, or make the code significantly more efficient. In what ways is adaptive resampling better than simply setting the geoGraticule precision to a high enough value?

GPUs don't really draw lines very well either, out of the box. But they are general purpose processors which can be used to draw line segments (or various kinds of curves, probably including circular arcs) in a variety of ways. If your code is set up to work with line segments or triangles, there's nothing at all wrong with just projecting enough points along the circle to match your desired error bound (whether for a graticule or for some arbitrary other spherical polylines/polygons). My main point I guess is that it's not really fair to say that the d3.geoGraticule function uses 'abysmal precision'. Its output data represent the endpoints of great-circle arcs, so for a spherical earth model this is 'perfect' precision.

Here's an example of the true geometry that d3.geoGraticule10() generates: https://observablehq.com/@werehamster/graticule-using-d3-geograticule10 When you blindly render that geometry into 3D space, you get something that's basically unusable. And unlike the precision along the latitude lines (which can be configured), the precision along the longitude lines is hardcoded to 90 degrees. That's what I meant by abysmal precision.

But the point is, the "true geometry that d3.geoGraticule10 generates" is perfect circles. If you choose to render that using chords that is not really the function's fault.