Also interested in how to overcome this behavior. I have 2 monitors and can’t see labels on the second one.

Negative. Also the “before” callback is called once only, for the main screen.

hmmm – if you set the drawing callback to the _before_ windows phase (the example shows after) do you get multi-monitor working? The second eye is not a second screen, it’s a second pass. But the ‘after’ phase isn’t in the HMD at all, the before is.

I can confirm this: No labels on 2nd monitor. Also, users report seeing labels in one VR eye only, which might be related (assuming the second eye is technically a second screen). I sense two issues here, which might not be simple to overcome:
– All projection matrices are (potentially) different on different screens as they are showing the scene from different view points;
– XLMDrawString (and simlar functions using pixel coordinates) cannot yet draw on the second screen.
One would assume that for several screens there would be a need for calling the drawing callback once per screen during each cycle, but I can’t find a way of making that happen: It is called once only for the main screen.

You cannot render to X-Plane using the Vulkan API, _even_ if the sim is running in Vulkan.

GDPR: If you _comment_ on the website, WordPress saves a bunch of info about you for anti-spam and comment moderation. It does this “out of the box”. That’s not negotiable; GDPR considers virtually everything including your IP to be personal data, so a comment feature that didn’t require a GDPR notice would be completely anonymous and untraceable, and therefore would just be a giant spam magnet. We wouldn’t be able to reply because we wouldn’t have time to look for real comments amongst a sea of unstoppable spam.

ie : XPLMCreateWindowEx then figure out the position and dimensions, then draw in 2D there, this was working perfectly using opengl.

I was also using X-Plane to work on terrain rendering by using xplm_Phase_Terrain, it would be nice to have a similar way of doing this with Vulkan.

On a different subject it is too bad that I have to accept you getting my personnal data in order to ask a question. Not too sure how this fits GDPR here as I am an european citizen.

PhM

You are correct the code above needs a fix to exit early if ndc[2] less than -1 (it is supposed to be OpenGL convention during 2D callbacks, but check it though). Usually such kind of computations are done inside a shader and there is no need to check for the clipping since this is done automatically by the graphics library, but here it is done on the CPU and then only fed into a 2D pipeline, which has no idea about what ndc[2] was.

Ndc coordinates are those that live after the optical projection, i.e. after projecting the pyramid shaped “physical” view frustum into a “non physical” cube (you may have a look here e.g. http://www.songho.ca/opengl/gl_projectionmatrix.html if you are not familiar with).

In OpenGL convention ndc[2] = -1 exactly means that the point lives on the near frustum plane ( “near clip plane”), and ndc[2] = 1 arises when the point is on the far plane. You don’t have access to the near and far planes directly through datarefs, but if you really need them they can be inverted directly from the projection matrix, and in that case “in front of the camera” would exactly be ndc greater or equal (n+f)/(n-f). In general though n is much smaller than f (by many orders of magnitude), so the last fraction is very close to -1 anyway.