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

Зачем Юнити своя физика ? (7 стр)

Страницы: 1 2 3 4 5 6 7
#90
12:26, 3 апр. 2019

GLoom
например сила гравитации F=mg
Что лучше?
1 написать программу код F=mg
2 включить этот плагин Физика и там настроить вот тут шарик и вот он падает вниз,вот тут земля и шарик встретился с землей=упал.
?


#91
12:51, 3 апр. 2019

Rikk
Какой то очень странный вопрос. Что в итоге ты хочешь получить то? Если ты хочешь показать как шарик движется с ускорением можно просто в Update формулу забить. Если тебе нужны столкновения, события и обобщённое решение - нужна полноценная система.

#92
13:10, 3 апр. 2019

GLoom
> Какой то очень странный вопрос. Что в итоге ты хочешь получить то?
что странного?
1 это шутер — пуля в тело
2 это танчики —снаряд в броню
3 это стратегия—-гаубица в окоп
4 это бомбы — в дом
5 это спортивный теннис—ракетка в мячик
6 это исторические — лук и арбалет стрельба навесной траекторией
это дофига ситуаций и моментов .
см тема — гугл—- падение на землю, упругий удар шаров, неупругий удар.
хочу наверное получить универсальную систему по физике продавать за миллион долларов , а вам останется только менять графику типа вместо шарика=снаряд а вместо земли=танчик

#93
14:10, 3 апр. 2019

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

В чём собственно вопрос?

#94
(Правка: 14:26) 14:22, 3 апр. 2019

Rikk
Смысл ECS - такое разделение данных и кода, чтобы коду на обработку можно было а) подавать данные большими непрерывными пачками; б) подавать только те данные, которые реально нужны, а не всё вперемешку. Цель - увеличить скорость обработки.

Если мы пишем физику с нуля и хотим реализовать гравитацию в стиле F = mg, то есть два противоположных подхода (и куча промежуточных):

1. "Привычный"

На каждый объект повесить компонент Rigidbody, в котором, в соответствии с традициями ООП, будет
а) храниться масса m;
б) иметься галочка affected by gravity;
в) храниться куча других данных, ненужных для расчёта гравитации, но нужных для чего-нибудь ещё;
г) иметься некий Update-код, который среди прочего проверяет состояние галочки, и если включена, прикладывает к телу силу в соответствии с его массой.

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

2. ECS

На объекты вешается три компонента:
а) компонент Mass, который только хранит массу и всё;
б) компонент Force, который только хранит приложенную в данный момент к объекту силу;
в) компонент AffectedByGravity, который ничего не хранит, выступает в роли флага.

И пишется система GravitySystem, которая хранит только логику обработки этих данных:
а) из всего множества объектов выбираются только имеющие одновременно компоненты Mass, Force и AffectedByGravity (при этом получаются непрерывный массив значений массы и непрерывный массив значений силы);
б) тупо в цикле по массивам масса умножается на g и результат добавляется к значению силы.

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

--
Плюсы у ECS-подхода определённо есть, но использовать ли его в каком-то конкретном случае - надо решать самому.

#95
14:42, 3 апр. 2019

Rikk
поверю, но это всё можно сделать примитивным обсчётом. Примитивный обсчёт будет быстрым, простым и предсказуемым. Полноценный физический движок не нужен же в этой ситуации.

#96
15:58, 3 апр. 2019

alexzzzz
> Т.к. данные лежат компактно, все обращения к ним проходят через процессорный
> кэш,
а если данные не компактно то не проходят через процессорный кэш
?

#97
(Правка: 16:27) 16:22, 3 апр. 2019

Rikk
Вот есть данные объектов подряд: A B C D E F A B C D E F A B C D E F A B C D E F A B C D E F
Из всех данных тебе нужно только поле B, а остальные поля только занимают место, и в одну кэш-линию помещается, например, всего четыре значения B, вместо шестнадцати.

Это не самый плохой случай. Если данные объектов разбросаны по памяти, то в худшем случае чтение любого поля B - это почти наверняка cache-miss и в 100 раз медленнее, чем чтение из L1.

Когда у множества объектов надо прочитать некоторое значение B, то в идеале эти значения должны лежать в памяти подряд: B B B B B B B B... ECS стремится сделать, чтобы ровно так и было.

#98
17:12, 3 апр. 2019

alexzzzz
> и в одну кэш-линию помещается, например,
что такое кэш-линия зачем она нужна чего делает

#99
17:20, 3 апр. 2019

Если ты по делу спрашиваешь, то посмотри/почитай в интернете.
Если чисто поспорить о формулировках, то без меня.

#100
17:31, 3 апр. 2019

alexzzzz
> то без меня.
ну конечно, ведь тут начинается момент когда не списать готовенький урок а самим надо напрягать мозги

#101
17:49, 3 апр. 2019

alexzzzz
> На каждый объект повесить компонент Rigidbody, в котором, в соответствии с
> традициями ООП

это не правда

#102
18:20, 3 апр. 2019

innuendo
Не в соответствии с ООП повесить компонент, а в соответствии с ООП внутри компонента объединить и данные, и логику.

#103
18:51, 3 апр. 2019

alexzzzz
> а в соответствии с ООП внутри компонента объединить и данные, и логику.

лет 5 назад был такой же спор с Пушковым ...

ООП запрещает делать так

class RigidBody {

Mass* mass;
Force* force;

}

#104
19:51, 3 апр. 2019

Я не знаю сути спора и того, что ты имеешь в виду.

Страницы: 1 2 3 4 5 6 7
ПрограммированиеФорумФизика