Comments 38
> Но рассказывать об оптимизации можно долго и занудно, а нужно это только программистам, которые занимаются программами реального времени, вроде меня.
Это придало бы хоть какой-то смысл данной статье на Хабре.
Это придало бы хоть какой-то смысл данной статье на Хабре.
Хотя визуализация и графика меня не очень интересует, но где-то пару лет назад на Хабре была статья про оптимизацию отрисовки, что даже мне очень понравилась. А здесь слишком много общего(для меня, как человека, не занимающегося визуализацией, трудно оценить выполненную работу), и я должна поверить в дважды повторяющуюся фразу в посте
визуализация есть, она хорошо и устойчиво работает на стенде ЦАГИ
.
Могли бы рассказать про самые нагруженные моменты и как удалось их оптимизировать. Пришлось ли браться за ассемблер? И как вообще синхронизировали 9 отдельных экранов — у них у всех железные 100 кадров? Как они общаются между собой? Сколько уровней детализации объектов применили?
Что думаете про VR-шлемы — четырёхметровые белые шары не устарели ли с их появлением?
Что думаете про VR-шлемы — четырёхметровые белые шары не устарели ли с их появлением?
Какой ассемблер в 2016 году? Это пустая трата времени. Если что и тормозит, то либо GPU, либо API overhead. И ассемблер в обоих случаях не поможет. Тут проблемы другого плана.
VR-шлемы для таких задач не особо подходят. Здесь вопрос создания максимально правдоподобного окружения для лётчика — кабина железная с кнопочками и пимпочками, а описанная в статье визуализация предназначена исключительно для имитации закабинной обстановки.
Тактильные ощущения от кнопочек и пимпочек пока VR-технологиями симитировать не удаётся.
Тактильные ощущения от кнопочек и пимпочек пока VR-технологиями симитировать не удаётся.
С удовольствием расскажу, если будет шанс.
Будет время, расскажу.
В своё время это называли — «закабинка».
Интересно, по какой причине был выбран вариант реализовывать подобную систему «с нуля»? Задача в полном развороте очень большая. Нужны и объекты с LOD'ами (как визуализация, так и редактор), и динамическая подгрузка для больших территорий, и автогенерация земли, погода/дожди/туманы, посадочные огни (отдельная проблема), звук с Допплером и многое другое.
Сейчас существует достаточно много систем визуализации — хороших и разных. При больших деньгах — тот же Транзас или Presagis, для малого бюджета — X-Plane или Prepar 3D. С открытым кодом есть flightgear (хотя с ним практически не знаком).
Я не умаляю Вашей работы, но на задачу визуализацию одного человека маловато.
Интересно, по какой причине был выбран вариант реализовывать подобную систему «с нуля»? Задача в полном развороте очень большая. Нужны и объекты с LOD'ами (как визуализация, так и редактор), и динамическая подгрузка для больших территорий, и автогенерация земли, погода/дожди/туманы, посадочные огни (отдельная проблема), звук с Допплером и многое другое.
Сейчас существует достаточно много систем визуализации — хороших и разных. При больших деньгах — тот же Транзас или Presagis, для малого бюджета — X-Plane или Prepar 3D. С открытым кодом есть flightgear (хотя с ним практически не знаком).
Я не умаляю Вашей работы, но на задачу визуализацию одного человека маловато.
Дилетантский вопрос: почему нельзя это сделать на условном Unity / Unreal Engine?
Задачи разные.
Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.
Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.
Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.
Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.
Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.
Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.
Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.
В нормальных игровых движках framerate тоже просто так проседать не будет, если программист не накосячит.
Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.
Подгрузка местности тоже много где есть. Есть движки, созданные специально для авиасимуляторов. При желании к обычному движку можно написать свой код, который будет что-то добавлять/убирать объекты с карты.
Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.
джиттера координат можно избежать, если время от времени переносить все координаты.
Или, как мне кажется лучше — разбить карту на прямоугольники с локальной системой координат внутри каждого. При рисовании куска карты перемножать model-view-projection матрицы с double точностью на процессоре (или вообще как-нибудь хитро считать) — итоговое произведение матриц не будет содержать излишне больших значений и всё нормально нарисуется.
Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.
Ну вот не надо, не надо. Все зависит от кривости рук. Можно и на Юнити запилить динамическую подгрузку/выгрузку объектов. Я уж не говорю про разметку карты — это вообще элементарно подгружается в динамике.
Есть еще DCS, который на сегодняшний день задает верхнюю планку для военных авиасимов.
Про одного человека — очень верно. Но я один, и у меня никого нет. А задача ставилась тогда, когда визуализации на стенде вообще не было никакой.
На дворе 2016 год. 2016, Карл! То что у вас на скриншотах — это уровень компьютерной графики 20-летней давности. Такую визуализацию пишут студенты 2-го курса в качестве курсовой по openGL-ю, причем плохие студенты, которые не знаю что такое шейдеры, lod-ы, карты нормалей и прочие основы. Примеры уровня графики, которая должна быть у любого уважающего себя симулятора в 2016: раз, два.
Даже с учетом того, что проект писался в одиночку — слабовато. Тем более когда есть очень простые способы существенно поднять качество картинки.
Даже с учетом того, что проект писался в одиночку — слабовато. Тем более когда есть очень простые способы существенно поднять качество картинки.
Что-то подсказывает, что у автора вообще не было доступа к арту. Хотя текстурки накачать и шейдеров понаписать он мог бы и сам.
bak, приводить screenshot'ы c MSFS, который делала большая команда, и сравнивать с работой одного человека, реализовавшего графику с нуля, весьма некорректно.
И 99% студентов 2-го курса не сделает даже такого, разве что сдерут демку какого-нибудь движка и добавят свои пять копеек.
Здесь сама задача достаточно сложная и многоплановая.
И 99% студентов 2-го курса не сделает даже такого, разве что сдерут демку какого-нибудь движка и добавят свои пять копеек.
Здесь сама задача достаточно сложная и многоплановая.
Делал на третьем курсе (не курсовая, просто для себя):
Большой скриншот с телефона
Я не утверждаю, что у меня лучше — конечно же нет, я потратил на это довольно мало времени и даже облаков по-человечески не сделал. Этот скриншот с телефона выглядит, на мой взгляд, явно симпатичнее картинок из статьи. Всего лишь надо подобрать текстуры и цвета. Но автор даже этого не сделал, и у меня складывается впечатление, что ему наплевать на графику. А это довольно странно, потому что всё для чего программа предназначена — рисовать самолёты и местность.
Красиво. Но в защиту автора — спутниковые фототекстуры (~ 1 m/pix) замечательно смотрятся с большой высоты, но на посадке нужно существенно большее разрешение (0.1 m/pix) + текстуры/шумы ещё большего разрешения. Полоса и её знаки чаще всего вообще делается отдельными полигонами. Плюс нужны объекты — домики/посадочные знаки, деревья.
Спасибо, Rend.
Приятно встретить человека, который не идёт на поводу у компьютерных красот, и вообще понимает дело и имеет опыт. Всё примерно так и есть, как вы говорите. Особенно если ещё учесть, что на мне ещё и «сопровождения» работы, вроде таких: "А нарисуйте ещё такой истребитель", или "А сделайте нам ещё авианосец", или "А ракеты у вас есть?", "А другой аэродром можете?", или даже "Вот, короткую полосу надо на 50 метров короче, но зато на 8 метров шире, и чтобы деревья вокруг на нужном расстоянии и нужной высоты, чтобы лётчик их должен был опасаться; когда вы сможете нам это сделать?". Это и есть сопровождение задачи, а делать красивые игрушки и отдавать их как есть, в неизменной форме — очевидно, несколько проще. (Насколько я знаю, стоимость сопровождения на год обычно примерно бывает равна стоимости одного канала визуализации — это так у большинства фирм.) Я не хвастаюсь, но кроме улучшения визуализации мне приходиться «тянуть» ещё многое.
Насчёт раскадровки. Синхронизируются все 9 каналов /плюс ещё 3 вспомогательных, типа «вида со стороны»/ по сети, частоту определяет host с математической моделью динамики самолёта /и всего остального/, но именно так и должно быть: ведь я делаю не игрушку, а инструмент разработки и отладки динамики и систем управления самолётов — поэтому в центре всего именно host с моделями динамики, а уж визуализация должна ему обепечивать всё, что нужно.
С уважением, Константин.
Приятно встретить человека, который не идёт на поводу у компьютерных красот, и вообще понимает дело и имеет опыт. Всё примерно так и есть, как вы говорите. Особенно если ещё учесть, что на мне ещё и «сопровождения» работы, вроде таких: "А нарисуйте ещё такой истребитель", или "А сделайте нам ещё авианосец", или "А ракеты у вас есть?", "А другой аэродром можете?", или даже "Вот, короткую полосу надо на 50 метров короче, но зато на 8 метров шире, и чтобы деревья вокруг на нужном расстоянии и нужной высоты, чтобы лётчик их должен был опасаться; когда вы сможете нам это сделать?". Это и есть сопровождение задачи, а делать красивые игрушки и отдавать их как есть, в неизменной форме — очевидно, несколько проще. (Насколько я знаю, стоимость сопровождения на год обычно примерно бывает равна стоимости одного канала визуализации — это так у большинства фирм.) Я не хвастаюсь, но кроме улучшения визуализации мне приходиться «тянуть» ещё многое.
Насчёт раскадровки. Синхронизируются все 9 каналов /плюс ещё 3 вспомогательных, типа «вида со стороны»/ по сети, частоту определяет host с математической моделью динамики самолёта /и всего остального/, но именно так и должно быть: ведь я делаю не игрушку, а инструмент разработки и отладки динамики и систем управления самолётов — поэтому в центре всего именно host с моделями динамики, а уж визуализация должна ему обепечивать всё, что нужно.
С уважением, Константин.
Очень справедливая квалификация. Спасибо.
А вы спросите себя — а ставил ли автор перед собой задачу добиться современной детализированной картинки? Это не тот инструмент, где важен графон.
Для этих целей есть мной трепетно любимый и ненавидимый osgEarth. На нём, ЕМНИП, и основан flightgear.
А что это? Это OpenGL, открытые исходники (перетаскивается даже на ОЧЕНЬ древние Линуксы), карты берутся откуда угодно и какие угодно грузятся бесшовно и потайлово. А ещё там есть граф сцены, отсечение невидимых объектов со всякими фруструмами, простая работа с любой картографической информацией, импортёр множества форматов 2D и 3D, атмосферные эффекты, домики и деревья какие угодно можно втыкать (не вручную даже, а подбирая данные из карт застройки районов и лесов).
С документацией, правда, грустновато — но осилить с нуля и в сжатые сроки, если есть опыт работы с OpenGL (OpenSceneGraph преимущественно) — вполне возможно. Сам использую.
А что это? Это OpenGL, открытые исходники (перетаскивается даже на ОЧЕНЬ древние Линуксы), карты берутся откуда угодно и какие угодно грузятся бесшовно и потайлово. А ещё там есть граф сцены, отсечение невидимых объектов со всякими фруструмами, простая работа с любой картографической информацией, импортёр множества форматов 2D и 3D, атмосферные эффекты, домики и деревья какие угодно можно втыкать (не вручную даже, а подбирая данные из карт застройки районов и лесов).
С документацией, правда, грустновато — но осилить с нуля и в сжатые сроки, если есть опыт работы с OpenGL (OpenSceneGraph преимущественно) — вполне возможно. Сам использую.
нулевое ядро процессора загружается на 100%, а первое простаивает — это так задумано? Ну а деревья сплайны и создаются копии одного и того же с разной детализацией, правильно?
Заголовок спойлера
Сейчас результат десятилетних наработок можно смело удалить, очистить свою память и сделать за пару недель(месяцев) то же самое, но лучше.
Скажите, а почему не использовать готовое (X-Plane, P3D)? Зачем эта разработка?
И ещё вопрос про погоду. Погода всегда миллион на миллион? Давление всегда и везде 2992?
И ещё вопрос про погоду. Погода всегда миллион на миллион? Давление всегда и везде 2992?
После такой визуализации единственное желание — поскорее пройти курс пилотажа и попасть в реальные летные испытания)
а мы вот заделали плагин для Unreal Engine 4 который умеет на много экранов и компьютеров, в активном стерео, поддержкой VRPN протокола и внутренней синхронизацией (анимации, физика и т.п), зацените пару видео.
http://vrcluster.io/
пару видео демок в кластере на 8 компьютеров:
https://www.youtube.com/watch?v=IA2W3kli8ZY
https://www.youtube.com/watch?v=5qtixjqxcp8
https://www.youtube.com/watch?v=hay_Ig-019E
мб статейку накидать про внутренности анрила? :)
http://vrcluster.io/
пару видео демок в кластере на 8 компьютеров:
https://www.youtube.com/watch?v=IA2W3kli8ZY
https://www.youtube.com/watch?v=5qtixjqxcp8
https://www.youtube.com/watch?v=hay_Ig-019E
мб статейку накидать про внутренности анрила? :)
Sign up to leave a comment.
Как я написал систему визуализации для стенда