Меню сайта |
|
|
Категории раздела |
|
|
Мини-чат |
|
|
Наш опрос |
|
|
Статистика |
Онлайн всего: 3 Гостей: 3 Пользователей: 0 |
|
|
| | |
|
Моделирование виртуальных кабин в MSFS
Моделирование виртуальных кабин в MSFS |
Описание: Очень полезная статья для сим-дизайнеров о моделировании виртуальных кабин для Microsoft Flight Simulator. |
Автор: Ranger Дата: 05.03.2007 13:38 Просмотров: 17854
|
Когда
заходит речь о виртуальных кабинах в моделях MSFS, то мнения
разделяются: одни плюются и говорят, что это все чушь, неудобно, другие
считают, что больше реализма, проще выруливать, по-другому чувствуется
скорость и высота, но слишком тормозят приборы, третьи вообще не мыслят
себе полетов с 2D-панелями. Все правы по-своему, лично мне больше
нравится летать в ВК. И еще в начале своего увлечения симулятором я
обратил внимание на то, что частенько кабина сделана нормально, счетчик
кадров не просаживает, а вот приборы двигаются рывками с большой
дискретностью. Но бывает и так: кабина еле-еле наскребает 16-18 кадров
в секунду, а по приборам вполне можно летать. Разбираясь в этом
вопросе, я выяснил, сначала экспериментально, а потом получив
подтверждение в информации на сайте команды Reality XP и на форуме
avsim.com, что скорость обновления приборов в виртуальной кабине
напрямую зависит от количества секций VCockpit в файле Panel.cfg.
Разработчики сделали интересную штуку: обновление изображений приборов
происходит раз в 1/18 секунды, причем секции Window обрабатываются все,
а секции VCockpit по очереди, то есть в первую 1/18 секунды будут
обновлены приборы из секции VCockpit01, в следующие 1/18 секунды –
приборы из секции VCockpit02 и так далее. И если у вас есть модель с
красивой и «легкой» виртуальной кабиной и 12 секциями VCockpit в
Panel.cfg – о полетах из ВК вы можете забыть, приборы будут обновляться
раз в 12/18=0.6 секунды. Разобравшись с этим, я занялся техническими
вопросами моделирования – почему, скажем, в стандартной Цессне-172 две
секции VCockpit, а попавшейся мне как-то Цессне-176 – аж шесть, хотя
приборов столько же и качество изображения у них не выше.
Прежде чем перейти к объяснениям, введем кое-какие условия – мы будем
использовать разрешение пиксель на миллиметр для $-текстур, то есть
текстура 1024x1024 у нас будет покрывать площадь 1024x1024 мм.
Итак, общепринятая практика размещения приборов в виртуальной кабине
выглядит примерно так:
Ширина
панели – 1м 69см, красным показана область, которую покроет квадрат с
$-текстурой указанных выше размеров, а поскольку в правой части панели
тоже должны быть приборы, то обычно кладется еще один квадрат (зеленый
на рисунке):
А
если понадобится разместить пару приборов на среднем пульте – положим
еще лист. Вроде все нормально, за исключением одного момента: каждый
лист $-текстуры – это секция VCockpit в файле Panel.cfg.
Теперь неплохо бы разобраться, как симулятор поступает, встретив секцию
VCockpit и как вообще отрисовываются приборы в ВК. А происходит
примерно следующее:
в памяти создается прозрачная текстура;
изображения приборов переносятся на эту текстуру по координатам и с
размерами, прописанными в строках GaugeXX в секции VCockpit;
после обработки секции, треугольники модели и текстуры интерьера,
вместе с созданной ранее в памяти, передаются видеокарте на отрисовку.
В общем $-текстура – это обычная текстура, только создается она
динамически перед отрисовкой, вот и все. И соответственно все приемы
работы с обычными текстурами к ней вполне применимы. Запомним и идем
дальше. Допустим, что приборы (выделены черным цветом) должны
располагаться на панели самолета так:
Посмотрим, как в таком случае располагаются изображения приборов на созданной в памяти текстуре:
И для второго листа:
Хорошо
видно, что на текстурах есть много неиспользованного пространства.
Почему так делают? Не знаю. Могу предположить 3 варианта: так проще и
быстрее моделисту, он слабо представляет что же такое эта $-текстура,
либо его сбивает с толку ее связь с Panel.cfg. И результатом становится
красивая, аккуратная… абсолютно бесполезная для полетов виртуальная
кабина. Не знаю насчет первого варианта – сколько там часов уходит у
моделиста на интерьер? 20? 30? 100? По мне – так лучше убить еще часа
4, но сделать хорошую во всех отношениях кабину.
И вот мы подошли, собственно, к несколько иному подходу создания панели
приборов в ВК. Намек на него, кстати, есть в SDK – обратите внимание на
пример текстуры с приборами в разделе, посвященном моделированию
интерьера. Итак, первое действие – атласирование изображений приборов.
Понадобятся изображения всех приборов, которые будут использованы в ВК.
Размеры их необходимо будет подогнать под реальные в миллиметрах или
близко к этому, поскольку мы договорились, что разрешение $-текстуры у
нас пиксель на миллиметр. Затем создаем рисунок 1024х1024 в графическом
редакторе и начинаем наносить на него изображения приборов с зазором не
менее 1 пикселя между ними. В результате должно получиться что-то вроде
этого:
Не
стоит беспокоится, что вокруг непрямоугольных приборов остаются «юбки»
и пытаться вместо прямоугольников делать полигоны – при переносе
симулятором изображений приборов на текстуру в памяти он сделает эти
«юбки» прозрачными. Кроме того, прямоугольник – это всего 2
треугольника, а их стоит экономить, пригодятся в дальнейшем. Но,
впрочем, выбор за вами.
Итог: мы разместили все приборы, обошлись всего одной секцией VCockpit
и имеем в запасе много места для приборов на потолочной панели и
среднем пульте (которые, кстати, пойдут в ту же секцию если что). И,
конечно же, максимально высокую скорость обновления показаний приборов.
Подобный подход не позволяет сдвинуть/растянуть пользователю прибор на
пару пикселей, если моделист слегка промазал, НО! Что мешает ему
сделать зазор на атласе, скажем, 5 пикселей, а прямоугольник под прибор
чуть больше нужного? Хотя лично я считаю это излишним. И кстати - мы
можем, не меняя UV-координат и не копаясь в исходном коде прибора,
развернуть его независимо от других на любой угол, подогнать под любой
наклон панели и так далее.
Мой совет: приборы всегда надо пытаться упаковывать в наименьшее
количество $-текстур.
Теперь, разобравшись, что $-текстура ничем, в принципе, не отличается
от обычной, можно заняться приданием виртуальной кабине большего
реализма. Итак, пусть мы имеем высотомер на панели. Он плоский и
хочется что-то с ним сделать.
Создаем цилиндр по размеру ручки настройки давления:
Применяем к нему тот же материал, что использован для прямоугольника прибора:
Выставляем Planar Map для цилиндра:
Завершающим этапом будет операция Unwrap UVW и подгонка вершин на изображение ручки:
В
итоге мы получаем полностью работающую объемную ручку без лишних
проблем с XML, переделкой прибора и тому подобного. Для пущей
оптимизации можно удалить заднее дно цилиндра. Ручка у нас получилась
статичная, а вращать ее средствами XML-кода в модели не стоит из-за
того, что вместе с поворотом цилиндра будут поворачиваться и зоны
управления прибором (мышиные зоны). Тем не менее, анимацию вращения
вполне можно сделать в самом приборе, но это уже задача для
программистов.
Теоретически ручку можно разобрать на составляющие и на боковую
поверхность натянуть более похожую на реальную ручку текстуру, но мы
потеряем возможность управлять высотомером в случае, если смотрим на
нее сбоку. Опять же, решать вам.
Кстати, аналогичным образом можно поступить для придания объемности не
только ручкам, но и самим приборам, например, сделать авиагоризонт
шаром, тут уж как кому нравится. Я бы посоветовал не увлекаться и
сохранять баланс между красотой и количеством треугольников в кабине –
она все же не должна сильно влиять на счетчик кадров в секунду, людям в
ней еще летать предстоит.
На заметку – можно попробовать кнопки сделать не просто объемными, а
нажимаемыми. Сам не пробовал – лень. Но теоретически мы можем
анимировать нажатие кнопки и по аналогии со стандартными
переключателями написать XML-код для этого дела (с той только разницей,
что при нажатии на клавишу мыши переменная устанавливается в TRUE, а
при отпускании – в FALSE). При этом данные в логику модели передавать
через ту же $-текстуру.
Есть и еще один интересный аспект моделирования приборных панелей –
например, мы хотим сделать 4 варианта одного самолета с разными
приборами (или просто с разным расположением их на панели). Дело в том,
что если нет записи gaugeXX в секции VCockpit – нет и изображения
прибора, его полигон будет прозрачным. Вариант – делаем в одной модели
несколько компоновок приборов, полигонам одной компоновки назначаем
материал с одной $-текстурой, полигонам другой – материал с другой
$-текстурой, создаем несколько вариантов Panel.cfg (каждый из них
по-прежнему имеет только одну секцию VCockpit, но разные имена
$-текстур в ней и компоновку приборов) и меняем их по мере надобности.
Но тут я не уверен, будут ли корректно отрабатывать мышиные зоны – надо
пробовать.
И, в завершение, нестандартный, но, тем не менее, работающий способ,
которой показывает, что решение есть почти всегда.
Переделывая кабину одной модели под нужную мне скорость обновления
приборов, я столкнулся с проблемой: запуск/останов турбореактивного
двигателя производился отдельным рычагом, программно это было
реализовано через регулировку смеси, анимация в модели также
производилась по значению переменной lever_mixture, но не было обратной
связи, то есть двигать в ВК рычаг можно было, но прибор не отрабатывал
изменение переменной симулятора. Он просто ее выставлял принудительно,
согласно своей внутренней логике. Поскольку исходного кода я не имел, а
управлять двигателем из виртуальной кабины хотел, пришлось «танцевать с
бубном».
Первое решение навскидку было – натянуть на рычаг соответствующий
прибору участок $-текстуры, работало бы, но 2D-изображение рычага в
приборе, во-первых менялось при переключении, а во-вторых, на нем уже
была симпатичная текстура.
Итак, поехали.
Есть рычаг:
Есть атлас с соответствующим прибором:
Клонируем верхнюю часть рычага:
Слегка увеличиваем клон, не забывая потом сделать Reset Scale:
Назначаем ему материал с соответствующей $-текстурой, выставляем объекту Planar Map, делаем Unwrap UVW:
А теперь начинается самое интересное – UV-координаты мы сгоняем в ту область изображения прибора, где имеется черный цвет:
В итоге довольно несимпатичная картинка:
Однако
получается следующее - вокруг ручки рычага мы имеем как бы оболочку, на
которую натянут кусочек прибора, причем кусочек, который симулятор при
отрисовке сделает прозрачным (та самая «юбка»), но будет считать зоной
управления 2D-прибором рычага. Вот теперь можно экспортировать модель,
компилировать ее и наслаждаться управлением двигателем в виртуальной
кабине. Причем все это мы сделали не вылавливая разработчиков приборов
и приставая к ним с дурацкими просьбами и советами. Кстати, намек
прибористам: по мере возможности выгружайте в XML-переменные внутреннее
состояние узлов прибора, которые могут быть анимированы, а если лень
делать обратную связь – добавьте еще один прибор с пустым изображением
небольшого размера, мышиной зоной на нем и реакцией, как у основного.
Работы в таком варианте минимум и вам и моделистам, а результат может
порадовать многих виртуальных пилотов. Еще стоит сказать пару слов о
размерах текстур. По мнению специалистов, наилучшую производительность
2004-й симулятор показывает с текстурами 512х512 пикселей, несмотря на
то, что может работать и с большим разрешением. Пробуйте,
экспериментируйте.
Успехов в создании виртуальных кабин и помните – невозможного нет!
PS Всех читавших данный документ, а также людей, чьи модели/приборы
были использованы в примерах, прошу обратить внимание – цель документа
не показать несостоятельность той или иной модели и ее разработчиков, а
всего лишь описать некоторые аспекты моделирования ВК и эти
модели/приборы были использованы всего лишь по причине наглядности и
наличия их под рукой.
|
Категория: Конструкторская деятельность | Добавил: Kurs (26.08.2009) |
Просмотров: 1219
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
| |
| | |
|
Поиск |
|
|
Друзья сайта |
|
|
|