Sorry for the off-topic again... what cards are you using?
Depends on the customer but typically its NVidia Quadro K2000 or K4200. We even have some Quadro 2000 (no 'K' version). Always Quadro, however. I have no control over that unfortunately.
The best practice for z-fighting (since about ~8 years ago) is to use a 32 bit float depth buffer (DXGI_FORMAT_D32_FLOAT in D3D terms) and to also swap the near and far parameters before you create your perspective matrix (so that e.g. near is 10000 and far is 0.1).
The 32-bit Z-buffer would probably make a big difference however even on recent (NVidia Quadro) cards however I cannot seem to create a 32-bit depth buffer without losing my multi-sample buffer bits. That means no anti-aliasing which makes scene look worse than having Z-fighting.
As for swapping the near and far parameters I remember seeing this talked about in an Outerra article
In my previous reply I add that I am using Vega Pirme and I do not have access to their projection matrix. I would have to take over the rendering pipeline. Which I may have to eventually do but that will not be easy.
So let's say I do take over the projection matrix and swap near and far values, does this solution "just work" given that I change the depth test type? Seems too easy.
Something along those lines is probably the most robust solution. You can do two completely seperate passes -- one where you render the entire scene except for your own aircraft, and another where you only render your own aircraft... and then layer them over the top of each other.
If you draw your own aircraft first, you can enable writing to the stencil buffer during that pass. Then during the second pass, you can enable stencil testing, such that you only allow writing to pixels where the stencil buffer still contains a zero. That will save a bit of performance as you won't waste time shading pixels that will end up being hidden.
This is along the lines of what L. Spiro suggested. Given my limitations with the depth buffer size and projection matrix reversed near/far plane matrix this solution may be my only robust solution even though it costs some in performance.
Based on both of your feedback I have decided to drop further investigation into a "better hack" and pursue the 2-pass render. I tried this a few years ago but after having trouble with the shadows I gave up.... perhaps too quickly. There may be a way to manipulate Vega Prime's dynamic shadow object to swap to both channels or maybe create two dynamic shadow objects. There are pros and cons to working with third party libaries and I may be running into the con as far as what I can do using their system of classes (and not have access to source code).
Thanks so much. I feel encouraged to give the 2-channel (ie 2-pass) rendering another try.