Hyperbolic trig in XML?

[Guest jprintz]

It's not documented in the SDK, but since many other things which work also aren't, I thought I'd take a chance and ask... is there any way to use hyperbolic trig functions in XML? I need to use tanh(x). Beyond a (too) complicated and taxing Taylor series, it's the best way I've found to approximate tan(x) and yet avoid the jump to infinity every pi/2 (which I WANT to avoid). Or, maybe some math-lover in here has an idea? I want, basically, tan(x) from 0 to +/- pi/3, but need it to trail off asymptotically (horizontally) around Y = +/- 5. I also need to avoid piece-wise solutions, if possible. The sign ramifications have already been acounted for. Thanks!

[Guest Patrick_Waugh]

Instead, just test for the initial condition which will result in the infinite result, ie. verify that x is not a multiple of pi/2. This is what is known as a "boundary condition", and it will be much faster to just test for it and provide a handler to deal with that case vs. getting fancy with a hyperbolic function or Taylor series.Hard without more details to suggest other strategies.Good luck.

[Guest jahman]

Consider tanh(x) = -i tan (ix)accroding to http://en.wikipedia.org/wiki/Tanh#Standard...aic_expressionsNo idea though if the "-i" thingy will make things too "complex" for you, though... :-)

[GCarty 1]

What do want tan(x) for?tanh(x) has completely different behaviour...

[Guest jprintz]

>What do want tan(x) for?>>tanh(x) has completely different behaviour...Yes, that's why I want to use it. ;-) I can manipulate tanh(x) to be "close enough" to tan(x) for the values that really count, and still have the last bit trail off nicely, in a smooth arc. What I do not want is a discrete stop or jump over, or a max value, or anything like that.It's very hard to explain what I'm doing, but, briefly, I'm using it in a HUD. In caged mode, the velocity vector is confined to being directly below the waterline. The ladder still rotates around the vector, however, and not the waterline, which complicates things. I have not seen any HUD on a PC ever do this properly, (or, at least, not one that attempts to maintain conformality between the symbology and the scenery), and for good reason.... Since the HUD ladder must remain conformal to the outside scenery, a quick little sketch and some basic trig will show that, when rolling the AC, with any drift at all, the HUD can no longer always accurately display BOTH angle of climb and angle of attack. One of the 3, at least, must suffer: conformality, AoA, climb angle. AoA is the obvious "loser" here, IMO. But I cannot figure out how this compromise is handled in real life. I suspect there are some pretty complex equations being used which give all weight to depicting climb angle accurately up to a certain roll angle, say +/- 70 degrees (and this must, in caged mode, as far as I can tell, involve the dreaded tan function), but then weighting AoA and climb angle after that (or just dampening the tan behavior in the climb function) so that the velocity vector fudge factor (the amount of correction added to it's normal vertical displacement) doesn't zoom out to infinity, and shoot all the symbology way off the bottom of the screen. (Man, after writing that, I can't imagine it would make sense to someone who doesn't have their hands dirty in it! ;-)Anyway, I would like to replace a complicated weighting scheme with one function, if possible, to dampen tan(x) near its ends, and avoid the sign change, too. Tanh(x) can be manipulated to get me close to where I need to be. (And if it's not close enough, a piecewise using tan in the middle merged with tanh on the ends would be perfect.) There are some great F-16 HUD vids out there showing off a caged velocity vector, and they clearly suggest the compromise that must be made. I have not seen any HUD on a PC ever properly replicate this very useful mode. I used to look down on a caged VV and wonder why it was ever used, but after having come close to success and spent some time flying it, the advantages are apparent. This might be useful to some, and interesting to others:http://ntrs.nasa.gov/archive/nasa/casi.ntr..._1995117610.pdf

[Guest Patrick_Waugh]

>Man, after writing that, I can't>imagine it would make sense to someone who doesn't have their>hands dirty in it! ;-)The understatement of the year! In the future, please post comprehensive tutorials and training to avoid the need to duck tape the brain prior to reading your post. :D>I used to look down on a caged VV and wonder why it was ever> used, but after having come close to success and spent some> time flying it, the advantages are apparent.Care to post a link to a video? Can't imagine how this would be useful.

[Guest jprintz]

>>Man, after writing that, I can't>>imagine it would make sense to someone who doesn't have>their>>hands dirty in it! ;-)>>The understatement of the year! In the future, please post>comprehensive tutorials and training to avoid the need to duck>tape the brain prior to reading your post. :D>Heheh, yeah. ;-) It's understandable. I'm just not the best... "explainer." I attached a pic that might make it more clear. I'm working on the red / blue vector and ladder. Blue will always show proper AoA. For the pitch ladder to remain conformal (HUD horizon tacked onto actual scenery horizon, at proper scale), however, it cannot show true climb angle within the ladder. Red is the opposite. It shows true climb angle, but is not an indication of AoA (if thought of simply as the vertical displacement between waterline and vector... which isn't quite right, but is close.) BUT... you can probably see that if I keep rolling, the red symbology will fall off the screen. That red vector will always be on a line parallel to the horizon from the green (true) vector. And this can only be done with the tangent function, which is unbounded and shoots up to infinity, i.e., that vector and ladder will have to shoot infinitely far down below the screen as roll approached 90 degrees.Anyway, I hope I've at least shown why I need a function that's very close to tan(x) up to a certain roll angle, but trails off horizontally at the end.... like tanh(x). A max value or limits to a tan(x) based displacement lead to all kinds of weird things, so after 70 degrees or so I'm going to have to weigh AoA and a modified tanh(roll angle) kind of function. This would work beautifully. I just need that function. One that's not a long Taylor or Fourier series or whatever. >>>I used to look down on a caged VV and wonder why it was ever>> used, but after having come close to success and spent some>> time flying it, the advantages are apparent.>>Care to post a link to a video? Can't imagine how this would>be useful.>It's not at all as apparent with the F-16 HUD. It has no ghost vector, like the F/A-18, which still shows true flight path when in cage mode. Caging is useful in crosswinds, with large drift, or at low speeds (approach and landing especially), and makes undoing the crab just before touchdown easier to execute precisely.caged:

(Check out that landing!)uncaged:http://www.youtube.com/watch?v=Z3VuypkS4PI&feature=relatedhttp://forums.avsim.net/user_files/180595.jpg

[Guest Patrick_Waugh]

Not sure I see a difference or caging of the vector on the HUD in the videos. Seems it is not confined at all in either.Also, I don't remember the symbol ever being described as showing AOA. That's why there is an AOA light to the left of the HUD. :DBut you seem to know way more and no doubt have researched this. I have only flown the Marine's Harrier sim, and never seen the real F-16 up close and personal.Anyway, you could program a function to use tan() over one part of the domain and tanh() over another to get the effect you seem to be needing. In other words, choose which function you use based on bank angle.Patrick

[n4gix 4,947]

Yikes! If I didn't know better I'd think those were examples of "completely out of control flying" performed by a low-hour simpilot who somehow had his dream fulfilled and found himself in a real F16/F18... :-lol I suffered from motion sickness just watching them!!!

[Guest Patrick_Waugh]

Those 8 g's come on almost instantly. What was hilarious to me was how after pulling 8, he'd go down to 3 and it was as if he was relaxing. I have pulled 3, and it was then that I knew I would not want to be a fighter pilot, haha. Of course he has a nice g suit on. Anyway, gives you and idea of what a workout it can be. I'm sure the stealth fighter guys like that they don't have to work quiet so hard. =)

[Varmint007 2]

>In caged mode, the velocity vector is>confined to being directly below the waterline. The ladder>still rotates around the vector, however, and not the>waterline, which complicates things. Are you sure about that?From NATOPS:"In the NAV master mode, the velocityvector may be caged to the vertical center line of the HUD by the cage/uncage switch on the throttle.When it is caged, a ghost velocity vector is displayed at the true velocity vector position if that positionis more than 2

[Guest jprintz]

Yeah, I know what you mean. The difference is usually not that great. But if you watch the landings really closely, you can see that in the "caged" video, the symbol we usually call a velocity vector or flight path marker (FPM) is not portraying his actual flight path as he balloons down the runway. The FPM has been "demoted" to a climb-dive marker (CDM). (Though it's not necessarily a demotion.) I guess the winds were high that day, and there are just too many important things tacked onto that FPM to have it drifting off the HUD glass. Anyway... my problem's solved(!!)... kinda. No need for tanh(x). I just sniffed down a copy of the standards for military HUD and display symbology (MIL-STD-1787), and there are several pages of diagrams and equations devoted to exactly this FPM vs. CDM issue. It turns out that what they let be compromised by FPM caging is (sure as heck) not climb/dive angle, and not AoA, but HUD pitch ladder conformality with the outside world. So the ladder won't necessarily match up with the scenery. Surprising. But I can see how those other 2 are SO much more critical on a primary flight display. So, the solution they come up with is to initially allow the caged FPM (CDM) to drift a little bit laterally, but once that limit is reached, all error is handed off to the pitch ladder:"Unfortunately, if the CDM is to remain fixed on the vertical centerline of the HUD... , conformality between the HUD horizon line and real world horizon line cannot be maintained during high- drift / high bank-angle maneuvers. One compromise is to allow slight lateral movement of the CDM to maintain full-time horizon correlation. With such an implementation, the amount of lateral displacement becomes a function of the magnitude of the beta angle, bank angle, and angle of attack, such that maximum deflection of the CDM is achieved when [all three of them] are high." ...followed by a bunch of diagrams and equations.... most of which I think would cut our FSX framerates in half. So I will still struggle with the roll angles and high beta situations, but at least now I'll know where to make the compromises... and I don't think I'll have to use tanh(x). So... question withdrawn. ;-)

[Guest jprintz]

Hi Jon. Looking forward to that VRS Hornet! Sure looks impressive.I'm just now revisiting this caged vs. uncaged issue. (I can go months without doing a darn thing with flightsim gauges.) Anyway, though your attachments are no longer viewable, I think I know exactly the portions of the NATOPS to which you refer. However, for whatever reason, what it says in there is not actually what both video and still images show. (For anyone who's spent any time in the military, surprise, surprise, right? ;-)This video shows it perfectly, as he switches from caged to uncaged mode near the end:http://video.google.com/videoplay?docid=-5...QLqoNi8DA&hl=enThe ladder appears to rotate around the symbol we normally call the velocity vector whether it's caged (and thus "merely" a CDM) or uncaged.Also, if you look closely in the attached image, it's obvious he's in caged mode, with the ghost vector showing true flightpath (unless he's aiming for the dirt!), and to me it looks like the ladder is not referenced to the waterline, but to the CDM (or former velocity vector).So when IS the ladder referenced to the waterline? The only time I have found is when in uncaged mode and the velocity vector leaves the HUD field of view. After a couple of seconds out of the HUD FOV, the ladder then "slides" over towards the waterline, still maintaining conformality with the outside world, until the waterline "catches" it, at which point the ladder rotates around it. Once the velocity vector comes back within the field of view, the ladder slides back to and is referenced to it. (Very slick!) I have video of this somewhere. And I almost have this working, too, except that I'm not sure the benefit of adding it is worth the performance hit due to some pretty substantial trig calculations. http://forums.avsim.net/user_files/189603.jpg

[Varmint007 2]

Yup, you're right. It looks like it's not caged to the waterline at all, but rather the vertical component only (alpha). I'd sure like to see the behavior you described for sustained beta outside the HUD FOV. But I agree, it sounds a little expensive to do for a transitory thing.Awesome video, thanks. I really enjoy watching those. --Jon