Этого треда уже нет.
Это копия, сохраненная 24 июня 2020 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
db6486421d2282d555d5ac5af577aafc.png95 Кб, 933x943
Для чего нужно ECS? Какие проблемы и задачи оно решает? 1620402 В конец треда | Веб
Для чего нужно ECS?
Какие проблемы и задачи оно решает?
3 1620412
>>20402 (OP)
Ты про это что ли?
https://en.wikipedia.org/wiki/Entity_component_system
Так там всё написано. Можно представить всю предметную область в виде сущностей, к которым можно легко добавлять какие-то конкретные фичи, либо убирать их.
4 1620419
>>20408
>>20412
Приведите простые и понятные примеры
5 1620431
>>20419
Ты чо спортсмен?
6 1620434
>>20419
Пример с твоей пикчи - компонент Collision, без него сущности в игровом мире не могут физически сталкиваться с другими сущностями и проходят при движении сквозь них. Ты добавляешь этот компонент к своим сущностям, и физический движок может начать обрабатывать столкновения. Другой пример - Material. Поверхность всех объектов с таким компонентом будет выглядеть одинаково. Если меняешь настройки этого компонента, это влияет на все сущности, использующие этот компонент.
Потыкай какой-нибудь Unity, там это юзается вовсю.
Ещё это похоже на примеси (mixin) в некоторых языках.
7 1620438
>>20434
Миксины это синтаксис УСЫ - это парадигма хорошо ты сравнил
8 1620455
>>20434
В юнити я знаю, можно добавлять коллайдер, материал, скрипт. Это там всегда было, и они это не называли ECS. А сейчас какую-то новую систему скриптов вводят, которая ECS.
9 1620463
>>20402 (OP)
До тебя наверное доходили слухи что композиция лучше наследования. ECS это доведенная до максимума композиция, вплоть до того что части из которых состоит сущность можно менять динамически (хотя конечно не факт что какая-то конкретная система поддерживает такое).
10 1620476
>>20402 (OP)
Те же проблемы и задачи, что и ООП или ФП. Лишь одно из средств или парадигм организации програмной системы. Очень часто встречается в игровых движках. Очень полезно для симуляций всякого рода. То-есть если у тебя есть дохуя всяких агентов (юнитов, атомов, вокселей, вертексов, партиклов итд) и каждый фрейм у них по каким-то общим правилам изменяется стейт. ECS в таком случае будет очень полезным, особенно если эту симуляции обрабатывать на ЦПУ, и симуляция предполагает сложное взаимодействие между агентами(решить такое на ГПУ уже довольно нетривиально).

Если без всяких заумных абстракций в наиболее каноническом виде это подразумевает, что у тебя есть под каждый тип компонента свой контейнер с этими компонентами, сущности (entity) есть ни что иное как индекс или указатель в эти контейнеры (как сделать так что бы один индекс указывал в необходимое место сразу во всех необходимых контейнерах, это уже вопрос имплементации). Системы же работают над этими контейнерами и сущностями, производя полезную работу.

Если хочешь действительно разобраться с ecs, возьми юнити и попробуй их ECS, это довольно мощная низкоуровневая вещь.
11 1620488
>>20476
Были у меня все компоненты в объекте и был список объектов. Теперь списки компонентов, коллайдер лежит в списке коллайдеров, материал в списке материалов. Хорошо, как мне это жизнь упрощает?
12 1620497
>>20488
Когда система будет обрабатывать компонет колайдера каждого ентити, например пересчитать его размеры, оно пройдется только через твой массив колайдеров, в противоположном случае ей придется проходить через гигантский масив гетерогенной даты. В итоге куча кеш мисов, в итоге хуевый перформанс. Тебе это сильно не поможет, это поможет конечному пользователю.

То что тебе поможет написано здесь, двачую этого >>20463

>вплоть до того что части из которых состоит сущность можно менять динамически

13 1620503
>>20497
А если мне надо рассчитать что-то, основанное на данных из двух компонентов, например из коллайдера и из АИ? Придется лезть в разные списки, и будут те же кеш мисы.
14 1620505
>>20412
А в чём преимущества по сравнению с прототипным программированием?
15 1620508
>>20476

> Если без всяких заумных абстракций в наиболее каноническом виде это подразумевает, что у тебя есть под каждый тип компонента свой контейнер с этими компонентами, сущности (entity) есть ни что иное как индекс или указатель в эти контейнеры (как сделать так что бы один индекс указывал в необходимое место сразу во всех необходимых контейнерах, это уже вопрос имплементации). Системы же работают над этими контейнерами и сущностями, производя полезную работу.



Что-то такое было ещё в первом Квейке, только там была просто большая структура для всего этого.
16 1620994
>>20503
Хранить списки с одинаковыми наборами компонентов, в виде битовых масок, например.
17 1620996
>>20402 (OP)

Пикрелейтед. Точнее их убогое железо без нормального кеша.

А поскольку этим занимались крупные студии - это стало модно и расхайповано и раскатилось сначала на весь геймдев а потом и за его пределы.
18 1620997
>>20402 (OP)

Пикрелейтед. Точнее их убогое железо без нормального кеша.

А поскольку этим занимались крупные студии - это стало модно и расхайповано и раскатилось сначала на весь геймдев а потом и за его пределы.
19 1621078
>>20996
Для ПК ECS не нужно?
20 1621086
>>21078

>Для ПК ECS не нужно?



Скажем так, на пк он не был так критически необходим - на нем предвыбираторы кеша и предсказаторы ветвлений худо-бедно работали еще со времен PII + плюс была отмаза "купи пекарню, нищееб".

На мыловарню 3 и хуящик 360 же межделмаш завез пусть и дохуядерные (в случае пс3 - одно ядро), но максимально кастрированные процы, с которыми у разработчиков начались проблемы просто сходу.
21 1623441
>>20503
Будут, но значительно меньше.

Вот структура с массивом обьектов, если это не ссылочные типы конечно, тогда все еще хуже.
КомпА1 | КомпБ1 | КомпВ1 | КомпГ1 | КомпД1 | КомпА2 | КомпБ2 | КомпВ2 | КомпГ2 | КомпД2 | ...

Вот более кеш френдли структура
КомпА1 | КомпА2 | КомпА3 | КомпА4 | КомпА5 | ...
КомпБ1 | КомпБ2 | КомпБ3 | КомпБ4 | КомпБ5 | ...
КомпГ1 | КомпГ2 | КомпГ3 | КомпГ4 | КомпГ5 | ...
...

Допустим мы хотим посчитать КомпГ = КомпА + КомпБ для большого количества обьектов. Соответственно пусть в кешлайн у нас помещаются по четыре любых компонента. И в кеше у нас могут быть только два кешлайна.

Первый пример
Считаем КомпГ1 = КомпА1 + КомпБ1
КомпА1 => Читаем в кешлайн 1 : КомпА1 | КомпБ1 | КомпВ1 | КомпГ1
КомпБ2 => Читаем в кешлайн 2 : КомпБ1 | КомпВ1 | КомпГ1 | КомпД1 (хотя здесь я не уверен, может быть еще какой-то алайнинг должен быть)
Считаем КомпГ2 = КомпА2 + КомпБ2
КомпА2 => уже есть в кеше (кешлайн 2), читать не нужно, но так как мы переписали на предыдущем этапе КомпГ1, то хз, инвалидуется ли тут кешлайн. Ну допустим не нужно.
КомпБ2 => Читаем в кешлайн 2 : КомпБ2 | КомпВ2 | КомпГ2 | КомпД2

Второй пример
Считаем КомпГ1 = КомпА1 + КомпБ1
КомпА1 => Читаем в кешлайн 1 : КомпА1 | КомпА2 | КомпА3 | КомпА4
КомпБ1 => Читаем в кешлайн 2 : КомпБ1 | КомпБ2 | КомпБ3 | КомпБ4
Считаем КомпГ2 = КомпА2 + КомпБ2
КомпА2 => уже есть в кешлайн 1
КомпБ2 => уже есть в кешлайн 2
Считаем КомпГ3 = КомпА3 + КомпБ3
КомпА3 => уже есть в кешлайн 1
КомпБ3 => уже есть в кешлайн 2
Считаем КомпГ4 = КомпА4 + КомпБ4
КомпА4 => уже есть в кешлайн 1
КомпБ4 => уже есть в кешлайн 2

Вот такое у меня представление о всем этом, если что поправляйте.
21 1623441
>>20503
Будут, но значительно меньше.

Вот структура с массивом обьектов, если это не ссылочные типы конечно, тогда все еще хуже.
КомпА1 | КомпБ1 | КомпВ1 | КомпГ1 | КомпД1 | КомпА2 | КомпБ2 | КомпВ2 | КомпГ2 | КомпД2 | ...

Вот более кеш френдли структура
КомпА1 | КомпА2 | КомпА3 | КомпА4 | КомпА5 | ...
КомпБ1 | КомпБ2 | КомпБ3 | КомпБ4 | КомпБ5 | ...
КомпГ1 | КомпГ2 | КомпГ3 | КомпГ4 | КомпГ5 | ...
...

Допустим мы хотим посчитать КомпГ = КомпА + КомпБ для большого количества обьектов. Соответственно пусть в кешлайн у нас помещаются по четыре любых компонента. И в кеше у нас могут быть только два кешлайна.

Первый пример
Считаем КомпГ1 = КомпА1 + КомпБ1
КомпА1 => Читаем в кешлайн 1 : КомпА1 | КомпБ1 | КомпВ1 | КомпГ1
КомпБ2 => Читаем в кешлайн 2 : КомпБ1 | КомпВ1 | КомпГ1 | КомпД1 (хотя здесь я не уверен, может быть еще какой-то алайнинг должен быть)
Считаем КомпГ2 = КомпА2 + КомпБ2
КомпА2 => уже есть в кеше (кешлайн 2), читать не нужно, но так как мы переписали на предыдущем этапе КомпГ1, то хз, инвалидуется ли тут кешлайн. Ну допустим не нужно.
КомпБ2 => Читаем в кешлайн 2 : КомпБ2 | КомпВ2 | КомпГ2 | КомпД2

Второй пример
Считаем КомпГ1 = КомпА1 + КомпБ1
КомпА1 => Читаем в кешлайн 1 : КомпА1 | КомпА2 | КомпА3 | КомпА4
КомпБ1 => Читаем в кешлайн 2 : КомпБ1 | КомпБ2 | КомпБ3 | КомпБ4
Считаем КомпГ2 = КомпА2 + КомпБ2
КомпА2 => уже есть в кешлайн 1
КомпБ2 => уже есть в кешлайн 2
Считаем КомпГ3 = КомпА3 + КомпБ3
КомпА3 => уже есть в кешлайн 1
КомпБ3 => уже есть в кешлайн 2
Считаем КомпГ4 = КомпА4 + КомпБ4
КомпА4 => уже есть в кешлайн 1
КомпБ4 => уже есть в кешлайн 2

Вот такое у меня представление о всем этом, если что поправляйте.
22 1623458
>>23441

А если абстрагироваться от кэш-локальности,
есть ли какие-то архитектурные преимущества такой темы?
23 1623818
>>20402 (OP)
Это для неосиляторов ООП. Можешь скипать.
24 1623922
>>20402 (OP)
Грубо говоря, ECS - Component Pattern, возведенный на уровень парадигмы.
Про Component Pattern:
https://gameprogrammingpatterns.com/component.html
25 1657570
>>20402 (OP)

>Для чего нужно ECS?


Тебе точно нинужно.
Тред утонул или удален.
Это копия, сохраненная 24 июня 2020 года.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски