Як я написав систему візуалізації для стенду

По-перше, спочатку треба сказати про те, що таке система візуалізації внекабинного простору літака. Це програма, яка показує те, що бачить льотчик, коли летить у літаку. При цьому я не маю на увазі приладів і взагалі всього того, що знаходиться всередині кабіни — вище не дарма вжито термін «внекабинное простір». Робити, звичайно, доводиться частково і прилади, але це окрема, набагато більш просте завдання, і про неї не можна говорити. У вузькому значенні «візуалізацією» називається саме зображення внекабинного простору, так що я буду говорити саме про це.

Нижче наведен приклад того, що бачить льотчик в моїй програмі при зльоті. Всі приклади в подальшому як раз і взяті з реальних візуалізаційних кадрів моєї програми.



По-друге, свою візуалізацію я робив для цілком реального працюючого пілотажного стенду в ЦАГІ, де вона зареєстрована, притому вже двічі. Пілотажний стенд — це, грубо кажучи, кабіна літака, взята окремо від усього іншого (фюзеляжу, крил, і т. д.), і поміщена всередину чотириметрової сфери, білої зсередини. Вся ця внутрішня біла поверхня сфери і є мій екран, то їсть екран системи візуалізації — на неї проектори, в нашому випадку їх 9 штук, проектують зображення від 9-ти різних комп'ютерів, на кожному з яких і стоїть моя система візуалізації (надалі я буду говорити просто — візуалізація, без лапок). Природно, візуалізація на всіх 9-ти комп'ютерах одна і та ж, але налаштована по-різному, грубо кажучи, одне поле зору вперед, одна праворуч, одна праворуч, ще одне вниз, вгору, і т. д., але, що теж зрозуміло, всі вони розраховуються так, щоб їх проекції йшли як би з однієї і тієї ж точки, з тієї, де сидить і з якої і дивиться оператор, як би з його очей, хоча самі проектори коштують, природно, не там, а в різних кутах, там, де інженерно вдалося їх встановити. В сумі вони засвічують зсередини всю білу сферичну поверхню і показують оператору, який сидить у кабіні, все, що може побачити льотчик в реальному польоті — землю, небо, море, міста, річки, гори, залізні і шосейні дороги, будинки, дерева, стовпи, каміння, машини, вулиці, людей, траву, нарешті, інші літаки (ворогів, наприклад), що летять в них ракети, хмари на небі, туман, сонце, місяць, вночі вогні на землі, зірки на небі, і багато-багато іншого. Все, що в принципі можливо льотчику побачити, візуалізація і повинна зображати. У цьому її сенс.

Ось, наприклад, маленький шматочок військового містечка в моїй програмі:



Повинен додати, що сам політ — це не моя турбота, тобто — не турбота системи візуалізації. У всякому стенді є host-комп'ютер: саме він є провідним, керує всім стендом, задає синхронізацію, постачає визуализационные і інші комп'ютери всієї базової поточною інформацією — координатами літака (де летимо), кутами його орієнтації (куди летимо, куди дивимося), параметрами всього управління, і багато чого ще (в ньому, наприклад, міститься аеродинаміка літака, вага і інерція, характеристики двигунів, підвішені або вже летять ракети (свої або чужі), координати ворогів і друзів, час доби, умови видимості (туман, дощ, ясно, та інше), а також загальне керування стендом (зупинити експеримент, продовжити, закінчити, все вимкнути або, навпаки, всі включити). І з нього вся ця інформація по мережі розподіляється по всім обслуговуючим стенд комп'ютерів, кому що потрібно. Але це робить «головна модель руху», а візуалізація лише синхронізується з ним, приймає мережевий пакет і обробляє його — тобто в кінцевому рахунку і показує те, що льотчик (у разі стенду оператор) повинен побачити при всіх цих умов і параметрів.

Так що моя візуалізація — це робоча приналежність нашого стенду. І, як така, повинна працювати, в першу чергу, стійко. В цьому сенсі для такої системи візуалізації найголовніше — це надійність. Недобре, коли до нас приїжджають льотчики, а програма не стартує, або зависає, або збивається в процесі, або показує помилки (адже це візуалізація, так що багато помилок просто видно): це зрив стендового експерименту (або навіть всієї планової роботи), втрата часу (особливо льотчиків — льотчики, вони люди зайняті; ми, звичайно, теж самі літаємо як оператори (крім мене, я інвалід і забратися по драбинці в нашу кабіну вже не можу), але в нас не та кваліфікація і, відповідно, не ті результати і оцінки. Так що для мене найбільш важливе — це надійність: програма повинна працювати абсолютно стійке.

Друга важлива вимога до візуалізації — швидкість, тобто ефективність реалізації процесу реального часу. Під цим розуміється, грубо кажучи, те, скільки кадрів в секунду може забезпечити програма візуалізації з тим наповненням, яке в ній є (під наповненням я маю на увазі все зображуване). Тут суворі критерії: як відомо всім в авіаційному світі, саме быстропеременное рух сучасного самого спритного літака, тобто винищувача — це так зване «ізольований рух крену». Це ось що таке: все, напевно, бачили, як винищувач на виставці крутить «бочки» — так оце воно і є. Він крутиться дуже швидко, параметрично вважається, що швидкість такого обертання може у сучасного винищувача досягати 100 градусів у секунду, тобто він робить один оберт приблизно в 3 секунди. При цьому оператор буде бачити на візуалізації все обертається, в тому числі і сам горизонт, і цей поворот візуалізація повинна представляти плавно, так, як це відбувалося насправді для льотчика, який сидів у кабіні літака, що летить. Це може бути здійснено тільки за рахунок швидкості роботи візуалізації — вона просто повинна наступний кадр видати настільки швидко, що оператор стенді не побачив би цього перещелкивания кадрів, стрибка, який повинен бути таким дрібним, що оператору б здавалося, що все насправді відбувається плавно і чисто. (Ну, що таке розкадровка, напевно, всім знайоме з іграшок.) Наприклад, просте кіно зі стандартною частотою 25 кадрів в секунду тут не підійде — людина буде бачити не плавне поступове зміна, а смикання всього зображення. Ось ці міркування і визначають той обов'язковий нижній межа частоти, який візуалізація повинна тримати: вона повинна бути здатна репродукувати свої кадри не рідше, ніж 100 разів за секунду. Якби наш відділ займався тільки важкими машинами (вантажні, пасажирські літаки, etc.), ці вимоги були б легше — ясно, що вантажівки та лайнери так не крутяться. Але мені доводиться орієнтуватися на легкі літаки (це саме і в першу чергу винищувачі, а також тренувальні, спортивні, etc.), і тому спільно з нашим начальником було вирішено, що частота візуалізації повинна бути не нижче 100 Гц. Зрозуміло, що це вимога не постійно: на посадці ніхто не буде крутити «бочки», і т. д., але в складному маневреному польоті (наприклад, у повітряному бою) така швидкість кадрів потрібно. Тому нами було вирішено, що візуалізація на стенді повинна встигати оновлювати свої повні зображення з частотою близько 100 Гц. Це і є те найважливіше для візуалізації умова реального часу.

Абсолютно ясно, що подібна вимога накладає досить суворі обмеження на детальність зображення. (Я не кажу тут якість, тому що під цим розуміється або вирішення і кольоровість екрану, або взагалі не те, що потрібно від реально функціонуючої системи візуалізації: нікому (тобто, врешті-решт, льотчику) не потрібно, щоб я, наприклад, на виставі ворожого F-16 зображував щілини, заклепки, подряпини на металі, пробоїни в крилах, приємну розмальовку емблем та символів на фюзеляжі, вуса у ворожого аса, видимі під шоломом і пр., тому що нашому бравому льотчику в бою важливо не це — він дивиться не на що-небудь таке, а те, від чого залежить його перемога, виконання завдання та сама життя).

Ось як треба (і цілком достатньо) зображати ворожий F-16 — без зайвих подробиць, які наш льотчик ніколи не побачить, оскільки ніколи не виявиться так близько.



Під детальністю, насиченістю, або навіть нехай якістю зображення в візуалізаціях розуміється ступінь деталізації всього внекабинного простору: тобто якою мірою подробиці намальоване небо (з хмарами), і, особливо, поверхня землі (з морем, очевидно, легше), скільки на ній всяких гір, лісів, полів і річок, міст, вулиць, сіл, доріг і окремих будинків, дерев та різних кущів, як зображено трава і грунт, і, нарешті, найважливіше — аеродром. Справа в тому, що наш відділ займається більше злітно-посадочними режимами для винищувачів (але не тільки, повітряний бій, приміром, теж буває), і тому особливу увагу і особливий працю належало докласти саме до докладного і правильному у всіх відносинах зображенню аеродромів, землі під ними, злітної смуги (бетонки), всього, що їх оточує (руління, ангари, баки, інші літаки, etc.), і вимоги по відношенню до цих речей у мене насправді найсуворіші. Наприклад, на смузі я дійсно зображую сліди попередніх посадок, окремі камінчики і плями та інші дрібниці, але так це ж смуга.

І ось тут це обмеження на мінімальну швидкість обробки і відтворення кадрів вступає в цілком зрозумілий конфлікт з вимогою подробиці зображення. Я можу дуже докладно, красиво і якісно намалювати свій чи чужий винищувач (один), буде просто чудово, але що в цьому сенс? Тим більше, що у нас в основному злітно-посадковий відділ. Набагато важливіше добре намалювати саму злітну смугу, землю навколо (це важливо, тому що льотчик при зльоті і посадці повинен мати можливість надзвичайно точно оцінювати свою висоту над бетонкой (тут йому сантиметри потрібні) і швидкість — це життєво важливо для того, щоб сісти або злетіти: зліт і посадка досі залишаються труднейшими маневрами для будь-якого літального апарату (що, взагалі-то, зрозуміло: котитися по бетонці легко, це і мотоцикл вміє, летіти теж нескладно, на те це і літак, а от щось проміжне, ні те ні інше — дійсно важко).

Ось приклад зображення короткої/прифронтовій/злітної смуги:


Тому тут потрібна велика особливо детальність і точність, так і, крім того, навколо аеродрому порожнім не буває: завжди є і руліжні доріжки, допоміжні шляху, стоянка для літаків, ангари, КПП, всякі антени і радари, на будь-якому аеродромі є пожарки, до всього цього повинні бути під'їзні шляхи, залізничні або шосе, і де-то повинні жити люди — стало бути, хоча б невелике військове містечко, казарми, будинки, магазини, школи, лікарня, і пішло-поїхало. Але, легко помітити, що чим далі від аеродрому, тим менша подробиця нам потрібна — льотчик ніколи не побачить, якого кольору фіранки на вікнах і є на підвіконнях кактуси.

Але, за зльотом слід виконання завдання, наприклад, простий політ за маршрутом. Тут, це зрозуміло, важливі не камінчики і не трава, а вже гори, ліси, річки, міста, будинку, і цього всього має бути пребагато — щоб все було по-справжньому. Ось тут і настає час программистской роботи: наприклад, як намалювати дерево настільки ефективно, щоб зображуваний з таких дерев лісок містив не тисячу дерев, а, скажімо, дві тисячі, при тому що містить його зображення вкладалося б у задану частоту. Або, хоча б, нехай півтори тисячі, теж плюс. Або, хоча б, на худий кінець, тисячу сто. Ось тут і потрібно дуже жорстока оптимізація.

Зрозуміло, що багато чого робить відеокарта, навіть видеогенный тракт в цілому. Але, як це ще більше має бути зрозуміло, аж ніяк і принципово не всі. Наприклад, дуже просто намалювати будиночок з подробицями. Але на деякій відстані від нього якась частина подробиць пропаде, буде не видно. А на великій відстані пропадуть (не видно) всі подробиці, залишиться тільки голий будиночок з площин. А на ще більшій відстані майже не буде видно і сам будиночок — він перетвориться на точку. Зрозуміло, що відеотракт (починаючи з OpenGL в моєму випадку і драйверів, і кінчаючи самим VPU) забезпечить цю проекцію — але якою ціною! Ясно, що нема чого розраховувати, передавати на відеопроцесор і малювати масу дрібних подробиць (наприклад, кактуси на вікнах, або відкриті кватирки) тоді, коли на ділі все зображення через дальності перетвориться в просто точку якогось темного кольору. І, слід зауважити, що це лише найпростіший приклад.

Але розповідати про оптимізацію можна довго і занудно, а потрібно це тільки програмістам, які займаються програмами реального часу, на зразок мене. Важливо те, що візуалізація є, вона добре і стійко працює на стенді ЦАГІ, на ній проводячи різні і численні дослідження. Можу додати, що робив я її фактично поодинці, мені ніхто не допомагав (крім, мушу зауважити, мого улюбленого начальника), а тих, хто заважав, я тут не можу згадувати, бо це зайняло б занадто багато місця. А приклад, демонстраційний варіант візуалізації, правда, досить старий, я з задоволенням додаю. Якщо вистачить сил, постараюся зробити і новий варіант demo, тоді зможу показати і його — все-таки з того часу візуалізація сильно підросла. Але слід пам'ятати, що, взагалі-то, система візуалізації — це дуже великий, прямо-таки величезний проект, особливо на одну людину, тому від мого demo не слід чекати запаморочливих краєвидів, для цього є іграшкові фірми, де працюють тисячі людей. А з моєї сторони цей проект просто вкладено дуже багато праці (я займаюся візуальними проблемами понад 30 років, ще з часу 286-х процесорів, коли ніяких видеосредств не було і все доводилося писати на асемблері вручну). Я, от наприклад, пам'ятаю, що, коли ми з моїм коханим начальником перший раз пішли на стенд пробувати візуалізацію, я порахував, що до цього я її готував вже 11 років, вже тоді! А взагалі-то у моєї візуалізації (яка, до речі, так і називається, для скромності — Petite), все є свої переваги: вона реально працює на стенді з льотчиками, працює стійко, і працює ефективно.

Все це я розповідаю не голослівно (і картинки я теж не сам від руки малював), і ось на підтвердження додаю посилання на архів з демонстраційною версією (demo), в якій кожен може подивитися, на те, як працює коротко описана вище візуалізація. Воно, demo, зображує щось на зразок польоту за маршрутом: літак як би стартує піднімається, і далі летить приблизно (але не зовсім) по одному і тому ж маршруту, облітаючи перешкоди (це теж не проста проблема), піднімаючись і опускаючись, розганяючись і тормозясь. Слід пам'ятати, що у візуалізації немає і не повинно бути математичної моделі динаміки літака, тому саме рух в demo не дуже плавне і гарне, я просто на швидку руку зробив, що міг. Ніякого особливого управління у цьому demo немає, за винятком того, що по прогалині можна зупинити політ, а за Escape'у завершити і вийти. Взагалі-то це demo старий, йому вже більше 15 років, нове я зроблю, коли зможу і якщо зможу, але все ж воно дає уявлення про те, що може зробити одна людина, правда, за досить багато років. Так що ось ця посилання. На всяк випадок (тому що деякі сервери дуже підозрілі і не допускають прийом-передачу файлів EXE) в наступному посиланню міститься той же архів, але файл VISUAL.E потрібно просто перейменувати в VISUAL.EXE. Ось і ця посилання:

Ну, ось, здається, і все.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.