Что если в играх использовать видеокарточку для физики, а не для графики +135



Хочу рассказать сообществу о проведённом мной эксперименте.

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

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

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

Или ещё замечательный пример — Kerbal Space Program. Там физика уже является непосредственым источником геймплея.

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

Я давно мечтал сделать именно такой, до предела физически реалистичный римейк Scorched Earth. Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.

Но недавнее моё «открытие» изменило ситуацию. Мы живём во времена быстрого развития геймерского железа. Развивались главным образом видеокарточки, потому что производители игр с наибольшим энтузиазмом наращивали именно графическую составляющую игр, а производители железа поддерживали высокий fps. И не удивительно решение компании Nvidia добавить возможность для разработчиков писать код для графической системы, то есть осуществлять вычисления в графичесокм ядре.

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

Конечно, задача должна быть хорошо распараллеливаема, этот бонус актуален не для любого алгоритма. Но моделирование тысяч частиц идеально распараллеливается.

Осознав это, я понял, что наконец-то смогу создать полностью физическую игру, в которой не будет заскриптовано ничего, кроме физики. Игра станет эквивалентна физической симуляции.

Я давно делаю игры на Юнити, и был рад, узнав, что в этом движке реализован класс ComputeShader, который позволяет использовать в проекте шейдеры на языке HLSL. Просто пишем шейдер, линкуем его к экземпляру ComputeShader, и диспатчим в Update.

Вникнуть в параллельные вычисления на GPU было не слишком просто. Туториалов маловато, а те, что есть, довольно ограничены в объёме поясняемых тонкостей. Но ключевых трудностей было не так уж много, довольно богата справочная информация по HLSL была на msdn, так что кое-как путём проб и ошибок я овладел спецификой и начал делать игру.

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

Параллельные вычисления — коварная штука. Нужно было свести все вычисления к простым блокам одинакового размера, чтоб на каждую частицу приходился один поток. Я решил упростить до предела математику взаимодействия частиц. К примеру, обойтись без интегратора, просто мерять величину поля (описывающего взаимодействие частиц) в текущей точке, и на его основе менять скорость частицы. Простота гарантировала, что все потоки будут выполняться одинаково быстро, и не возникнет тяжёлых потоков, которых остальными придётся дожидаться.

Кроме того, при взаимодействии частиц нужно было работать с данными в защищённом режиме, чтобы паралельные потоки были осведомлены об одновременной записи-чтении и не путались. Ведь если частица может одновременно взаимодействовать с десятком других частиц, все они могут параллельно изменять её скорость, а значит, необходимо делать это в защищённом режиме. Средства для этого в HLSL нашлись. Правда, операторы вроде InterlockedAdd() работают только с int-величинами, так что приходилось пожертвовать точностью, и хранить скорость в видеопамяти в виде int-величин.

Огромные массивы взаимодействующих частиц — тоже коварная штука. Нужно было упростить сложность вычилений с

$O(n^2)$

до чего-то вроде

$O(log(N) * N)$


Этого я добился, создав двумерную сетку 256x256, и в каждом её элементе на каждом шагу сохранял ссылки на все ближайшие частицы, так что при обсчёте взаимодействия частиц, каждая частица взаимодействует лишь с теми частицами, что находятся в пределах нескольких 3x3 элементов сетки.

Кстати, почему вместо уже реализованного в Юнити физического движка я создал свой? Потому что универсальный физический движок, подходящий для широкого спектра задач, связанных с моделированием системы твёрдых тел, плохо подходит для моделирования системы взаимодействующих материальных точек. Я предпочёл оптимизированный под специфику оригинальный движок. Если создать в юнити тысячу объектов с rigidbody, можно убедиться, что fps падает довольно сильно. В моём случае нужны десятки тысяч частиц, и написанный с нуля движок позволяет их вычислять с хорошим fps.

Дискретная симуляция физического взаимодействия — опять же, коварная штука. Чем больше шаг, тем больше погрешность. Взаимодействия между частицами реализовано через силу Леннарда-Джонса, то есть, при сближении частиц сила отталкивания растёт в двенадцатой степени. Это неимоверно усиливает ошибку, связанную с большим шагом. Попросту, материя взрывается, нарушается закон сохранения энергии.

Возникает противоречие: нам нужна быстрая real-time симуляция. Но шаг должен быть очень маленький. Это противоречие я разрешил уменьшив шаг в десять раз по сравнению с первыми экспериментами, и производя десять циклов симуляции в каждом Update(). Цена этого решения — производительность. Так что пришлось сильно уменьшить количество частиц. Но всё же их осталось достаточно для сложного поведения всей системы.

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

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

Что в итоге получилось? Получилась игра в жанре «2д артиллерия», вроде Pocket Tanks, Scorched Earth или Worms.

Вот длинное, в десять минут, видео, в котором тоже показан игровой процесс, но более подробно:



Можно заметить, что земля и строения выглядят как желе. Это исправляется за счёт производительности. Можно уменьшить шаг и усилить коэффициент влияния полей на скорость частиц. Но пока я стараюсь удержать игру на уровне не слишком обременительном для большинства не слишком старых видеокарт. Скажем, на моей карте GTX 750m, в которой 384 ядра, игра с 20 тысячами частиц работает с частотой 25 fps, что делает её вполне играбельной.

Вывода здесь два, объективный и субъективный:

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

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


Комментарии (211):

  1. deep_orange
    /#10027938

    А почему не Bullet?

    • ThisIsZolden
      /#10027946 / +3

      Потому что вычисления для твёрдого тела не требуются, здесь всё построено на вычислениях для материальной точки. Кроме того, игры в жанре 2d-sandbox, вроде Powder Toy или OE Cake, не использовали gpu-вычисления, так что я сразу решил сделать своё, полагая, что такие движки пока просто не появились.

      • deep_orange
        /#10027958

        На самом деле новый Bullet не пригоден для OpenGL 2.1 / OpenGL ES 2.0 видеокарт. Да и с C API проблемы. Не такой уж радужный инструмент. Он вообще рассчитан на отдельную видеокарту под физику, дескать одна для физики — одна для графики.

        • BratSinot
          /#10028512

          Про Ageia все забыли уже? :( А ведь их демка первая и последняя с таким количеством объектов на экране…

          • AllexIn
            /#10028692

            Никто про них не забыл. Их решения активно используются во многих играх. Вот только называется это все сейчас иначе.

            • BratSinot
              /#10028702

              Да вот не совсем. Если раньше PhysX это было про много объектов на экране (демонстрации Cellfactor даже сейчас впечатляют), то сейчас это обычный конкурент Havok.
              Да, Nvidia сделала возможность просчета на GPU через CUDA, только вот AGEIA специализировалась на физическом движке и продвигала бы его возможности, что возможно привело бы к крутой физике в играх (да банально кучу объектов на экране никто не делает!).

  2. VovanZ
    /#10027944 / +34

    Хмм, очень странная статья. CUDA появилась в 2007, OpenCL в 2008, все даавно используют видеокарты для самых разных вычислений.


    По-моему, это решение было тихой революцией.

    Да, но это случилось 10 лет назад :)

    • ThisIsZolden
      /#10027950

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

      • AllexIn
        /#10027978 / +17

        Очень странно «открывать» на это глаза в мире победивших Angry Birds.

        • ThisIsZolden
          /#10028006 / +3

          Angry Birds — тоже хороший пример физики, создающей геймплей. Хотя, у них геймплей слишком простой, нет передвигающихся персонажей. И физика тоже проста — несколько спрайтов с коллайдерами на уровень. Но это уже кое-что. С момента выпуска прошло несколько лет. Появилось много клонов, но все они не пытаются выйти из ограниченной физики оригинала. Я просто попытался пойти дальше, как на уровне геймплея, так и на уровне физики, чтоб посмотреть, насколько интересно довести процент физики до предела.

          • AllexIn
            /#10028022 / +5

            Это что-то из разряда «да, там красные пиксели есть, но не много. Но хочется довести их количества до предела.»
            Физика — сама по себе геймплей не создает. Это один из инструментов геймдизайнера, но не единственный. Если использовать только его получится либо песочница, либо симулятор козла-хирурга(впрочем тоже песочница). Игры не получится.

            • deep_orange
              /#10028038 / +1

              2D-артилерия состоит на 100% из физики. Причём примитивной. А геймплей создаёт чувак, которого надо загасить или он загасит тебя.

              • AllexIn
                /#10028046 / +7

                О чем и речь. И интересность игры вообще минимально меняется от того, насколько круто считается физика грунта.

            • ThisIsZolden
              /#10028092 / +2

              Как раз сейчас я взялся за геймплей. Демка из видоса — первая экспериментальная версия игры на этой физической земле, простое переложение механики Scorched Earth на физическую землю. Достоинства тут пока визуальные, взрывы незаскриптованы, и потому разнообразные.

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

              А идей для проверки много, внедряю помаленьку, экспериментирую. Удастся найти чего-то оригинальное и интересное — добавлю, а не удастся — буду другим заниматься.

              • DnV
                /#10028166

                Конечно, сегодняшнее применение физики — сплошной компромисс и оптимизация. Вы сами показали, что мощностей даже GPU пока хватает впритык на желеобразные двумерные абстракции. А если мы хотим симулировать трёхмерные объекты реального мира, то выгоднее всего исключить из расчетов физику твёрдых материалов, ограничившись взаимодействием физических тел. Но будущее за полной симуляцией, безусловно.

                • ThisIsZolden
                  /#10028364

                  Интересно было бы поэкспериментировать с GTX 1080, чтоб понять сегодняшний предел, думаю эта карточка потянет 2-5 сотен тысяч частиц, этого и для 3д может хватить.

                  Но что верно, то верно, даже с крутой карточкой ограничения довольно близки. Я подумываю попробовать однажды другой подход, когда всё состоит из динамически разрушаемых при столкновениях мешей. Там физики — по числу осколков. Можно гораздо более сложный разрушаемый мир смоделировать, без особых вычислительных затрат.

                  • selenite
                    /#10028430

                    как-то писал демку астероидов с voronoi transform в качестве тестового задания в одну веселую компанию :) сделать технично вышло, красиво — нет. Стоит попробовать найти дизайнера в пару )

                    • ThisIsZolden
                      /#10029296

                      Ага, разбиение вороного — хороший инструмент для получения осколков.

                      А «технично, но не очень красиво» — наверное, самая распространённая ситуация в инди-геймдеве, когда программист делает клёвые штуки, которые не впечатляют на вид. На форуме unity3d.com сейчас можно довольно легко привлечь энтузиастов-дизайнеров, если показать что-то техничное.

                  • pavel_kudinov
                    /#10029270 / +3

                    если говорить чисто об SPH, без образования временных валентных связей, то 1млн+ частиц c «сеткой соседей» в 60 FPS можно считать на GTX 780, если на CUDA, с построением динамической сетки по примеру стандартной демки

                    CUDA Samples / Particles

                    только нужно обязательно переходить на VBO (избегать копирования данных на хост и обратно) и заменять fast_radix_sort в построении сетки на inclusive_scan (лучшая научная работа по теме оптимизации регулярных сеток для SPH-подобных симуляций:

                    FAST FIXED-RADIUS NEAREST NEIGHBORS:
                    INTERACTIVE MILLION-PARTICLE FLUIDS


                    имплементация от автора:

                    fluids_v3

                    (тормозная за счёт того, что он с реализацией напутал, но конкретно его идея замены fast-radix-sort'а inclusive_scan'ом — шикарна, x10 прирост производительности построения сетки)

                    на GTX 1080 — я ожидаю возможным 2-2.5млн+ частиц при максимально эффективной известной мне реализации

                    200-500 сотен тысяч частиц в чистом виде можно считать даже на GTX 580

                    • ThisIsZolden
                      /#10029342 / +1

                      Спасибо, прочитаю статью. Возможно, смогу что-то ускорить в своей программе, было бы кстати.

                      А моя оценка количествf частиц на GTX 1080 касалась не общего случая, а моей реализации. Специфика такова: чтобы кристалл удерживал форму, нужно повысить (в сравнении с моделированием жидкости) силы взаимодействия частиц, но встаёт проблема: погрешность дискретизации умножается на величину сил Поэтому, я сильно уменьшил шаг дискретизации. И за один Update() прогоняю 10 циклов симуляции с довольно маленьким шагом, чтоб сохранить быструю работу в реальном времени.

                      Не исключаю, что где-то я не дотянул с оптимизацией, но при прочих равных создаётся впечатление, что для моделирования жидких сред нужно в 5-10 раз меньше производительности на частицу, чем для твёрдых.

                      • pavel_kudinov
                        /#10029356 / +1

                        да, так и есть.

                        у меня тройная вложенность

                        за один кадр визуализации происходит N кадров взаимодействия частиц, при этом за один кадр взаимодействия частиц происходит ещё M кадров перераспределения сил по уже образовавшимся связям

                        так как взаимодействие частиц работает с поиском соседей, оно примерно на порядок-полтора медленнее, чем передача сил по уже образованным связям (временным или постоянным)

                        поэтому, можно иметь 60 FPS визуализации, при этом частицы будут жить на 120-240 FPS, а внутри твёрдых тел силы будут передаваться на частотах 500-2000 FPS

                        чистый шаг симуляции 1 кадр = 1 взаимодействие частиц действительно подходит только для больших «чисто-жидкостных» экспериментов

                        а так, на выбор обычно остаются «полу-упругие» объекты при соотношении 2:2 (на 1 кадр отрисовки 2 кадра взаимодействий частиц и 4 кадра на взаимодействие связей внутри упругих тел)

                        если хочется иметь широкий диапазон свойств, то перехожу вплоть до 5:10 (на 1 кадр отрисовки 5 квадров SPH и 50 кадров физики упругого тела)

                        радует то, что производительность при использовании таких кратных вложенных циклов падает далеко не в 50 раз, а скорее за всё приходится заплатить двух-трёхкратным снижением производительности, за счёт дешевизны расчётов взаимодействий связей по сравнению с SPH

                        • pavel_kudinov
                          /#10029368 / +2

                          раньше ещё использовал один раз посчитанную сетку на несколько кадров взаимодействия частиц, но это даёт артефакты на быстром движении объектов, а fluidsv3 сделал расчёт сетки очень дешёвым, поэтому отказался от этого читерства и теперь объекты могут очень быстро двигаться относительно пространства и корректно при этом «столкновения на относительных скоростях» обрабатывать

                          p.s. я во многих случаях вообще убираю трение и гравитацию и живу в «бесконечном космосе без трения».

                          кстати, конечная по размеру SPH сетка отлично обрабатывает бесконечный космос, это поначалу сбивает с толку, но всё просто — частицы проецируются в сетку как остаток от деления на размер сетки, в результате чего сетка начинает быть периодической структурой. в этом случае, «на соседей» приходится проверять физически не близкие друг к другу объекты, но это никак не влияет на производительность, потому что как бы частицы не разлетелись по бесконечному космосу, количественно их всегда останется столько же, и пар проверок будет всегда «стабильное количество», просто чаще будет даваться ответ «нет, несмотря на то, что клетки в „индексной“ сетке — соседние, частицы друг от друга очень далеко»

                          • ThisIsZolden
                            /#10029622

                            вау, роскошный «чит» с бесконечной сеткой!

                            • pavel_kudinov
                              /#10029706 / +1

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

                              CUDA Samples / Particles это делает так:

                              // для частиц вычисляем номер для "настоящей бесконечной сетки"
                              __device__ int2 calcGridPos(float2 p){
                              	int2 gridPos;
                              	gridPos.x = floor(p.x / gridstep);
                              	gridPos.y = floor(p.y / gridstep);
                              	return gridPos;
                              };
                              
                              // для "номеров ячеек в бесконечной сетке", как в случае если они вычислены из координаты частицы, так и в случае "обхода соседей" - используем уже формулу свёртки бесконечной адресации сетки в периодическую:
                              __device__ uint calcGridHash(int2 gridPos){
                              	// wrap grid, assumes size is power of 2
                              	gridPos.x = gridPos.x & ( gridsize - 1);
                              	gridPos.y = gridPos.y & ( gridsize - 1);
                              	return (gridPos.y * gridsize) + gridPos.x;
                              };
                              

              • HerrDonUlt
                /#10028362

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

                • ThisIsZolden
                  /#10028366

                  Да, так можно было бы, но это бы подразумевало кроме вычислений типа частица-частица, проводить вычисления типа двумерное тело-частица. А это уже более сложная математика. Совмещать подходы счастицами и с телами — не слишком правильно, потому что лучше всего параллельный обсчёт работает, когда все потоки выполняются за примерно равное время. А расчёт тел сложней, и его все будут ждать, Общая производительность упадёт.

                  • pavel_kudinov
                    /#10029298 / +1

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

                    я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»

                    в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:

                    Nvidia FLEX

                    демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц

                    плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)

                    • ThisIsZolden
                      /#10029378

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

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

                      плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям

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

              • VeroLom
                /#10029630

                Будет ли где-нибудь выкладываться код или хотя бы бинарник, чтобы можно было просто погонять?

                • ThisIsZolden
                  /#10029642

                  Да, я загрузил основной код для частиц в ассет стор юнити:
                  https://www.assetstore.unity3d.com/en/#!/content/76233

                  Он пока платный, но после выхода игры сделаю беспланым.

                  А игра, скорее всего, будет включать не только геймплейную составляющую, но и редактор мира, чтоб рисовать домики и взрывать их — как раз для тех, кто хочет «погонять».

            • Areso
              /#10028178 / +1

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

              • Mavka-pony
                /#10029418

                Как вы махом весь жанр китайского фэнтези «Уся» раскритиковали…

        • VovanZ
          /#10028036 / +1

          Кстати, ещё Cut The Rope — в каком-то смысле про физику.


          Сходу больше не могу вспомнить, но мне кажется, что я видел больше одной подобной "головоломки с физикой".

          • AllexIn
            /#10028042 / +11

            Да тыщи игр с физикой в основе геймплея.
            Неиссякаемые Incredible Machines, вообще под досом начались.

          • Areso
            /#10028182 / +1

            На смартфонах есть популярный Where is my water? про кродильчика Свомпи. Очень достойно сделан.

          • tsul
            /#10029416

            «Прыгательные» уровни Quake3. q3dm17 и прочие карты с джамперами. Гравитация и прыгалки, больше ничего не надо :)

  3. maaGames
    /#10027956 / +2

    OpenCL, CUDA. Может вам эти технологии жизнь облегчат.

    • ThisIsZolden
      /#10027960 / +3

      CUDA — Nvidia specific. А компьют шейдер в юнити компилится в opnegl или directx.

      • Nokta_strigo
        /#10030004

        На сколько я знаю историю GPGPU, расчёты не графики с использованием шейдеров использовались как костыль когда не было CUDA и прочих (правда я сам с помощью шейдеров никогда ничего не считал, сравнивать не могу), сейчас вроде уместней использовать вышеупомянутый OpenCL, он умеет с разным железом работать.

  4. AllexIn
    /#10027974 / +7

    Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.

    Всё упирается в вашу неспособность сделать это.
    В 2007 году вышла игра Maelstrom.
    С терраформингом и растекающимися жидкостями.
    А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
    2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.

    • ThisIsZolden
      /#10027996

      Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.

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

      А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?

      • AllexIn
        /#10028012 / -6

        Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.

        ДА полюбому. Как минимум куча физически сложных игр, существующих задолго до CUDA тому показатель.

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

        Терраформинг — это немного больше, чем перемещение вершин. :)
        ТАк можно сказать, что и у вас просто вершины двигать надо.

        А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?

        Простите, нет желания раскапывать архивы. А навскидку вспомнить не получится, это было очень давно.
        Вы можете глянуть Maelstrom в режиме сетки. Там вполне можно оценить сложность расчетов.
        Тем более что там еще и влиения ветра уникальное в каждой точке.

    • malbaron
      /#10028454 / +1

      Всё упирается в вашу неспособность сделать это.
      В 2007 году вышла игра Maelstrom.
      С терраформингом и растекающимися жидкостями.
      А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
      2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.


      В году 1994-1998 видел терраморфинг (на ассемблере) на i386/i486
      Все летало.

    • santa324
      /#10028776 / +1

      Количество частиц не единственный параметр, важна частота итераций. Чем больше интервал интегрирования тем менее твердые и более желеобразные тела у вас получатся.
      На современном i5 (CPU), в реалтайме (2D) мне удалось максимум выжать 20 000 частиц на 2 000 итераций интегрирования в секунду в один поток (это был эксперимен из любопытства, распараллелить не дошли руки).
      Это тела с жесткостью визуально как у ластика.
      Не думаю что возможно сильно больше, это примерно 7 связей на частицу, того около 300 000 000 связей в секунду.

    • andybelo
      /#10028856

      «зарыто много неожиданных идей в области геймплей-дизайна»
      «это даже близко не предел» А сколько предел?

      • AllexIn
        /#10028860

        Я без понятия, сколько предел.
        2000 человек — не предел населения земли. Сколько предел? Я не знаю. Но точно не 2000.

        «зарыто много неожиданных идей в области геймплей-дизайна»

        Я не понял что это и откуда.

        • andybelo
          /#10029046

          С теми, кто карму минусует не общаюсь

          • AllexIn
            /#10029056 / +2

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

  5. basilbasilbasil
    /#10028010 / +1

    http://www.nvidia.ru/object/nvidia-physx-ru.html

    • ThisIsZolden
      /#10028020 / -5

      PhysX — универсальный движок, но он не слишком хорошо годится для этой специфической задачи. У меня взаимодействуют не твёрдые тела, а материальные точки.

  6. Labunsky
    /#10028024 / +4

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

    • ThisIsZolden
      /#10028080

      Можно, конечно, выпустить отдельную карту для физики, полностью лишённую чисто графической функциональности. Только у такой карточки всё равно цена за единицу производительности будет выше, потому что в производстве железа главный ценообразующий фактор — массовость. Видеокарты — массовый продукт, поэтому доля стоимости разработки и постройки производственных мощностей в цене каждой железки — ничтожна.

      По этой причине физические карточки в своё время не прижились, а видеокарты сегодня заточены для физики.

      • Wilk
        /#10029412 / +1

        Здравствуйте

        Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.

        • ThisIsZolden
          /#10029648

          Для научных расчётов такая штука наверняка лучше подходит, если Nvidia её сделала как модификацию популярного железа, и снизила за этот счёт цену.

          • Mad__Max
            /#10029862

            Нет, за счет этого Nvidia наоборот резко увеличила цену. На «богатеньких профи» же рассчитано, у них в отличии от геймеров денег много, можно трясти по полной.

    • Mad__Max
      /#10028482

      Они именно мощнее по вычислительным возможностям, как минимум на порядок для слабеньких карт, и на 2 порядка для топовых. Свои особенности конечно есть, но сейчас это практически такие же универсальные вычислительные устройства как центральные процессоры, позволяющие практически любые алгоритмы реализовать и задачи решать. Только в десятки раз быстрее CPU. Точнее реализовать мощно вообще любые, но не на любых будет такое огромное преимущество в скорости.

      • Deerenaros
        /#10029410

        Я бы не был настолько категоричным, архитектура GPU подразумевает RISC, правда не который у каждого в кармане, а настоящий, лишённый всех утех, вроде настоящего бранчинга http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html

        В каких-то смыслах GPU и правда быстрее. На самом деле, даже в очень многих, но работа с памятью очень… Специфичная, любой тяжёлый поток может практически убить производительность, сведя её до нуля. Тогда как Skylake сожрёт его и не нагреется.

        Что действительно будет быстрее, так это некий NoC из FGPA, но он пока так и остался в концептах. Вроде что-то говорили про NoC, что-то про FGPA в Core iX, но ничего не видно. Но эти вещи вместе могут избавить нас от такого рудимента как GPU за раз.

        • Mad__Max
          /#10029884

          Ну задержки при работе с памятью там разве большие очень. Зато ПСП на порядок выше чем у CPU.
          Один поток ничего не убъет, если конечно программа не из разряда когда все остальные потоки ждут в простое результатов от этого одного ведущего потока (т.е. по факту софт однопоточный и не распараллелен), т.к. в современных GPU помимо кучи исполнительных устройств и довольно много полностью независимых самостоятельных ядер(каждое с собственными декодарами и диспетчерами инструкций, блоками загрузки/выгрузки и т.д.) и Х независимых контроллеров(каналов) памяти с собственными кэшами на каждом.

          А по ссылке книжка конечно хорошая, но очень уж старая — писалась в 2004м году, 13 лет назад описывая архитектуры GPU выходившие в 2002-2004 годах, 1-2 поколение программируемых, когда микропрограммы для GPU еще только начинали внедрять. Те GPU что были тогда и те что имеются сейчас довольно мало общего имеют. В т.ч. и бранчиг вполне полноценный появился, по крайней мере все имевшиеся в первых поколениях ограничения на условия, переходы и циклы давно сняты.

          • Deerenaros
            /#10030144 / +2

            Я не говорю, что задержки большие, даже наборот, доступ ядра к «своей» RAM памяти намного быстрее, чем доступ CPU к RAM. Проблема в том, что на эту память наложены просто огромные ограничения. Есть ещё Read-Only, она такая же по скорости (или даже быстрее, тут луна), но она Read-Only. Есть, как я понял, что-то вроде памяти вывода, она, как можно догадаться, на вывод. Конечно, всю память можно в Shared захерачить, но производительность конвейра сойдёт в нуль в таком случае и вся прелесть высокой производительности улетучится словно спирт в бане.

            За 13 лет в архитектурах изменилось много, да ничего. Вообще говоря, GPU — это полноценная печка со своей ОСью, BIOS и прочей мишурой. Только вот дохрена ограниченная. Бранчинг никогда не появлялся, и никогда его не будет. «Нормальный» он как кажется, потому что перфомансом задавили, сейчас обе ветки посчитать как нехрен для CPU… Один раз, ну два раза. А вот попробуй рекурсию и умри — не могёт GPU в рекурсию. Те же циклы разворачиваются компилятором в набор простых вызвов если условие тривиальное. Потому что Read-only памяти хоть лопатой греби, а вот ядра супер-урезанные в бранчинг не особо умеют.

            На самом деле это и понятно почему так. На GPU ооооочень глубокий конвейр. Как бы ядра вроде бы и ядра, но контроля за ними нет. Вообще никакого. Снова луна. Тут нет полностью подконтрольных потоков Linux или Windows, тут нет процессов erlang, тут есть параллелизм на уровне параметров, но этого для ворошения текстур или вершин более чем достаточно. Зато теперь можно как угодно пытать код, чтобы запускать его на ядрах, хоть каждое ядро по инструкции обрабатывает, хоть каждому ядру свой параметр. В этом и заключается сила конвейра, поэтому GPU так быстры на однотипных операциях. Но вот попробуй сделать на нём поиск в глубину, nvidia и amd расчехлят их большой жирных #$%. Производительность будет хотя бы такая же, как и на CPU. При этом нефти сгорит несравнимо больше. Всё таки TDP i7 6700K в два раза меньше, чем у GTX 1080.

            И на самом деле я бы не писал, что у каждого ядра свой диспетчер инструкций, блоки загрузки-выгрузи и прочее-подобное. Ядро на GPU суть очень простая, это просто часть конвейра. В некотором роде унифицированная, но всё таки, банальная дробилка простейших инструкций. На GPU надо смотреть как на очень прожорливое нечто, стоящее между CPU и FGPA. Хотя, всё таки спасибо nVidia, прожорливость резко меняется в лучшую сторону. Ещё помню времена, когда на 275 с Марса можно было хоть чайник кипятить. Вполне успешно.

  7. vintage
    /#10028106

    Физику уже давно все крутят на GPU при помощи https://ru.wikipedia.org/wiki/PhysX


    Где на бетатест вашей игрушки записаться? :-)

    • ThisIsZolden
      /#10028134

      Да, официальная физика от нвидиа — на gpu, но мне нужен был больший контроль, чем даёт их апи.

      Для бетатеста пока рановато, ещё месяц надо над геймплеем поработать. Но можно на стиме проголосовать: http://steamcommunity.com/sharedfiles/filedetails/?id=845215183

      Если её одобрят, весь бета-тестинг будет там происходить.

      • vintage
        /#10028324 / +6

        Тогда где на альфа-тест записаться? :-)


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


        Ещё было бы круто собирать свой танк, как в robocraft.

        • ThisIsZolden
          /#10028370

          А какая у вас видеокарта? Мне как раз может понадобиться несколько человек с разными видюшками, чтоб отправить им сырую версию и посмотреть, какой fps у них покажет.

          А что до желейных войн, то я игру пока так и назвал, «Jelly in the sky». Но сегодня я чуть физику исправил, и теперь твёрдое выглядит чуть более твёрдым. Вот, можно посмотреть:

          http://i.imgur.com/qcGOQgW.gif

          • Mad__Max
            /#10028502 / +1

            Могу на карточках AMD среднего уровня (7850/7870 — 1024/1280 выч. блоков) под windows 7 прогнать. И на старой 5750(720 выч. блоков) под XP если оно конечно под XP с DX9 вообще в принципе работать может.

          • vintage
            /#10028586

            GeForce 840M


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

          • 1as1
            /#10029404 / +1

            протестировал бы на gtx 1060.
            протестировал бы и более тяжеловесные эксперименты.

          • Gron44
            /#10029406 / +1

            Есть возможность протестировать на GTX 1060

          • Art4es
            /#10029408 / +1

            2 x gtx660, как дела со sli/crossfire?

          • Deerenaros
            /#10029448 / +1

            У меня Quadro мобильная, кстати говоря. Слабая, но что-то. Может у неё какие-то преимущества в GPGPU, не? Попробовать можно. Могу ещё на 1060 запустить, но это не так интересно.

          • rds92
            /#10029652 / +1

            AMD r7 360, win 10.
            Тоже хотелось бы попробовать

          • ThisIsZolden
            /#10029656

            Спасибо всем в этой ветке, я с вами непременно свяжусь, когда возникнет надобность потестировать игру.

          • pav5000
            /#10029660 / +1

            А под Линукс версия есть?
            GTX 970

    • EvilFox
      /#10030166 / +1

      Крутят да только юнити вертит PhysX только на CPU.

  8. gorodnev
    /#10028114

    Огромные массивы взаимодействующих частиц — тоже коварная штука.

    Задача уже давно решена — http://algs4.cs.princeton.edu/61event/

    • ThisIsZolden
      /#10028140

      Конечно, есть разные подходы, я почитал статьи перед тем, как взялся за реализацию. Но всё равно пришлось повозиться, потому что нужно было сочетать разные методы оптимизации.

  9. schroeder
    /#10028126 / +1

    а где можно поиграться в эти клевые танчики?

    • ThisIsZolden
      /#10028144 / +3

      Я выложил игру на гринлайт:
      http://steamcommunity.com/sharedfiles/filedetails/?id=845215183

      Если опубликуют, то на стиме. А если нет, ещё где-нибудь выложу. Вряд ли раньше, чем через два месяца закончу, но до релиза в любом случае доведу.

      • malbaron
        /#10028286 / +1

        Забавная графика, спецэффекты то что надо.

        Каков объем работы?
        За какое время (в пересчете на полный рабочий день) это было сделано?

        • ThisIsZolden
          /#10028372 / +1

          Если на полный рабочий день, то 2-3 месяца примерно, точней сложно сказать.

  10. an24
    /#10028168 / +1

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

    • SHVV
      /#10028200 / +3

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

      • ThisIsZolden
        /#10028208

        Именно.

        • MatiasGray
          /#10029400 / +2

          Можно заметить, что земля и строения выглядят как желе. Это исправляется за счёт производительности.

          Предлагаю очевидное решение: устанавливаем название игры «Jelly tanks». Устанавливаем мир игры — желейная вселенная. Всё состоит из желе. Получаем, что у игры есть идея™, которая отражена в основе геймплея. Профит и целостность проекта. И ещё оптимизация. Можно сделать несколько огромных уровней, с более желейной физикой.
          Или можно использовать это в сюжете: злой злодей собрал зловещее устройство, которое в зловещих целях превратило весь мир в зловещее желе. Он также расставил везде своих роботизированых прихвостней-танков (тоже зловещих)
          P.s. отличный снеговик, хе хе.

          • ThisIsZolden
            /#10029662

            Ага, я так и назвал игру, «Jelly in the sky». Хотя, физику подкрутил, стало всё потвёрже, но в иоге тубет несколько материалов с разными свойствами.

    • ThisIsZolden
      /#10028206

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

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

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

  11. DrZlodberg
    /#10028240 / +5

    Суровые мармеладки! Вот только избыток красного после взрывов вызывает ассоциацию с кровищей. Что удивляет там, где её взяться неоткуда. А так физика прикольная. Особенно когда с разгона хоботом в мясе застревают.

    • ThisIsZolden
      /#10028536

      Подразумевалось, что это расплавленная взрывом материя. Хотя, и правда, многовато.

      • vintage
        /#10028598 / +2

        Расплавленная материя в зависимости от температуры будет светиться сначала красным, потом жёлтым, потом вообще голубым.
        http://www.digcode.ru/BlackBodySpecrtrum.html
        Типичные взрывы дают всё же жёлтый цвет: https://ru.wikipedia.org/wiki/Температура_взрыва

        • Mad__Max
          /#10029904

          Это при нагреве. После выстрела/взрыва мы же имеем обратный процесс — остывания. И правильными в этом случае будут переходы желтый-оранжевый-красный-коричневый-черный(уже холодный, но обугленный/оплавленный материал)

      • AngReload
        /#10029398

        Почему внешне выглядит так твердо?
        Можно же красочно раскрасить все под тортики, пироженки, желе — и никаких вопросов.

      • tautomer
        /#10039386

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

  12. perfect_genius
    /#10028242 / +4

    Что можете сказать об PixelJunk Shooter?
    Игры давно не играю, но эта, основанная на физике, заставила пройти до конца.

    • ThisIsZolden
      /#10028378

      Выглядит здорово. Частиц для жидкости — минимум, но благодаря хорошей математике взаимодействия, они довольно реалистично изображают жидкость. Ну и с графикой правильно сделали: множество частиц покрывается сплошной динамической текстурой. Я думал тоже нечто подобное сделать, но пока не копал в этом направлении.

  13. sleeply4cat
    /#10028326

    А какие вообще есть способы распараллеливания «устойчивой» симуляции частиц? Хотя бы на примере того же The Powder Toy. Или клеточных автоматов.
    Я пытался объединить обработку блоков сетки в «транзакции», чтобы в случае конфликта блокировок/очёрёдности обсчёта откатывалось состояние менее приоритетной, а потом вычислялось заново, но это сожрало все 8 ядер, дав скорость одного.

    • ThisIsZolden
      /#10028534

      Основной метод — использовать защищённую запись. В HLSL используются Interlocked операторы, а в процессорной многопоточности есть разные методы, в подробности которых я не вдавался и не могу ничего подсказать, но этому посвящено много статей, легко гуглится.

      Насчёт Powder Toy — не знаю. Судя по динамике работы, эта однопоточная программа, но я могу ошибаться.

  14. xPomaHx
    /#10028380 / +3

    Меня в свое время шокировала физика песка из игры Earthworm Jim на Sega. Думаю что чем больше игра предлагает способов прохождения, чем больше вызывает интерес.
    image

  15. yetanotherman
    /#10028386 / +4

    Признаться честно, от GPU после прочтения статьи я ожидал большего, чем у вас на видео.
    Но, с другой стороны, если отвлечься от технических деталей — я бы с удовольствием в это порубился, выглядит очень интересно. Похоже, вормсами вдохновлялись? :)

    Еще никуда не выкладывали?

    • ThisIsZolden
      /#10028530

      Да, вдозновился вормсами и scorched earth. А на видео многое скрыто. Например, тот факт, что за каждый фрейм запускается 10 циклов симуляции, чтоб шаг был в 10 раз меньше. С меньшей точностью у меня и 500 тысяч частиц летало. Это было зрелищно, но не подходило для игры. А тут точность большая, но это не бросается в глаза.

      Игру уже выложил в гринлайт:
      http://steamcommunity.com/sharedfiles/filedetails/?id=845215183

      • SAKrisT
        /#10029104

        А почему только для PC? для macOS есть в планах?

        • ThisIsZolden
          /#10029666

          Если Юнити каким-то образом смогут компилировать compute shaders в Metal-код или Metal сам сможет поддерживать DX11, то не будет препятствий для выпуса игры под мак.

          • SAKrisT
            /#10030036

            Я почему-то думал, что в Unity свой шейдер язык и он конвертируется на таргет платформу автоматически. Или есть какие-то ограничения?

      • itforge
        /#10029130

        Когда-то играл в scorched earth на 386 процах под досом :)

  16. chersanya
    /#10028388 / +1

    Не смотрели в сторону более продвинутых методов решения дифуров, чем прямой прогон вперёд? Кажется, что методы имеющие ошибку второго порядка (вместо первого, как у вас) могут заметно помочь.

    Ну и если ещё больше углубляться, то для моделирования частиц и действующийх на них сил есть неплохой метод particle-in-cell (гуглится), используемый в том числе для серьёзных физических симуляций. Здесь, конечно, оверкиллом будет :)

    • ThisIsZolden
      /#10028528

      Спасибо, погуглю.

      А более продвинутые методы могут сработать, я пока не пробовал. Если вместо величины поля в текущей точке использовать усреднённое значение по текущей и следующей (по вектору скорости), то можно уменьшить ошибку.

    • pavel_kudinov
      /#10029322

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

      в плане характеристик кипения в зависимости от величины шага дискретизации, тупо .pos += .vel; ничем не отличается от формул с кучей переменных и компенсациями ошибок второго порядка, а алгоритм от более сложной математики ещё начинает притормаживать

  17. TheIncognito
    /#10028466

    Вспоминается стрелялка про танки на Flash… Только управление было поподробнее, и не придумали лазерные снаряды.

  18. Fen1kz
    /#10028472 / +4

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

    • ThisIsZolden
      /#10028526 / +2

      «Желейность» я могу пофиксить, вот сегодня записал гифку, получше стало?

      http://i.imgur.com/qcGOQgW.gif

      • equand
        /#10029128

        Теперь не желе а торт. Думается нужны разные свойства для разных материалов

      • Fen1kz
        /#10030258 / +1

        Не пожалейте 15 минут, посмотрите видео


        Как бы вы молодец, и я восхищен вашими навыками написания физики, но, если честно, то не впечатляет =(

        • vintage
          /#10032688 / +1

          Ваше видео с прибитыми гвоздями текстурами тоже не особо впечатляет.

        • ThisIsZolden
          /#10032700

          Да, это хороший пример геймплея, в котором много взаимодействия с землёй. Чуть позже, после реализации основных фич уровня scorched earth, я попробую что-то в этом роде реализовать, с копанием земли.

  19. Win332
    /#10028480

    Очень хорошая статья. Давно думал сделать подобное, но руки не доходили. Была так же идея сделать библиотеку для обработки достаточно сложных операций не через ЦП, а предоставить это GPU.

    • ThisIsZolden
      /#10028524

      Это всё не так уж и сложно, если делать с помощью compute shader на юнити. Так что если давно думал сделать, есть смысл попробовать.

  20. Mad__Max
    /#10028506

    Возникает противоречие: нам нужна быстрая real-time симуляция. Но шаг должен быть очень маленький. Это противоречие я разрешил уменьшив шаг в десять раз по сравнению с первыми экспериментами, и производя десять циклов симуляции в каждом Update(). Цена этого решения — производительность. Так что пришлось сильно уменьшить количество частиц. Но всё же их осталось достаточно для сложного поведения всей системы.

    А шаг динамическим сделать нельзя? При наличии близких частиц уменьшать шаг обсчета, при дальних взаимодействиях где погрешность намного медленней накапливается считать крупными шагами.

    • ThisIsZolden
      /#10028522

      Определить наличие близких частиц — это значит уже сделать полноценный шаг. А определять наличие дальних частиц при отсутствии ближних стоит дорого в вычислительном смысле.

      • Mendel
        /#10028956

        Попробуйте температуру или еще какой аналог.
        Или инверсию зависимостей.
        Читал по диагонали статью, но меня смутило что у вас время везде равномерно.
        От этого приходится ждать «медленные» потоки, или считать что лежачий камень всё еще лежит.
        Помню в школе когда еще не знал о нейронных сетях, придумал что-то похожее. Только у меня веса лежали не у принимающей стороны а у нейрона который выдает спайк. Это усложняло обучение, но упрощало симуляцию на процессоре — те нейроны которым спайки не приходили (импульсные), те и не пересчитывались.
        Что-то похожее можно и у вас сделать. Частица изменила свои координаты и вектор. Посчитали кого это может задеть, добавили их в очередь.
        Чтобы понимать кто где — можно не просто координаты хранить, но разбить вселенную на сектора и иметь массив частиц находящихся в секторе. Ну или по графу двигаться. Просчитали каждому кто рядом с ним. Навесили связи. Частица сместилась — поменяли связи. Кого убрать понятно, кого добавить — полюбому будет кто-то из соседей наших соседей. Если скорость слишком большая — уменьшили квант времени в этом секторе.
        Я понимаю что это звучит как поток сознания, но основная мысль у меня — удорожание просчета одной частицы даже в два раза, легко окупится если за счет этого 90% частиц мы пересчитывать не будем.

        Да, про температуру я здесь упомянул в том смысле, что температура это некая интегральная мера количества движения/суеты. Если сделать поле температуры (сглаженное значение модулей кинетических энергий) и пропорционально температуре распределять локальную частоту квантования времени, то можно существенно сэкономить мощности без существенной потери точности, а на сэкономленное — повысить точность там, где оно важнее.
        Опять таки — отказ от однородности времени даст Вам возможность вводить более сложные алгоритмы для частных случаев (предмет+частица и другие) не опасаясь что это повредит распараллеливанию.

      • marsermd
        /#10028994

        Забавный факт: Miles Macklin et.al. (http://mmacklin.com/uppfrta_preprint.pdf) находят соседей только один раз на несколько итераций солвера.

        • pavel_kudinov
          /#10029328 / +1

          да, это кстати работает, но ценно только до тех пор, пока сетку чертить дорого, а с алгоритмом fluidsv3 это начинает стоить копейки, зато исчезают артефакты при быстром движении объектов («дрожание физики по линиям сетки»)

      • Mad__Max
        /#10029932

        Не совсем полноценный — пересчет сил, скоростей и координат можно не делать же в этом случае, а в следующем шаге посчитать их один раз за удвоенное/утроенное/учетверенный отрезок внутриигрового времени.

        Ну или если полноценный, то при отсутствии близких частиц можно просто следующий шаг или несколько целиком пропустить.
        В грубой реализации допустим сейчас есть цикл который делает 10 или 20 итераций как у вас на каждое обновление. Но сделать его не на простом счетчике i=1..10; i++, а на условном — были при обсчете текущего шага близкие частицы делаем в конце итерации i+1, если таких не было значит в конце итерации будет i+2 или i+3.
        Естественно время во всех формулах расчета сил и координат частиц будет не фиксированными шагами меняться, а пропорционально номеру шага/итерации.

  21. ntkj666
    /#10028514

    А на карточках от amd как работает?

    • ThisIsZolden
      /#10028520

      Пока не проверял, но должно работать. На amd ведь работает directx и opengl?

  22. KoToSveen
    /#10028518

    Желейная реализация физики показалась очень забавной. Очень сильно раззадоривает момент после выстрела, когда вся конструкция складывается. Дома обязательно ребятишкам покажу эту игру. И да, я бы купил эту игру (с ностальгией вспоминаю времена Scorched Earth).

  23. 3aicheg
    /#10028538

    Ваша игра напомнила демки Phyz, который вышел когда ещё, и, вроде, не использует никакого GPGPU.

    Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени. В среднем геймерском компьютере производительность видокарты в 50-100 раз выше производительности центрального процессора.

    Как считали?

    Конечно, задача должна быть хорошо распараллеливаема, этот бонус актуален не для любого алгоритма. Но моделирование тысяч частиц идеально распараллеливается.

    Не только «хорошо распараллеливаема», там ещё должен быть достаточно простенький алгоритм без ветвлений.

    • AllexIn
      /#10028698

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

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

      • 3aicheg
        /#10028704

        Там не требования, ветвиться-то можно, но оно, насколько я помню, просаживает производительность куда хуже, чем ошибка в branch prediction на CPU. Выполняются всегда все ветки кода, потом ненужное выкидывается. Возможно, мои сведения устарели, не знаю.

        • marsermd
          /#10028978

          Нет, все верно. Каждый мультипроцессор в видеокарте работает по принципу Single Instruction Multiple Data, выполняя за один такт одну и ту же инструкцию на каждом из ядер, но на разных участках памяти. Соответственно, если какая-то строчка сработала на одном из ядер, она займет время и всех остальных ядер мультипроцессора.

          • pavel_kudinov
            /#10029340

            насколько я знаю, блокируется на ветвлении не весь мультипроцессор, а только WARP_SIZE.

            в WARP'е всего 16-32 потоков, так что немного веток таки можно делать, это снизит производительность, но не фатально за счёт небольшого размера WARP'а

            • ThisIsZolden
              /#10029820

              А ветвление — это когда используются операторы if и case? Я, признаться, ничего не знал об этом ограничении, и понатыкал их всюду довольно много. Я не замечал особо явного влияния на fps. Видимо, оно не слишком велико. По сравнению, например, с переходом от незащищённого read/write к защищённым Interlocked-функциям.

            • Nokta_strigo
              /#10030090 / +2

              Ну каждое ветвление может снизить скорость до 2х раз. Максимально возможная потеря скорости (если весь код покрыть кучей вложенных ветвлений) — 32 раза (для NVIDIA). Не сказать что мало. Но это худший случай.
              Для CUDA (про AMD не знаю): потерь на ветвление не будет, если для всех нитей в warp предикат, по которому выполняется ветвление, принимает одно и то же значение (т.е. все нити в warp переходят по одной и той же ветке). Если в warp есть и нити для которых условие перехода true, и есть нити для которых false, то будет замедление в ~2 раза (реально для всех нитей будет обсчитан и один и другой переход, просто сохранён только нужный результат)
              Т.е. условие «if (thread_num % 2 == 0)» даст сильное замедление, а условие «if (thread_num > N/2)» замедления почти не даст.

  24. Arxitektor
    /#10028688 / +3

    А на самом деле желе это круто.
    Только надо вписать в гемплей.
    Война в мире желе )) Сделать какой желейный сеттинг.
    Конфетная артиллерия и прочее )

  25. marozz1k
    /#10028756 / -5

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

    • marsermd
      /#10028984 / +1

      Простите, а почему это вы бы не стали считать физику на видеокарте? О_О Физика частиц — отлично оптимизированная для видеокарты область вычислений.
      Пруф.

      • marozz1k
        /#10029010 / -1

        Я не утверждаю, а сказал «в целом» что переложить вычисления с процессора и оперативки на видеокарту — это не выход. Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено. В общем в аналогии с человеком — это перевести часть обязанностей участков мозга, ответственных за вычисление и дать дополнительную нагрузку на глаза

        • herr_kaizer
          /#10029030 / +2

          Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено

          Как там в 90-ых, Doom уже вышел?

          • PsyHaSTe
            /#10029280

            Тут другой вопрос, в 2017 году видеокарта и так еле пережевывает графику, особенно если мы говорим о чем-то вроде 4к, загружать её сверх этого — ну не знаю… Сейчас наблюдается какой-то баланс между физикой и графикой, если его сместить, графика резко пострадает. А как мне кажется, сейчас это золотая жила для всяких EA, и вряд ли они решатся сильно от нее отказаться. Желейные войны — это забавно, но когда эффект новизны пройдет, люди все равно пойдут в игры с не такой уж чудесной физикой, но зато нормальным геймплеем — цива, стелларис и т.п. Просто потому, что у "желейных войн" сеттинг не предполагает серьезности и существенной реиграбельности. Единственное исключение — червячки (в плане реиграбельности, но серьезности там опять же нет), но за годы педалирования одного и того же даже они поднадоели. Сыграть разок с друзьями в армагеддон — пожалуйста, но на выходные лучше засесть в цивилизацию.

            • ThisIsZolden
              /#10029812

              На данный момент это верно. Хотя, качество геймплея не является следствием графики. Просто так вышло, что графика — высокое требование для всех игр, среди которых нашлись интересные. И вряд ли графика способна создать предпосылки для новых идей в гейм-дизайне.

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

              А графика не исключается физикой. Существует многообразие стилей и шейдерных трюков, которые дают визуальную конфетку без насилия над видеокартой. В моём случае визуализация слабенькая, но можно сделать гораздо лучше малыми средствами.

              Так что, всеобъемлющая физика — это не исключительная альтернатива, а скорее дополнительная степень свободы именно для гейм-дизайна.

              • Idot
                /#10029824 / +1

                Главное чтобы дизайнер был толковый умеющий этим пользоваться.

                А то в DOOM III при наличии динамического освещения не нашлось дизайнеров умеющих им пользоваться так, чтобы это хоть как-то влияло на геймплей. Хотя старенький Aliens vs Predator 1999 года, имея лишь лайтмапы, использовал в геймплее динамическое освещение на полную катушку.
                Другой пример Red Faction — с разрушаемым окружением, и дизайнерами не умеющими это использовать, более того топорно влепившими ничем неразрушаемые стены.

                Хорошим примером можно назвать использование физики в геймплейе Half-Life 2. Тут дизайнеры дали возможность почувствовать её наличие вовлёкши её в геймплей.

          • marozz1k
            /#10029976 / -2

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

            • herr_kaizer
              /#10030140 / +3

              вот с этим я крайне не согласен

              Из религиозных соображений? Вы не обижайтесь, но я искренне не понимаю, почему делать расчёты на ЦП — канонично, а на ГП — нет. Вам-то какое дело, как игроку, да и как разработчику тоже?

              • marozz1k
                /#10030546 / -1

                Потому что каждый должен выполнять свою задачу) объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП? Ну хорошо, сделаете вы игру, где вам хватит мощности вашей крутой видеокарты для рассчёта 2000 частиц)) а дальше? А вы знаете что у большинства пользователей НЕ игровые видеокарты? Это перекос не туда, я уже говорил что автор словил верное направление, что надо не на графику ориентироваться, а на реалистичность физики и свободу действий, а не линейные фильмы из игр делать, но в остальном остаюсь при своём мнении — ресурсы видеокарте нужны для обработки и вывода на экран уже более-менее обработанной информации, насиловать её вычислениями не надо. Спасибо за обсуждение.

                • herr_kaizer
                  /#10030588 / +2

                  объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП?

                  Обработка игровой логики, ИИ, динамическая подгрузка ресурсов?

                  А вы знаете что у большинства пользователей НЕ игровые видеокарты?

                  У автора поста тоже, у него вообще ноутбучная из позапрошлого поколения.

                  насиловать её вычислениями не надо

                  3д-ускорители изначально изобретали для «насилования» их вычислениями. Если бы это было не так, мы бы до сих пор сидели в тех самых 90-х с тем самым Doom.

        • marsermd
          /#10029118 / +3

          Аналогия неуместна. Уже лет 8 функция видеокарты — выполнение параллельных алгоритмов, которые хорошо ложатся в идеологию SIMD.

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

          А в наши дни эта концепция развилась до General Purpose программирования на видеокартах: нейронные сети, кодирование/декодирование видео, симуляция физики.

          Если вы находите мои рассуждения обоснованными, можете просто согласиться, не обязательно продолжать спор)

        • AllexIn
          /#10029830 / +3

          А CPU предназначен, чтобы вояджеры в космос отправлять. Зачем вы на них предлагает игровую физику считать?

          Вобщем и целом — переносить жирные вычисления на GPU — это норма в современном мире. И не просто норма, это правильно.
          Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
          Ну вот тако вот мир ПК развивается, никуда не деться.

          Полагаю вы просто мало понимаете/знаете о внутренностях, поэтому и делаете столько абсурдные заявления.

          ТС идёт на 100% верным путём.

          • ThisIsZolden
            /#10030240 / +1

            Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.

            Действительно, у Nvidia сейчас огромные наработки в области многоядерного железа. А интел всю дорогу шёл по пути мощных одноядерных вычислителей, и упёрся в ограничения по частоте работы и размеру транзистора. А миру нужны вычислительные мощности. Акции Nvidia за полтора года выросли на 300%, и это говорит о том, что они вышли далеко за пределы рынка только графических карт.

        • Idot
          /#10029894 / +1

          Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено.

          Вообще-то, на видеокартах Вертексные Шейдеры появились ещё ДО появления CUDA и OpenCL Более того они появились раньше, чем Ageia PhysX. И на них с самого появления можно было считать простейшую физику в духе «сложить два вектора».

  26. Lerg
    /#10029114

    Проголосовал в гринлайте.
    Можно ли объединять точки в твёрдые тела? У вас там есть танки, но они тоже желейные. Для вариативности не хватает некоторого количества твёрдых тел.

    • ThisIsZolden
      /#10029800

      Я разовью физику, чтоб у некоторых объектов были свойства более твёрдого тела, у других — помягче. Будут камень, земля, дерево, желе.

  27. denisromanenko
    /#10029246

    Эти желейные миры и танчики выглядят невероятно весело! Срочно на Greenlight!

    • ThisIsZolden
      /#10029798

      ага, уже:
      http://steamcommunity.com/sharedfiles/filedetails/?id=845215183

  28. General_Error
    /#10029248

    Отличная идея на мой взгляд. Со временем может получиться очень хорошая вещь! Если бы не недостаток знаний, тоже бы попробовал что-то такое написать или влиться в разработку.

    Могу проверить и рассказать, как работает на Radeon 270X, если нужно.

  29. reforms
    /#10029250

    Я прочитал статью и понял, как отстал. С игровой индустрией, как разработчик попрощался в далеком 2004г, завершив его единственной 2D игрой — логические шарики. Вся 'физика', да простят меня спецы, решалась анимацией (сжатие и расширение шаров) 8-10 кадрами в гифки.
    Спасибо за статью.

  30. Smorodov
    /#10029316

    Для 3D уже делают вполне реалистичные разрушения.

    • DAumkraft
      /#10029590 / +2

      Довольно реалистично, но уже долго оно выглядит до убогого одинаково. Постоянно одинаковые куски, которые просто сваливаются в кучу. Изначально более мелких и крупных частиц мы не получим, раздробить уже полученные — тоже. И вот так и выглядит это с 2008 года без существенных изменений.

      • Smorodov
        /#10029690

        Да, не хватает в этом ощущения «хряп!», которое как раз и достигается измельчением осколков, выглядит как-то малость «пенопластово». Но при помощи адаптивных разбиений в местах контакта и добавлением облаков пыли при падении на землю, а не только при попадании снаряда, можно и это допилить. Здесь видимо решили что для игрового процесса большего не нужно. Есть интерактивный ландшафт, и этого достаточно.

    • dshster
      /#10039764

      А этого в Red Faction в начале 2000-х не было случайно? Выглядит довольно примитивно для уровня современного GPU.

      UPD: Видео 2012 года, это частично объясняет.

  31. LogEdge
    /#10029396

    А что вы думаете о нейросетевых вычислениях?
    https://www.youtube.com/watch?v=iOWamCtnwTc

    • ThisIsZolden
      /#10029796

      Когда гугл купил университетский стартап, занимавшийся дип лёрнингом, указывалось, что они делали вычисления то ли на видеокартах, то ли на игровых консолях. Нейросетевые вычисления хорошо параллелятс, и потому отлично подходят для вычисления на видюшках.

  32. ivvi
    /#10029592

    > «Или те же гоночки: до чего приятней на полной скорости сшибать людей...»

    Ох, зря вы слово «людей» вставили в эту фразу. Я бы убрал, оставив только неодушевленные предметы.

    • ThisIsZolden
      /#10030234 / +1

      Ну, понятно, что речь идёт про нарисованных людей из компьютерной игры.

  33. webhamster
    /#10029900

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

  34. Nokta_strigo
    /#10030106

    Очень согласен с утверждением, что современным играм не хватает физики! Графика на высоте, а физика — так себе. KSP и некоторые другие — исключение :-)
    А под Linux (Mint) игра планируется?

    • ThisIsZolden
      /#10030230

      Looks like Unity now can build for Linux. But does Linux support DirectX10? Anyway, it may happen after PC release, which may take minimum 2 months.

  35. MaximSuvorov
    /#10031906

    Подобную задачу давным давно решили без велосипеда, новомодной вещей с расчётами на видеокарте и при этом работающей быстро:

    http://www.gamedev.ru/code/articles/PositionBasedPhysics#v_chyom_je_profit_

    С виду простой метод возволяет моделировать вполне внушительное количество взаимодействующих объектов:

    На этом просчитывается взаимодействие 5000 шариков, расчёт всей физики занимает чуть больше 2мс на одном ядре процессора Core2Duo E6600 2.4GHz.

  36. Smorodov
    /#10033638

    Есть хорошая статья о моделировании сеточной физики:
    http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html
    идеи там близкие к тому что вы описали в статье, только более формализовано.

    • ThisIsZolden
      /#10034288

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

  37. Smorodov
    /#10034362

    Еще здорово смотрится физическое моделирование в дополненной реальности.

    • ThisIsZolden
      /#10034434

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

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

      И если сравнивать виртуальную модель песочницы, в которой песок подвластен контролю со стороны программы, и реальную, в которой песок недвижим, я предпочёл бы пока первую, ибо совсем другой объём возможностей открывается. Но было бы здорово, если б сделали живой песок в реальности.

      Теоретически это было бы возможно с помощью конфигурируемого магнитного поля высокого разрешения и управляемо ионизируемыми частицами. Но практической реализации этой идеи пока не существует.

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

  38. Jarro
    /#10036796

    Приветствую,
    я правильно понял, что вместо формулы потенциала 6-12 вы на деле использовали упрощенную для вычислений 4-8?

    • ThisIsZolden
      /#10036802

      Было 4-8, сейчас 6-12. Хотя, разницы особой нет, я всё равно коэффициентом добивался максимально возможной крутизны графика в точке нулевоко коэффициента.

      • Jarro
        /#10036846

        Кстати, а насколько реально совмещать частицы с разными свойствами, чтобы действительно сделать что-то наподобие OE-Cake GPU Version?)

        • ThisIsZolden
          /#10036872

          Реально, вот сейчас как раз доделал, теперь есть несколько материалов с разными свойствами — камень, песок, снег, грязь, металл, и т.д. Но взаимодействие между ними я не слишком прорабатывал. Масса и теплоёмкость у всего одинаковая, динамика жидкости — так себе. Я бы не против поглубже в эту сторону покопать, но сейчас хочется закончить с физикой и аняться геймплеем.

      • Jarro
        /#10036854

        Допустим, Rigid-axis body (твердое тело с осью вращения) или даже сложные механизмы, которые успешно создавались в том же OE-Cake

        • ThisIsZolden
          /#10036880

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

          А механизмы будут простенькие. Я ввёл сущность, вроде кости, которая упруго задаёт расстояние между частицами. Такими костями можно усилить строения и заскриптовать анимацию уровней, вроде катающихся туда-сюда мостиков. А сам танк в демке — тоже механизм, сделанный из частиц, и работающий как молекулярная машина.

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

  39. Drunya_tek
    /#10036868

    а можно где то скачать эту вашу игру?)

    • ThisIsZolden
      /#10036870

      Через пару месяцев можно будет, она получила зелёный свет на стиме, доделать надо.
      http://steamcommunity.com/sharedfiles/filedetails/?id=845215183

  40. andybelo
    /#10037510 / -1

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

    • malbaron
      /#10044422

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


      Бредятину пишите.
      Не ставьте человеческому мозгу задач, которые хорошо щелкают компьютеры.
      Пусть человек решает то, что компьютеры делают хуже.

      • andybelo
        /#10044714 / -1

        Хабр не место для дискуссий.

  41. Smorodov
    /#10039314

    Кстати, подкину идею. Если вместо земли использовать воду, а вместо танков кораблики, то волны от взрывов могут сильно разнообразить игру.

  42. Jarro
    /#10040970

    А вы случаем не знакомы с очень похожей демкой от майкрософта?:)

    image

    https://code.msdn.microsoft.com/windowsdesktop/DirectCompute-Graphics-425de5a8

    • ThisIsZolden
      /#10043586

      Моделей материи на основе взаимодействующих частиц, конечно, существет много. Но геймплей в таких симуляциях вроде пока не делали, если не считать песочниц, вроде OE Cake.

      С этой конкретной моделью я бы поиграл, но там только код, а мне лень возиться с visual studio.

  43. ceperaang
    /#10040992 / +3

    Странно, что автор пишет об как о каком-то неожиданном открытии, как будто и правда сейчас 2007 год. Но вообще, эта тема очень горячая и активно исследуемая: тут и клёвые трюки с изменяемым размером сетки/плотностью частиц в ключевых/маловажных областях (например, больше внимания к поверхности, меньше к толще материала), аппроксимация точных уравнений нейронными сетями (т.е. сеть учится делать симуляцию, чтобы это выглядело для члеовека достаточно хорошо, выше уже дали ссылку на подобную работу), ну и вообще всякое подобное.
    Я бы порекомендовал полистать последние работы со всяких SIGGRAPH'ов — можно много интересного найти и не нужно будет набивать шишки на собственном лбу.

    • andybelo
      /#10041114 / -4

      А, вот кто мне сейчас ответитправду. Вот скажи, студент Маши Лёрнинко, где нейросети, имитирующие ловлю мухи лягушкой? Или вас только учат, как карму минусовать, несчастные? Я лично уверен, что ничего кроме % сверки изображений с образцом в вашей «науке» нету.

      • marsermd
        /#10041488 / +1

        За такие комментарии стоит минусовать)


        • Придрались к незначительной части комментария
        • Обвинили автора комментария в том, что он минусует карму ТС
        • Упомянули никому неизвестного человека(гугл не находит буквально ничего по запросу "Маша Лёрнинко")
        • Высказали поверхностное суждение, не нагуглив, что действительно есть работа, которая с помощью нейронных сетей улучшает результат физических солверов.
          WTF?

        Большая часть ваших комментариев о том, что все такие плохие-нехорошие и минусуют, а большая часть оставшихся комментариев — не аргументированная критика.
        Статей нет.
        Как следствие, и карма у вас в минусах.

        • chersanya
          /#10041564 / +1

          Видимо, Маша Лёрнинко — это Машин Лёрнинг :)

          • marsermd
            /#10041670 / +1

            А, блин, нормальная анаграмма.
            Этот пункт беру обратно) Остальные остаются)

            • andybelo
              /#10042126

              http://choose-life.ru/themes/lyuboj-superkompyuter-ne-sravnim-s-chelovecheskim-mozgom

              • marsermd
                /#10042372

                И?)

                • andybelo
                  /#10042578

                  А вы нагуглите, про лягушку. Вот когда нейронные сети сделают лягушку, которая ловит мух, тогда учите других, про «достижения» нейронных сетей.

                  • ThisIsZolden
                    /#10043630 / -1

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

        • herr_kaizer
          /#10047234 / +1

          У человека фобия по нейронным сетям.

    • ThisIsZolden
      /#10043604 / -1

      У меня индуктивный метод обучения: сделать самому, обобщить проблематику, ознакомиться с литературой. Так что это вопрос не шишек, а оптимального способа приобретения знаний и навыков.

  44. Smorodov
    /#10048180 / +1

    Наткнулся на интересную работу, близкую по теме статьи (с исходниками), может Вам будет интересно: статья.
    Статья о моделировании песка в 3D и получилось у них довольно реалистично.