Archived

This topic is now archived and is closed to further replies.

Guest ridgell

Stubborn compass tape in a hud

Recommended Posts

i am wanting the compass tape to rotate with the horizon-line,used; (A:PLANE HEADING DEGREES MAGNETIC, Degrees)(A:PLANE BANK DEGREES,radians) but the tape inverts and does not rotate at all.why? same routine rotates every other component of the hud.(without the rotate the tape behaves well, but...)

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Have you tried removing the mask to see what is going on?Not sure, but maybe you can't rotate the mask in this way. Could also try puting the mask and image in separate elements.

Share this post


Link to post
Share on other sites

i do not believe it is the mask.the mask is round ( like the real projection area of a hud) i am rotating the vertical items ( the pitch ladder) useing the same mask.my pitch ladder is to scale meaning it shows 10 degrees of pitch at 10 degrees up vs the fs9 world. i had to break up the pitch ladder into 3 parts to accomodate such a huge vertical picture. a trick i learned from 'jprintz' who made a beautiful f-18 hud.i was (in the code above) trying to rotate a 2000 bit picture.but since it is shifted before it is rotated the axis points are screwy.it rotates fine if i the shift part. after messing with it some more i have decided to make the compass to scale, that will require breaking it up into 3 pieces as well. then rather then use item value= i will use a scale X = .that is the method i used to manage the pitch ladder which is shifted to accomodate pitch, shifted again to accomodate alpha & beta, AND then rotated. im hoping that will work. but first i have to redraw the compass tape. if it does not ill pull a 'schwarzenegger' (i'll be back)

Share this post


Link to post
Share on other sites

>i do not believe it is the mask.>the mask is round ( like the real projection area of a hud) >i am rotating the vertical items ( the pitch ladder) useing>the same mask.I don't either, but removing it would let you see all of the tape, but I have figured out your problem below.>my pitch ladder is to scale meaning it shows 10 degrees of>pitch at 10 degrees up vs the fs9 world. i had to break up the>pitch ladder into 3 parts to accomodate such a huge vertical>picture. a trick i learned from 'jprintz' who made a beautiful>f-18 hud.>>i was (in the code above) trying to rotate a 2000 bit>picture.>but since it is shifted before it is rotated the axis points>are screwy.>it rotates fine if i the shift part.There's your problem, you have exceeded the limits for the size of the BMP. There is no need to have such a big BMP, as the distance between your scale lines on the tape, can be any distance you define apart, and then you scale the FS variable to meet your scale. To have such a big BMP just creates more work for FS, and slows your sim unnecessarily. In this case it will not even work.> after messing with it some more i have decided to make the>compass to scale, that will require breaking it up into 3>pieces as well. then rather then use item value= i will use a>scale X = .Bad plan. Use the smallest bmp's you can to maximize performance.>that is the method i used to manage the pitch ladder which is>shifted to accomodate pitch, shifted again to accomodate alpha>& beta, AND then rotated. im hoping that will work. but first>i have to redraw the compass tape. if it does not ill pull a>'schwarzenegger' (i'll be back) Good luck

Share this post


Link to post
Share on other sites

Hi,I tried .bmp's too, but didn't succeed.Now i use text only and that works ok.There is already somewhere here an older discussion.Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

sigh ! the hud guru himself says it can not be done. jan, do you have a method for makeing the string track?if i just use strings in a static place where the numbers change to reflect headings it looks 'cheezy' seems 'without having tried' that you would encounter the same axis problem string or bitmap.

Share this post


Link to post
Share on other sites

PATRICKyour belief is certainly the predominant one.most HUDs are actually transparent attitude indicators.the first scaled HUD i came across was by jprintz,the coding was very complex, and he did not use registers or macros. he also coded to keep the horizon on the horizon at all altitudes. which is not accurate. at 30000ft the horizon is 500+ miles away and undiscernible.i threw snipets of his coding up in the forum looking for shorter versions. his HUD was a stand alone cockpit.(no cockpit). he was less then thrilled at having his work critiqued by some of the code gurus, but in spite of all that. his scaled HUD was BEAUTIFUL!i can not go back. the spatial reality increase from a HUD in scale is pretty impressive. the tree or bridge under the -005 pitch line is still on the -005 pitch line when you push the nose on it, or the house 15' port is still 15' port when you jink over. even if you have to leave off many of the bells and whistles and stick to basic components. he also wrote a really nice premier in the manual for his HUD. for those of use who are ?technically challenged? or who work more from diligence then skill or programming ability would do well to read it. he gets very detailed about the visual references of fs9. and how most cockpits are (and look) just pasted onto the screen without regard to scale. my $00.02

Share this post


Link to post
Share on other sites

Hi ridgell. Sound like maybe you're trying to do an A-320 HUD or something like that, where the heading tape IS the horizon line? That's going to be a complex series of shifts and rotates, which I have never tried, but i'm certain it's possible, because some French team did it. The heading degrees were almost but not entirely to scale, also. It was really very nice work. (I'll just have to try to remember where it was that I saw it!) It was not XML though, so even if I can ultimately point you to it there's no way to get hints from the code.About your horizon and all the shifts and rotates necessary... keep hammering away. There is a waypoint "tadpole" in my F-16 HUD which took something like 9 or 10 shifts / rotates to get it even close to its action in reality. (It floats around with the vector (3 operations, or elements), shifts across it based on bearing to waypoint (1 op.), rotates to point to the waypoint (1 op.), and, finally, it's always in a position where a line between it and the vector is parallel to the horizon (that's 2 more trig ops). And then... some of those shifts and rotates have to be undone. (2 or 3 more ops.) Crazy. And it is still not entirely correct! My point with all of that: you'd be surprised at what can be done with a little experimentation (i.e., pulling of hair ;-) ... and the order of those shifts and rotates is (obviously) extremely important, and what I had to tinker with the most. Oh, and the horizon shifting with altitude thing... this is difficult to explain in detail, but i'll try, because i've been exactly where you are with it. First, the amount of shifting is done by the "guts" of the sim, not HUD code. The HUD is focussed at infinity, and the HUD horizon (as I know you know)just demarcates the point of level flight. Naturally then it shifts up with altitude. The extent of the shift... well, I measured this once and the extent to which it's shifted up in the sim was like 1.4 times the amount in reality or something like that... (5 degrees at 30K feet, as I recall?). But againb, the extent to which it does shift up with altitude is set by the sim, not HUD code. And I for one would be VERY hesitant to mess with that operation. (I once did anyway. ;-) Why the hesitation now? Well.... your longitudinal axis must always be at the same point on the screen, as must your waterline, since only rebuilding the aircraft in flight could change them (heheh)... and 1 degree worth of pitch is always the same, no matter the altitude... as is 1 degree worth of vector displacement... so, since it's not just the HUD horizon but the sim's internal longitudinal axis that's shifting up with altitude (that's the important part), it's pretty easy to see how artificially messing with that HUD horizon shift throws off the balance and relationship between those 3 things - axis, pitch, flight path. (And I consider those to be the most fundamental things in a HUD.)I do know exactly what you're talking about and the problem you wish to overcome, only because it annoyed the #### out of me for awhile and I tried to "fix" it once, but I soon realized there was no way to do so without ultimately fudging on either axis position, pitch ladder displacement WRT the real axis, or vector displacement WRT the real axis... all very bad things, IMHO!!Anyway, good luck with your horizon / heading tape. I'll try to dig up where it was I saw that Airbus HUD. Thanks for the kind words too, and ####, don't ever feel like you're "critiquing." Seriously. 90 percent of us on here are amateurs who do this stuff part time, for fun, so how seriously can it be taken? I for one have plenty of other things to take way more seriously. ;-)Scott

Share this post


Link to post
Share on other sites

Ridgell,The size of the bitmap shouldn't be a factor.Did you try shifting with (A:PLANE HEADING DEGREES MAGNETIC, Degrees) dnorOr using with instead of ?Tom

Share this post


Link to post
Share on other sites

minus the dnor that is what i used.like i said it rotates like a champ without the shift.so it is not the size.it has got to be the axis. unless it is the mask that rotates and only the image contained within. if i am at the edge of the tape and the axis is set up for the midline...it would be like a needle on a regular gauge. i went through a LOT of trouble to get the pitch in scale, i was using the CustomDraw Name="fs9gps:rose to give the HUD a different look. i am doing a saab Viggen cockpit. the Swedes have a foot in both Warsaw and NATO standards...gauges spin backwards with zero at the bottom. having never seen a Viggen HUD i created a cross between a French mirage HUD and made up the rest...year later i find a video of a Viggen HUD! and back to the drawing board i went. after my initial failure, & all hope of a 5 minute fix out the window, i decided to scale the compass. a degree is a degree and i had the scale worked out on the pitch ladder. to my thinking it should work the same as the pitch later. Just finished the 1st set in light color

Share this post


Link to post
Share on other sites

At the risk of stirring up a hornet's nest, I would say don't worry so much about vectors vs. bitmaps, quite frankly. I did a basic vector HUD (ladder, vector, compass), and while there is a very nice crispness to the pitch ladder lines, the one BIG benefit which I somehow assumed vectors would bring (elimination of the dark jagged edges which appear on some symbology and text) was nowhere to be found. (My fault for assuming I suppose!) And the BIG downside to vectors is that, if you're modeling a real-life, "busier" type of HUD, and you're trying to make it REALLY look like the real one, you can get a type of authenticity with bitmaps that you're extremely unlikely to get with vector drawings (at least without some SERIOUSLY dedicated effort... and I do mean really massive investments of time). Take the F-16 HUD pic I've attached, for example... I contemplated doing my F-16 HUD with vectors, but... do you know how many vector drawing elements that would take, even considering the blatantly obvious shortcuts? A TON. One for each dash in each of the altitude, heading and airspeed tapes, to start. Then for the dashed and slanted negative pitch ladder (where each rung has a different slope)... forget about it. Absolutely nightmarish. Just to be clear though, there's no denying the benefits in crispness that vector drawings bring, and for a less involved HUD (or even the main horizon line and some of the pitch ladder lines in a busier one), I would not hesitate to use them. But for something really involved, for me (at last until vectors get rid of those dark jaggies -- any chance of this in FSX???), their benefits just do not outweight the cost, IMO.And now, let the flaming commence.... ;-)

Share this post


Link to post
Share on other sites

Hi,You are right about the not optimal look of the cifers, but they pitch, shift and rotate as they should.I don't have the code available here, but it looks like:"heading" code 10 -important!valuescompassbankthe limits,"mask""heading" code important!valuescompassbankthe limits,"mask""heading" code 10 +important!valuescompassbankthe limits,"mask"pitchy=".."Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

You misunderstand my post.You can have what you are calling "correct scale" without having to have the bmp any particular size.For example, my attitude heading reference system lines up 1 for 1 with the pitch and bank. You bank 5 or 10 degrees, and you'll see you line up with the 5 or 10 degree marks that are at exactly that angle off plumb. Same with pitch.The distance between pitch lines is completely arbitrary, and up to you. You just move the tape as far as you need per degree. If you want to do 1:1, then you have to use bigger bmp's, or smaller instruments. Since you are doing a HUD which amounts to a large instrument, I'd use a larger scale, and that way I could use a smaller bmp.Just my .02 cents.

Share this post


Link to post
Share on other sites

>The distance between pitch lines is completely arbitrary, and>up to you. You just move the tape as far as you need per>degree. If you want to do 1:1, then you have to use bigger>bmp's, or smaller instruments. Since you are doing a HUD>which amounts to a large instrument, I'd use a larger scale,>and that way I could use a smaller bmp.Well, actually that's not true; The distance between pitch lines is only "arbitrary" on incorrectly modeled HUDs. Each pitch line should represent exactly the angular section of sky it's labeled for. i.e. 5 degree pitch lines should represent 5 degrees of FS "sky" each, and therefore be a specific number of pixels apart. This is how real HUDs are modeled. Simply scaling the translation so some arbitrarily spaced lines are correct when 0 degrees is level and 90 degrees is vertical is not correctly modeling a HUD as these separations will no longer represent correct angles. Pitch lines are used to correlate to velocity vectors, target symbology and many other elements which directly relate to the outside world.--Jon

Share this post


Link to post
Share on other sites

>>>The distance between pitch lines is completely arbitrary,>and>>up to you. You just move the tape as far as you need per>>degree. If you want to do 1:1, then you have to use bigger>>bmp's, or smaller instruments. Since you are doing a HUD>>which amounts to a large instrument, I'd use a larger scale,>>and that way I could use a smaller bmp.>>>Well, actually that's not true; The distance between pitch>lines is only "arbitrary" on incorrectly modeled HUDs. Each>pitch line should represent exactly the angular section of sky>it's labeled for. i.e. 5 degree pitch lines should represent 5>degrees of FS "sky" each, and therefore be a specific number>of pixels apart. This is how real HUDs are modeled. Simply>scaling the translation so some arbitrarily spaced lines are>correct when 0 degrees is level and 90 degrees is vertical is>not correctly modeling a HUD as these separations will no>longer represent correct angles. Pitch lines are used to>correlate to velocity vectors, target symbology and many other>elements which directly relate to the outside world.>>--JonJon,It is simple math, and you have reified one scale is all. See you are thinking the arc length is from the CG of the aircraft. What you forget is the real center is the gyro. So the arc length the distance measures is really from the center of the gyro in any case. It is measuring degrees of rotation.Imagine that I surround your aircraft with a large transparent ball, and mark off your degrees of "sky" for you. That would unwrap to one size of bmp.Now imagine I double, or half the size of the ball. The bmp would double, or half, but the angle measured is the same.Same principle. The distance between the lines on each of those balls is going to be very different, but measure the same arc.So, why use twice the size ball, when you get the same effect. In other works, there would be no apparent difference to you in the cockpit.Patrick

Share this post


Link to post
Share on other sites

>Jon,>>It is simple math, and you have reified one scale is all. See>you are thinking the arc length is from the CG of the>aircraft. What you forget is the real center is the gyro. So>the arc length the distance measures is really from the center>of the gyro in any case. It is measuring degrees of>rotation.>>Imagine that I surround your aircraft with a large transparent>ball, and mark off your degrees of "sky" for you. That would>unwrap to one size of bmp.>>Now imagine I double, or half the size of the ball. The bmp>would double, or half, but the angle measured is the same.>>Same principle. The distance between the lines on each of>those balls is going to be very different, but measure the>same arc.>>So, why use twice the size ball, when you get the same effect.> In other works, there would be no apparent difference to you>in the cockpit.>>PatrickPatrick, It's possible we're talking about two different things here, and if so, I apologize for the confusion, but it sure sounds like you're saying the distance between the lines in a HUD pitch ladder can be arbitrary. If so, I continue to disagree:) If we're both talking about arcs, and we're both talking about pitch lines in a HUD, then there can only be one correct scale (pixels between lines) for a given resolution and FOV. While FS will properly scale the element for resolution, it won't hold up if the FOV changes.As far as the reference position (CG, or gyro), it's really neither here nor there, since the reference for a HUD is always the longitudinal axis, waterline, boresight, or whatever term happens to suit your particular branch of aviation. Again, this is why I think I may have missed something, since surely you'd have to agree with that:)--Jon

Share this post


Link to post
Share on other sites

There's nothing to flame, I think we're just either not communicating our concepts correctly, or not paying attention. I'll be happy to digress if I've misinterpreted anything. But I have been doing HUDs for a long time, and I think I may have helped you with your Hornet HUD way back there somewhere.The problem you describe of achieving crispness while maintaining detail can be solved partially by using custom fonts. For example you can design a font in which a single character represents any level of detail .The picture illustrates what I mean. Note the curved pitch lines and particularly the circular, 10 degree AIM-120 visual envelope which has dashed lines. That circle and the pitch lines are each single characters in a custom font. They not only render faster than large bitmaps, they can be adjusted for hue, brightness, or anything else you can do with a vector - on the fly.The fonts can also be forced to anti-alias only above some specified fontsize (i.e. you can eliminate anti-aliasing which contributes to those nasty back artifacts you were talking about).I also hope FSX provides better facilities for HUD, particularly transparency of vectors over the rendering port.--Jonhttp://forums.avsim.net/user_files/153002.jpg

Share this post


Link to post
Share on other sites

That's a nice looking HUD John! Yes, I've seen it before. ;-) We did have a long discussion about velocity vectors probably a year ago or something, when I was having headaches experimenting with all different kinds of variables for vector displacement (velocity world, velocity body, AoA, Beta, etc....) I think you advocated the alpha and beta method (????), but, to be honest, I found the velocity world and velocity body variables much more suitable for a true velocity vector.About the vector vs. bitmap thing, it doesn't really have to be a "vs." thing, IMO. You've communicated the advantages of vectors quite well, I for one certainly agree with them(!), and I think only a fool would argue those points. Your HUD definitely has a nice crisp look to it. On the other hand... if I were going to be completely honest (and this is in no way meant as a slam against you), I would say that it also demonstrates my previous point, in that it suffers from the very thing I mentioned earlier about authenticity - while in your pic all the elements are there, and they all look good and I'm sure function properly on their own, something about the "whole" of it just really doesn't seem to match the look and feel of the real Hornet's HUD. (See attached pic... not the best one, but still....) The scale or spacing or relation between the elements has just not been duplicated. And I don't see my comment as a slam against you because... that would be EXTREMELY difficult to do with vectors!!! That is my point. I'm sorry for saying the above outright, and hope you won't take it too personally, but again, I say it only to illustrate how very hard it would be to capture that "whole" with vector drawings. I know you even went to the trouble of creating custom fonts, etc., for the draw elements, and that is admirable to say the least. But what would the rest of us mere mortal, part-time people have to do to capture that "whole", if the full-time programmers and forum gurus are having such headaches?!?! ;-) Could someone theoretically do a vector HUD that looked almost exactly like the real (complex) one they're modelling? Yes. Would it be difficult? Yes. Would it be EXTREMELY difficult? Yes. Would it be "advantages not worth the disadvantages" difficult? IMO... yep.Scotthttp://forums.avsim.net/user_files/153003.jpg

Share this post


Link to post
Share on other sites

>Same principle. The distance between the lines on each of>those balls is going to be very different, but measure the>same arc.Pardon me for jumping in here, but it seems that you are both saying correct things from your own points of view... ;)Stick, consider this from a different perspective for a moment. A HUD is primarily a VISUAL reference, and secondarily an INFORMATIONAL reference...One of the chief benefits of a HUD is that from the pilot's eyepoint, the angle depicted on the pitch ladder should be precisely calibrated to represent that same arc angle in the outside view.That means, assuming the a/c is in level flight, that if there is a target at 12 o'clock and 10

Share this post


Link to post
Share on other sites

I have to agree with all the above with the possible exception of the eye angle through the HUD, but I suppose this depends on the HUD.The pitch ladders on the ones I have flown (AV-8B) weren't calibrated in the way you describe. The HUD is actually pretty darn small in comparison to the bubble of the cockpit.But I think mainly we were talking about different things.

Share this post


Link to post
Share on other sites

oh goodie! code! i will see if your snippet is informative enough for me to get behind the wheel. i did get the thing working; shifting, rotating, etc. in bitmaps.@heading 60 <@heading 30 - /-/l3where l3 = (A:PLANE BANK DEGREES,radians) @heading will get stuffed into a reg. when i optomizenext dilema; where to put it? http://www.novelair.com/forum/(viggen movie link) looks like it rides between the 00 and -02 pitch lines

Share this post


Link to post
Share on other sites

Hi Scott,Yes, you're correct in that the size of individual elements in my HUD are not the same as the real thing. For instance text is proportionately larger. However this is by design, and not a result of lack of information. The reason is that real HUDs are much larger and brighter than those which must be integrated into FS panels. One must consider the readability at the reduced scales, particularly in contrast to things like a bright FS sky which unfortunately must share the same luminosity as the HUD being modeled.If the HUD were fullscreen it would be much easier to remain true to the original proportions while maintaining readability. But IMO, it's just not readable otherwise. It's certainly not difficult to create font vectors which exactly match the RL counterparts.--Jon

Share this post


Link to post
Share on other sites

ridgell,You may want to nose around this site: http://www.patricksaviation.com. There are many HUD videos on it, and I THINK I recall seeing a Viggen HUD video on there at some point, but am not positive.

Share this post


Link to post
Share on other sites

thanks for the tip Scott.i am a big fan of Patrick

Share this post


Link to post
Share on other sites

Hi,I use very often something like:Your bitmap valuesbitmap1 Luminousbitmap1 Brightbitmap2 etc.your rotate valuesWorks perfect and saves a lot of code.Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites