Мне всегда нравились игры, в которых есть физика. То есть, некоторые процессы не управляются скриптами, а эволюционируют во времени, следуя физическим законам. Из этого проистекают сложность и непредсказуемость игрового процесса.
Примеров много, физические элементы тонко пронизывают многообразие компьютерных игр. Взять хоть любой платформер: совсем другие ощущения от игры, когда есть инерция персонажа, скольжение, гравитация, урон от падения с большой высоты и отдача от оружия.
Или те же гоночки: до чего приятней на полной скорости сшибать людей, рекламные щиты и помойки, чтобы разлетались во все стороны, вместо того, чтобы мгновенно останавливаться, врезаясь в мёртво врощенный в землю столб.
Или ещё замечательный пример — Kerbal Space Program. Там физика уже является непосредственым источником геймплея.
Или, например, жанр 2д артиллерии. Часть его очарования базируется на уничтожаемой, динамичной земле. Но до чего он был бы лучше, если б земля не просто линейно осыпалась, а вела себя реалистично, разлетаясь от взрывов кусками.
Я давно мечтал сделать именно такой, до предела физически реалистичный римейк Scorched Earth. Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.
Но недавнее моё «открытие» изменило ситуацию. Мы живём во времена быстрого развития геймерского железа. Развивались главным образом видеокарточки, потому что производители игр с наибольшим энтузиазмом наращивали именно графическую составляющую игр, а производители железа поддерживали высокий fps. И не удивительно решение компании Nvidia добавить возможность для разработчиков писать код для графической системы, то есть осуществлять вычисления в графичесокм ядре.
По-моему, это решение было тихой революцией. Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени. В среднем геймерском компьютере производительность видокарты в 50-100 раз выше производительности центрального процессора.
Конечно, задача должна быть хорошо распараллеливаема, этот бонус актуален не для любого алгоритма. Но моделирование тысяч частиц идеально распараллеливается.
Осознав это, я понял, что наконец-то смогу создать полностью физическую игру, в которой не будет заскриптовано ничего, кроме физики. Игра станет эквивалентна физической симуляции.
Я давно делаю игры на Юнити, и был рад, узнав, что в этом движке реализован класс ComputeShader, который позволяет использовать в проекте шейдеры на языке HLSL. Просто пишем шейдер, линкуем его к экземпляру ComputeShader, и диспатчим в Update.
Вникнуть в параллельные вычисления на GPU было не слишком просто. Туториалов маловато, а те, что есть, довольно ограничены в объёме поясняемых тонкостей. Но ключевых трудностей было не так уж много, довольно богата справочная информация по HLSL была на msdn, так что кое-как путём проб и ошибок я овладел спецификой и начал делать игру.
Задача была проста: нужно смоделировать в реальном времени несколько десятков тысяч взаимодействующих частиц, и из них построить мир, который жил бы уже по своим законам.
Параллельные вычисления — коварная штука. Нужно было свести все вычисления к простым блокам одинакового размера, чтоб на каждую частицу приходился один поток. Я решил упростить до предела математику взаимодействия частиц. К примеру, обойтись без интегратора, просто мерять величину поля (описывающего взаимодействие частиц) в текущей точке, и на его основе менять скорость частицы. Простота гарантировала, что все потоки будут выполняться одинаково быстро, и не возникнет тяжёлых потоков, которых остальными придётся дожидаться.
Кроме того, при взаимодействии частиц нужно было работать с данными в защищённом режиме, чтобы паралельные потоки были осведомлены об одновременной записи-чтении и не путались. Ведь если частица может одновременно взаимодействовать с десятком других частиц, все они могут параллельно изменять её скорость, а значит, необходимо делать это в защищённом режиме. Средства для этого в HLSL нашлись. Правда, операторы вроде InterlockedAdd() работают только с int-величинами, так что приходилось пожертвовать точностью, и хранить скорость в видеопамяти в виде int-величин.
Огромные массивы взаимодействующих частиц — тоже коварная штука. Нужно было упростить сложность вычилений с до чего-то вроде
Этого я добился, создав двумерную сетку 256x256, и в каждом её элементе на каждом шагу сохранял ссылки на все ближайшие частицы, так что при обсчёте взаимодействия частиц, каждая частица взаимодействует лишь с теми частицами, что находятся в пределах нескольких 3x3 элементов сетки.
Кстати, почему вместо уже реализованного в Юнити физического движка я создал свой? Потому что универсальный физический движок, подходящий для широкого спектра задач, связанных с моделированием системы твёрдых тел, плохо подходит для моделирования системы взаимодействующих материальных точек. Я предпочёл оптимизированный под специфику оригинальный движок. Если создать в юнити тысячу объектов с rigidbody, можно убедиться, что fps падает довольно сильно. В моём случае нужны десятки тысяч частиц, и написанный с нуля движок позволяет их вычислять с хорошим fps.
Дискретная симуляция физического взаимодействия — опять же, коварная штука. Чем больше шаг, тем больше погрешность. Взаимодействия между частицами реализовано через силу Леннарда-Джонса, то есть, при сближении частиц сила отталкивания растёт в двенадцатой степени. Это неимоверно усиливает ошибку, связанную с большим шагом. Попросту, материя взрывается, нарушается закон сохранения энергии.
Возникает противоречие: нам нужна быстрая real-time симуляция. Но шаг должен быть очень маленький. Это противоречие я разрешил уменьшив шаг в десять раз по сравнению с первыми экспериментами, и производя десять циклов симуляции в каждом Update(). Цена этого решения — производительность. Так что пришлось сильно уменьшить количество частиц. Но всё же их осталось достаточно для сложного поведения всей системы.
Ну, и ещё пара десятков хитростей были мной реализованы, чтоб получить удовлетворительное поведение материи. Например, я ввёл аналог валентных связей между частицами, которые распределяют импульсы и скорости частицы между соседями. Или, к примеру, гравитация не действует по всему объёму земли, а затрагивает только верхний слой частиц. Но если большие куски материи взлетят в воздух, гравитация будет на них влиять в полной мере. Это реализовано с помощью построения на каждом шагу гравитационной маски, и учёта её при расчётах.
И таких тонкостей ещё много, не хочу слишком углубляться в эту специфику. Месяца четыре в хобби-режиме ушло на решение всех проблем с параллельным вычислением и физикой, и в какой-то момент можно было переходить на уровень геймплея.
Что в итоге получилось? Получилась игра в жанре «2д артиллерия», вроде Pocket Tanks, Scorched Earth или Worms.
Вот длинное, в десять минут, видео, в котором тоже показан игровой процесс, но более подробно:
Можно заметить, что земля и строения выглядят как желе. Это исправляется за счёт производительности. Можно уменьшить шаг и усилить коэффициент влияния полей на скорость частиц. Но пока я стараюсь удержать игру на уровне не слишком обременительном для большинства не слишком старых видеокарт. Скажем, на моей карте GTX 750m, в которой 384 ядра, игра с 20 тысячами частиц работает с частотой 25 fps, что делает её вполне играбельной.
Вывода здесь два, объективный и субъективный:
1. Видеокарта обладает огромной мощностью, и сейчас уже не существует непреодолимых технических преград, мешающих разработчикам использовать её для вычислений. Это может открыть для практического использования прежде недоступные (из-за вычислительной тяжеловесности) подходы к игровому процессу.
2. Очень необычные ощущения возникают от игры в физически реалистичной песочнице. И по-моему, тут зарыто много неожиданных идей в области геймплей-дизайна. И хотелось бы, чтобы разработчики побольше экспериментировали с внедрением физики в геймплей, ибо на графике свет клином не сошёлся.
Комментарии (211)
VovanZ
22.01.2017 18:20+34Хмм, очень странная статья. CUDA появилась в 2007, OpenCL в 2008, все даавно используют видеокарты для самых разных вычислений.
По-моему, это решение было тихой революцией.
Да, но это случилось 10 лет назад :)
ThisIsZolden
22.01.2017 18:24Согласен, это всё появилось давно. Я хотел сосредоточить внимание не на самой технической возможности считать на видеокарточке, а на альтернативе обычному подходу к геймплею, когда физику используют как вспомогательную и незначительную составляющую. Статья посвящена возможности построить геймплей на физике полностью.
AllexIn
22.01.2017 18:41+17Очень странно «открывать» на это глаза в мире победивших Angry Birds.
ThisIsZolden
22.01.2017 18:54+3Angry Birds — тоже хороший пример физики, создающей геймплей. Хотя, у них геймплей слишком простой, нет передвигающихся персонажей. И физика тоже проста — несколько спрайтов с коллайдерами на уровень. Но это уже кое-что. С момента выпуска прошло несколько лет. Появилось много клонов, но все они не пытаются выйти из ограниченной физики оригинала. Я просто попытался пойти дальше, как на уровне геймплея, так и на уровне физики, чтоб посмотреть, насколько интересно довести процент физики до предела.
AllexIn
22.01.2017 18:58+5Это что-то из разряда «да, там красные пиксели есть, но не много. Но хочется довести их количества до предела.»
Физика — сама по себе геймплей не создает. Это один из инструментов геймдизайнера, но не единственный. Если использовать только его получится либо песочница, либо симулятор козла-хирурга(впрочем тоже песочница). Игры не получится.
deep_orange
22.01.2017 19:03+12D-артилерия состоит на 100% из физики. Причём примитивной. А геймплей создаёт чувак, которого надо загасить или он загасит тебя.
AllexIn
22.01.2017 19:04+7О чем и речь. И интересность игры вообще минимально меняется от того, насколько круто считается физика грунта.
ThisIsZolden
22.01.2017 19:48+2Как раз сейчас я взялся за геймплей. Демка из видоса — первая экспериментальная версия игры на этой физической земле, простое переложение механики Scorched Earth на физическую землю. Достоинства тут пока визуальные, взрывы незаскриптованы, и потому разнообразные.
Кроме, того, в актуальной версии есть особенность, которая уже граничит с уровнем фищек геймплея: танки тоже сотоят из частиц, и урон визуализируется в виде повреждений. Может отвалиться кусок корпуса, могут порваться и слететь гусеницы, может взорваться колесо или сломаться пушка. Всё это влияет на управление танком.
А идей для проверки много, внедряю помаленьку, экспериментирую. Удастся найти чего-то оригинальное и интересное — добавлю, а не удастся — буду другим заниматься.
DnV
22.01.2017 20:29Конечно, сегодняшнее применение физики — сплошной компромисс и оптимизация. Вы сами показали, что мощностей даже GPU пока хватает впритык на желеобразные двумерные абстракции. А если мы хотим симулировать трёхмерные объекты реального мира, то выгоднее всего исключить из расчетов физику твёрдых материалов, ограничившись взаимодействием физических тел. Но будущее за полной симуляцией, безусловно.
ThisIsZolden
22.01.2017 23:34Интересно было бы поэкспериментировать с GTX 1080, чтоб понять сегодняшний предел, думаю эта карточка потянет 2-5 сотен тысяч частиц, этого и для 3д может хватить.
Но что верно, то верно, даже с крутой карточкой ограничения довольно близки. Я подумываю попробовать однажды другой подход, когда всё состоит из динамически разрушаемых при столкновениях мешей. Там физики — по числу осколков. Можно гораздо более сложный разрушаемый мир смоделировать, без особых вычислительных затрат.
selenite
23.01.2017 00:33как-то писал демку астероидов с voronoi transform в качестве тестового задания в одну веселую компанию :) сделать технично вышло, красиво — нет. Стоит попробовать найти дизайнера в пару )
ThisIsZolden
23.01.2017 15:18Ага, разбиение вороного — хороший инструмент для получения осколков.
А «технично, но не очень красиво» — наверное, самая распространённая ситуация в инди-геймдеве, когда программист делает клёвые штуки, которые не впечатляют на вид. На форуме unity3d.com сейчас можно довольно легко привлечь энтузиастов-дизайнеров, если показать что-то техничное.
pavel_kudinov
23.01.2017 15:09+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 580ThisIsZolden
23.01.2017 15:39+1Спасибо, прочитаю статью. Возможно, смогу что-то ускорить в своей программе, было бы кстати.
А моя оценка количествf частиц на GTX 1080 касалась не общего случая, а моей реализации. Специфика такова: чтобы кристалл удерживал форму, нужно повысить (в сравнении с моделированием жидкости) силы взаимодействия частиц, но встаёт проблема: погрешность дискретизации умножается на величину сил Поэтому, я сильно уменьшил шаг дискретизации. И за один Update() прогоняю 10 циклов симуляции с довольно маленьким шагом, чтоб сохранить быструю работу в реальном времени.
Не исключаю, что где-то я не дотянул с оптимизацией, но при прочих равных создаётся впечатление, что для моделирования жидких сред нужно в 5-10 раз меньше производительности на частицу, чем для твёрдых.pavel_kudinov
23.01.2017 15:48+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 раз, а скорее за всё приходится заплатить двух-трёхкратным снижением производительности, за счёт дешевизны расчётов взаимодействий связей по сравнению с SPHpavel_kudinov
23.01.2017 15:54+2раньше ещё использовал один раз посчитанную сетку на несколько кадров взаимодействия частиц, но это даёт артефакты на быстром движении объектов, а fluidsv3 сделал расчёт сетки очень дешёвым, поэтому отказался от этого читерства и теперь объекты могут очень быстро двигаться относительно пространства и корректно при этом «столкновения на относительных скоростях» обрабатывать
p.s. я во многих случаях вообще убираю трение и гравитацию и живу в «бесконечном космосе без трения».
кстати, конечная по размеру SPH сетка отлично обрабатывает бесконечный космос, это поначалу сбивает с толку, но всё просто — частицы проецируются в сетку как остаток от деления на размер сетки, в результате чего сетка начинает быть периодической структурой. в этом случае, «на соседей» приходится проверять физически не близкие друг к другу объекты, но это никак не влияет на производительность, потому что как бы частицы не разлетелись по бесконечному космосу, количественно их всегда останется столько же, и пар проверок будет всегда «стабильное количество», просто чаще будет даваться ответ «нет, несмотря на то, что клетки в „индексной“ сетке — соседние, частицы друг от друга очень далеко»ThisIsZolden
23.01.2017 18:22вау, роскошный «чит» с бесконечной сеткой!
pavel_kudinov
23.01.2017 19:08+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
22.01.2017 23:29Насчёт идей, возможно ли соединить, скрепить частицы, и сделать из них группу, которая обладает некоторыми едиными изменчивыми характеристиками? Например, броня танка, представляет собой единый материал, который можно деформировать, применив лишь достаточно твёрдый и крепкий материал, а также большой импульс.
ThisIsZolden
22.01.2017 23:36Да, так можно было бы, но это бы подразумевало кроме вычислений типа частица-частица, проводить вычисления типа двумерное тело-частица. А это уже более сложная математика. Совмещать подходы счастицами и с телами — не слишком правильно, потому что лучше всего параллельный обсчёт работает, когда все потоки выполняются за примерно равное время. А расчёт тел сложней, и его все будут ждать, Общая производительность упадёт.
pavel_kudinov
23.01.2017 15:19+1не совсем так. если составить тело из таких же частиц, то частицы будут естественным образом обрабатываться за один проход как частица-частица взаимодействия, останется только собрать физику мягкого тела на spring-mass-damper связях между частицами, и, чтобы достичь более менее интересных характеристик упругости, обязательно не забыть именно про damper составляющую (иначе будет кипеть при попытке перехода от мягкого к упругому), плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям
я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»
в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:
Nvidia FLEX
демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц
плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)ThisIsZolden
23.01.2017 16:00У меня это примерно так сейчас и сделано. Я использую силу леннарда-джонса, которая комбинирует притяжение и отталкивание. Так что частицы слипаются в тела, если сталкиваются, и ведут себя как тело, потому что связи между ними работают как пружины. При этом, тела разрушаемы, потому что составляющая притяжения не велика по силе.
В ближайшее время я сделаю разные материалы, и одновременно будут существовать и более твёрдые, и более текучие среды. Сейчас это частично реализовано: температура влияет на склонность к образованию и разрыву связей, так что системы горячих частиц напоминают жидкость.
плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям
Вот сразу видно, что вы практикуете в этом направлении. Это решение у меня, действительно, реализовано. Хотя, я всё же уменьшил эту составляющую, потому что из-за неё энергия взрыва вместо того, чтоб разрушать землю, распространяется волной вглубь, а это не так зрелищно.
VeroLom
23.01.2017 18:25Будет ли где-нибудь выкладываться код или хотя бы бинарник, чтобы можно было просто погонять?
ThisIsZolden
23.01.2017 18:29Да, я загрузил основной код для частиц в ассет стор юнити:
https://www.assetstore.unity3d.com/en/#!/content/76233
Он пока платный, но после выхода игры сделаю беспланым.
А игра, скорее всего, будет включать не только геймплейную составляющую, но и редактор мира, чтоб рисовать домики и взрывать их — как раз для тех, кто хочет «погонять».
Areso
22.01.2017 20:35+1Какая-то укуренная физика в этой игре про козла. Когда смотрел обзоры игры на ютубе, она мне нравилась, и, дождавшись распродаж, я её купил. Разочаровался.
Чем-то напомнила нереалистичные китайские боевики в средневеком сеттинге, где все герои прыгают половину фильма на растяжках.
VovanZ
22.01.2017 19:01+1Кстати, ещё Cut The Rope — в каком-то смысле про физику.
Сходу больше не могу вспомнить, но мне кажется, что я видел больше одной подобной "головоломки с физикой".
AllexIn
22.01.2017 19:03+11Да тыщи игр с физикой в основе геймплея.
Неиссякаемые Incredible Machines, вообще под досом начались.
Areso
22.01.2017 20:36+1На смартфонах есть популярный Where is my water? про кродильчика Свомпи. Очень достойно сделан.
tsul
23.01.2017 16:13«Прыгательные» уровни Quake3. q3dm17 и прочие карты с джамперами. Гравитация и прыгалки, больше ничего не надо :)
maaGames
22.01.2017 18:26+2OpenCL, CUDA. Может вам эти технологии жизнь облегчат.
ThisIsZolden
22.01.2017 18:32+3CUDA — Nvidia specific. А компьют шейдер в юнити компилится в opnegl или directx.
Nokta_strigo
23.01.2017 22:47На сколько я знаю историю GPGPU, расчёты не графики с использованием шейдеров использовались как костыль когда не было CUDA и прочих (правда я сам с помощью шейдеров никогда ничего не считал, сравнивать не могу), сейчас вроде уместней использовать вышеупомянутый OpenCL, он умеет с разным железом работать.
AllexIn
22.01.2017 18:40+7Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.
Всё упирается в вашу неспособность сделать это.
В 2007 году вышла игра Maelstrom.
С терраформингом и растекающимися жидкостями.
А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.ThisIsZolden
22.01.2017 18:50Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.
Терраформинг — это изменение координат вершин меша, это не требует больших вычислительных ресурсов.
А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?AllexIn
22.01.2017 18:55-6Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.
ДА полюбому. Как минимум куча физически сложных игр, существующих задолго до CUDA тому показатель.
Терраформинг — это изменение координат вершин меша, это не требует больших вычислительных ресурсов.
Терраформинг — это немного больше, чем перемещение вершин. :)
ТАк можно сказать, что и у вас просто вершины двигать надо.
А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?
Простите, нет желания раскапывать архивы. А навскидку вспомнить не получится, это было очень давно.
Вы можете глянуть Maelstrom в режиме сетки. Там вполне можно оценить сложность расчетов.
Тем более что там еще и влиения ветра уникальное в каждой точке.
malbaron
23.01.2017 01:21+1Всё упирается в вашу неспособность сделать это.
В 2007 году вышла игра Maelstrom.
С терраформингом и растекающимися жидкостями.
А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.
В году 1994-1998 видел терраморфинг (на ассемблере) на i386/i486
Все летало.
santa324
23.01.2017 11:19+1Количество частиц не единственный параметр, важна частота итераций. Чем больше интервал интегрирования тем менее твердые и более желеобразные тела у вас получатся.
На современном i5 (CPU), в реалтайме (2D) мне удалось максимум выжать 20 000 частиц на 2 000 итераций интегрирования в секунду в один поток (это был эксперимен из любопытства, распараллелить не дошли руки).
Это тела с жесткостью визуально как у ластика.
Не думаю что возможно сильно больше, это примерно 7 связей на частицу, того около 300 000 000 связей в секунду.
andybelo
23.01.2017 12:05«зарыто много неожиданных идей в области геймплей-дизайна»
«это даже близко не предел» А сколько предел?AllexIn
23.01.2017 12:07Я без понятия, сколько предел.
2000 человек — не предел населения земли. Сколько предел? Я не знаю. Но точно не 2000.
«зарыто много неожиданных идей в области геймплей-дизайна»
Я не понял что это и откуда.
basilbasilbasil
22.01.2017 18:54+1http://www.nvidia.ru/object/nvidia-physx-ru.html
ThisIsZolden
22.01.2017 18:57-5PhysX — универсальный движок, но он не слишком хорошо годится для этой специфической задачи. У меня взаимодействуют не твёрдые тела, а материальные точки.
basilbasilbasil
22.01.2017 19:03+8не только твердые тела.
KpoKec
22.01.2017 20:28В юнити в 2д бывший Box2D. Физикс только в 3д.
А так можно много узких мест найти, если постараться, хоть в том же List, где при получении значения по индексу, индекс переводится из int в uint и потом сравнивается с int'овым пределом листа...EvilFox
23.01.2017 14:00И в юнити насколько помню не поддерживается аппаратное ускорение у Physx.
DanielTop
23.01.2017 16:13https://ru.wikipedia.org/wiki/PhysX Игровые движки, использующие в качестве физической подсистемы компоненты PhysX SDK: (там список игровых движков) и Unity…
EvilFox
24.01.2017 00:24+1Речь о том что Юнити использует PhysX порезанный, без аппаратного ускорения.
https://forum.unity3d.com/threads/could-unity-physx-be-accelerate-on-gpus.402848/
https://www.youtube.com/watch?v=P3CnprXSXJU
Они даже для ткани не спешат/или реализовывать.
Labunsky
22.01.2017 18:58+4По-моему, это решение было тихой революцией. Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени.
Она не мощнее, она просто другая. Ageia для обработки физики вон вообще одно время отдельные железки выпускали, которые еще круче (того, что было тогда, конечно) считать ее умелиThisIsZolden
22.01.2017 19:37Можно, конечно, выпустить отдельную карту для физики, полностью лишённую чисто графической функциональности. Только у такой карточки всё равно цена за единицу производительности будет выше, потому что в производстве железа главный ценообразующий фактор — массовость. Видеокарты — массовый продукт, поэтому доля стоимости разработки и постройки производственных мощностей в цене каждой железки — ничтожна.
По этой причине физические карточки в своё время не прижились, а видеокарты сегодня заточены для физики.
Wilk
23.01.2017 16:13+1Здравствуйте
Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.ThisIsZolden
23.01.2017 18:33Для научных расчётов такая штука наверняка лучше подходит, если Nvidia её сделала как модификацию популярного железа, и снизила за этот счёт цену.
Mad__Max
23.01.2017 21:11Нет, за счет этого Nvidia наоборот резко увеличила цену. На «богатеньких профи» же рассчитано, у них в отличии от геймеров денег много, можно трясти по полной.
Mad__Max
23.01.2017 02:48Они именно мощнее по вычислительным возможностям, как минимум на порядок для слабеньких карт, и на 2 порядка для топовых. Свои особенности конечно есть, но сейчас это практически такие же универсальные вычислительные устройства как центральные процессоры, позволяющие практически любые алгоритмы реализовать и задачи решать. Только в десятки раз быстрее CPU. Точнее реализовать мощно вообще любые, но не на любых будет такое огромное преимущество в скорости.
Deerenaros
23.01.2017 16:13Я бы не был настолько категоричным, архитектура GPU подразумевает RISC, правда не который у каждого в кармане, а настоящий, лишённый всех утех, вроде настоящего бранчинга http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html
В каких-то смыслах GPU и правда быстрее. На самом деле, даже в очень многих, но работа с памятью очень… Специфичная, любой тяжёлый поток может практически убить производительность, сведя её до нуля. Тогда как Skylake сожрёт его и не нагреется.
Что действительно будет быстрее, так это некий NoC из FGPA, но он пока так и остался в концептах. Вроде что-то говорили про NoC, что-то про FGPA в Core iX, но ничего не видно. Но эти вещи вместе могут избавить нас от такого рудимента как GPU за раз.Mad__Max
23.01.2017 21:28Ну задержки при работе с памятью там разве большие очень. Зато ПСП на порядок выше чем у CPU.
Один поток ничего не убъет, если конечно программа не из разряда когда все остальные потоки ждут в простое результатов от этого одного ведущего потока (т.е. по факту софт однопоточный и не распараллелен), т.к. в современных GPU помимо кучи исполнительных устройств и довольно много полностью независимых самостоятельных ядер(каждое с собственными декодарами и диспетчерами инструкций, блоками загрузки/выгрузки и т.д.) и Х независимых контроллеров(каналов) памяти с собственными кэшами на каждом.
А по ссылке книжка конечно хорошая, но очень уж старая — писалась в 2004м году, 13 лет назад описывая архитектуры GPU выходившие в 2002-2004 годах, 1-2 поколение программируемых, когда микропрограммы для GPU еще только начинали внедрять. Те GPU что были тогда и те что имеются сейчас довольно мало общего имеют. В т.ч. и бранчиг вполне полноценный появился, по крайней мере все имевшиеся в первых поколениях ограничения на условия, переходы и циклы давно сняты.Deerenaros
24.01.2017 00:10+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 с Марса можно было хоть чайник кипятить. Вполне успешно.
vintage
22.01.2017 19:54Физику уже давно все крутят на GPU при помощи https://ru.wikipedia.org/wiki/PhysX
Где на бетатест вашей игрушки записаться? :-)
ThisIsZolden
22.01.2017 20:11Да, официальная физика от нвидиа — на gpu, но мне нужен был больший контроль, чем даёт их апи.
Для бетатеста пока рановато, ещё месяц надо над геймплеем поработать. Но можно на стиме проголосовать: http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Если её одобрят, весь бета-тестинг будет там происходить.vintage
22.01.2017 22:49+6Тогда где на альфа-тест записаться? :-)
Касательно графики: не можешь победить — возглавь. Думаю тут бы лучше смотрелась не натуралистичная графика, а что-нибудь по проще. Раз уж разрешение невысокое и физика гутаперчивая, то имеет смысл и сеттинг выбирать соответствующий. Какие-нибудь "желейные войны" или "нано-конфликт".
Ещё было бы круто собирать свой танк, как в robocraft.
ThisIsZolden
22.01.2017 23:41А какая у вас видеокарта? Мне как раз может понадобиться несколько человек с разными видюшками, чтоб отправить им сырую версию и посмотреть, какой fps у них покажет.
А что до желейных войн, то я игру пока так и назвал, «Jelly in the sky». Но сегодня я чуть физику исправил, и теперь твёрдое выглядит чуть более твёрдым. Вот, можно посмотреть:
http://i.imgur.com/qcGOQgW.gifMad__Max
23.01.2017 03:23+1Могу на карточках AMD среднего уровня (7850/7870 — 1024/1280 выч. блоков) под windows 7 прогнать. И на старой 5750(720 выч. блоков) под XP если оно конечно под XP с DX9 вообще в принципе работать может.
vintage
23.01.2017 07:35GeForce 840M
Всё-равно как пудинг :-) Если хочется твёрдых тел, то можно попробовать добавить давление. Приложение силы к твёрдой субстанции на входе при этом должно вызывать минимальное смещение, но передавать дальше большое давление. А на выходе падение давления должно вызывать большое смещение. При этом, если мы попали в землю, то волна давления должна отразиться от низа экрана и жахнуть по поверхности земли.
vokinsel
23.01.2017 16:13+1R7 в APU A10-7850K и GTX 460, могу поспособствовать в тестировании на Win10.
1as1
23.01.2017 16:13+1протестировал бы на gtx 1060.
протестировал бы и более тяжеловесные эксперименты.
Deerenaros
23.01.2017 16:24+1У меня Quadro мобильная, кстати говоря. Слабая, но что-то. Может у неё какие-то преимущества в GPGPU, не? Попробовать можно. Могу ещё на 1060 запустить, но это не так интересно.
ThisIsZolden
23.01.2017 18:35Спасибо всем в этой ветке, я с вами непременно свяжусь, когда возникнет надобность потестировать игру.
gorodnev
22.01.2017 19:59Огромные массивы взаимодействующих частиц — тоже коварная штука.
Задача уже давно решена — http://algs4.cs.princeton.edu/61event/
ThisIsZolden
22.01.2017 20:13Конечно, есть разные подходы, я почитал статьи перед тем, как взялся за реализацию. Но всё равно пришлось повозиться, потому что нужно было сочетать разные методы оптимизации.
schroeder
22.01.2017 20:05+1а где можно поиграться в эти клевые танчики?
ThisIsZolden
22.01.2017 20:15+3Я выложил игру на гринлайт:
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Если опубликуют, то на стиме. А если нет, ещё где-нибудь выложу. Вряд ли раньше, чем через два месяца закончу, но до релиза в любом случае доведу.malbaron
22.01.2017 22:15+1Забавная графика, спецэффекты то что надо.
Каков объем работы?
За какое время (в пересчете на полный рабочий день) это было сделано?ThisIsZolden
22.01.2017 23:42+1Если на полный рабочий день, то 2-3 месяца примерно, точней сложно сказать.
an24
22.01.2017 20:29+1Все выглядит как желе, потому что ваша модель твердого тела является реологической. Это более или менее подходит для сыпучего грунта. Но для моделирования твердого кристаллического тела нужны более сложные законы (кристаллическая решетка, упругая деформация, пластическая деформация и т.д.)
SHVV
22.01.2017 20:52+3Нет, по-моему, основная проблема в статье верно указана. Чем жёстче материал, тем выше его коэффициент упругости, тем выше скорость распространения взаимодействия в среде. Шаг времени должен быть таким, чтобы за одну итерацию это взаимодействие не прошло больше одной пространственной ячейки (частицы в данном случае). Иначе модель разойдётся и частицы просто разлетятся в стороны. По-этому, чтобы симулировать такое большое количество частиц в реальном времени приходится уменьшать коэффициент упругости и материал становится больше похожим на желе.
ThisIsZolden
22.01.2017 20:55Именно.
MatiasGray
23.01.2017 16:12+2Можно заметить, что земля и строения выглядят как желе. Это исправляется за счёт производительности.
Предлагаю очевидное решение: устанавливаем название игры «Jelly tanks». Устанавливаем мир игры — желейная вселенная. Всё состоит из желе. Получаем, что у игры есть идея™, которая отражена в основе геймплея. Профит и целостность проекта. И ещё оптимизация. Можно сделать несколько огромных уровней, с более желейной физикой.
Или можно использовать это в сюжете: злой злодей собрал зловещее устройство, которое в зловещих целях превратило весь мир в зловещее желе. Он также расставил везде своих роботизированых прихвостней-танков (тоже зловещих)
P.s. отличный снеговик, хе хе.ThisIsZolden
23.01.2017 18:37Ага, я так и назвал игру, «Jelly in the sky». Хотя, физику подкрутил, стало всё потвёрже, но в иоге тубет несколько материалов с разными свойствами.
ThisIsZolden
22.01.2017 20:54Эти более сложные типы взаимодействия есть, но из-за дискретности шага симуляции возникает ошибка, делающая материю нестабильной. Ряд решений, смягчающих эту ошибку (например, злоупотребление вязкостью, реализованной как распределение скорости и импульса частицы по соседям) создают эту желейность.
Но если заплатить немного производительности, отказаться от вязкости в пользу хрупкости и усилить жёсткость связи (риск нестабильности снижается уменьшением шага дискретизации), то материя ведёт себя в большей степени как твёрдое тело. Вопрос лишь в том, каким количеством производительности я готов пожертвовать.
В дальнейшем я планирую создать несколько типов вещества: твёрдое тело, землю, дерево и песок. И у них будут различные жёсткость/хрупкость/текучесть.
DrZlodberg
22.01.2017 21:28+5Суровые мармеладки! Вот только избыток красного после взрывов вызывает ассоциацию с кровищей. Что удивляет там, где её взяться неоткуда. А так физика прикольная. Особенно когда с разгона хоботом в мясе застревают.
ThisIsZolden
23.01.2017 04:49Подразумевалось, что это расплавленная взрывом материя. Хотя, и правда, многовато.
vintage
23.01.2017 07:47+2Расплавленная материя в зависимости от температуры будет светиться сначала красным, потом жёлтым, потом вообще голубым.
http://www.digcode.ru/BlackBodySpecrtrum.html
Типичные взрывы дают всё же жёлтый цвет: https://ru.wikipedia.org/wiki/Температура_взрываMad__Max
23.01.2017 21:39Это при нагреве. После выстрела/взрыва мы же имеем обратный процесс — остывания. И правильными в этом случае будут переходы желтый-оранжевый-красный-коричневый-черный(уже холодный, но обугленный/оплавленный материал)
AngReload
23.01.2017 16:12Почему внешне выглядит так твердо?
Можно же красочно раскрасить все под тортики, пироженки, желе — и никаких вопросов.
tautomer
28.01.2017 01:05Вовсе не многовато. Вот только, чтобы казалось, что материя нагрета до красного каления, красным должен быть только «ореол». То есть, тёплые частицы могут краснеть, а вот самые горячие частицы желтеют аж до белого.
perfect_genius
22.01.2017 21:29+4Что можете сказать об PixelJunk Shooter?
Игры давно не играю, но эта, основанная на физике, заставила пройти до конца.
ThisIsZolden
22.01.2017 23:48Выглядит здорово. Частиц для жидкости — минимум, но благодаря хорошей математике взаимодействия, они довольно реалистично изображают жидкость. Ну и с графикой правильно сделали: множество частиц покрывается сплошной динамической текстурой. Я думал тоже нечто подобное сделать, но пока не копал в этом направлении.
sleeply4cat
22.01.2017 22:50А какие вообще есть способы распараллеливания «устойчивой» симуляции частиц? Хотя бы на примере того же The Powder Toy. Или клеточных автоматов.
Я пытался объединить обработку блоков сетки в «транзакции», чтобы в случае конфликта блокировок/очёрёдности обсчёта откатывалось состояние менее приоритетной, а потом вычислялось заново, но это сожрало все 8 ядер, дав скорость одного.ThisIsZolden
23.01.2017 04:48Основной метод — использовать защищённую запись. В HLSL используются Interlocked операторы, а в процессорной многопоточности есть разные методы, в подробности которых я не вдавался и не могу ничего подсказать, но этому посвящено много статей, легко гуглится.
Насчёт Powder Toy — не знаю. Судя по динамике работы, эта однопоточная программа, но я могу ошибаться.
xPomaHx
22.01.2017 23:49+3Меня в свое время шокировала физика песка из игры Earthworm Jim на Sega. Думаю что чем больше игра предлагает способов прохождения, чем больше вызывает интерес.
yetanotherman
22.01.2017 23:55+4Признаться честно, от GPU после прочтения статьи я ожидал большего, чем у вас на видео.
Но, с другой стороны, если отвлечься от технических деталей — я бы с удовольствием в это порубился, выглядит очень интересно. Похоже, вормсами вдохновлялись? :)
Еще никуда не выкладывали?ThisIsZolden
23.01.2017 04:43Да, вдозновился вормсами и scorched earth. А на видео многое скрыто. Например, тот факт, что за каждый фрейм запускается 10 циклов симуляции, чтоб шаг был в 10 раз меньше. С меньшей точностью у меня и 500 тысяч частиц летало. Это было зрелищно, но не подходило для игры. А тут точность большая, но это не бросается в глаза.
Игру уже выложил в гринлайт:
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
SAKrisT
23.01.2017 13:49А почему только для PC? для macOS есть в планах?
ThisIsZolden
23.01.2017 18:40Если Юнити каким-то образом смогут компилировать compute shaders в Metal-код или Metal сам сможет поддерживать DX11, то не будет препятствий для выпуса игры под мак.
SAKrisT
23.01.2017 23:03Я почему-то думал, что в Unity свой шейдер язык и он конвертируется на таргет платформу автоматически. Или есть какие-то ограничения?
chersanya
22.01.2017 23:55+1Не смотрели в сторону более продвинутых методов решения дифуров, чем прямой прогон вперёд? Кажется, что методы имеющие ошибку второго порядка (вместо первого, как у вас) могут заметно помочь.
Ну и если ещё больше углубляться, то для моделирования частиц и действующийх на них сил есть неплохой метод particle-in-cell (гуглится), используемый в том числе для серьёзных физических симуляций. Здесь, конечно, оверкиллом будет :)ThisIsZolden
23.01.2017 04:41Спасибо, погуглю.
А более продвинутые методы могут сработать, я пока не пробовал. Если вместо величины поля в текущей точке использовать усреднённое значение по текущей и следующей (по вектору скорости), то можно уменьшить ошибку.
pavel_kudinov
23.01.2017 15:33насколько я проверял, не помогают другие, более сложные формулы на практике с целью оптимизации.
в плане характеристик кипения в зависимости от величины шага дискретизации, тупо .pos += .vel; ничем не отличается от формул с кучей переменных и компенсациями ошибок второго порядка, а алгоритм от более сложной математики ещё начинает притормаживать
TheIncognito
23.01.2017 01:59Вспоминается стрелялка про танки на Flash… Только управление было поподробнее, и не придумали лазерные снаряды.
Fen1kz
23.01.2017 02:07+4Простите, но я бы не назвал физику в видео хоть сколько бы реалистичной. Вот совсем, скорее забавный физический эксперимент.в мире "желе". Если вам нравятся игры с физикой, посмотрите тот же Cortex Command (И следующую игру от них же). Несмотря на отвратность разработчиков, физика у них сносит мозг.
ThisIsZolden
23.01.2017 04:38+2«Желейность» я могу пофиксить, вот сегодня записал гифку, получше стало?
http://i.imgur.com/qcGOQgW.gifFen1kz
24.01.2017 02:54+1Не пожалейте 15 минут, посмотрите видео
Как бы вы молодец, и я восхищен вашими навыками написания физики, но, если честно, то не впечатляет =(
ThisIsZolden
25.01.2017 01:08Да, это хороший пример геймплея, в котором много взаимодействия с землёй. Чуть позже, после реализации основных фич уровня scorched earth, я попробую что-то в этом роде реализовать, с копанием земли.
Win332
23.01.2017 02:48Очень хорошая статья. Давно думал сделать подобное, но руки не доходили. Была так же идея сделать библиотеку для обработки достаточно сложных операций не через ЦП, а предоставить это GPU.
ThisIsZolden
23.01.2017 04:37Это всё не так уж и сложно, если делать с помощью compute shader на юнити. Так что если давно думал сделать, есть смысл попробовать.
Mad__Max
23.01.2017 03:28Возникает противоречие: нам нужна быстрая real-time симуляция. Но шаг должен быть очень маленький. Это противоречие я разрешил уменьшив шаг в десять раз по сравнению с первыми экспериментами, и производя десять циклов симуляции в каждом Update(). Цена этого решения — производительность. Так что пришлось сильно уменьшить количество частиц. Но всё же их осталось достаточно для сложного поведения всей системы.
А шаг динамическим сделать нельзя? При наличии близких частиц уменьшать шаг обсчета, при дальних взаимодействиях где погрешность намного медленней накапливается считать крупными шагами.ThisIsZolden
23.01.2017 04:36Определить наличие близких частиц — это значит уже сделать полноценный шаг. А определять наличие дальних частиц при отсутствии ближних стоит дорого в вычислительном смысле.
Mendel
23.01.2017 12:42Попробуйте температуру или еще какой аналог.
Или инверсию зависимостей.
Читал по диагонали статью, но меня смутило что у вас время везде равномерно.
От этого приходится ждать «медленные» потоки, или считать что лежачий камень всё еще лежит.
Помню в школе когда еще не знал о нейронных сетях, придумал что-то похожее. Только у меня веса лежали не у принимающей стороны а у нейрона который выдает спайк. Это усложняло обучение, но упрощало симуляцию на процессоре — те нейроны которым спайки не приходили (импульсные), те и не пересчитывались.
Что-то похожее можно и у вас сделать. Частица изменила свои координаты и вектор. Посчитали кого это может задеть, добавили их в очередь.
Чтобы понимать кто где — можно не просто координаты хранить, но разбить вселенную на сектора и иметь массив частиц находящихся в секторе. Ну или по графу двигаться. Просчитали каждому кто рядом с ним. Навесили связи. Частица сместилась — поменяли связи. Кого убрать понятно, кого добавить — полюбому будет кто-то из соседей наших соседей. Если скорость слишком большая — уменьшили квант времени в этом секторе.
Я понимаю что это звучит как поток сознания, но основная мысль у меня — удорожание просчета одной частицы даже в два раза, легко окупится если за счет этого 90% частиц мы пересчитывать не будем.
Да, про температуру я здесь упомянул в том смысле, что температура это некая интегральная мера количества движения/суеты. Если сделать поле температуры (сглаженное значение модулей кинетических энергий) и пропорционально температуре распределять локальную частоту квантования времени, то можно существенно сэкономить мощности без существенной потери точности, а на сэкономленное — повысить точность там, где оно важнее.
Опять таки — отказ от однородности времени даст Вам возможность вводить более сложные алгоритмы для частных случаев (предмет+частица и другие) не опасаясь что это повредит распараллеливанию.
marsermd
23.01.2017 12:56Забавный факт: Miles Macklin et.al. (http://mmacklin.com/uppfrta_preprint.pdf) находят соседей только один раз на несколько итераций солвера.
pavel_kudinov
23.01.2017 15:35+1да, это кстати работает, но ценно только до тех пор, пока сетку чертить дорого, а с алгоритмом fluidsv3 это начинает стоить копейки, зато исчезают артефакты при быстром движении объектов («дрожание физики по линиям сетки»)
Mad__Max
23.01.2017 22:03Не совсем полноценный — пересчет сил, скоростей и координат можно не делать же в этом случае, а в следующем шаге посчитать их один раз за удвоенное/утроенное/учетверенный отрезок внутриигрового времени.
Ну или если полноценный, то при отсутствии близких частиц можно просто следующий шаг или несколько целиком пропустить.
В грубой реализации допустим сейчас есть цикл который делает 10 или 20 итераций как у вас на каждое обновление. Но сделать его не на простом счетчике i=1..10; i++, а на условном — были при обсчете текущего шага близкие частицы делаем в конце итерации i+1, если таких не было значит в конце итерации будет i+2 или i+3.
Естественно время во всех формулах расчета сил и координат частиц будет не фиксированными шагами меняться, а пропорционально номеру шага/итерации.
ntkj666
23.01.2017 04:12А на карточках от amd как работает?
ThisIsZolden
23.01.2017 04:34Пока не проверял, но должно работать. На amd ведь работает directx и opengl?
KoToSveen
23.01.2017 04:34Желейная реализация физики показалась очень забавной. Очень сильно раззадоривает момент после выстрела, когда вся конструкция складывается. Дома обязательно ребятишкам покажу эту игру. И да, я бы купил эту игру (с ностальгией вспоминаю времена Scorched Earth).
3aicheg
23.01.2017 05:07Ваша игра напомнила демки Phyz, который вышел когда ещё, и, вроде, не использует никакого GPGPU.
Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени. В среднем геймерском компьютере производительность видокарты в 50-100 раз выше производительности центрального процессора.
Как считали?
Конечно, задача должна быть хорошо распараллеливаема, этот бонус актуален не для любого алгоритма. Но моделирование тысяч частиц идеально распараллеливается.
Не только «хорошо распараллеливаема», там ещё должен быть достаточно простенький алгоритм без ветвлений.AllexIn
23.01.2017 10:18там ещё должен быть достаточно простенький алгоритм без ветвлений.
Почему?
Ну, то есть, понятно что ветвления это минус в прозиводительности.
Но особых требований по этому поводу сейчас уже минимум.3aicheg
23.01.2017 10:24Там не требования, ветвиться-то можно, но оно, насколько я помню, просаживает производительность куда хуже, чем ошибка в branch prediction на CPU. Выполняются всегда все ветки кода, потом ненужное выкидывается. Возможно, мои сведения устарели, не знаю.
marsermd
23.01.2017 12:53Нет, все верно. Каждый мультипроцессор в видеокарте работает по принципу Single Instruction Multiple Data, выполняя за один такт одну и ту же инструкцию на каждом из ядер, но на разных участках памяти. Соответственно, если какая-то строчка сработала на одном из ядер, она займет время и всех остальных ядер мультипроцессора.
pavel_kudinov
23.01.2017 15:38насколько я знаю, блокируется на ветвлении не весь мультипроцессор, а только WARP_SIZE.
в WARP'е всего 16-32 потоков, так что немного веток таки можно делать, это снизит производительность, но не фатально за счёт небольшого размера WARP'аThisIsZolden
23.01.2017 20:33А ветвление — это когда используются операторы if и case? Я, признаться, ничего не знал об этом ограничении, и понатыкал их всюду довольно много. Я не замечал особо явного влияния на fps. Видимо, оно не слишком велико. По сравнению, например, с переходом от незащищённого read/write к защищённым Interlocked-функциям.
Nokta_strigo
23.01.2017 23:37+2Ну каждое ветвление может снизить скорость до 2х раз. Максимально возможная потеря скорости (если весь код покрыть кучей вложенных ветвлений) — 32 раза (для NVIDIA). Не сказать что мало. Но это худший случай.
Для CUDA (про AMD не знаю): потерь на ветвление не будет, если для всех нитей в warp предикат, по которому выполняется ветвление, принимает одно и то же значение (т.е. все нити в warp переходят по одной и той же ветке). Если в warp есть и нити для которых условие перехода true, и есть нити для которых false, то будет замедление в ~2 раза (реально для всех нитей будет обсчитан и один и другой переход, просто сохранён только нужный результат)
Т.е. условие «if (thread_num % 2 == 0)» даст сильное замедление, а условие «if (thread_num > N/2)» замедления почти не даст.
Arxitektor
23.01.2017 09:57+3А на самом деле желе это круто.
Только надо вписать в гемплей.
Война в мире желе )) Сделать какой желейный сеттинг.
Конфетная артиллерия и прочее )
marozz1k
23.01.2017 11:00-5Очень верное направление мыслей. Но на видеокарту я бы не стал загружать функции, которые должен выполнять процессор, она должна выводить поток уже обработанной и структурированной информации, ничего не вычисляя.
Верное направление мыслей в плане реалистичных физ. взаимодействий, не занимаясь при этом графодрочерством. Всё должно быть оптимизировано и с большой свободой действий для пользователя, а все зачем-то хотят из игр фильмы делать) в общем + вам.marsermd
23.01.2017 12:54+1Простите, а почему это вы бы не стали считать физику на видеокарте? О_О Физика частиц — отлично оптимизированная для видеокарты область вычислений.
Пруф.marozz1k
23.01.2017 13:03-1Я не утверждаю, а сказал «в целом» что переложить вычисления с процессора и оперативки на видеокарту — это не выход. Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено. В общем в аналогии с человеком — это перевести часть обязанностей участков мозга, ответственных за вычисление и дать дополнительную нагрузку на глаза
herr_kaizer
23.01.2017 13:12+2Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено
Как там в 90-ых, Doom уже вышел?
PsyHaSTe
23.01.2017 15:12Тут другой вопрос, в 2017 году видеокарта и так еле пережевывает графику, особенно если мы говорим о чем-то вроде 4к, загружать её сверх этого — ну не знаю… Сейчас наблюдается какой-то баланс между физикой и графикой, если его сместить, графика резко пострадает. А как мне кажется, сейчас это золотая жила для всяких EA, и вряд ли они решатся сильно от нее отказаться. Желейные войны — это забавно, но когда эффект новизны пройдет, люди все равно пойдут в игры с не такой уж чудесной физикой, но зато нормальным геймплеем — цива, стелларис и т.п. Просто потому, что у "желейных войн" сеттинг не предполагает серьезности и существенной реиграбельности. Единственное исключение — червячки (в плане реиграбельности, но серьезности там опять же нет), но за годы педалирования одного и того же даже они поднадоели. Сыграть разок с друзьями в армагеддон — пожалуйста, но на выходные лучше засесть в цивилизацию.
ThisIsZolden
23.01.2017 20:27На данный момент это верно. Хотя, качество геймплея не является следствием графики. Просто так вышло, что графика — высокое требование для всех игр, среди которых нашлись интересные. И вряд ли графика способна создать предпосылки для новых идей в гейм-дизайне.
А вот физика способна дать что-то новое. Но идеи невидимы, надо думать, изобретать, пробовать, общаться. Не исключено, что найдутся возможности сделать интересную игру, невозможную при классическом скриптовом подходе.
А графика не исключается физикой. Существует многообразие стилей и шейдерных трюков, которые дают визуальную конфетку без насилия над видеокартой. В моём случае визуализация слабенькая, но можно сделать гораздо лучше малыми средствами.
Так что, всеобъемлющая физика — это не исключительная альтернатива, а скорее дополнительная степень свободы именно для гейм-дизайна.Idot
23.01.2017 20:34+1Главное чтобы дизайнер был толковый умеющий этим пользоваться.
А то в DOOM III при наличии динамического освещения не нашлось дизайнеров умеющих им пользоваться так, чтобы это хоть как-то влияло на геймплей. Хотя старенький Aliens vs Predator 1999 года, имея лишь лайтмапы, использовал в геймплее динамическое освещение на полную катушку.
Другой пример Red Faction — с разрушаемым окружением, и дизайнерами не умеющими это использовать, более того топорно влепившими ничем неразрушаемые стены.
Хорошим примером можно назвать использование физики в геймплейе Half-Life 2. Тут дизайнеры дали возможность почувствовать её наличие вовлёкши её в геймплей.
marozz1k
23.01.2017 22:33-2не воспринимайте так близко к сердцу, я имел ввиду в целом, понятно что графический процессор создан в помощь основному, но только лишь в помощь, а не как полноценная альтернатива. Если вы думаете что выход из положения — проблемы реалистичности игрового физ. мира кроется в том что процессор не может справиться с этой задачей и надо её перекладывать на видеокарту — вот с этим я крайне не согласен. Помочь — да, полностью заменить — бред.
herr_kaizer
24.01.2017 00:09+3вот с этим я крайне не согласен
Из религиозных соображений? Вы не обижайтесь, но я искренне не понимаю, почему делать расчёты на ЦП — канонично, а на ГП — нет. Вам-то какое дело, как игроку, да и как разработчику тоже?marozz1k
24.01.2017 09:55-1Потому что каждый должен выполнять свою задачу) объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП? Ну хорошо, сделаете вы игру, где вам хватит мощности вашей крутой видеокарты для рассчёта 2000 частиц)) а дальше? А вы знаете что у большинства пользователей НЕ игровые видеокарты? Это перекос не туда, я уже говорил что автор словил верное направление, что надо не на графику ориентироваться, а на реалистичность физики и свободу действий, а не линейные фильмы из игр делать, но в остальном остаюсь при своём мнении — ресурсы видеокарте нужны для обработки и вывода на экран уже более-менее обработанной информации, насиловать её вычислениями не надо. Спасибо за обсуждение.
herr_kaizer
24.01.2017 10:20+2объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП?
Обработка игровой логики, ИИ, динамическая подгрузка ресурсов?
А вы знаете что у большинства пользователей НЕ игровые видеокарты?
У автора поста тоже, у него вообще ноутбучная из позапрошлого поколения.
насиловать её вычислениями не надо
3д-ускорители изначально изобретали для «насилования» их вычислениями. Если бы это было не так, мы бы до сих пор сидели в тех самых 90-х с тем самым Doom.
marsermd
23.01.2017 13:58+3Аналогия неуместна. Уже лет 8 функция видеокарты — выполнение параллельных алгоритмов, которые хорошо ложатся в идеологию SIMD.
Это началось с программируемых шейдеров, которые позволили выполнять не фиксированные функции на каждом этапе отображения, а самописные подпрограммы: шейдеры геометрии, вершинные, тесселяции, фрагментные.
А в наши дни эта концепция развилась до General Purpose программирования на видеокартах: нейронные сети, кодирование/декодирование видео, симуляция физики.
Если вы находите мои рассуждения обоснованными, можете просто согласиться, не обязательно продолжать спор)
AllexIn
23.01.2017 20:45+3А CPU предназначен, чтобы вояджеры в космос отправлять. Зачем вы на них предлагает игровую физику считать?
Вобщем и целом — переносить жирные вычисления на GPU — это норма в современном мире. И не просто норма, это правильно.
Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
Ну вот тако вот мир ПК развивается, никуда не деться.
Полагаю вы просто мало понимаете/знаете о внутренностях, поэтому и делаете столько абсурдные заявления.
ТС идёт на 100% верным путём.ThisIsZolden
24.01.2017 02:09+1Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
Действительно, у Nvidia сейчас огромные наработки в области многоядерного железа. А интел всю дорогу шёл по пути мощных одноядерных вычислителей, и упёрся в ограничения по частоте работы и размеру транзистора. А миру нужны вычислительные мощности. Акции Nvidia за полтора года выросли на 300%, и это говорит о том, что они вышли далеко за пределы рынка только графических карт.
Idot
23.01.2017 21:35+1Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено.
Вообще-то, на видеокартах Вертексные Шейдеры появились ещё ДО появления CUDA и OpenCL Более того они появились раньше, чем Ageia PhysX. И на них с самого появления можно было считать простейшую физику в духе «сложить два вектора».
Lerg
23.01.2017 13:56Проголосовал в гринлайте.
Можно ли объединять точки в твёрдые тела? У вас там есть танки, но они тоже желейные. Для вариативности не хватает некоторого количества твёрдых тел.ThisIsZolden
23.01.2017 20:20Я разовью физику, чтоб у некоторых объектов были свойства более твёрдого тела, у других — помягче. Будут камень, земля, дерево, желе.
denisromanenko
23.01.2017 14:55Эти желейные миры и танчики выглядят невероятно весело! Срочно на Greenlight!
ThisIsZolden
23.01.2017 20:19ага, уже:
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
General_Error
23.01.2017 14:55Отличная идея на мой взгляд. Со временем может получиться очень хорошая вещь! Если бы не недостаток знаний, тоже бы попробовал что-то такое написать или влиться в разработку.
Могу проверить и рассказать, как работает на Radeon 270X, если нужно.
reforms
23.01.2017 14:55Я прочитал статью и понял, как отстал. С игровой индустрией, как разработчик попрощался в далеком 2004г, завершив его единственной 2D игрой — логические шарики. Вся 'физика', да простят меня спецы, решалась анимацией (сжатие и расширение шаров) 8-10 кадрами в гифки.
Спасибо за статью.
Smorodov
23.01.2017 15:26Для 3D уже делают вполне реалистичные разрушения.
DAumkraft
23.01.2017 18:01+2Довольно реалистично, но уже долго оно выглядит до убогого одинаково. Постоянно одинаковые куски, которые просто сваливаются в кучу. Изначально более мелких и крупных частиц мы не получим, раздробить уже полученные — тоже. И вот так и выглядит это с 2008 года без существенных изменений.
Smorodov
23.01.2017 18:58Да, не хватает в этом ощущения «хряп!», которое как раз и достигается измельчением осколков, выглядит как-то малость «пенопластово». Но при помощи адаптивных разбиений в местах контакта и добавлением облаков пыли при падении на землю, а не только при попадании снаряда, можно и это допилить. Здесь видимо решили что для игрового процесса большего не нужно. Есть интерактивный ландшафт, и этого достаточно.
dshster
28.01.2017 12:22А этого в Red Faction в начале 2000-х не было случайно? Выглядит довольно примитивно для уровня современного GPU.
UPD: Видео 2012 года, это частично объясняет.
LogEdge
23.01.2017 16:12А что вы думаете о нейросетевых вычислениях?
https://www.youtube.com/watch?v=iOWamCtnwTcThisIsZolden
23.01.2017 20:18Когда гугл купил университетский стартап, занимавшийся дип лёрнингом, указывалось, что они делали вычисления то ли на видеокартах, то ли на игровых консолях. Нейросетевые вычисления хорошо параллелятс, и потому отлично подходят для вычисления на видюшках.
ivvi
23.01.2017 18:01> «Или те же гоночки: до чего приятней на полной скорости сшибать людей...»
Ох, зря вы слово «людей» вставили в эту фразу. Я бы убрал, оставив только неодушевленные предметы.ThisIsZolden
24.01.2017 02:03+1Ну, понятно, что речь идёт про нарисованных людей из компьютерной игры.
webhamster
23.01.2017 21:39Кроваво-красная земля при взрывах выглядит жутко. Надо бы что-то более нейтральное, ну хотя бы цвет грязи или вообще черное, типа обуглилось в этом месте.
Nokta_strigo
23.01.2017 23:46Очень согласен с утверждением, что современным играм не хватает физики! Графика на высоте, а физика — так себе. KSP и некоторые другие — исключение :-)
А под Linux (Mint) игра планируется?ThisIsZolden
24.01.2017 02:03Looks 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.
MaximSuvorov
24.01.2017 18:47Подобную задачу давным давно решили без велосипеда, новомодной вещей с расчётами на видеокарте и при этом работающей быстро:
http://www.gamedev.ru/code/articles/PositionBasedPhysics#v_chyom_je_profit_
С виду простой метод возволяет моделировать вполне внушительное количество взаимодействующих объектов:
На этом просчитывается взаимодействие 5000 шариков, расчёт всей физики занимает чуть больше 2мс на одном ядре процессора Core2Duo E6600 2.4GHz.
Smorodov
25.01.2017 13:20Есть хорошая статья о моделировании сеточной физики:
http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html
идеи там близкие к тому что вы описали в статье, только более формализовано.ThisIsZolden
25.01.2017 17:29Да, подход хороший. Я хотел сделать воздух по Навье-Стоксу, чтоб с тепловыми эффектами от взрывов и ударными волнами, но в итоге решил не перегружать видюшку.
Smorodov
25.01.2017 17:59Еще здорово смотрится физическое моделирование в дополненной реальности.
ThisIsZolden
25.01.2017 18:22Как раз эта технология мне доставляла наибольшие страдания, связанные с величиной диссонанса между идеалом и нынешним положением.
Представь то же самое, но нарисованная вода действительно размывает песок. То есть, программа не ограничивается накладыванием текстуры, а способна двигать материю. Чтоб за несколько секунд можно было построить город, заложенный в виде 3д-модели в программе. Или чтобы происходили реалистичные взрывы. И прочее в этом духе.
И если сравнивать виртуальную модель песочницы, в которой песок подвластен контролю со стороны программы, и реальную, в которой песок недвижим, я предпочёл бы пока первую, ибо совсем другой объём возможностей открывается. Но было бы здорово, если б сделали живой песок в реальности.
Теоретически это было бы возможно с помощью конфигурируемого магнитного поля высокого разрешения и управляемо ионизируемыми частицами. Но практической реализации этой идеи пока не существует.
Так что приходится довольствоваться вирутеальным песочком, что тоже, в общем, довольно занятно.
Jarro
27.01.2017 00:06Приветствую,
я правильно понял, что вместо формулы потенциала 6-12 вы на деле использовали упрощенную для вычислений 4-8?ThisIsZolden
27.01.2017 00:10Было 4-8, сейчас 6-12. Хотя, разницы особой нет, я всё равно коэффициентом добивался максимально возможной крутизны графика в точке нулевоко коэффициента.
Jarro
27.01.2017 01:06Кстати, а насколько реально совмещать частицы с разными свойствами, чтобы действительно сделать что-то наподобие OE-Cake GPU Version?)
ThisIsZolden
27.01.2017 01:37Реально, вот сейчас как раз доделал, теперь есть несколько материалов с разными свойствами — камень, песок, снег, грязь, металл, и т.д. Но взаимодействие между ними я не слишком прорабатывал. Масса и теплоёмкость у всего одинаковая, динамика жидкости — так себе. Я бы не против поглубже в эту сторону покопать, но сейчас хочется закончить с физикой и аняться геймплеем.
Jarro
27.01.2017 01:22Допустим, Rigid-axis body (твердое тело с осью вращения) или даже сложные механизмы, которые успешно создавались в том же OE-Cake
ThisIsZolden
27.01.2017 01:42Тела сами слипаются из частиц, мне этого пока достаточно, изначально цель была в том, чтобы получитьреалистично разрушаемый мир из частиц.
А механизмы будут простенькие. Я ввёл сущность, вроде кости, которая упруго задаёт расстояние между частицами. Такими костями можно усилить строения и заскриптовать анимацию уровней, вроде катающихся туда-сюда мостиков. А сам танк в демке — тоже механизм, сделанный из частиц, и работающий как молекулярная машина.
В качестве врагов для синглплеерного аркадного режима я создам ещё несколько разных механизмов с локомоцией, реализуемой через физические свойства мира.
Drunya_tek
27.01.2017 01:32а можно где то скачать эту вашу игру?)
ThisIsZolden
27.01.2017 01:33Через пару месяцев можно будет, она получила зелёный свет на стиме, доделать надо.
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
andybelo
27.01.2017 11:49-1У человеческого мозга есть несколько интересных особенностей при работе с изображениями. Во-первых, он страшно медленный по сравнению с электронными Гигагерцами, во-вторых — синтез изображения развит плохо у мозга, зато очень быстрое распознавание. И ещё, у мозга отсутствует общая шина. Скорость мозга обусловлена его Гигапараллельностью.
malbaron
30.01.2017 23:54У человеческого мозга есть несколько интересных особенностей при работе с изображениями. Во-первых, он страшно медленный по сравнению с электронными Гигагерцами, во-вторых — синтез изображения развит плохо у мозга, зато очень быстрое распознавание. И ещё, у мозга отсутствует общая шина. Скорость мозга обусловлена его Гигапараллельностью.
Бредятину пишите.
Не ставьте человеческому мозгу задач, которые хорошо щелкают компьютеры.
Пусть человек решает то, что компьютеры делают хуже.
Smorodov
27.01.2017 23:59Кстати, подкину идею. Если вместо земли использовать воду, а вместо танков кораблики, то волны от взрывов могут сильно разнообразить игру.
Jarro
29.01.2017 06:29А вы случаем не знакомы с очень похожей демкой от майкрософта?:)
https://code.msdn.microsoft.com/windowsdesktop/DirectCompute-Graphics-425de5a8ThisIsZolden
30.01.2017 17:03Моделей материи на основе взаимодействующих частиц, конечно, существет много. Но геймплей в таких симуляциях вроде пока не делали, если не считать песочниц, вроде OE Cake.
С этой конкретной моделью я бы поиграл, но там только код, а мне лень возиться с visual studio.
ceperaang
29.01.2017 07:21+3Странно, что автор пишет об как о каком-то неожиданном открытии, как будто и правда сейчас 2007 год. Но вообще, эта тема очень горячая и активно исследуемая: тут и клёвые трюки с изменяемым размером сетки/плотностью частиц в ключевых/маловажных областях (например, больше внимания к поверхности, меньше к толще материала), аппроксимация точных уравнений нейронными сетями (т.е. сеть учится делать симуляцию, чтобы это выглядело для члеовека достаточно хорошо, выше уже дали ссылку на подобную работу), ну и вообще всякое подобное.
Я бы порекомендовал полистать последние работы со всяких SIGGRAPH'ов — можно много интересного найти и не нужно будет набивать шишки на собственном лбу.andybelo
29.01.2017 10:41-4А, вот кто мне сейчас ответитправду. Вот скажи, студент Маши Лёрнинко, где нейросети, имитирующие ловлю мухи лягушкой? Или вас только учат, как карму минусовать, несчастные? Я лично уверен, что ничего кроме % сверки изображений с образцом в вашей «науке» нету.
marsermd
29.01.2017 15:21+1За такие комментарии стоит минусовать)
- Придрались к незначительной части комментария
- Обвинили автора комментария в том, что он минусует карму ТС
- Упомянули никому неизвестного человека(гугл не находит буквально ничего по запросу "Маша Лёрнинко")
- Высказали поверхностное суждение, не нагуглив, что действительно есть работа, которая с помощью нейронных сетей улучшает результат физических солверов.
WTF?
Большая часть ваших комментариев о том, что все такие плохие-нехорошие и минусуют, а большая часть оставшихся комментариев — не аргументированная критика.
Статей нет.
Как следствие, и карма у вас в минусах.chersanya
29.01.2017 16:01+1Видимо, Маша Лёрнинко — это Машин Лёрнинг :)
marsermd
29.01.2017 17:10+1А, блин, нормальная анаграмма.
Этот пункт беру обратно) Остальные остаются)andybelo
29.01.2017 22:18http://choose-life.ru/themes/lyuboj-superkompyuter-ne-sravnim-s-chelovecheskim-mozgom
marsermd
30.01.2017 03:18И?)
andybelo
30.01.2017 09:26А вы нагуглите, про лягушку. Вот когда нейронные сети сделают лягушку, которая ловит мух, тогда учите других, про «достижения» нейронных сетей.
ThisIsZolden
30.01.2017 17:14-1Нейросети медленно развиваются, и пока умеют только довольно специфические вещи. Но в принципе сетевая топология вычислителей на нечёткой логике — это то, что рано или поздно сможет делать всё, что умеет мозг. Нейросети сейчас на той же стадии технологического взросления, как первые самолёты братьев райт. До мёртвых петлей и сверхзвука далеко, но понятно, что всё будет.
ThisIsZolden
30.01.2017 17:06-1У меня индуктивный метод обучения: сделать самому, обобщить проблематику, ознакомиться с литературой. Так что это вопрос не шишек, а оптимального способа приобретения знаний и навыков.
deep_orange
А почему не Bullet?
ThisIsZolden
Потому что вычисления для твёрдого тела не требуются, здесь всё построено на вычислениях для материальной точки. Кроме того, игры в жанре 2d-sandbox, вроде Powder Toy или OE Cake, не использовали gpu-вычисления, так что я сразу решил сделать своё, полагая, что такие движки пока просто не появились.
deep_orange
На самом деле новый Bullet не пригоден для OpenGL 2.1 / OpenGL ES 2.0 видеокарт. Да и с C API проблемы. Не такой уж радужный инструмент. Он вообще рассчитан на отдельную видеокарту под физику, дескать одна для физики — одна для графики.
BratSinot
Про Ageia все забыли уже? :( А ведь их демка первая и последняя с таким количеством объектов на экране…
AllexIn
Никто про них не забыл. Их решения активно используются во многих играх. Вот только называется это все сейчас иначе.
BratSinot
Да вот не совсем. Если раньше PhysX это было про много объектов на экране (демонстрации Cellfactor даже сейчас впечатляют), то сейчас это обычный конкурент Havok.
Да, Nvidia сделала возможность просчета на GPU через CUDA, только вот AGEIA специализировалась на физическом движке и продвигала бы его возможности, что возможно привело бы к крутой физике в играх (да банально кучу объектов на экране никто не делает!).