General Category > Unofficial F/A-18 Acceleration Pack board

Collimated HUD

<< < (4/6) > >>

Paddles:

--- Quote from: Sludge on May 14, 2010, 08:16:28 pm ---And, Im definately on-board with your ideas about the Approach Lights assembly being part of the model instead of the "workaround" gauge that you did earlier.  Not that it wasnt good, but it un-enables some of the VC light switches themselves (ie. cant shut off certain lights because the gauge needs it to display red/amber/green light).  Personally, I dont use it anymore, but if you can get that modelled inside the Hornet, that would be another great addition.

--- End quote ---

Sludge
Exactly! I do not like the way the ALA is made either, I'd prefer the way it's made on Dino's Goshawk.


--- Quote from: virtuali on May 14, 2010, 08:36:19 pm ---Yes, of course...we had this feature for ages, since the Cloud9 MB339/Phantom. We needed it to fix a problem of gauges update routines that were called twice by flightsim, if the same gauge appeared both the 2D and the VC panel so, with this detection in place, we save a lot of calls and fps...and yes, we also used so our sounds (the custom DirectSound calls) could be programmed differently or even being shut down, in case the view was inside or outside the cockpit.

...Of course, the Addon Manager could make it easier for XML developers, since it could publish it as an L: Variable.

--- End quote ---

virtuali
Can't wait for such Variables! And is it posiible to use your Addon Manager to program custom sounds as well? That would be cool, indeed


--- Quote from: saprintz on May 15, 2010, 04:16:07 am ---... Theoretically and mathematically it seems like such a straight and obvious shot, but the practical doesn't always comply, and for me at least, a barrier pops up that is (or was to me) a little surprising. You can get some of it done properly this way, but there are probably going to always be some circumstances where the HUD detail gets pretty ugly.

--- End quote ---

saprintz
Right now it seems to me quite simple - that plane, upon which all HUD elements are drawn, should be shifted (and clipped as needed) within the HUD frame boundaries, depending on amount of that eyepoint delta. So, anything else with the HUD gauge would remain untouched. That's my point of view so far  :)

saprintz:

--- Quote from: fsxnavypilot on May 15, 2010, 05:14:44 pm ---

--- Quote from: saprintz on May 15, 2010, 04:16:07 am ---... Theoretically and mathematically it seems like such a straight and obvious shot, but the practical doesn't always comply, and for me at least, a barrier pops up that is (or was to me) a little surprising. You can get some of it done properly this way, but there are probably going to always be some circumstances where the HUD detail gets pretty ugly.

--- End quote ---

saprintz
Right now it seems to me quite simple - that plane, upon which all HUD elements are drawn, should be shifted (and clipped as needed) within the HUD frame boundaries, depending on amount of that eyepoint delta. So, anything else with the HUD gauge would remain untouched. That's my point of view so far  :)

--- End quote ---


I'm not sure we're talking about the same thing here? You mention the delta eyepoint thing (needed for the gauge solution), but also mention shifting the plane upon which the gauge is drawn, which sounds much more like what we've called the "model" solution, no? (Or do you mean the "imaginary plane" upon which the pilot *perceives* the symbology to be drawn? I'm assuming you don't mean that, because that perceived shifting of plane is needed regardless of the technique used. I know you know that, but I'm just pointing out the source of my possible mis-understanding.)

The magic and trickery of a C++ module's delta eyepoint method is, you can use a standalone gauge to make it *seem* like you have done what only the model actually can do - move the projection plane. But the delta-eyepoint, standalone gauge method is not the primary route we're taking, because (as I tried to say) a few things point to it being much more difficult to do 100% than it first seems. It's not difficult in the sense that you can't get some okay collimation, and certainly not because the math or the concept is too hard... but instead because of other bad things that (it seems to me at least) must inevitably come through with the standalone gauge method. I hope somebody can get past those things, and make a standalone HUD work as it should!! That would be great. But it seems like it's been elusive to more than a few people who've had quite the incentive. Imagine a "universal" collimated HUD, independent of any aircraft model, projected based only on delta eyepoint. It would be the ultimate, and could work with any aircraft's VC, since it would be able to read the relevant settings from their cfg files. VERY cool. I would SO love to get to play with one of those. ;-)

virtuali:

--- Quote from: saprintz on May 16, 2010, 12:47:41 am ---I'm assuming you don't mean that, because that perceived shifting of plane is needed regardless of the technique used.
--- End quote ---

Well...not. I think you are reasoning with the concept of tweaking the model in mind so yes, in this case, it wouldn't change much if it was done in C++ or in the model.

Note that I'm assuming that with "shifing of plane", you are refering to physically move the polygon the gauge is projected on, right ? In this case, even if it would be done in C++, the model would need to be tweaked anyway, otherwise how could you tag it to be recognized as a movable part ?

But why having to shift the plane in the first place ? You can just translate the simbology to compensate for the eyeposition shift, over a fixed plane...this way, it would work independently of the model.

Of course, the model would need to at have at least one available projection plane for the HUD modeled in and tagged with a $VC texture.


--- Quote ---Imagine a "universal" collimated HUD, independent of any aircraft model, projected based only on delta eyepoint. It would be the ultimate, and could work with any aircraft's VC, since it would be able to read the relevant settings from their cfg files. VERY cool. I would SO love to get to play with one of those.
--- End quote ---

Well, to make it *truly* universal (meaning, working with airplanes that weren't even supposed to have an HUD in the first place), there might be an entirely different solution...

look at our XPOI program, especially this feature:

http://www.fsdreamteam.com/products/xpoi/XPOI_Screen011.jpg

See the Wikipedia pointer icon ? It's an object that is created on the fly by the program (actually, it's not C++, it's Python AND C++, but it can be done in C++ only as well...) and, it's an object that FLIES WITH YOU so, imagine that one, replaced with a floating projection plane, and there you have your "universal" HUD...

Paddles:
Definately I forgot one of Murphy's laws - If everything seems to be going well, you have obviously overlooked something  ;D
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.

saprintz:

--- Quote from: fsxnavypilot on May 16, 2010, 06:34:09 pm ---Definately I forgot one of Murphy's laws - If everything seems to be going well, you have obviously overlooked something  ;D
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.

--- End quote ---


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!!!!!

Navigation

[0] Message Index

[#] Next page

[*] Previous page