Definately I forgot one of Murphy's laws - If everything seems to be going well, you have obviously overlooked something 
Perhaps I used wrong terminology when talking about the plane, but virtuali expressed exactly what I meant: You can just translate the simbology to compensate for the eyeposition shift, over a fixed plane. A quick test proves that. Here I've shifted HUD elements by 50 points to the right. Notice some clipping.. So, if our eyepoint shifted to the right by 50 units, we'd see this picture.
Yes, I see what you mean, but I'm just not sure that your quick test is congruent enough to the actual method that's needed... at least not enough so to conclude that the gauge-based solution actually IS workable (without side-effects, at least)?? It sounds like maybe your test was done manually? As if the symbology in the pic was shifted by directly modifying some X coordinates in the gauge, or even in the panel.cfg? I infer that from "if our eyepoint shifted... [we would] see this." (But that might just be you speaking with understandable caution! ;-) But it seems to me that, if done manually, it's dangerous to conclude much at all.
These HUD issues have been taunting me again lately, like years ago, and it's encouraged partly by e-mails from some of you saying "switch focus to the gauge-based approach, please!" So I've done more thinking, and will now probably put it into (way too) many words....
I hate, really HATE to sound negative or pessimistic regarding something ALL of us would love to have, the gauge-based solution. Where would we be if that attitude too often prevailed in this community? But there are just too many examples in my personal development past that tell me "whoa, careful with that!" And these e-mails saying "shift focus to gauge-based!" ... well, it's just a little worrisome to see that the trend seems to be that people ARE starting to lean towards that less likely "home run" of a solution. And all while a great, model-based collimation solution already exist, and even when the model that's needed in order to accomplish it is not *that* far from reach, with a little creative thinking. ;-) The model-based method is the proven; the gauge-based method is a theoretically sound one that should offer a tremendous amount, but it has so far yielded hints( perhaps even evidence?) that it does not wish to be tamed.
First thing... you cannot just add one more delta-eyepoint <shift> command to each individual HUD element (or, in groups) and still expect them to behave. Elements whose movement is complex -- and these HUD's sport some of the most complex -- do not necessarily like to "simply" be moved straight up, down, left, or right, in whole, according to a continually updating (and probably slightly delayed?) variable.
I will give HUD-specific examples: the steering arrow I constructed for the Hornet HUD, or the "tadpole" steering cue for the F-16, involved a shockingly large amount of trial and error, though it looks like it's obvious when peering at the code. Ten times more of a hassle than expected! It's as if you're trying to dictate the movement of a lever, which is rotating around an axis that's shifting up and down another lever, with that second lever itself shifting around the screen. (This process is the same, XML or C++.) The Hornet's pop-up HUD steering arrow was one rotate command, then another, then a shift, then another shift, then a final rotate, with all kinds of dynamic axes and rotation variables intertwined. The F-16 tadpole... wow what a mess... rotate, rotate, shift, shift, rotate, shift, shift. (Ha. I'm having some PTSD symptoms this very moment.) But things like that are why I caution against assuming the efficacy of any "common-sense" method. (Words you'll never hear me say: "Okay, now I just add one last set of shift commands to the whole element, based on delta eyepoint, and we're done!")
There's a decent chance that any attempt to force a mass exodus of HUD symbols from the default longitudinal axis would end up untangling the entire thing. (I have no idea if it would or not. It's just an example of why I do not take the ultimate success of the common-sense, delta-eyepoint heory for granted. It can all be so unpredictable. The results of those F-16 tadpole commands are even different between FS9 vs. FSX... even though I remember a Microsoft developer saying basically "nope, no relevant variables or processes changed between versions, so neither would that result." But... it did change!! Who knows why. There are just so many quirks to it all.
So, delta-eyepoint procedure seems obvious: compare current eyepoint to default eyepoint, then move the whole HUD the same amount. Simple! But, the reality of how it may actually work? Perhaps there are "features" and factors that interact with each other in unpredictable ways, that do not manifest until late in the gauge-based development process? Wouldn't surprise me a bit. Really, it just would not. Very telling is this: consider the magnitude of such a breakthrough, an independent, collimated, gauge-based HUD, that excitement that comes with it... then add the competitive and financial advantages that such a breakthrough would bring... BUT... then temper those prospects by considering the number of pretty competent developers that have *actually encountered* unpredicted problems with the technique (the same problems? Don't know....) And finally, add in that all of these developers' "I give up on it!" declarations took place despite substantial incentives to achieve it, it sounds.
One last thing that occurs to me: QUALITY issues, even within a single method. What is an acceptable result for one developer may not be for another. And certainly, the opinion of the community members as to what limitations and negative side-effects are acceptable, differs wildly. But I assume that the level of tolerance becomes quite small when the prospect of *paying* for such a product materializes. (Even within the model-based solution(s) to HUD collimation, look at the range of techniques and results we've seen in just ~1.5 years -- Aerosoft, VRS, IRIS, others.) What I'm getting at is that, if the standalone gauge method of HUD collimation IS ever adequately accomplished, my money's on it coming from a freeware, independent, "hobbyist" type of developer. Not payware entities that are incredibly burdened by expectations of support, information, and patches, and who would also have to take a big leap of faith and invest significant development $ *up front*, based merely on "MAYBE it can be done" assertions by some developer... probably the only assertions that any reasonably prudent developer could offer. So the kind of person we're probably relying on to deliver any possible gauge-based breakthrough is the guy in his basement at night, trying to escape from the 9-to-5 / wife / kids stress, who can afford to have a very lax, "maybe I'll fool with that HUD now, maybe not 'til next week" kind of attitude. This person has a real advantage. And that's the type who may end up the hero in this saga. (And maybe that'll inspire them to get their butts off this forum, fool with it *tonight*, and not wait until next week. ;-) But the disadvantage that most of those same developers must overcome -- time and experience -- work against the possibility. On balance, I don't know which side of that prevails. But I HOPE those people are the ones who will really put their hearts and especially their time into it. It's just that... this project we're doing here... those who must necessarily be involved in it are not all lone wolves.
These are the things to consider, especially for anyone who relies on development money to put food on the table... and REALLY especially before writing and questioning someone's rationale or understanding of the issues. The theory behind a gauge-based, delta-eyepoint solution... simple! The workability of it in practice.... well, I don't actually know! But there are plenty of reasons to be cautious. People who have butted heads with it. I really HOPE it does come. I mean, even the developers ultimately just want to FLY and have fun like everyone else, right?
So... I'm sorry, but for those asking for justification of the decision to head down the model-based path... wow... if that wasn't enough, I'd say consider yourself "entrenched". Heheh. I hope that a post for several to consume as opposed to customized, personal responses is okay? Time is a facor, that's all. And amazingly, I've found that all of this, this mass of words, will ultimately save it!
It really is just one more equation: the reasonable certainty of success of a model-based solution, minus the chance that we can't even GET the model, is still greater than the apparently dubious prospects of a gauge-based method, whose "common sense" solution, one that must be free of significant issue, has so far eluded several talented and incentivized developers.
Man... okay, that's it. Done now!!!!!
