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

Collimated HUD

<< < (2/6) > >>

Paddles:

--- Quote from: virtuali on March 26, 2008, 02:40:38 am ---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.
--- End quote ---

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:

--- Quote from: fsxnavypilot on May 14, 2010, 01:35:49 pm ---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?

--- End quote ---

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:

--- Quote from: Sludge on May 14, 2010, 05:05:03 pm ---So thats what youre talking about as far as what a gauge could do to monitor real-time (in the sim) eyepoint changes?
--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version