How would you program a PFD (Primary Flight Display)
What you see up there is a PFD (Primary Flight Display), used for displaying the current orientation of an aircraft. Me and a friend of mine, want to program a PFD using OpenGL. However, since neither of us has a sufficient overview of OpenGL and how to program a PFD in a simple way, I was wondering if you have an idea on how to approach this task.
What do you think of using textures to anti-alialise lines and shapes?
Would you use display lists, or rearrange the viewport constantly in order to render specific regions of the PFD at a time?
Would you make use of some modelling tool like Blender or Anim8or?
Or do you maybe have a complete different idea?
I would appreciate any hint, link or comment, since I want to use this project to realy step into the OpenGL world!
Thx in advance
Best regards
Woltan
Well, being as the horizon changes slightly if ever on a PFD, you may want to have a quad with a texture on it representing the background (Horizon). I dont remember exactly how it works (its been years), but When the aircraft banks up or down you would simply move the up and down the texture.
As for the tick marks and ticks representing the wings. I would make a simple model (using polygons) representing it, and use glRotate depending on the bank of the turn. There is a lot of other stuff on there, but one thing i would make sure is to make your implementations of the different parts separate, so they dont rely on or affect each other if something goes wrong.
i hope that gives you some ideas, there are several other ways to do it, and maybe someone can come up with a better way to do the stuff above.
As for the tick marks and ticks representing the wings. I would make a simple model (using polygons) representing it, and use glRotate depending on the bank of the turn. There is a lot of other stuff on there, but one thing i would make sure is to make your implementations of the different parts separate, so they dont rely on or affect each other if something goes wrong.
i hope that gives you some ideas, there are several other ways to do it, and maybe someone can come up with a better way to do the stuff above.
Quote:Original post by AverageJoeSSU
Well, being as the horizon changes slightly if ever on a PFD
Uhh, don't turn much in planes, do we?
If I were doing this, I would use some sort of engine (read: Irrlicht, OGRE, etc.) that can do sprites, and from there it would be a simple (well, define simple, I imagine) task of setting initial positions of alpha sprites with textures on them, and when you receive events from your sim (or whatever you are creating) such as bank, and do transformations accordingly to those sprites.
Just a way that it could be handled, I'm sure there are many more.
FlyingIsFun1217
Haha,
well the last time i saw one of those things was when i was 13 years old, and i was actually using it to fly the plane. Depending on what you are applying this to, i wouldnt use something so big to program something so little.
And when i said move, i meant all it does is move slightly, or rotate slightly... its not moving in 3d space or anything like that. So when you turn, you would just rotate the Quad that the texture is on. No need for Ogre i think.
well the last time i saw one of those things was when i was 13 years old, and i was actually using it to fly the plane. Depending on what you are applying this to, i wouldnt use something so big to program something so little.
And when i said move, i meant all it does is move slightly, or rotate slightly... its not moving in 3d space or anything like that. So when you turn, you would just rotate the Quad that the texture is on. No need for Ogre i think.
This is a project that is sufficiently complex for a company to make a lot of money by abstracting it for you.
When I said Irrlicht and OGRE, I was just giving examples of engines that can do sprites. Obviously, if you can do this on your own, feel free to. It's the idea that counts here.
Best of luck!
FlyingIsFun1217
Best of luck!
FlyingIsFun1217
Quote:Original post by smitty1276
This is a project that is sufficiently complex for a company to make a lot of money by abstracting it for you.
ahhh this makes sense in context. yeah depending on how you guys render eveything else i would make a class that contains the mesh for the lil plane ticks, and then a Quad with a texture on it (Containing the horizon ticks). then have an update function which reads in your information and rotates and moves the quad accordingly and then a render function that draws it to the screen... i've never moved a texture on geomotry before but i'm sure its not that bad.
you could also have a 3d circular strip that you rotate from a point in the middle... kind of like a wheel... and that wouldnt require the texture to be moved.
EDIT: actually i like the wheel better, seems more natural if the aircraft flips around or something.
Good luck
Heyas,
first of all thx for all the postings and suggestions.
As I can see, all of you would draw, at least the horizont, with a texture mapped on a mesh. But how would go about the speed band (the left part of the PFD). It has a yellow line in the middle indicating the current speed of the aircraft. This yellow line is static and does not move. Therefore the speed band itself moves. I could think of three solutions how I would do it.
1: Have a pretty long mesh, that has the whole texture mapped on it and move that mesh vertically depending on the speeds. The borders get cut off either by a mesh that lies over the speed band or by redefining the viewport.
2: As suggested before, having a static mesh, but a texture where only parts of it are drawn on the speed band, depending on the speed.
3: Render everything "by hand". Meaning, all numbers and lines are rendered with polygons into a fbo and then mapped as a texture on the speed band. This would still make use of the textures anti-alialising effects, and would reduce the work of creating a texture since the texture is created during runtime. The difficult part is to know where to render the numbers and dashes.
I am anxiously waiting for your replys on this one.
Thx in advance!
Best regards
Woltan
first of all thx for all the postings and suggestions.
As I can see, all of you would draw, at least the horizont, with a texture mapped on a mesh. But how would go about the speed band (the left part of the PFD). It has a yellow line in the middle indicating the current speed of the aircraft. This yellow line is static and does not move. Therefore the speed band itself moves. I could think of three solutions how I would do it.
1: Have a pretty long mesh, that has the whole texture mapped on it and move that mesh vertically depending on the speeds. The borders get cut off either by a mesh that lies over the speed band or by redefining the viewport.
2: As suggested before, having a static mesh, but a texture where only parts of it are drawn on the speed band, depending on the speed.
3: Render everything "by hand". Meaning, all numbers and lines are rendered with polygons into a fbo and then mapped as a texture on the speed band. This would still make use of the textures anti-alialising effects, and would reduce the work of creating a texture since the texture is created during runtime. The difficult part is to know where to render the numbers and dashes.
I am anxiously waiting for your replys on this one.
Thx in advance!
Best regards
Woltan
OpenGL is not really practical or suited for this kind of task, so how about using a 2D library (e.g. Cairo) to draw the display and (if the rest of your application is using OpenGL) upload it as a texture.
I find text and curves a bit more difficult to do in OpenGL rather than Cairo.
Here is a screenshot from a similar project I once did using Cairo:
I find text and curves a bit more difficult to do in OpenGL rather than Cairo.
Here is a screenshot from a similar project I once did using Cairo:
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement