LuciadLightspeed strives to keep the differences between 2D and 3D to a minimum, so that application code doesn’t usually need to know or care whether the view is currently 2D or 3D. There are some use cases, however, in which separate code branches for 2D and 3D are unavoidable.
An example of such a code divergence is the level-of-detail styling for icons. When you define icon styling based on level-of-detail, you use an icon of a 3D airplane model for objects that are nearby, for instance, and replace the airplane with a simple 2D icon when the objects are further off. In 3D, you could achieve this by computing the distance from the object to the eye point. In 2D there is no eye point, so the scale of the view is typically used instead. The distance-to-eye and scale values have different units of measure, however, and can therefore not be compared to one another. Hence, you end up with two code paths that need to be finetuned individually.
A trick that can occasionally be useful to minimize such branching, is to treat the 2D view like a virtual "top down" 3D view. In other words: we have a 2D view, but we pretend that we’re looking at it through a virtual 3D camera. Obtaining the position of this virtual camera is straightforward:
As shown in the image, some simple trigonometry gives us the camera’s Z coordinate. You can obtain the camera’s X and Y coordinates by transforming the coordinates of the view center to world coordinates. As a result, we now have a plausible “eye point” for our 2D view. From this point on, we can allow the 2D code to work exactly like it does in 3D.