1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

FSX RMI Needles 3D

Discussion in 'Modeling' started by n4gix, 12 Jun 2010.

  1. Roy Holmes

    Roy Holmes Resource contributor

    Joined:
    20 Feb 2011
    Messages:
    1,346
    Country:
    us-virginia
    Well, here I go again! Being picky!

    Although the SDK says ADF RADIAL is current direction FROM ADF station is really is current direction TO ADF station. So it is a direction relative to the airframe and has nothing directly to do with plane heading.

    Since it is relative to the airplane and has a range of 0 to 360 degrees I do not understand why dnor is needed if the direction is calculated in degrees. I thought dnor was needed when a subtraction gave say -15 degrees when what it should be is 345 degrees so you bring dnor to the rescue.

    Reasons why the needle should be parked facing 90 degrees to the right also include inadequate signal strength as well as lack of electrical signal to the gauge or system. So (A:ADF:1 signal, number) also needs to be greater than zero or something similarly low, if not the needle should be parked.

    For example, ignoring master battery or avionics master considerations and using radians which is simpler, I use:
    Code:
    <Value>(A:ADF:1 signal, number) 0 &gt; if{ (A:ADF:1 radial, radians) } els{ pi / 2 }</Value>
    Just a query and a suggestion. Before I decided to be picky again I took the precaution of arranging to be on vacation for 3 weeks starting really early in the morning!

    Roy
     
  2. n4gix

    n4gix Resource contributor

    Joined:
    26 Sep 2006
    Messages:
    10,803
    Country:
    unitedstates
    Roy, "radians" works just fine and dandy for 2d gauge code (C) or script (XML).

    However, it doesn't fit worth a tinker's damn when dealing with keyframe animated 3d XML script...

    ...where the output of any "formula" must be scaled to a fixed range of keyframes.

    Mostly what this means is that accuracy is down to single integer precision. Fractional values are meaningless.

    With that in mind, the highest accuracy practical is a keyframe animated rotation of 360 frames: 0 through 359, which will of course yield an accuracy of only 1º.

    The number of keyframes permitted is 1024, which means at best one could -by doubling the number of keyframes- achive 0.5º precision.

    The main point I'm trying to make is that for a 3d modeler/animator, one properly chooses the measurement system that best "fits" the limitations and practicalities of scaling the formula's output to such a rigid and restrictive mechanics. ;)
     
  3. Roy Holmes

    Roy Holmes Resource contributor

    Joined:
    20 Feb 2011
    Messages:
    1,346
    Country:
    us-virginia
    Bill,
    When modeling a 3D gauge, am I correct in assuming that, in general, the frame number corresponds to the input value and that the number of frames should equal the maximum expected value for the input?

    For instance I modeled an airspeed gauge based on needle_asi_eh101 which has 200 frames (at that time I had not noticed the EH-101 ASI reads to 200 knots). My max speed was 150 and I used 200 frames. The error I got when calibrating it was proportional to the ratio of 150 to 200 and the angular rotation of my needle compared to the EH-101 needle. Made the number of frames 150 and got the correct results. This modeldef entry uses A:AIRSPEED INDICATED.

    If I had a maximum value of say 800 I guess I could use 800 frames or use an A: or L:var with 1/8 scaled input for 100 frames. I notice that looking up needle_asi in modeldef there are three entries. Needle_asi which has 70 frames and the input is (A:AIRSPEED INDICATED, mph) 10 /. It relates to the P-51, so 70 frames makes sense. There is also needle_asi_l which has 360 frames but uses (L:needle_asi,number). Plus the EH-101 version.

    As an aside, I'm trying to finish a SeaKing helo using FSDS and again found that if you use something like needle_asi_eh101 for the animated part the FSDS compiler does not look past needle_asi so that is what gets animated. Easy to fix but wrong.

    So my assumption is that frame number is input value and you animate the needle or whatever rotation so it reads correctly.

    Roy
     
  4. n4gix

    n4gix Resource contributor

    Joined:
    26 Sep 2006
    Messages:
    10,803
    Country:
    unitedstates
    Roy, the general "formula" for synching sim variables (or custom vars) to keyframes is simple:

    keyframes = simvar * scale + bias

    For example, a VSI with a range of -6000 to +6000

    Max keyframes is 1024, so pick whatever seems reasonable. I'm going to pick 120 frames, which means I'll need a bias value of 60 to shift the 0 point to mid-scale.

    The simvar "VERTICAL SPEED" is returned in ft/min, so I need to scale down that returned value to fit within my total number of frames. Either of the examples below will work:

    Code:
    120 = (A:VERTICAL SPEED, ft/min) .001 * 60 + 
    
    120 = (A:VERTICAL SPEED, ft/min) 100 / 60 + 
    This means that every frame = 100'. I could double my precision by simply doubling the keyframes to 240 and adjusting the scalar and bias appropriately.

    For my T-38A airspeed indicator, I used a total of 425 frames, since the max speed on the dial is 850. Of course I could have used 850 frames, but that seemed a bit of overkill... ;)

    Hence:

    Code:
    (A:AIRSPEED INDICATED,knots) 2 /
    When I keyframe animated the needle, I baked in the non-linearity table via the needles' movement. Obviously no "bias" is needed since there's no +/- zero point offset required.

    For my mach dial, since it is Linked to the ASI needle, I used 200 frames of animation and this formula:

    Code:
    (A:AIRSPEED MACH,mach) 100 *
    The example in the default modeldef.xml file using (L:needle_asi,number) simply means that the programmer is calculating their IAS value in an external gauge or logic module.
     
    Last edited: 11 Jul 2011
  5. Roy Holmes

    Roy Holmes Resource contributor

    Joined:
    20 Feb 2011
    Messages:
    1,346
    Country:
    us-virginia
    Bill,
    Thanks for this very clear explanation.

    I do the "rotation baking" in Excel from the 2D gauge image needle center pixels and non-linearity value pixels calculating the rotation angles in degrees versus start point. Pretty obvious, but might help someone.

    I have only done the F-4/A-7 combined Mach/IAS gauge in 2D so far. It is different to the T-38 in layout and mechanical function, but the principles you described will help me attempt a 3D version.

    Thanks again, as always
    Roy
     
  6. n4gix

    n4gix Resource contributor

    Joined:
    26 Sep 2006
    Messages:
    10,803
    Country:
    unitedstates
    Just to be clear here, what I mean by "baking the non-linearity" into the keyframe animation is this:

    Starting at first desired value (say 40 knots), click AutoKey button, rotate needle to 40, move slider to next point (say 50 knots), rotate needle to 50...

    ...repeat the process until you've reached the max value (in my case 850 knots). (un)click AutoKey button.

    Done!

    Another neat trick. If you have multiple gauges such as oil-pressure for left/right engines, you can select both needle objects and keyframe animate both of them at the same time. :D
     

Share This Page