This set of examples will use the first scene. It is real simple (in terms of elements), but it is sufficient to illustrate the projection issues. For the purposes of this discussion assume that the display screen is sufficiently large to show everything that is desired to be displayed. Also assume that the rendering software does not enlarge the displayed scene to fit the screen.
For the last nine months I have been working on a declarative language for VR/AR/MR to display 3D content in a browser. I have called the language XSeen.
In the marketplace of file formats for 3D content, X3D has a tremendous advantage over all other formats by nature of its ISO Standardization, openness, and compatibility over 20 years. There are other formats that meet one or more of these features, including OBJ and FBX; however, X3D has not been a dominant or even significant player in the marketplace.
Recently there has been discussion about the suitability of various 3D formats as an archive format, especially for models. There are formats that have been around a long time (OBJ, FBX, X3D), those that are optimized for delivery (glTF), those that are widely used in existing tool chains (OBJ and FBX), plus a number of other criteria and formats including tool-specific (Blender, Maya, etc.). The most widely used format is FBX and any format that seeks to supplant it needs to offer at least as much capability as that one.
WIth 3D/VR becomming practical in the web browser there are a lot of questions concerning the right format to use for various situations. This post looks at two model formats - X3D and glTF. Both formats support full geometric surface modeling, but there are differences between these formats for some specific areas.
This is part of a multi-part post that explores some ideas for integrating X3D into HTML5 DOM. It explores various options and their implications. The primary post is "Integrating X3D into DOM - Issues".