Движок и др

[Igors]

Добрый день

Тут смотрю народ вовсю юзает термин "движок" (и даже "движек") на все случаи жизни. Дай думаю и себе поюзаю 

Есть движок упр-я 3D моделями, обычно character'ами (персонажами). Упр-е осуществляется командами (точнее BML). Выглядит примерно так: дана команда "идти" - char идет, "поворот" - поворачивает и.т.п. Есть также и "одноразовые" команды - напр сделать какой-то жест рукой. Это довольно легко превратить в "игровое" управление от клавиш.

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

"Линейка времени" - это любое число параметров (чисел) которые могут меняться во времени фильма. Простой пример: упр-е положением объекта. Юзер двинул слайдер времени напр на кадр 10 и перетащил объект в  "точку 1". Затем на кадре 20 поместил объект в "точку 2". Ну вот от кадра 10 до 20 объект движется из одной точки в другую.

Проблема в том что "линейка" плохо дружит с "движком". Напр "расстановка положений" (как в примере выше) здесь ничего хорошего не дает, придется приложить массу совершенно бесполезных усилий чтобы обеспечить прибытие char'а "в точку 2" точно в заданное время, ведь char не пассивный объект, у него есть своя скорость, поведение и.т.п. 

Какие есть мысли и/или познания?

Спасибо

[Old]

Проблема в том что "линейка" плохо дружит с "движком". Напр "расстановка положений" (как в примере выше)

Откладывайте на линейке времени не точку откуда и точку куда, а действия для движка:
в точке времени 1 начать поворот персонажа по азимуту 45, по окончанию поворота, запустить ходьбу, в точке пространства XYZ, остановить ходьбу.

Движок знает сколько времени требуется на поворот персонажа, знает его скорость и может сам вычислить точку 2 на линии времени, в которой скрипт завершиться.

[Igors]

Движок знает сколько времени требуется на поворот персонажа, знает его скорость и может сам вычислить точку 2 на линии времени, в которой скрипт завершиться.

Движок работает "кадр за кадром" используя текущие установленные данные, вычислять какое-то "будущее" он не собирается.

Откладывайте на линейке времени не точку откуда и точку куда, а действия для движка:
в точке времени 1 начать поворот персонажа по азимуту 45, по окончанию поворота, запустить ходьбу, ..

А тогда возникает капитально неприятная проблема: нет никакого feedback'а. Напр на кадре 5 был "поворот налево", теперь юзер изменил, сделал "направо" - и это меняет все кадры после 5-го. Придется запускать движок с нуля чтобы пересчитать все, и так на каждый чих. Такое "слепое" редактирование вряд ли устроит юзера.

[Old]

Движок работает "кадр за кадром" используя текущие установленные данные, вычислять какое-то "будущее" он не собирается.

Вы рендер называете движком?
Движок это комплекс подсистем, и рендер только одна из этих подсистем.
Движок должен уметь вычислять "будущее", ему на вход приходит интервал времени прошедший от предыдущего обновления состояний объектов, а он должен вычислить в какие позы перешли объекты спустя указанное время.

Напр на кадре 5 был "поворот налево", теперь юзер изменил, сделал "направо" - и это меняет все кадры после 5-го. Придется запускать движок с нуля чтобы пересчитать все, и так на каждый чих.

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

[Igors]

..и теперь чар вместо пустынной дорожки идет по оживленной площади, где..

Так что с редактированием на линейке? Есть предложения?

[Old]

Так что с редактированием на линейке? Есть предложения?

Выше же.

[Igors]

В общем, на "линейке времени" нужно ставить крест, из нее здесь ничего не выжать. Поинтересовался как др приложения решают схожие проблемы - везде так или иначе граф. Да, но как его мой юзер будет строить и что в том графе должно быть - хз. Вот в общих чертах базовая система:

- есть записанные (обычно с датчиков) движения char'ов (motions) и в конце-концов все сводится к проигрыванию этих движений во времени (с разнообразными миксами, blend'ами, переходами).  Движения сменяют друг друга во времени,могут являться миксами неск исходных (при этом весами нужно как-то управлять). Продолжительность одного motion обычно невелика, секунд 5 и меньше.

- есть 3 основных независимых слоя управления на которых вычисляется анимация, последние 2 аддитивны. Напр первый слой занимается ходьбой, а второй отвечает за жесты руками. Упр-е сводится к назначению подходящих motions с набором опций, напр:
    - loop (движение зациклено)
    - once (одноразовое)
    - N times (заданное число раз)
    и др

 На всякий случай напомню что надо получить: средства упр-я с помощью которых юзер может управлять поведением char'a во времени. Напр (очень упрощенно) char сидел, затем встал, помахал ручкой и ушел.

И как-то я тут совсем растерялся-запутался Не удается выделить "сущности", построить хоть какие-то классы (пусть сначала и не идеальные). Ну да, если "граф", то значит "ноды". Ну и что? Что должно быть в ноде и как контролировать переход от одного нода к другому? Пытался зацепиться за какой-то конкретный пример, да, так вроде "все укладывается в общую схему" - но увы, для другого (тоже простого) примера так уже не выходит.

[Igors]

Вот, казалось бы, "элементарный пример" поведения

идет - остановился - сел - посмотрел на цель

Каждый текст -  "нод" графа, прямоугольник, ну а в нем опции (напр сколько секунд "идет"). Соединяем их стрелками - готово!

Не тут-то было. "Посмотрел" сюда не вписывается - ведь это действие не сменяет предыдущее ("сидит"). Выходит "сел и посмотрел" должно быть в одном (составном) ноде. Да, но "посмотрел" может начаться совсем не одновременно с посадкой, как этим управлять из графа?

Хорошо, идет-стоит-сидит = один "канал упр-я", а вот "смотрит (на)" - уже другой. Пусть упр-е этими каналами будет независимым. Разумно, но "смотрит" может зависеть от др канала - напр должен смотреть только когда сел (а не когда шел). Хмм... и что должно рисоваться в графе?

Плюс на все это логика if (триггера). Напр "смотрит" обычно связано с каким-то объектом (напр шариком), т.е. если шарика пока нет - то и смотреть не на что, действие не имеет эффекта.

Мдааа... вообще "операции со временем" наименее интуитивны