Войти
ПрограммированиеФорумГрафика

Архитектурные вопросы (3 стр)

Страницы: 1 2 3
#30
15:37, 2 ноя. 2019

0xc0de
Да с какого перепуга меши растягиваться начнут? Я же сказал, и у длинного и у короткого свои родные скелеты с ОДИНАКОВОЙ топологией. Художник сделал мне анимацию для длинного. Теперь дабы сэкономить ресурсы я хочу проиграть ту же самую анимацию на коротком скелете. Вопрос в этом:) В ближайшее время собираюсь заняться как раз вопросом шаринга анимаций между скелетами и поэтому пытаюсь перенять твой опыт:)
Aroch
Ну вот такое поведение я и ожидаю.. есть ли алгоритмы может какие, чтоб как-то компенсировать различные длины костей у разных скелетов?

#31
(Правка: 16:31) 16:01, 2 ноя. 2019

AMM1AK
> Да с какого перепуга меши растягиваться начнут? Я же сказал, и у длинного и у
> короткого свои родные скелеты с ОДИНАКОВОЙ топологией.

Топология то одинаковая, но локальная трансформация кости в момент времени t хранится именно в анимации, а не в скелете.

Трансформация кости = поворт,масштаб,позиция - все это относительно трансформации родительской кости. Теоретически, если забить на позицию и масштаб в анимации и вынести их в скелет, а в анимации кости оперировать только поворотами, то можно анимацию длинного переложить на короткого и наоборот - ведь анимируются только повороты. Но вот как это будет смотреться - х.з.

#32
(Правка: 16:14) 16:13, 2 ноя. 2019

тело меша обволакивает кость.
двигаешь кость - за нею вслед движутся вершины vertex меша.
это удобнее чем если метко выделять 100вершин и их двигать — объект кость выделил одна штука и подвинул—подвинутся 100вершин.
значит если рука человека=70см =это одна кость
если рука=85см это совсем другая кость+другие вершины вокруг кости=совсем другая анимация

значит по идее один меш=один скелет костей который соответствует этому конкретному мешу
если другой меш=это совсем другой скелет и совсем другие кости
1меш=1скелет

#33
17:19, 2 ноя. 2019

не изобретайте велопед - посмотрите как в UE

#34
0:14, 3 ноя. 2019

AMM1AK
> есть ли алгоритмы может какие, чтоб как-то компенсировать различные длины
> костей у разных скелетов?
как ты их будешь компенсировать? IK может немного помочь, но до определенных пределов. Дальше уже совсем другая анимация понадобится. С нормальным ростом просто сядет на стул, а карлик вынужден будет карабкаться на него.

#35
2:42, 22 янв. 2020

Назрел второй вопрос :)

Должны ли материал-инстансы тикать?
Реализовал материалы следующим образом: материал - есть граф (аналог анриловского blueprint), который транслируется в набор шейдеров и пайплайнов рендер бэкэнда. Есть material instance, который определяет входные параметры материала (текстуры, константы) и устанавливается для MeshComponent.
Собственно для динамического изменения состояния материала (управления константами/текстурами) имеют право на существование следующие варианты:
1) изменение осуществлять в логике актора (Tick/PrePhysicsTick/PostPhysicsTick/etc), где актор при необходимости изменяет параметры MaterialInstance-а
либо
2) дать возможность MaterialInstance-ам тикать самим, т.е. добавить им метод(ы) обновления, сделав их некими "живыми" сущностями, состояние которых обновляется на каждом кадре (или при попадании в область видимости).

ПС:

class Actor {
   Vector<ComponentPtr> Components;
   virtual void Tick(float TimeDelta);
};
class MeshComponent : Component {
  MaterialInstancePtr MatInstance;
  MeshResourcePtr Mesh;
};
class MaterialInstance {
  MaterialResourcePtr Material;
  Vector<float> Constants;
  Vector<TextureResourcePtr> Textures;
  //virtual void Tick(float TimeDelta);
};

#36
2:49, 22 янв. 2020

0xc0de
Дать возможность материалам подписываться на рассылку тиков:
Tick/PrePhysicsTick/PostPhysicsTick/PreRenderTick
И если материал меняет только визуальные свойства - то он подписывается на PreRenderTick, если материал меняет еще и физические свойства - то подписывается на PrePhysicsTick

#37
3:11, 22 янв. 2020

MrShoor
> Дать возможность материалам подписываться на рассылку тиков:
> Tick/PrePhysicsTick/PostPhysicsTick/PreRenderTick

Я вот сейчас подумал, а ведь тогда придется еще и добавлять OnBeginPlay/OnEndPlay. Т.е. по сути MaterialInstance будет обладать функциями Actor-а, что не есть хорошо (два разных типа объекта со схожим функционалом), появится соблазн из материала влиять на внешнюю среду и осуществлять не свойственную материалу игровую логику.

#38
3:40, 22 янв. 2020

0xc0de
> а ведь тогда придется еще и добавлять OnBeginPlay/OnEndPlay
Куда ты их собрался добавлять? Ты хочешь узнать когда материал закончил меняться или что?

#39
9:11, 22 янв. 2020

0xc0de
> Должны ли материал-инстансы тикать?
недостаточно передать time в шейдер-материал?

#40
(Правка: 9:35) 9:35, 22 янв. 2020

0xc0de
> Должны ли материал-инстансы тикать?
В приниципе звучит интересно.

>следующие варианты
Но пока особо не видно особого профита 2-го варианта по сравнению с 1-ым.

#41
11:49, 22 янв. 2020

MrShoor
> Куда ты их собрался добавлять

Пока не собрался :) в MaterialInstance.

innuendo
> недостаточно передать time в шейдер-материал?

Так уже и есть. Все передается. Просто размышления над тем, кому лучше устанавливать входные параметры для материала. Т.е. владелец/внешняя среда материала говорит, установи мне такую-то текстуру или материал спрашивает у владельца или у внешней среды какую текстуру ему сейчас отображать. Зависимость необязательно от времени.

ПС: сейчас больше склонен к первому варианту.

#42
(Правка: 15:19) 15:18, 22 янв. 2020

0xc0de
>>Должны ли материал-инстансы тикать?

Вопросы такого рода в первую очередь про сериализацию. Если состояние материалов предполагается сохранять, то конечно. Если нет, значит придётся чем-то пренебречь. Ну например для короткоживущих примитивов, типа гаснущих декалей, сохранение обычно не делают.


А вообще все движкописатели попадают в логическую ловушку. Если движок пилится под конкретную игру, он будет чаще всего кривой, косой, но зато на нём будет игра. А абстрактный движок обычно пишется как самый лучший в мире ну и с соответствующим итогом :)

Страницы: 1 2 3
ПрограммированиеФорумГрафика