As I wrote the visualization system for the stand
First, first you need to say what the visualization system outside the cabin of the aircraft. This is a program that shows what the pilot sees when flying in an airplane. At the same time, I do not mean instruments and in general everything that is inside the cabin - the term “outside cabin space” is not in vain used above. Of course, it is necessary to do some of the devices, but this is a separate, much simpler task, and one can not speak about it. In the narrow sense, “visualization” is called the image of the outside cabin space, so I will speak about this.
Below is an example of what the pilot sees in my program during takeoff:
(All the examples in the future just taken from the real visualization frames of my program.)
Secondly, I did my visualization for a very real working aerobatic stand at TsAGI, where it was registered, moreover twice already. An aerobatic stand is, roughly speaking, an airplane cabin, taken separately from everything else (fuselage, wings, etc.), and placed inside a four-meter sphere, white inside. All this inner white surface of the sphere is my screen, then the screen of the visualization system eats - projectors on it, in our case there are 9 of them, project images from 9 different computers, on each of which my visualization system stands (later I will say simply - visualization, without quotes). Naturally, the visualization on all 9 computers is the same, but configured differently, roughly speaking, one field of vision is forward, one to the left, one to the right, one more down, up, etc., but that too it is clear that all of them are calculated so that their projections come as if from the same point, from the one where the operator is sitting and from, as if from his eyes, although the projectors themselves stand, of course, not there, but in different corners, where engineering managed to install them. In sum, they illuminate the entire white spherical surface from inside and show the operator, sitting in the cockpit, everything that a pilot can see in real flight - land, sky, sea, cities, rivers, mountains, railways and roads, houses, trees, pillars, stones, cars, streets, people, grass, finally, other planes (enemies, for example), rockets flying in them, clouds in the sky, fog, the sun, the moon, lights on the earth at night, stars in the sky, and much, much more. Everything that, in principle, it is possible for a pilot to see, should be visualized. This is its meaning.
Here, for example, a small piece of the military town in my program:
')
I must add that the flight itself is not my concern, that is, not the care of the visualization system. In every stand there is a host computer: it is he who is the master, controls the entire stand, sets the synchronization, supplies the visualization and other computers with all the basic current information - the coordinates of the plane (where we fly), the angles of its orientation (where we fly, where we look) control, and much more (it, for example, contains the aerodynamics of the aircraft, weight and inertia, engine characteristics, suspended or already flying missiles (own or others), coordinates of enemies and friends, time of day, visibility conditions (fog, cloudiness, clear Oh, and so on), as well as the general control of the stand (stop the experiment, continue, finish, turn off everything or, on the contrary, turn everything on.) And from it all this information is distributed across the network to all computers serving the stand, who need what. it does the “main movement model”, and the visualization only synchronizes with it, accepts the network packet and processes it - that is, ultimately it shows what the pilot (in the case of the stand operator) should see under all these conditions and parameters.
So my visualization is the working identity of our stand. And, as such, should work, first of all, steadily. In this sense, for such a visualization system, the most important thing is reliability . It is not good when the pilots come to us, and the program does not start, or hangs, or gets lost in the process, or shows errors (after all, this is visualization, so many errors are just visible): this is a breakdown of the bench experiment (or even the entire planned work), loss of time (especially pilots are pilots, they are busy people; of course, we also fly as operators (except for me now, I am disabled and cannot climb into our cockpit), but we do not have the qualifications and, accordingly, not those results and assessments. So for me the most important thing is reliability: the program should work absolutely steadily.
The second important requirement for visualization is speed, that is, the efficiency of real-time process implementation . By this is meant, roughly speaking, how many frames per second a visualization program can provide with the content that it contains (by filling, I mean everything depicted). Here, the criteria are harsh: as everyone knows in the aviation world, the most rapid-variable movement of the modern, most nimble aircraft — that is, a fighter — is the so-called “isolated roll movement”. That's what it is: everyone probably saw the fighter spinning “barrels” at the exhibition - so this is it. It rotates very quickly, it is parametrically considered that the speed of such a rotation in a modern fighter can reach 100 degrees per second, that is, it makes one revolution in about 3 seconds. At the same time, the operator will see everything rotating on the visualization, including the horizon itself, and this rotation should represent the visualization smoothly, as if it actually happened to the pilot sitting in the cabin of the flying plane. This can only be done at the expense of the rendering speed - it just has to issue the next frame so quickly that the operator in the stand would not see this frame flipping, a jump that should be so small that the operator would think that everything actually happens smooth and clean. (Well, the storyboard is probably familiar to everyone in toys.) For example, a simple movie with a standard frequency of 25 frames per second will not work here - a person will not see a smooth gradual change, but a jerk of the entire image. These considerations determine the obligatory lower limit of the frequency that the visualization should hold: it should be able to reproduce its frames no less than 100 times per second. If our department was engaged only in heavy vehicles (cargo, passenger aircraft, etc.), then these requirements would be easier - it is clear that trucks and airliners do not turn like that. But I have to focus on light aircraft (it is precisely and primarily fighters, as well as training, sport, etc.), and therefore, together with our boss, it was decided that the visualization frequency should be no less than 100 Hz. It is clear that this requirement is not constant: at landing no one will turn the “barrels”, etc., but in a difficult maneuverable flight (for example, in air combat) this frame rate is required. Therefore, it was decided by us that the visualization at the stand should have time to update its full images with a frequency of about 100 Hz. This is the most important real-time condition for visualization.
It is quite clear that such a requirement imposes very severe restrictions on the detail of the image. (I don’t say quality here, because it means either the resolution and the color of the screen, or not at all what is required of a really functioning visualization system: no one (that is, after all, a pilot) is required for me, for example on the representation of the enemy F-16 depicted slots, rivets, scratches on the metal, holes in the wings, a pleasant coloring of emblems and signs on the fuselage, the mustache of the enemy ace, visible under the helmet, etc., because our brave pilot in battle is not important - he looks not at something like that, but at something from which Avisit his victory, the execution of the task and life itself).
This is how it is necessary (and quite enough) to depict enemy F-16 - without unnecessary details that our pilot never sees, because he will never be so close:
Detail, saturation, or even image quality in visualizations refers to the degree of detail of the entire outdoor space: that is, with what measure of detail the sky (with clouds) is drawn, and, especially, the surface of the earth (with the sea, obviously, is easier), how much all kinds of mountains, forests, fields and rivers, cities, streets, villages, roads and individual houses, trees and all kinds of bushes, like grass and soil, and, finally, the most important thing is the airfield. The fact is that our department deals more with the take-off and landing modes for fighters (but not only air combat, for example, also happens), and therefore special attention and special work had to be applied to the airfields detailed and correct in all respects the land beneath them, the runway (concrete), everything that surrounds them (taxiing, hangars, tanks, other planes, etc.), and I have the most severe requirements in relation to these things. For example, on the strip, I do depict traces of previous landings, individual pebbles and spots and other trifles, but this is also a strip.
And here this restriction on the minimum speed of processing and playback of frames comes in quite understandable conflict with the requirement of image details. I can very detailed, beautiful and high-quality draw my or someone else's fighter (one), it will be just a lovely view, but what's the point? Moreover, we mainly have a takeoff and landing department. It is much more important to draw a good runway itself, the ground around (this is important, because a pilot should take an extremely accurate estimate of his height above the concrete surface (he needs centimeters) when taking off and landing) and speed - this is vital for him to sit down or take off: take-off and landing still remain the most difficult maneuvers for any aircraft (which, in fact, it is clear: it is easy to roll on concrete, this is also a motorcycle, it is also easy to fly, this is just an airplane, but neither is really hard).
Here is an example of a short / front / runway image:
Therefore, a great deal of detail and accuracy is needed here, and, moreover, there are no empty airfields around the airfield: there are always taxiways, auxiliary tracks, aircraft parking, hangars, checkpoints, all kinds of antennas and radars, there are fire stations on any airfield, All this should have access roads, railways or highways, and people should live somewhere — hence, at least a small military town, barracks, houses, shops, schools, a hospital, and they went. But it is easy to see that the farther from the airfield, the less detail we need - the pilot will never see what color the curtains are in the windows, and whether there are cacti on the windowsills.
But, takeoff is followed by the execution of the task, for example, a simple flight along a route. Here, it is clear, not pebbles and not grass are important, but already mountains, forests, rivers, cities, houses, and all this should be very nice - for everything to be as real. Here comes the time for programmer work: for example, how to draw a tree so effectively that the woods depicted from such trees contained not a thousand trees, but, say, two thousand, while the image containing it would fit into a given frequency. Or, at least, let a half thousand, is also a plus. Or, at least, at worst, one thousand one hundred. This is where a very brutal optimization is required.
It is clear that the video card does a lot, even the video path as a whole. But, as it should be even more clear, by no means all. For example, it is very easy to draw a house with details. But at some distance from him some part of the details will be lost, will not be visible. And at a great distance all the details will disappear (they will not be visible), only the bare house of the planes will remain. And at a greater distance, the house itself will hardly be visible - it will turn into a point. It is clear that the video path (starting with OpenGL in my case and the drivers, and ending with the VPU itself) will provide this projection - but at what price! It is clear that there is no need to count, transfer to the video processor and draw a lot of small details (for example, cacti on the windows, or open vents) when in fact the whole image due to the distance turns into just a point of a certain dark color. And, it should be noted, this is only the simplest example.
But talking about optimization can be long and boring, and it only needs programmers who are engaged in real-time programs, like me. It is important that there is visualization, it works well and stably at the TsAGI stand, doing various and numerous studies on it. I can add that I actually did it alone, no one helped me (except, I must say, my beloved chief), and I could not mention those who interfered, because it would take too much space. And an example, a demo version of visualization, however, is quite old, I am pleased to attach. If I have enough strength, I will try to make a new demo version, then I can show it as well - all the same since that time the visualization has grown a lot. But it should be remembered that, in general, the visualization system is a very big, really huge project, especially for one person, so you shouldn’t expect breathtaking beauties from my demo, for this there are toy companies with thousands of people working. And for my part, this project simply invested a lot of work (I have been working on visual problems for more than 30 years, since the time of the 286 processors, when there was no video and everything had to be written in assembler manually). I remember, for example, that when my favorite boss and I went to the stand for the first time to try visualization, I counted that I had already prepared it for 11 years before, even then! But in general, my visualization (which, by the way, is called Petite for modesty), everything has its merits: it really works on the stand with the pilots, works steadily, and works efficiently.
I tell all this not unfounded (and I also did not draw pictures by hand myself), and in confirmation I enclose a link to the archive with a demo version (demo) in which everyone can look at how the visualization described above works in brief. It, demo, represents something like a flight along a route: the plane starts, rises, and then flies along (but not quite) along the same route, flying around obstacles (this is also not an easy problem), rising and falling, accelerating and braking. It should be remembered that in the visualization there is not and should not be a mathematical model of the dynamics of the aircraft, so the movement itself in demo is not very smooth and beautiful, I just did a quick move then I could. There is no special control in this demo, except for the fact that by a space you can stop the flight, and by Escape you can complete and exit. Actually, this is an old demo, it is already more than 15 years old, I will do a new one when I can and if I can, but it still gives an idea of ​​what one person can do, however, for quite a few years. So here is this link . Just in case (because some servers are very suspicious and do not allow receiving and transmitting EXE files) the following link contains the same archive, but the VISUAL.E file just needs to be renamed to VISUAL.EXE. Here is this link :
Well, that seems to be all.
Below is an example of what the pilot sees in my program during takeoff:
Secondly, I did my visualization for a very real working aerobatic stand at TsAGI, where it was registered, moreover twice already. An aerobatic stand is, roughly speaking, an airplane cabin, taken separately from everything else (fuselage, wings, etc.), and placed inside a four-meter sphere, white inside. All this inner white surface of the sphere is my screen, then the screen of the visualization system eats - projectors on it, in our case there are 9 of them, project images from 9 different computers, on each of which my visualization system stands (later I will say simply - visualization, without quotes). Naturally, the visualization on all 9 computers is the same, but configured differently, roughly speaking, one field of vision is forward, one to the left, one to the right, one more down, up, etc., but that too it is clear that all of them are calculated so that their projections come as if from the same point, from the one where the operator is sitting and from, as if from his eyes, although the projectors themselves stand, of course, not there, but in different corners, where engineering managed to install them. In sum, they illuminate the entire white spherical surface from inside and show the operator, sitting in the cockpit, everything that a pilot can see in real flight - land, sky, sea, cities, rivers, mountains, railways and roads, houses, trees, pillars, stones, cars, streets, people, grass, finally, other planes (enemies, for example), rockets flying in them, clouds in the sky, fog, the sun, the moon, lights on the earth at night, stars in the sky, and much, much more. Everything that, in principle, it is possible for a pilot to see, should be visualized. This is its meaning.
Here, for example, a small piece of the military town in my program:
')
I must add that the flight itself is not my concern, that is, not the care of the visualization system. In every stand there is a host computer: it is he who is the master, controls the entire stand, sets the synchronization, supplies the visualization and other computers with all the basic current information - the coordinates of the plane (where we fly), the angles of its orientation (where we fly, where we look) control, and much more (it, for example, contains the aerodynamics of the aircraft, weight and inertia, engine characteristics, suspended or already flying missiles (own or others), coordinates of enemies and friends, time of day, visibility conditions (fog, cloudiness, clear Oh, and so on), as well as the general control of the stand (stop the experiment, continue, finish, turn off everything or, on the contrary, turn everything on.) And from it all this information is distributed across the network to all computers serving the stand, who need what. it does the “main movement model”, and the visualization only synchronizes with it, accepts the network packet and processes it - that is, ultimately it shows what the pilot (in the case of the stand operator) should see under all these conditions and parameters.
So my visualization is the working identity of our stand. And, as such, should work, first of all, steadily. In this sense, for such a visualization system, the most important thing is reliability . It is not good when the pilots come to us, and the program does not start, or hangs, or gets lost in the process, or shows errors (after all, this is visualization, so many errors are just visible): this is a breakdown of the bench experiment (or even the entire planned work), loss of time (especially pilots are pilots, they are busy people; of course, we also fly as operators (except for me now, I am disabled and cannot climb into our cockpit), but we do not have the qualifications and, accordingly, not those results and assessments. So for me the most important thing is reliability: the program should work absolutely steadily.
The second important requirement for visualization is speed, that is, the efficiency of real-time process implementation . By this is meant, roughly speaking, how many frames per second a visualization program can provide with the content that it contains (by filling, I mean everything depicted). Here, the criteria are harsh: as everyone knows in the aviation world, the most rapid-variable movement of the modern, most nimble aircraft — that is, a fighter — is the so-called “isolated roll movement”. That's what it is: everyone probably saw the fighter spinning “barrels” at the exhibition - so this is it. It rotates very quickly, it is parametrically considered that the speed of such a rotation in a modern fighter can reach 100 degrees per second, that is, it makes one revolution in about 3 seconds. At the same time, the operator will see everything rotating on the visualization, including the horizon itself, and this rotation should represent the visualization smoothly, as if it actually happened to the pilot sitting in the cabin of the flying plane. This can only be done at the expense of the rendering speed - it just has to issue the next frame so quickly that the operator in the stand would not see this frame flipping, a jump that should be so small that the operator would think that everything actually happens smooth and clean. (Well, the storyboard is probably familiar to everyone in toys.) For example, a simple movie with a standard frequency of 25 frames per second will not work here - a person will not see a smooth gradual change, but a jerk of the entire image. These considerations determine the obligatory lower limit of the frequency that the visualization should hold: it should be able to reproduce its frames no less than 100 times per second. If our department was engaged only in heavy vehicles (cargo, passenger aircraft, etc.), then these requirements would be easier - it is clear that trucks and airliners do not turn like that. But I have to focus on light aircraft (it is precisely and primarily fighters, as well as training, sport, etc.), and therefore, together with our boss, it was decided that the visualization frequency should be no less than 100 Hz. It is clear that this requirement is not constant: at landing no one will turn the “barrels”, etc., but in a difficult maneuverable flight (for example, in air combat) this frame rate is required. Therefore, it was decided by us that the visualization at the stand should have time to update its full images with a frequency of about 100 Hz. This is the most important real-time condition for visualization.
It is quite clear that such a requirement imposes very severe restrictions on the detail of the image. (I don’t say quality here, because it means either the resolution and the color of the screen, or not at all what is required of a really functioning visualization system: no one (that is, after all, a pilot) is required for me, for example on the representation of the enemy F-16 depicted slots, rivets, scratches on the metal, holes in the wings, a pleasant coloring of emblems and signs on the fuselage, the mustache of the enemy ace, visible under the helmet, etc., because our brave pilot in battle is not important - he looks not at something like that, but at something from which Avisit his victory, the execution of the task and life itself).
This is how it is necessary (and quite enough) to depict enemy F-16 - without unnecessary details that our pilot never sees, because he will never be so close:
Detail, saturation, or even image quality in visualizations refers to the degree of detail of the entire outdoor space: that is, with what measure of detail the sky (with clouds) is drawn, and, especially, the surface of the earth (with the sea, obviously, is easier), how much all kinds of mountains, forests, fields and rivers, cities, streets, villages, roads and individual houses, trees and all kinds of bushes, like grass and soil, and, finally, the most important thing is the airfield. The fact is that our department deals more with the take-off and landing modes for fighters (but not only air combat, for example, also happens), and therefore special attention and special work had to be applied to the airfields detailed and correct in all respects the land beneath them, the runway (concrete), everything that surrounds them (taxiing, hangars, tanks, other planes, etc.), and I have the most severe requirements in relation to these things. For example, on the strip, I do depict traces of previous landings, individual pebbles and spots and other trifles, but this is also a strip.
And here this restriction on the minimum speed of processing and playback of frames comes in quite understandable conflict with the requirement of image details. I can very detailed, beautiful and high-quality draw my or someone else's fighter (one), it will be just a lovely view, but what's the point? Moreover, we mainly have a takeoff and landing department. It is much more important to draw a good runway itself, the ground around (this is important, because a pilot should take an extremely accurate estimate of his height above the concrete surface (he needs centimeters) when taking off and landing) and speed - this is vital for him to sit down or take off: take-off and landing still remain the most difficult maneuvers for any aircraft (which, in fact, it is clear: it is easy to roll on concrete, this is also a motorcycle, it is also easy to fly, this is just an airplane, but neither is really hard).
Here is an example of a short / front / runway image:
Therefore, a great deal of detail and accuracy is needed here, and, moreover, there are no empty airfields around the airfield: there are always taxiways, auxiliary tracks, aircraft parking, hangars, checkpoints, all kinds of antennas and radars, there are fire stations on any airfield, All this should have access roads, railways or highways, and people should live somewhere — hence, at least a small military town, barracks, houses, shops, schools, a hospital, and they went. But it is easy to see that the farther from the airfield, the less detail we need - the pilot will never see what color the curtains are in the windows, and whether there are cacti on the windowsills.
But, takeoff is followed by the execution of the task, for example, a simple flight along a route. Here, it is clear, not pebbles and not grass are important, but already mountains, forests, rivers, cities, houses, and all this should be very nice - for everything to be as real. Here comes the time for programmer work: for example, how to draw a tree so effectively that the woods depicted from such trees contained not a thousand trees, but, say, two thousand, while the image containing it would fit into a given frequency. Or, at least, let a half thousand, is also a plus. Or, at least, at worst, one thousand one hundred. This is where a very brutal optimization is required.
It is clear that the video card does a lot, even the video path as a whole. But, as it should be even more clear, by no means all. For example, it is very easy to draw a house with details. But at some distance from him some part of the details will be lost, will not be visible. And at a great distance all the details will disappear (they will not be visible), only the bare house of the planes will remain. And at a greater distance, the house itself will hardly be visible - it will turn into a point. It is clear that the video path (starting with OpenGL in my case and the drivers, and ending with the VPU itself) will provide this projection - but at what price! It is clear that there is no need to count, transfer to the video processor and draw a lot of small details (for example, cacti on the windows, or open vents) when in fact the whole image due to the distance turns into just a point of a certain dark color. And, it should be noted, this is only the simplest example.
But talking about optimization can be long and boring, and it only needs programmers who are engaged in real-time programs, like me. It is important that there is visualization, it works well and stably at the TsAGI stand, doing various and numerous studies on it. I can add that I actually did it alone, no one helped me (except, I must say, my beloved chief), and I could not mention those who interfered, because it would take too much space. And an example, a demo version of visualization, however, is quite old, I am pleased to attach. If I have enough strength, I will try to make a new demo version, then I can show it as well - all the same since that time the visualization has grown a lot. But it should be remembered that, in general, the visualization system is a very big, really huge project, especially for one person, so you shouldn’t expect breathtaking beauties from my demo, for this there are toy companies with thousands of people working. And for my part, this project simply invested a lot of work (I have been working on visual problems for more than 30 years, since the time of the 286 processors, when there was no video and everything had to be written in assembler manually). I remember, for example, that when my favorite boss and I went to the stand for the first time to try visualization, I counted that I had already prepared it for 11 years before, even then! But in general, my visualization (which, by the way, is called Petite for modesty), everything has its merits: it really works on the stand with the pilots, works steadily, and works efficiently.
I tell all this not unfounded (and I also did not draw pictures by hand myself), and in confirmation I enclose a link to the archive with a demo version (demo) in which everyone can look at how the visualization described above works in brief. It, demo, represents something like a flight along a route: the plane starts, rises, and then flies along (but not quite) along the same route, flying around obstacles (this is also not an easy problem), rising and falling, accelerating and braking. It should be remembered that in the visualization there is not and should not be a mathematical model of the dynamics of the aircraft, so the movement itself in demo is not very smooth and beautiful, I just did a quick move then I could. There is no special control in this demo, except for the fact that by a space you can stop the flight, and by Escape you can complete and exit. Actually, this is an old demo, it is already more than 15 years old, I will do a new one when I can and if I can, but it still gives an idea of ​​what one person can do, however, for quite a few years. So here is this link . Just in case (because some servers are very suspicious and do not allow receiving and transmitting EXE files) the following link contains the same archive, but the VISUAL.E file just needs to be renamed to VISUAL.EXE. Here is this link :
Well, that seems to be all.
Source: https://habr.com/ru/post/315978/
All Articles