четверг, 17 марта 2016 г.

Классы и физика. Кокпит и аэродинамика...

Помимо такой увлекательной вещи, как кодинг, существует масса рутинных вещей. Например, создание номеров. номеров надо много, хороших и разных. В начале недели этим пришлось заняться весьма тщательно. Помимо создания своих собственных номеров для ливийских самолетов (четырехзначные "арабские" - не путать с настоящими арабскими цифрами, без кавычек!), на основе известных мне фото и декалей для моделей (пластиковых, не трехмерных, и самых, что ни есть настоящих, только маленьких!), поискал и нашел в своих закромах арабские номера, с настоящими, без кавычек, арабскими цифрами. Все они были маленькие и из них пришлось "клеить" большую текстуру. С обычными цифрами дело было проще - создаем в ГИМПе текстовый слой и набиваем до одурения - 6901, 6902 и так далее с вариациями для первых двух цифр.
Далее я "припаял" стекла к кабине и фонарю, в смысле, объединил стекла с их "родителями". По большому счету, чем меньше объектов, тем лучше, а прописывать в большом коде по замене мешей еще и стекла... Да ну на фиг... Та же участь постигла малодетализированный кокпит модели на внешнем игровом слое. Я его объединил с фюзеляжем. Все равно в кабине с внешней камеры ничего не видно. Правда, пути отступления я себе сохранил, создав группы вершин для стекол и этого самого кокпита. Чтобы в случае чего, быстро "отрезать".
Затем я поперся постигать Силу... Не джедайскую. Force в БГЕ. Занимает она меня тем, что с ней можно творить что-то близкое к аэродинамике, ну и поведение самолетов как бы естественней. Тем более, что на данный момент Torque задействована в управлении разворотами. Пока я не стал еще переделывать скрипт движения, потому что опять  взбрело в голову поискать, нет ли чего по аэродинамике в BGE. Оказалось, было дело - в 2009 году делалось что-то подобное и ветка на blenderartist сохранилась. С файлами. Устаревшими напрочь. Но несколько таких файликов я скачал и самый "свежий" переделал под сегодняшний Блендер. Ну как переделал? Поубирал GameLogic и вписал bge.logic, с помощью Яндекса перевел комментарии (несколько коряво, но уж лучше того же Гугла-переводчика). Результат столь же ошеломителен, сколь и непонятен... Объект то ли летает задом наперед, то ли что-то было заменено в Питоне с тех пор, в общем, летает "пуля", только очень быстро. Половина скорости света точно есть. Что с этим дальше делать - ясно. Разбираться, разбираться и еще раз разбираться (перевранное (с)). Ну ладно, аэродинамика вещь сложная, но постижимая.времени б только побольше, а то и другое делать надо.
До всех описанных выше событий я занимался кокпитом. Консоль матерится на пару текстур, есть подозрение, что dds не любит квадратные текстуры, не кратных 2 в энной степени (таких у меня 2 точно есть- надо их проверить). Однако сам принцип работы кокпита, о котором я писал ранее, на удивление, пока работает и хорошо. Все стрелки, за исключением указателей ориентации, работают,  их прилично и пульсация для них установлена 1. Если в старой версии кокпитов работа стрелочек кушала много (я проверял, отключая зеркала и метку цели), то в новой версии кокпит пока жрет 1 процент логики, в дополнение к паре процентов движка на игровом слое.
Разумеется, какая-то часть ресурсов еще будет съедена теми же зеркалами, меткой цели, СПО и прочей индикацией. однако... В старой версии, по моим подсчетам, кокпит жрал около 20 процентов, а иногда и до 30. Ненормально много, как выясняется. Причина - запись в глобальный словарь ну очень большого количества данных, да еще и с вычислением попутно, прямо в списке, да еще и с вызовом функций типа int. В общем, теперь в списке находятся 11 данных вместо более полусотни - и это только те, которые меняются постоянно. Остальные будут передаваться напрямую на сцену кокпита. И как управлять объектами оверлее с игровой сцены, не дописывая отдельные скрипты для оверлейных сцен я понял относительно недавно и сегодня успешно реализовал. Пока для переключения камер и зума камеры летчика.

Приведу кусочек кода

#Переключения камеры, если камера в кабине, заодно выставляется ее фокус
                if key == bge.events.F1KEY or key == bge.events.F2KEY or key == bge.events.F3KEY or key == bge.events.F4KEY or key == bge.events.F5KEY or key == bge.events.F6KEY or key == bge.events.F7KEY or key == bge.events.F8KEY or key == bge.events.F9KEY or key == bge.events.F10KEY or key == bge.events.F11KEY or key == bge.events.F12KEY:
                   
                    scene.active_camera = cameraPilot
                    #Если оверлейная сцена с кокпитом уже работает, переключаем камеру и там
                    for sceneGame in bge.logic.getSceneList():
                        if sceneGame.name == 'Cockpit':
                            cameraPilotOver = sceneGame.objects['CameraPilotOver']
                            sceneGame.active_camera = cameraPilotOver
                           
                    if key == bge.events.F1KEY:
                        cameraPilot.lens = 50
                        #Если оверлейная сцена с кокпитом уже работает, переключаем камеру и там
                        cameraPilotOver.lens = 50
                           
                    if key == bge.events.F2KEY:
                        cameraPilot.lens = 35
                        #Если оверлейная сцена с кокпитом уже работает, переключаем камеру и там
                        cameraPilotOver.lens = 35

Думаю, понятно. Но с одной оговоркой - на мой взгляд такие фокусы с оверлеем пройдут при нечастом вызове циклов. Я вообще стараюсь циклы вызывать пореже, где это возможно. И по возможности их не использовать вообще. Попутно сделал так, чтобы камера на оверлее при подключении сцены занимала свое место  соответственно нужному расположению в кабине и припаренчивалась к управляющим плейнам, обеспечивающим ее повороты (имитация поворотов головы летчика). Теперь пора подумать о передаче изменяемых данных непосредственно на кокпит, который будет по поступлении команд "мигать" индикацией шасси, отказов систем, и прочая и прочая... И начать писать код для смены уровней детализации и замены мешей.
Пока что скрин кабины выглядит так (я попутно тестировал еще и работу камеры, поэтому взгляд "не прямо").
В общем пока так. Впереди еще подгонка данных по движению, ЛОДы и прочая. А затем - отработка взаимодействия систем вооружения и БРЭО. Кстати о БРЭО. На мой взгляд, использовать скрипт радара все время нерационально. Скорее всего, он будет работать импульсами - раз в столько-то секунд с десятыми долями. Сильно измениться положение оппонентов за это время не успеет, а в ближнем бою у меня и так была отработана методика стрельбы из пушки и пусков ракет малой дальности с ТГСН. Заодно дополнительно можно сделать разные характеристики для разных машин. По частоте работы радара, прежде всего. Про угол обзора и дальность я уж не говорю. Цели должны попадать "под раздачу" при двух условиях - первое - дистанция меньше, чем разрешенная дальность пуска (зависит от высоты, положения цели, ее ЭПР и еще много чего) и второе  - нос самолета должен быть направлен если не строго на цель, то близко к этому - все это у меня в скриптах было, теперь это надо "очистить от шелухи" и привести в удобочитаемый вид с комментариями. И научиться запихивать в класс несколько функций сразу. И заодно сделать самолеты "ограниченно зрячими". В первой версии боты всегда видели игрока, а вот игрок их мог и не увидеть. Теперь же боты будут следовать либо по маршруту, либо к обнаруженной их радаром цели. У игрока появляется шанс "подловить" ничего не подозревающего оппонента, к примеру подойдя сбоку или сзади. Разумеется, на расстоянии этак км в 8 бот будет знать, что творится и позади него (типа имитация взгляда летчика в зеркало заднего вида). Но вот безнаказанно расстрелять группу противника, зайдя ей в хвост, с большего расстояния - это станет вполне реально. Все-таки работу систем прицеливания и обнаружения надо подтягивать поближе к реальности.

Комментариев нет:

Отправить комментарий