Collimated HUD

[crim3]

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.

[virtuali]

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.

[wambulance]

what is a Collimated HUD??

[virtuali]

Have a look here:

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.

[Intrepid]

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

[Paddles]

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?

[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?

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)

[Sludge]

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

[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

[virtuali]

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.

[Sludge]

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

[Paddles]

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

[Sludge]

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

[virtuali]

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.

[saprintz]

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.