FSDreamTeam forum
General Category => Unofficial F/A-18 Acceleration Pack board => Topic started by: crim3 on February 21, 2008, 08:12:37 am
-
I'm having a great time with the F-18. The only thing that I'm missing is a collimated HUD (I run FSX in stereoscopic). That would complete my experience. I can't avoid thinking almost all the time how cool would be not to see the HUD doubled when looking outside through him, specially at landings.
Is there anything that could be done unofficialy to do that? Any editing, any file patch or replacement? Is not a problem if the HUD simbology can be seen outside the HUD when moving the point of view, I read that you initially were going to do a collimated HUD but that problem stopped you from do it.
-
Collimated HUD was planned but, it requires some support from Simconnect that is actually missing.
We can read the default eye position (that one that resets itself when pressing ctrl+space), and the eye position as modified by the head latency wobbling, but we miss the actual eye position when moving it, like for example with a Trackir.
Without that info, it's not possible to really collimate the display, without having to resort to an half-backed solution like we did in the Cloud9 Phantom, were we simply had a *very* big gunsight placed ahead the airplane and flying with it, giving the illusion of a projection, but with other issues, like for example the gunsight not being 3d clipped by the hud glass so, if you moved your head laterally in the Phantom, the gunsight would eventually appear floating outside, giving away the trick.
Collimated hud is also much easier with 2d panels, but since we don't have one in the f/a-18...
We might consider it for our next airplane to be out next year. Since it will be published by ourselves, we should have more freedom about deadlines and features and of course using unofficial and/or dirty hacks to get the info we miss from Simconnect in other ways.
-
what is a Collimated HUD??
-
Have a look here:
http://www.rockwellcollins.com/products/cs/at/avionics-systems/head-up-displays/system-overview/hud-basics/index.html (http://www.rockwellcollins.com/products/cs/at/avionics-systems/head-up-displays/system-overview/hud-basics/index.html)
On top of being focused to infinity, in a simulation we have to add additional calculations to have the outside world conformal to the HUD informations. For example, the HUD waterline should always be aligned to the real horizon. In real world, this is done with optics and everything is then calibrated to the normal human field of vision and to a typical height ( I think the pilot has to be seated a look at a specific point in the cockpit to calibrate the HUD to his own height).
In the sim, we have also changing conditions not found in the real world, like the ability to change the field of view with the zoom command, and that complicates things.
We tried to do that in the F/A-18 but, unfortunately, due both to timing constraints and to information missing via Simconnect (we can't read the actual eye position, only the default eye position) and with the increased difficulty of a varying FOV, a proper collimated HUD didn't make it into the final product.
-
Have a look here:
http://www.rockwellcollins.com/products/cs/at/avionics-systems/head-up-displays/system-overview/hud-basics/index.html
WOW that was a lot of info , thanks for the link,it cleared up a few misconceptions
Randy
-
We tried to do that in the F/A-18 but, unfortunately, due both to timing constraints and to information missing via Simconnect (we can't read the actual eye position, only the default eye position) and with the increased difficulty of a varying FOV, a proper collimated HUD didn't make it into the final product.
virtuali
In the FSX SDK (Simulation Variables) I read:
EYEPOINT POSITION The eyepoint position relative to the reference datum position for the aircraft.
STRUCT EYEPOINT DYNAMIC OFFSET A variable offset away from the EYEPOINT POSITION
So we can get the actual eyepoint position?
-
In the FSX SDK (Simulation Variables) I read:
EYEPOINT POSITION The eyepoint position relative to the reference datum position for the aircraft.
STRUCT EYEPOINT DYNAMIC OFFSET A variable offset away from the EYEPOINT POSITION
So we can get the actual eyepoint position?
No, we can't. Not with the SDK, at least. The EYEPOINT POSITION variable it's only the *initial* position, as specified in the aircraf.cfg. It doesn't update if the eyepoint is changed with keys and/or TrackIR. So, it's only correct the moment the eyepoint is reset to the default starting position for the selected airplane.
The STRUCT EYEPOINT DYNAMIC OFFSET, while looking promising with that "dynamic" term, is just the small offset that is added by FSX at runtime to simulate the "wobbling" effect due to head movement/acceleration, but it doesn't account for a changed eyepoint position.
So, ideally, a third variable should be needed, which the SDK doesn't provide.
BUT
I've made some research on this, and yes, by reverse engineering a little bit FSX, IT IS possible to get the actual eyepoint position, with a direct memory access, which is of course only allowed with an in-process .DLL module or a C++ Gauge.
In fact, our Addon Manager already supports this, because it's needed for some features we are going to use in future products, that require to know the actual eye position. A C++ gauge might be able to call this function to get that information, which can be used to create a collimated HUD, without having to modify the airplane model.
For XML gauge programmers, it's be possible for the Addon Manager to "publish" custom L: variables that XML can read. I don't know much of XML gauge programming but, if it's possible to draw lines with a starting position offset by an amount that is specified by an L: variable, it might be possible to do this with XML as well.
The only downside of this would be that any gauge using this method, will need to have the Addon Manager installed but, it wouldn't be a problem for us adding this feature for free, as long the resulting gauge is used in a free product. The Addon Manager itself is already freely downlodable and, many already have it installed, if they have a least one FSDT or Cloud9 product.
Of course, if any 3rd party developer would like to use this feature in a commercial project, we'll be more than willing to license the Addon Manager to them, as we did for other devs that use it (like Qualitywings, for example)
-
Crim3...
Im working with Scott Printz (aerosoft F-16 HUD designer, fully collimated/conformal) to get collimation on the Hornet HUD. Thats why I went to Microsoft, to get permission to break down the default model into workable code, so he can attach the HUD to the model (same way it was done with the aerosoft HUD) and give it collimation. From what Scott has told me, his show-stopper item when he tried making a collimated HUD using a "non-model tied" gauge was what he referred to at "delta eyepoint". It was a very technical explanation, but it sounds VERY SIMILAR if not the same as what Virtuali talked about. Being able to read the difference between the default eyepoint and the actual sim eyepoint position, hence his term "delta eyepoint".
Will keep you guys up on the current status, but Im looking for people that have any insight to breaking down the RTM default Hornet model into workable code. We have had some hits on the other thread, but Im always looking for help anywhere it can be found.
Later
Sludge
-
Virtuali...
So thats what youre talking about as far as what a gauge could do to monitor real-time (in the sim) eyepoint changes? You said something about licensing, Ive gone this far, Id be willing to throw some money at this, if we arent able to sufficiently break down the model to use it as needed.
very interested in this application as well.
Later
Sludge
-
So thats what youre talking about as far as what a gauge could do to monitor real-time (in the sim) eyepoint changes?
Yes, we have that info in the Addon Manager already. It's only a matter of exposing it to gauges which, if we are written in C++, it would be done by standard .DLL function exports, and for an XML gauge, it should be probably done with custom L: variables, that the Addon Manager could export for XML use.
You said something about licensing, Ive gone this far, Id be willing to throw some money at this, if we arent able to sufficiently break down the model to use it as needed.
We are willing to add that feature for use for free projects. Since the permission you had from Microsoft specifically exclude doing any commercial work derived from the F-18, there are no licensing issues with us, since it HAS to be freeware anyway.
I've cited licensing, only in case someone would want to create a commercial product using this method, because he'll need to license the Addon Manager (and get product protection on top of it). This could be either:
1) A replacement gauge for the Acceleration F/A-18 that would be sold as an Acceleration Addon. This can be done legally, since if it's a whole new gauge that requires the Acceleration Pack installed and it doesn't contain any MS code, there would no problems selling it.
2) A gauge for a different airplane that doesn't have anything to do with the Acceleration F/A-18, which might be part or a commercial airplane product.
-
Virtuali...
OK, thanks for clarifying. Will keep this route in mind. I think we (myself and Scott Printz) are gonna keep down the path of attaching the HUD on the model, either until it works or we fail. If it fails (could happen, I dont know), I know Im open to trying your method and using a C++ gauge or .xml that could monitor the actual sim-eyepoint.
That being said, just because myself and Scott are going ONE POSSIBLE ROUTE of HUD collimation, PLEASE do not let that stop anyone else from trying this route. Virtuali seems pretty confident that it could work, so please, if you have the desire, follow up on it and proceed as he is discussing in this thread.
Later
Sludge
-
virtuali
Many thanks for very useful info. When developing an XML gauge I'd like to have some L: variables to get access to the aircraft's data, definately. BTW, when using your Addon Manager is it posiible to tell the current point of view? I mean is it a VC, or a tower view, or a spot view... I badly needed this info when developing my voice announcing gauge.
Sludge
I do believe that a collimated HUD could be made 'non-model tied'. That delta eyepoint is all that we need, and the Addon Manager can provide it. The rest is a matter of time )))
-
FSXNP...
Cool. Give it a whirl. The more people we have working, the better chance we have of someone actually succeeding. And, if you need any input from me, feel free to ask... there's no competition on my end. If you end up getting us a collimated HUD, then thats how it is, Im all for it.
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.
Definately liking the momentum we got going this week!! 3rd wind in the sails for the default and Sludge Hornet!
Later
Sludge
-
BTW, when using your Addon Manager is it posiible to tell the current point of view? I mean is it a VC, or a tower view, or a spot view... I badly needed this info when developing my voice announcing gauge.
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.
Note that, this was relatively tricky to do in FS9, because it required in-memory access, but it's easier in FSX, since Simconnect does provide with that info. Of course, the Addon Manager could make it easier for XML developers, since it could publish it as an L: Variable.
-
I think that there are going to be problems if trying to do a standalone, C++ HUD, one not integrated with the model. Before lots of fiddling, I thought that having current eyepoint in hand meant that collimation was right around the corner... just add a bunch more trigonometry to make the symbology appear to be fixed, and then bingo, home free. But there are some issues with the "independent dll" method, at least as far as I can tell. 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. Just my few cents...
On the OTHER hand... there are some VERY talented people out there, certainly many with more experience than me, so who knows? I agree that everything possible should be tried! My gut and experience just lead me down the model-integrated route, so that's where my personal efforts will be focused. But it would be GREAT if someone came up with a reliable way to do a non-model-dependent HUD. I think we all just want to have fun flying an F/A-18 with a great HUD, as soon as we can, right? So who cares how we get there. I'm just looking forward to the arrival.
-
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.
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.
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.
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
... 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.
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 :)
-
... 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.
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 :)
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. ;-)
-
I'm assuming you don't mean that, because that perceived shifting of plane is needed regardless of the technique used.
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.
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.
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 (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...
-
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.
-
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.
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!!!!!
-
Good lord Scott, you like making long posts, eh?
Edit:
Would you mind also making the clipping area much smaller, the hud size smaller, and a little more transparent?
References:
http://www.fsdreamteam.com/forum/index.php?topic=3093.msg26142#msg26142
http://www.fsdreamteam.com/forum/index.php?topic=3093.msg26146#msg26146
-
I think long posts (with good content) are brilliant ;D.
-
That's right. ;D
Scott
thank you very much for enlightening and detailed explanation. I agree that the common sense didn't work again. :)
-
That's right. ;D
Scott
thank you very much for enlightening and detailed explanation. I agree that the common sense didn't work again. :)
Well, I should be more clear: I'm not 100% SURE that gauge-based can't work. I just know that so far it hasn't. And based on some of the circumstances, it seems very likely that if it could be done (done "good enough", heheh), it would have been done by now. In fact, I know people who were fooling with the gauge-only, delta eyepoint approach probably around 4 years ago, as soon as FSX came out. You can see the stir it was back in the avsim panel & gauge forum. I always like examples... and I THINK (but am not positive I'm recalling correctly) that Jon Blum was trying model-independent, delta eyepoint methods YEARS ago. Not positive. But in fact, I don't recall the model-based approach discussed much at all. (We were *gauge* people after all!) I'll admit I didn't even know enough to even consider that a model-based solution was possible. Then I get a very casual e-mail from someone, model attached, with the question: "do you think this effect could be useful?" Uhm.... YEAH!! A buried treasure. (I'm not saying he's the 1st; I have no idea.) But THAT WAS the model solution, the first time I'd seen it, and it was breathtaking to fly it the 1st time. And my *immediate* fantasy reverted back to a great F/A-18 HUD. So I'm really glad to be involved here, especially since it's strictly for the fun of it. (Enough gauge stress already, and this Hornet stuff is cathartic....)
I hope that the long post up above was illuminating. We do know what we're doing here with the Hornet collimation attempt, promise. We've just gotta play the odds. (I hope others, those lone wolf basement developers, will still pursue gauge-based though!) I want a collimated Hornet HUD possibly more than anyone. Because I was in it before even "just" conformality had been properly done. I *got into gauge design* in the first place, handful of hours a week, for the very REASON of making a good F/A-18 HUD; conformality was the goal and first big achievement (though I had no knowledge of the two actual "C" words), and IT is now somewhat commonplace, thankfully. (Those were the pre-FSX days, w/ more people still flying 2D, no TrackIR and all that, so the impetus for a "fixed" HUD (collimation) was not so great until the lack of it became so dreadfully obvious after scenery conformity.
Okay, one last thing, just to keep it positive and look on some bright sides. This is for Track IR users, probably most of us, and it may seem like common sense, but I'm positive a few TrackIRers haven't considered it... but... do consider settling for an alternate, "special" TrackIR profile, w/ significant reduction in head movement features, to be used for conformal but not collimated HUDs. By limiting left, right, up, down, in, and out, but with ROTATION, I think enjoyabilty may actually increase. I know it seems *barbaric* to start turning off things that are the very reason of the product's existence, bur when using this profile, the HUD symbols within FSX will stay not just scaled, but conformal all the time -- no annoying reminders of the lack of collimation. It's great, after getting over the initial hump. (I sent a couple of people the right kind of profile, anyone else who'd like it, I'm happy to send to them too. But all you do is disable everything but swivel.) And w/ something like JR's adaptation and enhancements of my original HUD (he is a really talented guy!), it's GREAT. Perspective, for me, was thinking back to the mid-90's and Graphsim's Hornet Korea, MiG Alley, or especially Parsoft's A-10 Attack (THE most underestimated sim of all time!!!), and imagine how incredible they would've been with just swivel-only TrackIR. Great fun. (Ahhhhh, memories of those old sims... ;-)
Okay gents (and any ladies), no *incredibly* long-winded post this time. (Right....heheh.) But thanks everyone for the feedback, the pictures, the information, and all that. It is overall very helpful and encouraging.
-
Ok guys, here's a quick (and dirty) test of this 'barbaric' approach 8)
I set an alternative Freetrack profile with only yaw and pitch axes enabled. Sure, it will take some time to get used to this setup. And Scott is right that there are no enjoyability losses, no collimation issues...
Sludge, I like your latest setup, it really gives more power, no need for burner.
-
Seems to me you forgot your flaps, but nice video anyway, quite realistic ;)
-
Apologies in advance for the stupid question, but I thought that the HUD mod that came out recently was a collimated HUD ? ( Most of that discussion is somewhat over my head I am afraid, but if I understand , it s the method of achieving it thats being discussed, not actually being able to do it? )
cheers, Mark
-
I think it's collimated for the default viewpoint, but if you use the Ctrl Shift Enter Backspace keyboard commands, FreeTrack or TrackIR to shift the viewpoint, it won't be anymore.
-
There are two terms here that get mixed up a little - one is CONFORMAL and the other is COLLIMATED. The HUD can be conformal but not collimated. Conformal is when the HUD symbology properly corresponds to the outside world - the horizon bar sits on the horizon and the velocity vector shows the direction you are flying relative to the outside world. Collimated is when the HUD symbology is always conformal regardless of where your viewpoint is at the moment. So if you have TrackIR and shift your head left - the symbology moves to the left and remains conformal to the outside world. Currently the HUD mod is only conformal at the default view point, which means that as the aircraft accelerates and your head moves naturally forward or left/right - the HUD symbology loses correlation (conformality) with the outside world, in other words it is fixed relative to the aircraft. Sludge tries to find a way to collimate the HUD. Some aircraft already have collimated HUDs such as the Aerosoft F-16, the IRIS F-16D, Dino's F-35, Lotus L-39. Some years ago HUDs were not even conformal and Scott Printz came up with a freeware HUD that was conformal and that was a big achievement. The push now is for collimation, but the method we use requires a specific change in the aircraft model. In real aircraft the HUD symbology is projected into infinity and that achieves the effect of collimation.
-
Yet another quick test... :)
This time I wanted to test two HUDs - on the Accel Hornet and on Dino's Tomcat - and see if my 'shifting plane' approach is feasible.
No joy... I have to admit that this approach won't work. The plane is too close to the eyepoint and moving/shifting the symbology would change nothing in the pilot's perception of it as being a distant object. The symbology appears to be more than 200 feet in front of the aircraft (http://www.rockwellcollins.com/products/cs/at/avionics-systems/head-up-displays/system-overview/hud-basics/index.html (http://www.rockwellcollins.com/products/cs/at/avionics-systems/head-up-displays/system-overview/hud-basics/index.html)). So, the only acceptable way to make a collimated/conformal HUD is to add to the aircraft model a distant plane (or something) upon which the symbology will be projected. Until that I'll have to fly with my Freetrack set as a 2DoF device. Period. 8)