Сценарий действия сил

[Igors]

Добрый день

В симуляции участвуют 3D объекты которые движутся под воздействием разнообразных "сил". Напр в симуляции участвуют

Sphere1  // простой 3D объект - шарик
Sphere2  // еще 1 шарик
Cube1     // кубик
// любое число еще каких-то объектов

Force_Wind  // простая сила типа "ветер", смещает 3D объекты в заданном направлении
Force_Path  // сила двигающая объекты по заданному пути
Force_Seek  // сила двигающая каждый объект к заданной точке

Сейчас никаких сценариев нет, просто все силы прилагаются ко всем объектам. И вот вылазит проблема - силы могут оказаться "несовместимы". Напр сумма сил Force_Path + Force_Seek дает в рез-те полную ерунду. Зато есть смысл применить их последовательно, напр: шарики сначала следуют по заданному пути (действует Force_Path). Когда шарики проходят весь путь, они начинают лететь к заданным точкам (Force_Seek). Достичь этого простыми средствами не удается - одни шарики могут уже закончить движение по пути, другие еще нет, а для третьих движение по пути еще и не начиналось. Поэтому обе силы должны быть по-разному активны/неактивны для разных шариков/объектов.

Также юзер может захотеть по-всякому использовать Force_Wind. Возможно он захочет добавить "легкий ветерок"  действующий одновременно с 2 др силами. Но может и по-другому - только когда шарик достиг заданной (Force_Seek) точки - он сдувается штормовым ветром.

Конечно реализовать каждый конкретный случай "просто в коде" не составляет никакого труда - но это "hard-coded". А надо в общнм виде, дать юзеру возможность создать произвольный сценарий. Как это лучше сделать, и как это должно выглядеть в UI?

Спасибо

[panAlexey]

Поставлю закладку, тоже интересует как это все делается.
ПС. У меня самого есть хотелка повозиться с такими вещами, сделать "каратиста" котроры бы на экране наносил бы удары в сторону смотрящего на экран. Хотелось бы знать как сделать.

[ssoft]

И вот вылазит проблема - силы могут оказаться "несовместимы". Напр сумма сил Force_Path + Force_Seek дает в рез-те полную ерунду. Зато есть смысл применить их последовательно,

Что значит "несовместимы"? Если имитация имеет физический смысл, то вектор результирующей силы как раз будет равен сумме всех действующих сил.

[Igors]

Что значит "несовместимы"? Если имитация имеет физический смысл, то вектор результирующей силы как раз будет равен сумме всех действующих сил.

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

[ssoft]

2 силы имеют нормальный смысл каждая - но не обе вместе.

Если силы действуют при разных обстоятельствах, то у объекта должны быть состояния, с каждым из которых соотнесен перечень сил, действующих на него.
Переход из одного состояние в другое определяется фактом завершения какого либо сценария (объект проходит по заданному пути -> объект возвращается в исходную точку).

[Igors]

Если силы действуют при разных обстоятельствах, то у объекта должны быть состояния, с каждым из которых соотнесен перечень сил, действующих на него.
Переход из одного состояние в другое определяется фактом завершения какого либо сценария (объект проходит по заданному пути -> объект возвращается в исходную точку).

С этим никто не спорит, но как это организовать, и как это должно выглядеть для юзера (UI) ?

[Racheengel]

Да, наверное, как и в других подобных приложения (типа флэша, например).
У каждого объекта есть таймлайн, на определенные моменты времени вешаются определенные экшены (силы в данном случае), и их время действия. Двойной клик по экшену откроет его параметры. Как-то так, наверное.

[Igors]

Да, наверное, как и в других подобных приложения (типа флэша, например).
У каждого объекта есть таймлайн, на определенные моменты времени вешаются определенные экшены (силы в данном случае), и их время действия. Двойной клик по экшену откроет его параметры. Как-то так, наверное.

Как уже говорилось, это не катит

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

[ssoft]

Для юзера это может выглядеть так:

С каждым объектом связывается схема состояний и условий перехода между ними, ее можно представить в графическом виде.
В простейшем случае можно ограничится списком состояний (сценарием).
В качестве условий перехода можно предложить: временной интервал, достижение определенного положения в пространстве, может чего-то еще.

Сами схемы сценариев пользователь формирует отдельно, затем для разных объектов может задать разные или одинаковые сценарии.

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

[Igors]

Для юзера это может выглядеть так:

С каждым объектом связывается схема состояний и условий перехода между ними, ее можно представить в графическом виде.
В простейшем случае можно ограничится списком состояний (сценарием).

Неясно в чем разница и что такое "просто список"? Как же обойтись без переходов?

В качестве условий перехода можно предложить: временной интервал, достижение определенного положения в пространстве, может чего-то еще.

Сами схемы сценариев пользователь формирует отдельно, затем для разных объектов может задать разные или одинаковые сценарии.

Один из пользователей предложил такой вариант: каждая сила имеет параметр, целое число "приоритет". Значение -1 = "сила действует всегда", иначе силы применяются в порядке убывания приоритета. Напр если есть сила с приоритетом 10, то силы с приоритетом 9 неактивны до тех пор пока 10 не закончена для данного объекта (напр достигнут конец пути или точка назначения).

Это можно сделать "по-быстрому", но уж слишком чмошно. Все-таки "состояния" нужны, как говорится, это "сущность". С др стороны выплывает совсем немаленький редактор, и пока я очень смутно представляю как он должен выглядеть.

Да, кстати, а почему до сих пор еще не прозвучало (Q)StateMachine ?
 

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

До боли знакомая песня Мол, чтобы что-то решить - нужно знать все-все подробности проекта. В результате перегрузка информацией, 99% которой только мешает, суть дела просто тонет в ненужных деталях. Может это просто отсутствие абстрактного мЫшления?  

[ssoft]

Неясно в чем разница и что такое "просто список"? Как же обойтись без переходов?

Список - это упрощенная форма. Переход к следующему состоянию в списке происходит сразу по окончанию предыдущего. В этом случае есть начало и конец, переход тривиальный, соответствует безусловному окончанию конкретного состояния.
Более сложный вариант - граф состояний, когда по разным условиям возможны переходы в разные состояния.
Список проще в реализации, можно обойтись, например, только табличным представлением. Граф потребует реализации уже какого-то графического редактора.

Да, кстати, а почему до сих пор еще не прозвучало (Q)StateMachine ?

QStateMachine - это всего лишь один из возможных инструментов, не факт что в данном случае удобный.

До боли знакомая песня Мол, чтобы что-то решить - нужно знать все-все подробности проекта. В результате перегрузка информацией, 99% которой только мешает, суть дела просто тонет в ненужных деталях. Может это просто отсутствие абстрактного мЫшления? 

К сожалению, 99% успеха зависит от понимания конечной цели, которая может быть выражена всего парой тезисов. Абстрактные вопросы порождают абстрактные ответы .
Тем не менее, если мы обсуждаем серьезный продукт с возможностью пользователю управлять поведением объектов, то без состояний и редактора не обойтись.

* Каждое состояние может иметь 1 вход и N выходов, каждый из которых соответствует какому-либо условию выхода из данного состояния.
Например, 1 - закончилось заданное время, 2 - достигли точки назначения, 3 - нажатие кнопки мыши (условие с параметром) , и т.п.

* Соединить можно только выход и вход с одинаковыми выходными/входными параметрами.
* Каждый выход и вход может быть соединен только один раз.
* Пользователь должен задать начальное состояние для объекта.
* Пользователю доступны состояния только из библиотеки состояний.
* Каждое состояние, кроме входящих параметров, может иметь и индивидуальные настройки.
* С разными объектами может быть соотнесен как разные, так один и тот же граф состояний.

Можно попробовать обойтись переходами и без параметров, это будет немного проще.

[Igors]

Например, 1 - закончилось заданное время, 2 - достигли точки назначения, 3 - нажатие кнопки мыши (условие с параметром) , и т.п.

Переход - это по существу реакция на "событие". Сейчас существуют такие события

1) Начало действия силы, которое может быть разным для разных объектов. Напр действует сила "Wander" (что-то типа броуновского движения). В какой-то момент времени появляется др сила действующая на объект, напр "Path" или "Seek". Очевидно нужно переключить объект в др состояние в котором "Wander" уже неактивна
 
2) Окончание действия силы - примеры уже были выше. Но только немногие силы имеют такую опции

3) Изменение поведения самой силы, напр сила Seek выдает событие когда объект приблизился к цели на заданное расстояние. Используется для "посадки" летящего объекта.

Да, возможно появятся и др события. Напр "истекло заданное время" вполне разумно. Кнопка мыши нет - симуляция не интерактивна. Ну и хорошо, появятся так появятся, что это меняет в общей схеме? По-моему ничего, ну добавится константа + строка. Также общее число сил невелико, обычно < 5. Ну десяток отсилы, хотя трудно представить для чего так городить.

По поводу "упрощенного списка" - ну как-то вряд ли, "окончание предыдущей" всего лишь один вариант.

* Каждое состояние, кроме входящих параметров, может иметь и индивидуальные настройки.

Да

[Bepec]

На деле опять идёт словоблудие в теме.

Как описать силы?
Список сил, для каждой силы период/время/усилие/условие завершения/условие начала.

Как описать взаимодействие сил?
Никак. Рассчитать пару тройку сценариев для объекта и их на выбор добавлять к силе. К примеру "прекращение других сил", "прекращение горизонтального/вертикального усилия", "остановка", "пауза".

Силы друг с другом не взаимодействуют и получается полный бред, как рассчитать?
Рассчитывается лишь общий сдвиг, основываясь на применяемых к объекту силах и взаимодействиях.

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

Таймлайн не катит

Бред сивой кобылы. У вас симуляция растянутая по времени. Таймлайн у вас будет всегда в том или ином виде. Мб это будет счетчик тиков обработки, мб кратность симуляции, но в любом случае это будет ось времени для рассчитываемых объектов.


По сути получается следующие варианты для юзера.
Список общих сил
Список объектов
    Список сил для каждого объекта
Список контрольных точек (дублирующихся на таймлайне и доступных для выбора в настройках сил)

Примерный список свойств силы: название силы, время, периодичность, усилие, направление, условие завершения, условие начала, контрольная точка начала, контрольная точка завершения.
    Возможно добавление формулы расчёта в зависимости от переменных. К примеру "x=height/2" с направлением вниз, даст скорость падение в половину высоты, или же "x=time*0.1" - подобие усиливающегося ветерка.

[Igors]

На деле опять идёт словоблудие в теме.

От словоблуда слышу. Ну вот какого лезть если ни хрена не соображаете?

Бред сивой кобылы.

Да еще так борзо

У вас симуляция растянутая по времени. Таймлайн у вас будет всегда в том или ином виде. Мб это будет счетчик тиков обработки, мб кратность симуляции, но в любом случае это будет ось времени для рассчитываемых объектов.

Для особо одаренных еще раз повторяю.

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

А для Вас еще разжую: даже если я создам 1000 осей (для каждого из объектов) - юзер не сможет ими рулить. Поэтому ось времени одна

Ще раз: нема тями - слухай мовчки

[Bepec]

Igors я вам о том же говорю. Таймлайн будет в любом случае. Одна ось. Она одна для всех объектов. Разниться будут только рассчитываемые силы.
Разность сил мы можем изобразить, используя иерархию и свойства сил для каждого объекта.

Одна ось, силы общие и силы персональные для объектов. Вот что получится в результате. Потому что они в исходных данных и более ничего.

Вы просите решение простой проблемы. Обобщить данные и создать на основе обобщения модель для расчётов. И для этого не нужно ни образования, ни великого ума или таланта, всего лишь нужно развитое мышление.

PS такую вот модельку любой студент напишет за пару часов. Основная проблема в том, что вы пытаетесь объять всё сразу и немедленно. Так не получится. Создайте основу, пускай простую, и дорабатывайте её.