итак, великая анимационная революция таки свершилась. Заодно она потянула за собой и устранение старых проблем и появление новых. Собственно, из новых проблем наиболее сложной является лишь строгое следование тобой же разработанным правилам. А еще - пересоздание анимаций...
На данный момент все движения и трансформации, за исключением вращения колес шасси, пламени форсажа и свечения турбины задаются изменеием всевозможных проперти. Несомненным достоинством этого метода является возможность избежать резких рывков анимации и прыжков скоростей. Особенно это касается анимаций аэродинамических поверхностей, "рывки" при кренах, тангаже и рыске были настоящим проклятием - было отчетливо видно, как резко "дергается" стабилизатор или элерон при смене курса. Также не вызывало особого восторга стремительное, почти мгновенное возрастание скорости при смене стреловидности или выпуске тормоза. Теперь проперти, управляющие кадрами анимации, интегрированы в модель полета. Это можно рассмотреть на примере выпуска-уборки щитков воздушного тормоза.
Как выглядит работа анимации тормоза:
if own['levelsDetails'] == 0:
#Собственно, анимация щитков тормоза - кадр анимации задается значением проперти AIRBRAKE
for obj in own['localDict']['deviceAirbrakes']:
obj.playAction(obj.name,own['AIRBRAKE'],own['AIRBRAKE'],0,0,0,bge.logic.KX_ACTION_MODE_PLAY,0.0,0,1.0)
#Выпуск тормоза
if own['localDict']['AIRBRAKE'] < own['AIRBRAKE'] and own['AIRBRAKE'] < 100:
own['AIRBRAKE'] += 1
if own['AIRBRAKE'] == 100:
own['localDict']['AIRBRAKE'] = own['AIRBRAKE']
#Уборка тормоза
if own['localDict']['AIRBRAKE'] > own['AIRBRAKE'] and own['AIRBRAKE'] > 1:
own['AIRBRAKE'] -= 1
if own['AIRBRAKE'] == 1:
own['localDict']['AIRBRAKE'] = own['AIRBRAKE']
Думаю, понятно. Вверху указывается - что работа анимации происходит только при высоком уровне детализации и наличия соответствующих деталей-потомков (списко deviceAirbrakes). Кадр анимации жестко привязан к занчению проперти AIRBRAKE. Само проперти работает от команд с клавиатуры (но для ботов - разницы никакой - там просто при выполнении ряда условий происходит отдача точног такой же команды):
###################################################
#Выпуск-уборка воздушного тормоза
if keyboard.events[bge.events.AKEY] == JUST_ACTIVATED:
if self['AIRBRAKE'] == 1:
self['AIRBRAKE'] += 1
elif self['AIRBRAKE'] == 100:
self['AIRBRAKE'] -= 1
#Если оверлейная сцена с кокпитом уже работает
for sceneGame in bge.logic.getSceneList():
if sceneGame.name == 'Cockpit':
cockpit = sceneGame.objects['Cockpit']
cockpit['airbrake'] = self['AIRBRAKE']
то есть достаточно просто "подтолкнуть" проперти вперед или назад один раз. и пока проперти не получит самого большого или самого маленького значения, будет продолжаться его нарастание или убывание. Для тормоза эти значения равны 1 и 100. Аналогично происходит выпуск-уборка шасси, закрылков, смена стреловидности, открытие фонаря и так далее. Но и это не все. величина проперти AIRBRAKE еще и влияет на скорость полета. Упрощенно - скорость задается какой-то формулой, в составе которой имеется и AIRBRAKES, только вот значение его используется не прямо, а вот так:
151/(150 + AIRBRAKES)
Поясняю - минимальное значение проперти равно 1 - тормоз убран. И мы имеем в итоге 1. Скорость не падает. Но стоит только выпустить тормоз, как в конце анимации мы получаем 151/(150 + 100). Что-то коло 0.6. Тормоз действует, "съедая" сорок процентов скорости. Но при этом эти проценты съедаются постепенно - с каждым тиком - с каждым кадром анимации.
Добившись четкой работы анимации всех деталей, я занялся дальнейшей доводкой кокпитов и пополнением авиапарка. Пока он состоит лишь из модификаций МиГ-23, да и то - одной национальности - ВВС Ливии полковника Каддафи. изначально я собирался делать версию про египетско-ливийскую войну 1977, да ещ и не сильно отходя от, как мне казалось тогда, незыблемых канонов. оказалось, каноны не такие уж незыблемые...
Пришлось немного повоевать с моделью движения самолета. Если с разворотами все оказалось более-менее понятно - с применением силы Torque, да и с новым методом учета стрелодидности - картинка получалсь архизамечательная по сравнению с первой версией, то вот с линейным движением вышел облом. Как оказалось, сила, толкающая объект вперед, не компенсирует силу тяжести, увы. Так что пришлось опять прибегнуть к localLinearVelocity. Хотя она рассчитывается по-другому, и, как я говорил, ее изменение стало более плавным и реалистичным... Но это дело можно совершенствовать по мере дальнейшего продвижения вперед, так что, кто его знает, что в итоге получится.
Всплыла еще одна не слишком приятная проблема. Ландшафт. С ним я воевал долгог и упорно, и, казалось, победил. но не совсем. При возросших скоростях движения вдруг выяснилось, что его подгрузка не поспевает за камерой и, что хуже всего, просаживает ФПС и сильно при увеличении частоты работы. Однако варианты все же есть и можно попробовать их несколько.
Первый - увеличить размеры блока, что приведет к уменьшению их числа,а, значит, можно даже уменьшить количество обновлений террайна в игре.
Второй вариант - отшлифовать код генерации блоков. что-то мне кажется, что я недостаточно уделял ему внимания. Это, пожалуй, обязательно.
Третий - многообещающий и в то же время рискованный. БГЕ может меня неправильно понять и сильно обидеться. Вплоть до зависания и вылета. Но попробовать надо. Суть в том, что грузится ВЕСЬ ландшафт - все блоки сразу на игровую сцену. И на ней происходит замена мешей блоков на плейны. Маленькие. Но физика-то меша должна сохраниться, как мне объясняли. Грузим ландшафт второй раз, но МЕШЕМ, из дугого файла. Дальше получается довольно приличное количество плейнов в виде "ячеек", которые будут подменяться мешаи по мере приближения к ним камеры. Проблема в том, что у меня ландшафт имеет 640 килополиков и комп начинает подтормаживать. Не в БГЕ, а в редактировании. Но не знаю, выдержит ли движок такую лютую нагрузку, пусть и на короткое время... Во всяком случае = первый вариант при этом можно применить. Или сделать блоки меша очень сильно низкополигональными. Да, пожалуй, стоит и это попробовать...
Ну, и завершаю пост красивыми (как без них) картинками.
МиГ-23МФ ВВС Ливии. Тест на замену мешей.
МиГ-23БН ВВС Ливии. Тест на анимацию механических частей.
МиГ-23МЛАЭ ВВС Ливии - тест на анимацию шасси.
На данный момент все движения и трансформации, за исключением вращения колес шасси, пламени форсажа и свечения турбины задаются изменеием всевозможных проперти. Несомненным достоинством этого метода является возможность избежать резких рывков анимации и прыжков скоростей. Особенно это касается анимаций аэродинамических поверхностей, "рывки" при кренах, тангаже и рыске были настоящим проклятием - было отчетливо видно, как резко "дергается" стабилизатор или элерон при смене курса. Также не вызывало особого восторга стремительное, почти мгновенное возрастание скорости при смене стреловидности или выпуске тормоза. Теперь проперти, управляющие кадрами анимации, интегрированы в модель полета. Это можно рассмотреть на примере выпуска-уборки щитков воздушного тормоза.
Как выглядит работа анимации тормоза:
if own['levelsDetails'] == 0:
#Собственно, анимация щитков тормоза - кадр анимации задается значением проперти AIRBRAKE
for obj in own['localDict']['deviceAirbrakes']:
obj.playAction(obj.name,own['AIRBRAKE'],own['AIRBRAKE'],0,0,0,bge.logic.KX_ACTION_MODE_PLAY,0.0,0,1.0)
#Выпуск тормоза
if own['localDict']['AIRBRAKE'] < own['AIRBRAKE'] and own['AIRBRAKE'] < 100:
own['AIRBRAKE'] += 1
if own['AIRBRAKE'] == 100:
own['localDict']['AIRBRAKE'] = own['AIRBRAKE']
#Уборка тормоза
if own['localDict']['AIRBRAKE'] > own['AIRBRAKE'] and own['AIRBRAKE'] > 1:
own['AIRBRAKE'] -= 1
if own['AIRBRAKE'] == 1:
own['localDict']['AIRBRAKE'] = own['AIRBRAKE']
Думаю, понятно. Вверху указывается - что работа анимации происходит только при высоком уровне детализации и наличия соответствующих деталей-потомков (списко deviceAirbrakes). Кадр анимации жестко привязан к занчению проперти AIRBRAKE. Само проперти работает от команд с клавиатуры (но для ботов - разницы никакой - там просто при выполнении ряда условий происходит отдача точног такой же команды):
###################################################
#Выпуск-уборка воздушного тормоза
if keyboard.events[bge.events.AKEY] == JUST_ACTIVATED:
if self['AIRBRAKE'] == 1:
self['AIRBRAKE'] += 1
elif self['AIRBRAKE'] == 100:
self['AIRBRAKE'] -= 1
#Если оверлейная сцена с кокпитом уже работает
for sceneGame in bge.logic.getSceneList():
if sceneGame.name == 'Cockpit':
cockpit = sceneGame.objects['Cockpit']
cockpit['airbrake'] = self['AIRBRAKE']
то есть достаточно просто "подтолкнуть" проперти вперед или назад один раз. и пока проперти не получит самого большого или самого маленького значения, будет продолжаться его нарастание или убывание. Для тормоза эти значения равны 1 и 100. Аналогично происходит выпуск-уборка шасси, закрылков, смена стреловидности, открытие фонаря и так далее. Но и это не все. величина проперти AIRBRAKE еще и влияет на скорость полета. Упрощенно - скорость задается какой-то формулой, в составе которой имеется и AIRBRAKES, только вот значение его используется не прямо, а вот так:
151/(150 + AIRBRAKES)
Поясняю - минимальное значение проперти равно 1 - тормоз убран. И мы имеем в итоге 1. Скорость не падает. Но стоит только выпустить тормоз, как в конце анимации мы получаем 151/(150 + 100). Что-то коло 0.6. Тормоз действует, "съедая" сорок процентов скорости. Но при этом эти проценты съедаются постепенно - с каждым тиком - с каждым кадром анимации.
Добившись четкой работы анимации всех деталей, я занялся дальнейшей доводкой кокпитов и пополнением авиапарка. Пока он состоит лишь из модификаций МиГ-23, да и то - одной национальности - ВВС Ливии полковника Каддафи. изначально я собирался делать версию про египетско-ливийскую войну 1977, да ещ и не сильно отходя от, как мне казалось тогда, незыблемых канонов. оказалось, каноны не такие уж незыблемые...
Пришлось немного повоевать с моделью движения самолета. Если с разворотами все оказалось более-менее понятно - с применением силы Torque, да и с новым методом учета стрелодидности - картинка получалсь архизамечательная по сравнению с первой версией, то вот с линейным движением вышел облом. Как оказалось, сила, толкающая объект вперед, не компенсирует силу тяжести, увы. Так что пришлось опять прибегнуть к localLinearVelocity. Хотя она рассчитывается по-другому, и, как я говорил, ее изменение стало более плавным и реалистичным... Но это дело можно совершенствовать по мере дальнейшего продвижения вперед, так что, кто его знает, что в итоге получится.
Всплыла еще одна не слишком приятная проблема. Ландшафт. С ним я воевал долгог и упорно, и, казалось, победил. но не совсем. При возросших скоростях движения вдруг выяснилось, что его подгрузка не поспевает за камерой и, что хуже всего, просаживает ФПС и сильно при увеличении частоты работы. Однако варианты все же есть и можно попробовать их несколько.
Первый - увеличить размеры блока, что приведет к уменьшению их числа,а, значит, можно даже уменьшить количество обновлений террайна в игре.
Второй вариант - отшлифовать код генерации блоков. что-то мне кажется, что я недостаточно уделял ему внимания. Это, пожалуй, обязательно.
Третий - многообещающий и в то же время рискованный. БГЕ может меня неправильно понять и сильно обидеться. Вплоть до зависания и вылета. Но попробовать надо. Суть в том, что грузится ВЕСЬ ландшафт - все блоки сразу на игровую сцену. И на ней происходит замена мешей блоков на плейны. Маленькие. Но физика-то меша должна сохраниться, как мне объясняли. Грузим ландшафт второй раз, но МЕШЕМ, из дугого файла. Дальше получается довольно приличное количество плейнов в виде "ячеек", которые будут подменяться мешаи по мере приближения к ним камеры. Проблема в том, что у меня ландшафт имеет 640 килополиков и комп начинает подтормаживать. Не в БГЕ, а в редактировании. Но не знаю, выдержит ли движок такую лютую нагрузку, пусть и на короткое время... Во всяком случае = первый вариант при этом можно применить. Или сделать блоки меша очень сильно низкополигональными. Да, пожалуй, стоит и это попробовать...
Ну, и завершаю пост красивыми (как без них) картинками.
МиГ-23МФ ВВС Ливии. Тест на замену мешей.
Комментариев нет:
Отправить комментарий