[Из песочницы] Как я написал систему визуализации для стенда
Ниже дан пример того, что видит летчик в моей программе при взлете. Все примеры в дальнейшем как раз и взяты из реальных визуализационных кадров моей программы.
Во-вторых, свою визуализацию я делал для вполне реального работающего пилотажного стенда в ЦАГИ, где она и зарегистрирована, притом уже дважды. Пилотажный стенд — это, грубо говоря, кабина самолета, взятая отдельно от всего остального (фюзеляжа, крыльев, и т.д.), и помещенная внутрь четырехметровой сферы, белой изнутри. Вся эта внутренняя белая поверхность сферы и есть мой экран, то ест экран системы визуализации — на нее проекторы, в нашем случае их 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. Вот и эта ссылка:
Ну, вот кажется, и все.
Комментарии (7)
napa3um
23 ноября 2016 в 19:55
+9↑
↓
> Но рассказывать об оптимизации можно долго и занудно, а нужно это только программистам, которые занимаются программами реального времени, вроде меня.Это придало бы хоть какой-то смысл данной статье на Хабре.
perfect_genius
23 ноября 2016 в 20:37
0↑
↓
Могли бы рассказать про самые нагруженные моменты и как удалось их оптимизировать. Пришлось ли браться за ассемблер? И как вообще синхронизировали 9 отдельных экранов — у них у всех железные 100 кадров? Как они общаются между собой? Сколько уровней детализации объектов применили?
Что думаете про VR-шлемы — четырёхметровые белые шары не устарели ли с их появлением?
kosmos89
23 ноября 2016 в 21:42
+3↑
↓
Какой ассемблер в 2016 году? Это пустая трата времени. Если что и тормозит, то либо GPU, либо API overhead. И ассемблер в обоих случаях не поможет. Тут проблемы другого плана.
23 ноября 2016 в 21:49
+1↑
↓
В своё время это называли — «закабинка».Интересно, по какой причине был выбран вариант реализовывать подобную систему «с нуля»? Задача в полном развороте очень большая. Нужны и объекты с LOD’ами (как визуализация, так и редактор), и динамическая подгрузка для больших территорий, и автогенерация земли, погода/дожди/туманы, посадочные огни (отдельная проблема), звук с Допплером и многое другое.
Сейчас существует достаточно много систем визуализации — хороших и разных. При больших деньгах — тот же Транзас или Presagis, для малого бюджета — X-Plane или Prepar 3D. С открытым кодом есть flightgear (хотя с ним практически не знаком).
Я не умаляю Вашей работы, но на задачу визуализацию одного человека маловато.
23 ноября 2016 в 22:00
+1↑
↓
Дилетантский вопрос: почему нельзя это сделать на условном Unity / Unreal Engine?23 ноября 2016 в 22:40
0↑
↓
Задачи разные.Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.
Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.
Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.
bak
23 ноября 2016 в 23:05
0↑
↓
На дворе 2016 год. 2016, Карл! То что у вас на скриншотах — это уровень компьютерной графики 20-летней давности. Такую визуализацию пишут студенты 2-го курса в качестве курсовой по openGL-ю, причем плохие студенты, которые не знаю что такое шейдеры, lod-ы, карты нормалей и прочие основы. Примеры уровня графики, которая должна быть у любого уважающего себя симулятора в 2016: раз, два.
Даже с учетом того, что проект писался в одиночку — слабовато. Тем более когда есть очень простые способы существенно поднять качество картинки.
