I need to draw a horizon line that dynamically adjusts as the camera moves. Any advice or code examples would be really helpful!

Hi @Mehmed, this sounds like something that would be implemented in a flight simulator. Some community members have done interesting work on this type of applicationāsee this older thread for example. Perhaps you could reach out to one of them?

I wonder if there are any features that support horizon line detection, or what would be the best method for implementing this feature in a simulator?

Maybe the actual requirements have to be fleshed out here. Starting with the initial view: Where and how should that āhorizon lineā be drawn?

The horizon line should look like this, the longer line represents the horizon. I need a method to calculate it and then draw it on the screen. I believe drawing it will be the easier part.

I found an this link that does something similar, and Iāve implemented the same logic for the four sides (when the roll is 0,90,180 and 270 degrees) of the screen. However, thatās not enough since the plane can roll in all 360 degrees. Iām looking for a more comprehensive solution. Any ideas?

This is what I am trying to achieve. You can check this video on youtube. It is called HUD (Head Up Display).

Iām roughly aware of the concept of a HUD. The point is (what you already mentioned in your second post): The camera can be oriented arbitrarily. So whatever solution someone comes up with, there will *always* be configurations where the horizon line, as a concept, does not make sense. I cannot imagine what āthe horizon lineā should be in this image:

(Exceptā¦ a circle, maybeā¦)

The GIST that you linked to takes a very pragmatic approach of finding the horizon, by essentially scanning the screen, pixel by pixel, until the horizon point is found. *Theoretically*, one could do the same to detect the actual orientation of the horizon, but I think that this will be prohibitely expensive.

It should be possible to compute the horizon line by the position, direction, up-, and right-vectors of the `camera`

. This would involve quite a bit of tricky math.

Maybe itās easiest to compute that line from the `heading/pitch/roll`

of the camera, also taking into account the āheightā of the camera position.

Butā¦ what will be the result of that? I mean, in which coordinate system will that horizon line be represented? For now, it is not even clear whether that should be drawn *as part of the (3D!) geometry that CesiumJS is rendering*, or whether it should really be drawn in 2D, on the canvas. (I assume that it should be the former, but that would still be on some artificial ā(near) view planeā or soā¦)

The image you referenced seems to be far from a planeās actual reach in flight. In my flight simulator, planes will follow regular intervals. Iām actually behind that tricky math, which, though challenging, provides a powerful solution. I also think drawing it on the canvas is the suitable way.

Do you have an idea about that math?

I just spent a while, trying to mush together the pitch, roll, camera height and FOV, but would need much more time for that.

(I hoped that there are some resources about how to compute that line *in general*, and *in theory*, butā¦ surprisingly, nobody on the whole internet ever seemed to have this problem ).

I think starting with the horizon line in a fixed position and updating its position based on the planeās heading, pitch, and roll could be a good approach. But it also does bring a bit of math into play.

Unfortunately, itās really hard to find any resources on this topic. Iām currently reading some (horizon culling,horizon occlusion point) articles by @Kevin_Ring , hoping they might help shed some light on the math behind it.

In theory, and on a *very* high level, many parts of this will boil down to plain trigonometry, and maybe some intercept theorem thrown in. Some simplifications (like treating earth as a sphere instead of an ellipsoid) might also be applicable. But assembling that, to eventually have that function that receives a `camera`

and throws out a (2D!) line that can be drawn on the canvas may be quite a bit of work.

The blog posts that you linked to should already contain some useful math (and maybe code snippets). Computing the āhorizon pointā for the view could be a first step. Computing the ātangent planeā at this point (from the ellipsoid normal at this point) should be simple. Projecting that into 2D space could be a bit tricky. If you donāt want to let CesiumJS render it (but render that line manually on a canvas), youāll have to do a lot of the projection and clipping on your own.

(I think that it could be nice to have a few utilities for implementing HUD-like elements in CesiumJS. And I started scribbling a bit of code for that. But the horizon line itself (and drawing that on a 2D canvas) would require more time, thought, and effort)

I completely agree that CesiumJS should include features for HUD-like elements and a horizon line.

I can currently find the horizon point and draw the line on the canvas using the method in the GIST I shared before.

Thank you for taking the time to share your insights! If you discover anything further on this topic, Iād love to hear about it.

I donāt really have anything that goes beyond basic experiments. Many aspects of the goals had not been clear. And a sandcastle like the following may not really provide any substantial helpā¦

It just defines a āHUD Canvasā (in the HTML part), and draws some arbitrary line into that. The computation of that line is marked with

`// XXX THIS DOES NOT MAKE SENSE!!!`

because I removed all my experiments for detecting the *actual* horizon line, and replaced it with some ādummyā line computation.

One can still see what the goal wasā¦

and the *orientation* of that red line is actually ācorrectā, because it only depends on the `roll`

angle. But implementing that *properly* would require more timeā¦