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

Во-первых, сначала надо сказать о том, что такое система визуализации внекабинного пространства самолета. Это программа, которая показывает то, что видит летчик, когда летит в самолете. При этом я не имею в виду приборов и вообще всего того, что находится внутри кабины — выше не зря употреблен термин «внекабинное пространство». Делать, конечно, приходится отчасти и приборы, но это отдельная, гораздо более простая задача, и о ней можно не говорить. В узком смысле «визуализацией» называется именно изображение внекабинного пространства, так что я буду говорить именно об этом.

Ниже дан пример того, что видит летчик в моей программе при взлете:
(Все примеры в дальнейшем как раз и взяты из реальных визуализационных кадров моей программы.)

Во-вторых, свою визуализацию я делал для вполне реального работающего пилотажного стенда в ЦАГИ, где она и зарегистрирована, притом уже дважды. Пилотажный стенд — это, грубо говоря, кабина самолета, взятая отдельно от всего остального (фюзеляжа, крыльев, и т.д.), и помещенная внутрь четырехметровой сферы, белой изнутри. Вся эта внутренняя белая поверхность сферы и есть мой экран, то ест экран системы визуализации — на нее проекторы, в нашем случае их 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. Вот и эта ссылка:

Ну, вот кажется, и все.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 38

    +24
    > Но рассказывать об оптимизации можно долго и занудно, а нужно это только программистам, которые занимаются программами реального времени, вроде меня.

    Это придало бы хоть какой-то смысл данной статье на Хабре.
      0
      Хотя визуализация и графика меня не очень интересует, но где-то пару лет назад на Хабре была статья про оптимизацию отрисовки, что даже мне очень понравилась. А здесь слишком много общего(для меня, как человека, не занимающегося визуализацией, трудно оценить выполненную работу), и я должна поверить в дважды повторяющуюся фразу в посте

      визуализация есть, она хорошо и устойчиво работает на стенде ЦАГИ
        0
        .
        +1
        Могли бы рассказать про самые нагруженные моменты и как удалось их оптимизировать. Пришлось ли браться за ассемблер? И как вообще синхронизировали 9 отдельных экранов — у них у всех железные 100 кадров? Как они общаются между собой? Сколько уровней детализации объектов применили?
        Что думаете про VR-шлемы — четырёхметровые белые шары не устарели ли с их появлением?
          +3
          Какой ассемблер в 2016 году? Это пустая трата времени. Если что и тормозит, то либо GPU, либо API overhead. И ассемблер в обоих случаях не поможет. Тут проблемы другого плана.
            +1
            VR-шлемы для таких задач не особо подходят. Здесь вопрос создания максимально правдоподобного окружения для лётчика — кабина железная с кнопочками и пимпочками, а описанная в статье визуализация предназначена исключительно для имитации закабинной обстановки.

            Тактильные ощущения от кнопочек и пимпочек пока VR-технологиями симитировать не удаётся.
              0
              Можно ведь приборную панель сделать физической.
              VR будет значительно дешевле, чем этот шар с 9 проекторами, компьютерами и их сетью. И невидимое рендерить не надо.
              0
              С удовольствием расскажу, если будет шанс.
                0
                Будет время, расскажу.
                +3
                В своё время это называли — «закабинка».

                Интересно, по какой причине был выбран вариант реализовывать подобную систему «с нуля»? Задача в полном развороте очень большая. Нужны и объекты с LOD'ами (как визуализация, так и редактор), и динамическая подгрузка для больших территорий, и автогенерация земли, погода/дожди/туманы, посадочные огни (отдельная проблема), звук с Допплером и многое другое.

                Сейчас существует достаточно много систем визуализации — хороших и разных. При больших деньгах — тот же Транзас или Presagis, для малого бюджета — X-Plane или Prepar 3D. С открытым кодом есть flightgear (хотя с ним практически не знаком).

                Я не умаляю Вашей работы, но на задачу визуализацию одного человека маловато.

                  +3
                  Дилетантский вопрос: почему нельзя это сделать на условном Unity / Unreal Engine?
                    0
                    Задачи разные.

                    Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.

                    Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.

                    Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.
                      +1
                      Как и упоминалось автором — фиксированный frame rate. Даже если его «зашивают» всего лишь в 30 fps (в своё время и подобное считалось приемлемым), он не должен плавать и тем более проседать.

                      В нормальных игровых движках framerate тоже просто так проседать не будет, если программист не накосячит.


                      Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.

                      Подгрузка местности тоже много где есть. Есть движки, созданные специально для авиасимуляторов. При желании к обычному движку можно написать свой код, который будет что-то добавлять/убирать объекты с карты.


                      Также при этом есть вопрос джиттера координат. Берём длину экватора (~40 000 км) и понимаем, что при классическом подходе в 32 бита координаты каждой точки объекта ложатся с недопустимой точностью. Как результат, всё дёргается и дрожит при движении.

                      джиттера координат можно избежать, если время от времени переносить все координаты.
                      Или, как мне кажется лучше — разбить карту на прямоугольники с локальной системой координат внутри каждого. При рисовании куска карты перемножать model-view-projection матрицы с double точностью на процессоре (или вообще как-нибудь хитро считать) — итоговое произведение матриц не будет содержать излишне больших значений и всё нормально нарисуется.

                        +3
                        Например, игровые движки ориентированы на «уровни», которые загружаются в начале. Авиационные движки должны поддерживать бесшовный перелёт за тысячи километров с динамической подгрузкой местности.


                        Ну вот не надо, не надо. Все зависит от кривости рук. Можно и на Юнити запилить динамическую подгрузку/выгрузку объектов. Я уж не говорю про разметку карты — это вообще элементарно подгружается в динамике.
                      0
                      Есть еще DCS, который на сегодняшний день задает верхнюю планку для военных авиасимов.
                        0
                        Про одного человека — очень верно. Но я один, и у меня никого нет. А задача ставилась тогда, когда визуализации на стенде вообще не было никакой.
                        +14
                        На дворе 2016 год. 2016, Карл! То что у вас на скриншотах — это уровень компьютерной графики 20-летней давности. Такую визуализацию пишут студенты 2-го курса в качестве курсовой по openGL-ю, причем плохие студенты, которые не знаю что такое шейдеры, lod-ы, карты нормалей и прочие основы. Примеры уровня графики, которая должна быть у любого уважающего себя симулятора в 2016: раз, два.
                        Даже с учетом того, что проект писался в одиночку — слабовато. Тем более когда есть очень простые способы существенно поднять качество картинки.
                          +1
                          Что-то подсказывает, что у автора вообще не было доступа к арту. Хотя текстурки накачать и шейдеров понаписать он мог бы и сам.
                            +2
                            bak, приводить screenshot'ы c MSFS, который делала большая команда, и сравнивать с работой одного человека, реализовавшего графику с нуля, весьма некорректно.

                            И 99% студентов 2-го курса не сделает даже такого, разве что сдерут демку какого-нибудь движка и добавят свои пять копеек.

                            Здесь сама задача достаточно сложная и многоплановая.
                              +2

                              Делал на третьем курсе (не курсовая, просто для себя):


                              Большой скриншот с телефона

                              image


                              Я не утверждаю, что у меня лучше — конечно же нет, я потратил на это довольно мало времени и даже облаков по-человечески не сделал. Этот скриншот с телефона выглядит, на мой взгляд, явно симпатичнее картинок из статьи. Всего лишь надо подобрать текстуры и цвета. Но автор даже этого не сделал, и у меня складывается впечатление, что ему наплевать на графику. А это довольно странно, потому что всё для чего программа предназначена — рисовать самолёты и местность.

                                0
                                Красиво. Но в защиту автора — спутниковые фототекстуры (~ 1 m/pix) замечательно смотрятся с большой высоты, но на посадке нужно существенно большее разрешение (0.1 m/pix) + текстуры/шумы ещё большего разрешения. Полоса и её знаки чаще всего вообще делается отдельными полигонами. Плюс нужны объекты — домики/посадочные знаки, деревья.
                                  0
                                  Спасибо, Rend.
                                  Приятно встретить человека, который не идёт на поводу у компьютерных красот, и вообще понимает дело и имеет опыт. Всё примерно так и есть, как вы говорите. Особенно если ещё учесть, что на мне ещё и «сопровождения» работы, вроде таких: "А нарисуйте ещё такой истребитель", или "А сделайте нам ещё авианосец", или "А ракеты у вас есть?", "А другой аэродром можете?", или даже "Вот, короткую полосу надо на 50 метров короче, но зато на 8 метров шире, и чтобы деревья вокруг на нужном расстоянии и нужной высоты, чтобы лётчик их должен был опасаться; когда вы сможете нам это сделать?". Это и есть сопровождение задачи, а делать красивые игрушки и отдавать их как есть, в неизменной форме — очевидно, несколько проще. (Насколько я знаю, стоимость сопровождения на год обычно примерно бывает равна стоимости одного канала визуализации — это так у большинства фирм.) Я не хвастаюсь, но кроме улучшения визуализации мне приходиться «тянуть» ещё многое.
                                  Насчёт раскадровки. Синхронизируются все 9 каналов /плюс ещё 3 вспомогательных, типа «вида со стороны»/ по сети, частоту определяет host с математической моделью динамики самолёта /и всего остального/, но именно так и должно быть: ведь я делаю не игрушку, а инструмент разработки и отладки динамики и систем управления самолётов — поэтому в центре всего именно host с моделями динамики, а уж визуализация должна ему обепечивать всё, что нужно.
                                  С уважением, Константин.
                                0
                                Очень справедливая квалификация. Спасибо.
                                0
                                А вы спросите себя — а ставил ли автор перед собой задачу добиться современной детализированной картинки? Это не тот инструмент, где важен графон.
                                  +1
                                  Ну вообще-то тот. Желателен фотореалистичный графон с правильной симуляцией погодных/природных явлений.
                                    0
                                    Верно. В первую очередь важно реальное время — то есть быстродействие.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Когда смогу, напишу.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      +1
                                      Для этих целей есть мной трепетно любимый и ненавидимый osgEarth. На нём, ЕМНИП, и основан flightgear.

                                      А что это? Это OpenGL, открытые исходники (перетаскивается даже на ОЧЕНЬ древние Линуксы), карты берутся откуда угодно и какие угодно грузятся бесшовно и потайлово. А ещё там есть граф сцены, отсечение невидимых объектов со всякими фруструмами, простая работа с любой картографической информацией, импортёр множества форматов 2D и 3D, атмосферные эффекты, домики и деревья какие угодно можно втыкать (не вручную даже, а подбирая данные из карт застройки районов и лесов).

                                      С документацией, правда, грустновато — но осилить с нуля и в сжатые сроки, если есть опыт работы с OpenGL (OpenSceneGraph преимущественно) — вполне возможно. Сам использую.
                                        +1
                                        нулевое ядро процессора загружается на 100%, а первое простаивает — это так задумано? Ну а деревья сплайны и создаются копии одного и того же с разной детализацией, правильно?
                                        Заголовок спойлера
                                        Сейчас результат десятилетних наработок можно смело удалить, очистить свою память и сделать за пару недель(месяцев) то же самое, но лучше.
                                          +1
                                          Ты не забывай что в госс структурах компы вообще редко имеют больше 2х ядер.
                                          Так как деньги или распилили еще до их покупки, или купили бу/списанное у других фирм.
                                          Печально, но это так.
                                          0
                                          Для одинарного и делал.
                                          0
                                          Скажите, а почему не использовать готовое (X-Plane, P3D)? Зачем эта разработка?
                                          И ещё вопрос про погоду. Погода всегда миллион на миллион? Давление всегда и везде 2992?
                                            0
                                            Вопрос верный. Просто примеров с плохой погодой не приводил.
                                            0

                                            После такой визуализации единственное желание — поскорее пройти курс пилотажа и попасть в реальные летные испытания)

                                              +2
                                              а мы вот заделали плагин для 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

                                              мб статейку накидать про внутренности анрила? :)

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое