Previous Entry Share Next Entry
2016-01

о симуляторах и железе

tl;dr: почему у нас до сих пор нет игр с супер-пупер живым миром? а вот почему.

я вот недавно жаловался на то, что железо современное плохое и не подходит для симуляторов ( http://wizzard0.livejournal.com/278128.html )

и вот расписал, как именно оно плохое ( http://wizzard0.livejournal.com/282769.html )

короче самое печальное что из этих эстимэйтов можно вывести - что если любое вычисление выполняется за константное время (==это таблица ранее вычисленных значений), то можно выполнить за кадр не более 150к независимых вычислений. зависимых - в 50 раз больше, в идеальном случае (тупое последовательное копирование) - в 500 раз. но реально таки 150к вычислений.

т.е. игрушка написанная "в лоб" на нынешнем железе может симулировать со скоростью 60 кадров в секунду 75к разных энтитей (считая одну операцию на изменение состояния энтити, и одну операцию на отрисовку)

Вроде бы, не так уж мало.
"можно закрасить экран iPad обьектами площадью в 10 пикселей" -- vgrichina

Для 2D игр, действительно, достаточно. А вот с 3D и мультиплеером - ситуация уже не столь радостная.

1. давеча thesz тут ( http://thesz.livejournal.com/1359825.html ) ужасался использованию Stackless Python в EVE Online и тому, что одновременно на узле могут присутсвовать "всего" 3000 игроков.

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

2. Если мы хотим *симулировать* сколько-нибудь большой мир - мы вынуждены делать либо пошаговую игру, либо упрощать обьекты вдалеке от игрока. Само по себе это не так плохо, и для single-player очень даже работает.

А вот в мультиплеере бюджет обьектов сьедается очень быстро, ведь, хоть игроки и кучкуются, но все равно у нас получается уже N "окрестностей игрока", а не 1 окрестность

3. Даже в "одной окрестности", если мир трехмерный, симулировать 50 метров по высоте и 400 м по ширине (квартал города в GTA) означает 8 млн куб.м. По 100м^3 на обьект. Или по материальной точке (точнее, обьекту, который описывается конечным автоматом, таблица состояний которого помещается в RAM) через каждые 4 метра. При этом изрядную часть этого бюджета сьедает графика.

Minecraft? Нет, не пойдет. Там ландшафт статичен. Хотя даже там дистанция отрисовки ненамногим больше магических 200 метров, хотя из динамических обьектов только коровы, лампочки и redstone.

Roblox ( http://www.youtube.com/user/roblox ) гораздо ближе. Вообще, Семен призывается в тред рассказать, какие у них реально получаются там размеры сцен.

4. "динамически понижать детализацию по удалению от игрока" - можно. и нужно. Но уметь надо. Для user-generated content это ой как непросто. Никого в GTA не раздражало, что если преследуемая машина свернет за угол (а то и если просто ненароком камеру повернуть) - она исчезнет навсегда? Вот я примерно об этом.

Comments welcome.

This entry was originally posted at http://wizzard.dreamwidth.org/262417.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
st_precursor February 8th, 2013
И всё же тут следует учитывать что это всё касается неких глобальных событий где меняются 75к объектов за кадр. То есть, обычный день в физическом симуляторе или архисложный процесс в остальных играх.

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

2. Что как раз решается мультисерверностью)

3. 11 сентября симулировать будет фигово. А простой прохожий хорошо если с 2-3 объектами взаимодействует, ну и штук 100 щедрой рукой разработчиков могут сами двигаться. Всё остальное можно сыпать "до востребования"

4. Ну а тут уж исключительно люди во всём виноваты, а не симуляторы и железо)

wizzard0 February 8th, 2013
1) явление-то редкое, но важное. отрубание ракет и полетов - это шаг назад от "живого мира", не так ли?
> питон всех всё же немного подушил.
Да. В 10 раз. Не более того.

2) если ты сделаешь мультисерверный физический симулятор, который может эксплуатировать хотя бы 2000 ядер с эффективностью как от 1000 ядер, то станешь миллиардером. кроме шуток.

3) > хорошо если с 2-3 объектами взаимодействует, ну и штук 100 щедрой рукой разработчиков могут сами двигаться
ну да, это мы и видим в GTA, собственно. А теперь помещаем игрока на корабль в шторм. Все еще кажется, что бюджета в 100 обьектов хватит на реалистичную симуляцию окружения?

4) > люди во всём виноваты, а не симуляторы и железо)
ключевое слово user-generated content - как разработчикам предсказать использование симулятора пользователями?

sagarasousuke February 8th, 2013
Объекты должны быть, но их быть не должно - вот он, любимый ТРИЗ :)))

"Поле потребных объектов волшебным образом появляется вокруг актора в нужный момент времени."

Объекты появляются только в те моменты, когда взаимодействуют с другими. Аппроксимация - неважные объекты движутся "прямолинейно и равномерно" (как камешек по орбите) - для них записана траектория и определено время взаимодействия/столкновения/следующего пересчета траектории (=поведения - "полено горит дальше, пламя светит и трепыхается с частотой f, стены греются, воздух с дымом поднимается вверх").

"Я тут, а вот кто со мной в сейчас провзаимодействовать придёт?" (с) дракон в ожидании консервы ака рыцаря :)


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

sagarasousuke February 8th, 2013
Да, и экспоненциальную историю ты поминал - ага, оно сюда.

justy_tylor February 8th, 2013
Касаемо EVE - использование Python в realtime игре не фатально для игры, но символично для наложения хуя на оптимизацию вообще.

Люди хотят "графон", но лишь до той степени, пока он развлекает. Люди не хотят очень умного AI, им нужен AI, который не тупит неестественным для человека образом. Просто не тупее солдатни, прущей на Брюса Уиллиса в очередном боевике. Нет запроса на реализм ради реализма. Есть запрос на The Truman Show.

wizzard0 February 8th, 2013
You are right given your premises about this systems' stakeholder model :)

Edited at 2013-02-08 02:22 am (UTC)

zeux February 8th, 2013
Какая-то странная математика. 150к независимых вычислений за 16 ms (кстати, 60 fps апдейт мало чему нужен, если про огромные масштабы речь то и тем более) это 10к за 1 ms это 1 за 200-300 тактов. Видимо, имеется в виду латентность памяти. Я правда считал что она в пару раз меньше на PC, но ладно.

1. Непонятно, почему не учитывается наличие нескольких ядер. Они безусловно шарят bandwidth, но latency-то общая.
2. Правильные пацаны умеют писать (в тяжких муках) код который обрабатывает сразу много однотипных объектов, лежащих рядом. На таком коде можно упереться в memory bandwidth или в ALU, но не в memory latency.
3. Конечно же, 75к объектов в кадр рисовать никто не умеет (если майнкрафтовские кубики не считать объектами, ыыы). Но 75к объектов в кадре кроме всего прочего и разглядеть-то сложно.

В итоге я пойнта вообще не понял. Чего хочется-то?

wizzard0 February 8th, 2013
0. 150к - да, латенси. 150k L3 cache miss'ов, по сути.

1. ядра помогают, особенно когда понятно, как между ними делить работу, и когда они не смывают друг другу кэш.

2. ключевое слово - однотипных. и да, я читал http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

так что однотипных и сотни тысяч легко можно, см. Казаки и подобное.

Но, тяжкие муки - не торт, если забить на перформанс то вроде вполне без мук получаются очень зачетные ништяки типа http://jpcs348b.blogspot.ca/ и http://raytracey.blogspot.co.nz/ - оба проекта сделало по одному человеку за вполне разумное время. http://procworld.blogspot.com/ вот тут тоже ничего так, но этому проекту уже несколько лет.

3. 75к обьектов симулируемых. из них в кадре будет где-то 50 на переднем плане, 200-5000 всего.

4. хочется относительно честного whole world симулятора а-ля Космические Рейнджеры, только в реалтайме, в 3д и мультиплеерного. Ближе всего eve, да.

EDIT: гибрид Minecraft, Roblox и Kerbal Space Program тоже подойдет, много планет не обязательно, обязательно отсутствие шардов :)

Edited at 2013-02-08 03:47 am (UTC)

kray_zemli February 8th, 2013
Текущая техника предназначена для дела, а не для генерации счастья. За счастьем -- к наркодилерам надо.

Хотя, последнее время, появился новый подход -- параллельные вычислительные системы с сотнями-тыщами объединенных в сеть ядер, примитивных и с небольшим количеством памяти на каждом. Однако, пока это только эксперименты.

alextutubalin February 8th, 2013
Эти "только эксперименты" уже лет 25-30 идут, как минимум.

Уже в 93-м году на верхушке списка Top500 были именно такие машины. Более старого Top500 list не нашел.

alextutubalin February 8th, 2013
Я вот подумал про "75к объектов за раз" и про простейший случай симуляции большого числа объектов: N-body simulation.

Вроде бы N-body вполне успешно раскладывают на кластерные системы. И совершенно точно, успешно раскладывают на сильно многоядерные системы с относительно слабой связью между группами ядер (собственно, на CUDA/OpenCL).

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

Т.е. не вижу, отчего бы не распараллелить это все на любое количество CPU/серверов (как и делают в реальных физических симуляциях).

kray_zemli February 8th, 2013
Ограничение скорости распространения информации мы уже обсуждали. И пришли к выводу, что нормальную игру на этом принципе не сделать. Или можно, но только теоретически, на офигенно большом кластере, который никогда не окупится. Игрокам ведь нужна массовка.

kunaifusu February 8th, 2013
У EVE и других ММО проблема не в обсчете а в bandwidth - на n игроков нужно n^2 апдейтов, если апдейтить просто позицию в 3Д, упакованую в 32 бита то на 3000 нужно послать 30 мегабайт данных, если апдейтить даже 5 раз в секунду то как раз забьется гигабитный этернет.

wizzard0 February 8th, 2013
Кстати да, про энквадрат я как-то и забыл.

nponeccop February 8th, 2013
Случайно наткнулся на материал по теме поста http://habrahabr.ru/company/intel/blog/168473/

Ну и чтоб два раза не вставать - у нас есть 2-30 МБ "оперативной памяти" (хотя E7-8870 это экзотика), 150к "сиков" на поток и 100-200МБ "трансфера".

На "сик" (который ты приравниваешь к "объекту") при этом приходится сотни килобайт, как-то многовато.

Думаю, твоя оценка в "150к объъектов на современном железе" занижена на 1-2 порядка.

wizzard0 February 8th, 2013
нашел с чем сравнивать!

а) ксеоны явным образом задизайнены решать pointer chasing на больших обьемах оперативки, в общем-то.
б) в тесте по ссылке - не случайные выборки ни разу

Т.е. когда мы помещаемся в L3 кэш - у нас будет 1М+ "сиков". У них 30 мб кэша, 128 мб хип, последовательный доступ (с шагом) - это практически идеальный сценарий.

А я мерял worst case - рандомный хоппинг по 256-мбайт массиву с 4 мбайт кэша :)

edit: рандомный data-dependent hopping. в смысле, next_i = array[prev_i ^ prevprev_i], где массив забит рандомно переставленными индексами

Edited at 2013-02-08 08:50 am (UTC)

si14 February 8th, 2013
Ну штангист, как всегда, в своём репертуаре с экспертными мнениями :) Я бы хотел добавить, что реально для EVE всё ещё сложнее: кроме непосредственно взаимодействий между шипами и их движения, у шипов есть ещё карго, которое влияет на геймплей — количество патронов, например. Поэтому нужно добавлять ещё и лукапы/кеширование/... всего этого.

deadzay4ik February 9th, 2013
А вот в мультиплеере бюджет обьектов сьедается очень быстро, ведь, хоть игроки и кучкуются, но все равно у нас получается уже N "окрестностей игрока", а не 1 окрестность

Хм, зачем графическу движку в мультиплеере общитывать окрестности других игроков, если нам нужна окрестность только одного - нашего персонажа?

wizzard0 February 9th, 2013
Не графическому. Серверу в мультиплеере желательно считать игровую логику всем персонажам, дабы усложнять жизнь читерам.

soonts May 14th, 2013
Прикидки притянуты за уши.

Вовсе не всегда нужно симулировать каждый объект 60 кадров в секунду, часто хватает намного медленнее + линейная интерполяция состояния.
При грамотном программировании, данные сущностей, которые нужны для симуляции, будут располагаться в памяти последовательно и изолировано, и занимать не так уж много места. А выходные будут записываться в другое место RAM, bandwidth-то там дай боже.
На отрисовку тратится намного меньше одной операции на объект, зависит в основном от количества разных материалов и эффектов у объектов которые влезли во view frustum. Если entity сфера из одного материала и без эффектов, то на отрисовку и 10k и 100k штук нужна ровно одна операция.

IMO основная причина описанных тенденций – симуляция не нужна. Гейм дизайн непонятен. Потребность симулировать тысячи объектов пожалуй есть только в играх RTS и симуляторах. Вот взять например GTA 4, если бы они сделали честную симуляцию траффика во всём городе (как например делали афтары Cities in Motion, кстати не такие уж высокие системные требования у игры) – на это бы кстати хватило бы ресурсов приставок не говоря уже про PC– это бы породило намного больше проблем, чем решило. Простой пример: припарковал грузовик на мосту поперёк, перекрыв все полосы в одну сторону, подождал немного, получил пустой город и многочасовую пробку перед грузовиком. Такое намного хуже пропавшей за углом машины.

wizzard0 May 14th, 2013
> получил пустой город и многочасовую пробку перед грузовиком
в реальном городе на это дело отреагируют слегка по-иному.

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

про отрисовку - я подчеркиваю, что обьекты уникальны тк симуляторы эволюционируют их в разные стороны

и да, меня интересуют гораздо более симуляторы, чем игры, и в идеале симуляторы планеты, а не города.

  • 1
?

Log in

No account? Create an account