Comments 217
А почему не Bullet?
Потому что вычисления для твёрдого тела не требуются, здесь всё построено на вычислениях для материальной точки. Кроме того, игры в жанре 2d-sandbox, вроде Powder Toy или OE Cake, не использовали gpu-вычисления, так что я сразу решил сделать своё, полагая, что такие движки пока просто не появились.
На самом деле новый Bullet не пригоден для OpenGL 2.1 / OpenGL ES 2.0 видеокарт. Да и с C API проблемы. Не такой уж радужный инструмент. Он вообще рассчитан на отдельную видеокарту под физику, дескать одна для физики — одна для графики.
Про Ageia все забыли уже? :( А ведь их демка первая и последняя с таким количеством объектов на экране…
Никто про них не забыл. Их решения активно используются во многих играх. Вот только называется это все сейчас иначе.
Да вот не совсем. Если раньше PhysX это было про много объектов на экране (демонстрации Cellfactor даже сейчас впечатляют), то сейчас это обычный конкурент Havok.
Да, Nvidia сделала возможность просчета на GPU через CUDA, только вот AGEIA специализировалась на физическом движке и продвигала бы его возможности, что возможно привело бы к крутой физике в играх (да банально кучу объектов на экране никто не делает!).
Да, Nvidia сделала возможность просчета на GPU через CUDA, только вот AGEIA специализировалась на физическом движке и продвигала бы его возможности, что возможно привело бы к крутой физике в играх (да банально кучу объектов на экране никто не делает!).
Хмм, очень странная статья. CUDA появилась в 2007, OpenCL в 2008, все даавно используют видеокарты для самых разных вычислений.
По-моему, это решение было тихой революцией.
Да, но это случилось 10 лет назад :)
Согласен, это всё появилось давно. Я хотел сосредоточить внимание не на самой технической возможности считать на видеокарточке, а на альтернативе обычному подходу к геймплею, когда физику используют как вспомогательную и незначительную составляющую. Статья посвящена возможности построить геймплей на физике полностью.
Очень странно «открывать» на это глаза в мире победивших Angry Birds.
Angry Birds — тоже хороший пример физики, создающей геймплей. Хотя, у них геймплей слишком простой, нет передвигающихся персонажей. И физика тоже проста — несколько спрайтов с коллайдерами на уровень. Но это уже кое-что. С момента выпуска прошло несколько лет. Появилось много клонов, но все они не пытаются выйти из ограниченной физики оригинала. Я просто попытался пойти дальше, как на уровне геймплея, так и на уровне физики, чтоб посмотреть, насколько интересно довести процент физики до предела.
Это что-то из разряда «да, там красные пиксели есть, но не много. Но хочется довести их количества до предела.»
Физика — сама по себе геймплей не создает. Это один из инструментов геймдизайнера, но не единственный. Если использовать только его получится либо песочница, либо симулятор козла-хирурга(впрочем тоже песочница). Игры не получится.
Физика — сама по себе геймплей не создает. Это один из инструментов геймдизайнера, но не единственный. Если использовать только его получится либо песочница, либо симулятор козла-хирурга(впрочем тоже песочница). Игры не получится.
2D-артилерия состоит на 100% из физики. Причём примитивной. А геймплей создаёт чувак, которого надо загасить или он загасит тебя.
Как раз сейчас я взялся за геймплей. Демка из видоса — первая экспериментальная версия игры на этой физической земле, простое переложение механики Scorched Earth на физическую землю. Достоинства тут пока визуальные, взрывы незаскриптованы, и потому разнообразные.
Кроме, того, в актуальной версии есть особенность, которая уже граничит с уровнем фищек геймплея: танки тоже сотоят из частиц, и урон визуализируется в виде повреждений. Может отвалиться кусок корпуса, могут порваться и слететь гусеницы, может взорваться колесо или сломаться пушка. Всё это влияет на управление танком.
А идей для проверки много, внедряю помаленьку, экспериментирую. Удастся найти чего-то оригинальное и интересное — добавлю, а не удастся — буду другим заниматься.
Кроме, того, в актуальной версии есть особенность, которая уже граничит с уровнем фищек геймплея: танки тоже сотоят из частиц, и урон визуализируется в виде повреждений. Может отвалиться кусок корпуса, могут порваться и слететь гусеницы, может взорваться колесо или сломаться пушка. Всё это влияет на управление танком.
А идей для проверки много, внедряю помаленьку, экспериментирую. Удастся найти чего-то оригинальное и интересное — добавлю, а не удастся — буду другим заниматься.
Конечно, сегодняшнее применение физики — сплошной компромисс и оптимизация. Вы сами показали, что мощностей даже GPU пока хватает впритык на желеобразные двумерные абстракции. А если мы хотим симулировать трёхмерные объекты реального мира, то выгоднее всего исключить из расчетов физику твёрдых материалов, ограничившись взаимодействием физических тел. Но будущее за полной симуляцией, безусловно.
Интересно было бы поэкспериментировать с GTX 1080, чтоб понять сегодняшний предел, думаю эта карточка потянет 2-5 сотен тысяч частиц, этого и для 3д может хватить.
Но что верно, то верно, даже с крутой карточкой ограничения довольно близки. Я подумываю попробовать однажды другой подход, когда всё состоит из динамически разрушаемых при столкновениях мешей. Там физики — по числу осколков. Можно гораздо более сложный разрушаемый мир смоделировать, без особых вычислительных затрат.
Но что верно, то верно, даже с крутой карточкой ограничения довольно близки. Я подумываю попробовать однажды другой подход, когда всё состоит из динамически разрушаемых при столкновениях мешей. Там физики — по числу осколков. Можно гораздо более сложный разрушаемый мир смоделировать, без особых вычислительных затрат.
как-то писал демку астероидов с voronoi transform в качестве тестового задания в одну веселую компанию :) сделать технично вышло, красиво — нет. Стоит попробовать найти дизайнера в пару )
Ага, разбиение вороного — хороший инструмент для получения осколков.
А «технично, но не очень красиво» — наверное, самая распространённая ситуация в инди-геймдеве, когда программист делает клёвые штуки, которые не впечатляют на вид. На форуме unity3d.com сейчас можно довольно легко привлечь энтузиастов-дизайнеров, если показать что-то техничное.
А «технично, но не очень красиво» — наверное, самая распространённая ситуация в инди-геймдеве, когда программист делает клёвые штуки, которые не впечатляют на вид. На форуме unity3d.com сейчас можно довольно легко привлечь энтузиастов-дизайнеров, если показать что-то техничное.
если говорить чисто об 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
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
Спасибо, прочитаю статью. Возможно, смогу что-то ускорить в своей программе, было бы кстати.
А моя оценка количествf частиц на GTX 1080 касалась не общего случая, а моей реализации. Специфика такова: чтобы кристалл удерживал форму, нужно повысить (в сравнении с моделированием жидкости) силы взаимодействия частиц, но встаёт проблема: погрешность дискретизации умножается на величину сил Поэтому, я сильно уменьшил шаг дискретизации. И за один Update() прогоняю 10 циклов симуляции с довольно маленьким шагом, чтоб сохранить быструю работу в реальном времени.
Не исключаю, что где-то я не дотянул с оптимизацией, но при прочих равных создаётся впечатление, что для моделирования жидких сред нужно в 5-10 раз меньше производительности на частицу, чем для твёрдых.
А моя оценка количествf частиц на GTX 1080 касалась не общего случая, а моей реализации. Специфика такова: чтобы кристалл удерживал форму, нужно повысить (в сравнении с моделированием жидкости) силы взаимодействия частиц, но встаёт проблема: погрешность дискретизации умножается на величину сил Поэтому, я сильно уменьшил шаг дискретизации. И за один Update() прогоняю 10 циклов симуляции с довольно маленьким шагом, чтоб сохранить быструю работу в реальном времени.
Не исключаю, что где-то я не дотянул с оптимизацией, но при прочих равных создаётся впечатление, что для моделирования жидких сред нужно в 5-10 раз меньше производительности на частицу, чем для твёрдых.
да, так и есть.
у меня тройная вложенность
за один кадр визуализации происходит 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
у меня тройная вложенность
за один кадр визуализации происходит 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
раньше ещё использовал один раз посчитанную сетку на несколько кадров взаимодействия частиц, но это даёт артефакты на быстром движении объектов, а fluidsv3 сделал расчёт сетки очень дешёвым, поэтому отказался от этого читерства и теперь объекты могут очень быстро двигаться относительно пространства и корректно при этом «столкновения на относительных скоростях» обрабатывать
p.s. я во многих случаях вообще убираю трение и гравитацию и живу в «бесконечном космосе без трения».
кстати, конечная по размеру SPH сетка отлично обрабатывает бесконечный космос, это поначалу сбивает с толку, но всё просто — частицы проецируются в сетку как остаток от деления на размер сетки, в результате чего сетка начинает быть периодической структурой. в этом случае, «на соседей» приходится проверять физически не близкие друг к другу объекты, но это никак не влияет на производительность, потому что как бы частицы не разлетелись по бесконечному космосу, количественно их всегда останется столько же, и пар проверок будет всегда «стабильное количество», просто чаще будет даваться ответ «нет, несмотря на то, что клетки в „индексной“ сетке — соседние, частицы друг от друга очень далеко»
p.s. я во многих случаях вообще убираю трение и гравитацию и живу в «бесконечном космосе без трения».
кстати, конечная по размеру SPH сетка отлично обрабатывает бесконечный космос, это поначалу сбивает с толку, но всё просто — частицы проецируются в сетку как остаток от деления на размер сетки, в результате чего сетка начинает быть периодической структурой. в этом случае, «на соседей» приходится проверять физически не близкие друг к другу объекты, но это никак не влияет на производительность, потому что как бы частицы не разлетелись по бесконечному космосу, количественно их всегда останется столько же, и пар проверок будет всегда «стабильное количество», просто чаще будет даваться ответ «нет, несмотря на то, что клетки в „индексной“ сетке — соседние, частицы друг от друга очень далеко»
вау, роскошный «чит» с бесконечной сеткой!
только, если будешь пробовать, не забудь обработать это не только для проецирования частицы в сетку, но и для ситуации обхода соседних клеток, чтобы крайняя справа соседом справа считала крайнюю слева и наоборот.
CUDA Samples / Particles это делает так:
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;
};
Насчёт идей, возможно ли соединить, скрепить частицы, и сделать из них группу, которая обладает некоторыми едиными изменчивыми характеристиками? Например, броня танка, представляет собой единый материал, который можно деформировать, применив лишь достаточно твёрдый и крепкий материал, а также большой импульс.
Да, так можно было бы, но это бы подразумевало кроме вычислений типа частица-частица, проводить вычисления типа двумерное тело-частица. А это уже более сложная математика. Совмещать подходы счастицами и с телами — не слишком правильно, потому что лучше всего параллельный обсчёт работает, когда все потоки выполняются за примерно равное время. А расчёт тел сложней, и его все будут ждать, Общая производительность упадёт.
не совсем так. если составить тело из таких же частиц, то частицы будут естественным образом обрабатываться за один проход как частица-частица взаимодействия, останется только собрать физику мягкого тела на spring-mass-damper связях между частицами, и, чтобы достичь более менее интересных характеристик упругости, обязательно не забыть именно про damper составляющую (иначе будет кипеть при попытке перехода от мягкого к упругому), плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям
я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»
в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:
Nvidia FLEX
демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц
плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)
я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»
в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:
Nvidia FLEX
демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц
плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)
У меня это примерно так сейчас и сделано. Я использую силу леннарда-джонса, которая комбинирует притяжение и отталкивание. Так что частицы слипаются в тела, если сталкиваются, и ведут себя как тело, потому что связи между ними работают как пружины. При этом, тела разрушаемы, потому что составляющая притяжения не велика по силе.
В ближайшее время я сделаю разные материалы, и одновременно будут существовать и более твёрдые, и более текучие среды. Сейчас это частично реализовано: температура влияет на склонность к образованию и разрыву связей, так что системы горячих частиц напоминают жидкость.
Вот сразу видно, что вы практикуете в этом направлении. Это решение у меня, действительно, реализовано. Хотя, я всё же уменьшил эту составляющую, потому что из-за неё энергия взрыва вместо того, чтоб разрушать землю, распространяется волной вглубь, а это не так зрелищно.
В ближайшее время я сделаю разные материалы, и одновременно будут существовать и более твёрдые, и более текучие среды. Сейчас это частично реализовано: температура влияет на склонность к образованию и разрыву связей, так что системы горячих частиц напоминают жидкость.
плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям
Вот сразу видно, что вы практикуете в этом направлении. Это решение у меня, действительно, реализовано. Хотя, я всё же уменьшил эту составляющую, потому что из-за неё энергия взрыва вместо того, чтоб разрушать землю, распространяется волной вглубь, а это не так зрелищно.
Будет ли где-нибудь выкладываться код или хотя бы бинарник, чтобы можно было просто погонять?
Да, я загрузил основной код для частиц в ассет стор юнити:
https://www.assetstore.unity3d.com/en/#!/content/76233
Он пока платный, но после выхода игры сделаю беспланым.
А игра, скорее всего, будет включать не только геймплейную составляющую, но и редактор мира, чтоб рисовать домики и взрывать их — как раз для тех, кто хочет «погонять».
https://www.assetstore.unity3d.com/en/#!/content/76233
Он пока платный, но после выхода игры сделаю беспланым.
А игра, скорее всего, будет включать не только геймплейную составляющую, но и редактор мира, чтоб рисовать домики и взрывать их — как раз для тех, кто хочет «погонять».
Физика очень хороша, я бы сам с удовольствием играл в эту игру, даже демку
Какая-то укуренная физика в этой игре про козла. Когда смотрел обзоры игры на ютубе, она мне нравилась, и, дождавшись распродаж, я её купил. Разочаровался.
Чем-то напомнила нереалистичные китайские боевики в средневеком сеттинге, где все герои прыгают половину фильма на растяжках.
Чем-то напомнила нереалистичные китайские боевики в средневеком сеттинге, где все герои прыгают половину фильма на растяжках.
Кстати, ещё Cut The Rope — в каком-то смысле про физику.
Сходу больше не могу вспомнить, но мне кажется, что я видел больше одной подобной "головоломки с физикой".
Да тыщи игр с физикой в основе геймплея.
Неиссякаемые Incredible Machines, вообще под досом начались.
Неиссякаемые Incredible Machines, вообще под досом начались.
На смартфонах есть популярный Where is my water? про кродильчика Свомпи. Очень достойно сделан.
«Прыгательные» уровни Quake3. q3dm17 и прочие карты с джамперами. Гравитация и прыгалки, больше ничего не надо :)
OpenCL, CUDA. Может вам эти технологии жизнь облегчат.
CUDA — Nvidia specific. А компьют шейдер в юнити компилится в opnegl или directx.
На сколько я знаю историю GPGPU, расчёты не графики с использованием шейдеров использовались как костыль когда не было CUDA и прочих (правда я сам с помощью шейдеров никогда ничего не считал, сравнивать не могу), сейчас вроде уместней использовать вышеупомянутый OpenCL, он умеет с разным железом работать.
C++ AMP. Не стал популярным, но для ваших задач должен быть хорош. Высокоуровневый ООП язык, работает на всех видеокартах с поддержкой Direct X11 и новее (или Direct X10 — не помню уже).
Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.
Всё упирается в вашу неспособность сделать это.
В 2007 году вышла игра Maelstrom.
С терраформингом и растекающимися жидкостями.
А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.
Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.
Терраформинг — это изменение координат вершин меша, это не требует больших вычислительных ресурсов.
А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?
Терраформинг — это изменение координат вершин меша, это не требует больших вычислительных ресурсов.
А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?
Да, возможно я что-то не так делал. Хотя, уделал оптимизации большое внимание.
ДА полюбому. Как минимум куча физически сложных игр, существующих задолго до CUDA тому показатель.
Терраформинг — это изменение координат вершин меша, это не требует больших вычислительных ресурсов.
Терраформинг — это немного больше, чем перемещение вершин. :)
ТАк можно сказать, что и у вас просто вершины двигать надо.
А как вы делали воду, частицами? Сколько удавалось в рилтайме моделировать?
Простите, нет желания раскапывать архивы. А навскидку вспомнить не получится, это было очень давно.
Вы можете глянуть Maelstrom в режиме сетки. Там вполне можно оценить сложность расчетов.
Тем более что там еще и влиения ветра уникальное в каждой точке.
Всё упирается в вашу неспособность сделать это.
В 2007 году вышла игра Maelstrom.
С терраформингом и растекающимися жидкостями.
А до этого был Периметр. Что уж греха таить, я и сам в 2005 году делал демки с растекающейся водой.
2000 частиц — это даже близко не предел CPU начала 2000х. Не говоря уж о современных системах.
В году 1994-1998 видел терраморфинг (на ассемблере) на i386/i486
Все летало.
Количество частиц не единственный параметр, важна частота итераций. Чем больше интервал интегрирования тем менее твердые и более желеобразные тела у вас получатся.
На современном i5 (CPU), в реалтайме (2D) мне удалось максимум выжать 20 000 частиц на 2 000 итераций интегрирования в секунду в один поток (это был эксперимен из любопытства, распараллелить не дошли руки).
Это тела с жесткостью визуально как у ластика.
Не думаю что возможно сильно больше, это примерно 7 связей на частицу, того около 300 000 000 связей в секунду.
На современном i5 (CPU), в реалтайме (2D) мне удалось максимум выжать 20 000 частиц на 2 000 итераций интегрирования в секунду в один поток (это был эксперимен из любопытства, распараллелить не дошли руки).
Это тела с жесткостью визуально как у ластика.
Не думаю что возможно сильно больше, это примерно 7 связей на частицу, того около 300 000 000 связей в секунду.
UFO just landed and posted this here
http://www.nvidia.ru/object/nvidia-physx-ru.html
PhysX — универсальный движок, но он не слишком хорошо годится для этой специфической задачи. У меня взаимодействуют не твёрдые тела, а материальные точки.
не только твердые тела.
В юнити в 2д бывший Box2D. Физикс только в 3д.
А так можно много узких мест найти, если постараться, хоть в том же List, где при получении значения по индексу, индекс переводится из int в uint и потом сравнивается с int'овым пределом листа...
И в юнити насколько помню не поддерживается аппаратное ускорение у Physx.
https://ru.wikipedia.org/wiki/PhysX Игровые движки, использующие в качестве физической подсистемы компоненты PhysX SDK: (там список игровых движков) и Unity…
Речь о том что Юнити использует PhysX порезанный, без аппаратного ускорения.
https://forum.unity3d.com/threads/could-unity-physx-be-accelerate-on-gpus.402848/
https://www.youtube.com/watch?v=P3CnprXSXJU
Они даже для ткани не спешат/или реализовывать.
https://forum.unity3d.com/threads/could-unity-physx-be-accelerate-on-gpus.402848/
https://www.youtube.com/watch?v=P3CnprXSXJU
Они даже для ткани не спешат/или реализовывать.
По-моему, это решение было тихой революцией. Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени.Она не мощнее, она просто другая. Ageia для обработки физики вон вообще одно время отдельные железки выпускали, которые еще круче (того, что было тогда, конечно) считать ее умели
Можно, конечно, выпустить отдельную карту для физики, полностью лишённую чисто графической функциональности. Только у такой карточки всё равно цена за единицу производительности будет выше, потому что в производстве железа главный ценообразующий фактор — массовость. Видеокарты — массовый продукт, поэтому доля стоимости разработки и постройки производственных мощностей в цене каждой железки — ничтожна.
По этой причине физические карточки в своё время не прижились, а видеокарты сегодня заточены для физики.
По этой причине физические карточки в своё время не прижились, а видеокарты сегодня заточены для физики.
Здравствуйте
Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.
Хотел бы заметить, что Вы только частично правы относительно того, что «физические карточки» не прижились. У Nvidia есть Tesla (http://www.nvidia.ru/object/why-choose-tesla-ru.html), которая, хотя и является формально графическим ускорителем, лишена (насколько мне известно) возможности вывода графики и предназначена только для ведения рассчётов. Не только физических, конечно же.
nVidia купила Ageia
Они именно мощнее по вычислительным возможностям, как минимум на порядок для слабеньких карт, и на 2 порядка для топовых. Свои особенности конечно есть, но сейчас это практически такие же универсальные вычислительные устройства как центральные процессоры, позволяющие практически любые алгоритмы реализовать и задачи решать. Только в десятки раз быстрее CPU. Точнее реализовать мощно вообще любые, но не на любых будет такое огромное преимущество в скорости.
Я бы не был настолько категоричным, архитектура GPU подразумевает RISC, правда не который у каждого в кармане, а настоящий, лишённый всех утех, вроде настоящего бранчинга http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html
В каких-то смыслах GPU и правда быстрее. На самом деле, даже в очень многих, но работа с памятью очень… Специфичная, любой тяжёлый поток может практически убить производительность, сведя её до нуля. Тогда как Skylake сожрёт его и не нагреется.
Что действительно будет быстрее, так это некий NoC из FGPA, но он пока так и остался в концептах. Вроде что-то говорили про NoC, что-то про FGPA в Core iX, но ничего не видно. Но эти вещи вместе могут избавить нас от такого рудимента как GPU за раз.
В каких-то смыслах GPU и правда быстрее. На самом деле, даже в очень многих, но работа с памятью очень… Специфичная, любой тяжёлый поток может практически убить производительность, сведя её до нуля. Тогда как Skylake сожрёт его и не нагреется.
Что действительно будет быстрее, так это некий NoC из FGPA, но он пока так и остался в концептах. Вроде что-то говорили про NoC, что-то про FGPA в Core iX, но ничего не видно. Но эти вещи вместе могут избавить нас от такого рудимента как GPU за раз.
Ну задержки при работе с памятью там разве большие очень. Зато ПСП на порядок выше чем у CPU.
Один поток ничего не убъет, если конечно программа не из разряда когда все остальные потоки ждут в простое результатов от этого одного ведущего потока (т.е. по факту софт однопоточный и не распараллелен), т.к. в современных GPU помимо кучи исполнительных устройств и довольно много полностью независимых самостоятельных ядер(каждое с собственными декодарами и диспетчерами инструкций, блоками загрузки/выгрузки и т.д.) и Х независимых контроллеров(каналов) памяти с собственными кэшами на каждом.
А по ссылке книжка конечно хорошая, но очень уж старая — писалась в 2004м году, 13 лет назад описывая архитектуры GPU выходившие в 2002-2004 годах, 1-2 поколение программируемых, когда микропрограммы для GPU еще только начинали внедрять. Те GPU что были тогда и те что имеются сейчас довольно мало общего имеют. В т.ч. и бранчиг вполне полноценный появился, по крайней мере все имевшиеся в первых поколениях ограничения на условия, переходы и циклы давно сняты.
Один поток ничего не убъет, если конечно программа не из разряда когда все остальные потоки ждут в простое результатов от этого одного ведущего потока (т.е. по факту софт однопоточный и не распараллелен), т.к. в современных GPU помимо кучи исполнительных устройств и довольно много полностью независимых самостоятельных ядер(каждое с собственными декодарами и диспетчерами инструкций, блоками загрузки/выгрузки и т.д.) и Х независимых контроллеров(каналов) памяти с собственными кэшами на каждом.
А по ссылке книжка конечно хорошая, но очень уж старая — писалась в 2004м году, 13 лет назад описывая архитектуры GPU выходившие в 2002-2004 годах, 1-2 поколение программируемых, когда микропрограммы для GPU еще только начинали внедрять. Те GPU что были тогда и те что имеются сейчас довольно мало общего имеют. В т.ч. и бранчиг вполне полноценный появился, по крайней мере все имевшиеся в первых поколениях ограничения на условия, переходы и циклы давно сняты.
Я не говорю, что задержки большие, даже наборот, доступ ядра к «своей» 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 с Марса можно было хоть чайник кипятить. Вполне успешно.
За 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 с Марса можно было хоть чайник кипятить. Вполне успешно.
Физику уже давно все крутят на GPU при помощи https://ru.wikipedia.org/wiki/PhysX
Где на бетатест вашей игрушки записаться? :-)
Да, официальная физика от нвидиа — на gpu, но мне нужен был больший контроль, чем даёт их апи.
Для бетатеста пока рановато, ещё месяц надо над геймплеем поработать. Но можно на стиме проголосовать: http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Если её одобрят, весь бета-тестинг будет там происходить.
Для бетатеста пока рановато, ещё месяц надо над геймплеем поработать. Но можно на стиме проголосовать: http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Если её одобрят, весь бета-тестинг будет там происходить.
Тогда где на альфа-тест записаться? :-)
Касательно графики: не можешь победить — возглавь. Думаю тут бы лучше смотрелась не натуралистичная графика, а что-нибудь по проще. Раз уж разрешение невысокое и физика гутаперчивая, то имеет смысл и сеттинг выбирать соответствующий. Какие-нибудь "желейные войны" или "нано-конфликт".
Ещё было бы круто собирать свой танк, как в robocraft.
А какая у вас видеокарта? Мне как раз может понадобиться несколько человек с разными видюшками, чтоб отправить им сырую версию и посмотреть, какой fps у них покажет.
А что до желейных войн, то я игру пока так и назвал, «Jelly in the sky». Но сегодня я чуть физику исправил, и теперь твёрдое выглядит чуть более твёрдым. Вот, можно посмотреть:
http://i.imgur.com/qcGOQgW.gif
А что до желейных войн, то я игру пока так и назвал, «Jelly in the sky». Но сегодня я чуть физику исправил, и теперь твёрдое выглядит чуть более твёрдым. Вот, можно посмотреть:
http://i.imgur.com/qcGOQgW.gif
Могу на карточках AMD среднего уровня (7850/7870 — 1024/1280 выч. блоков) под windows 7 прогнать. И на старой 5750(720 выч. блоков) под XP если оно конечно под XP с DX9 вообще в принципе работать может.
GeForce 840M
Всё-равно как пудинг :-) Если хочется твёрдых тел, то можно попробовать добавить давление. Приложение силы к твёрдой субстанции на входе при этом должно вызывать минимальное смещение, но передавать дальше большое давление. А на выходе падение давления должно вызывать большое смещение. При этом, если мы попали в землю, то волна давления должна отразиться от низа экрана и жахнуть по поверхности земли.
R7 в APU A10-7850K и GTX 460, могу поспособствовать в тестировании на Win10.
протестировал бы на gtx 1060.
протестировал бы и более тяжеловесные эксперименты.
протестировал бы и более тяжеловесные эксперименты.
Есть возможность протестировать на GTX 1060
2 x gtx660, как дела со sli/crossfire?
У меня Quadro мобильная, кстати говоря. Слабая, но что-то. Может у неё какие-то преимущества в GPGPU, не? Попробовать можно. Могу ещё на 1060 запустить, но это не так интересно.
AMD r7 360, win 10.
Тоже хотелось бы попробовать
Тоже хотелось бы попробовать
Спасибо всем в этой ветке, я с вами непременно свяжусь, когда возникнет надобность потестировать игру.
А под Линукс версия есть?
GTX 970
GTX 970
GTX 670
Крутят да только юнити вертит PhysX только на CPU.
Огромные массивы взаимодействующих частиц — тоже коварная штука.
Задача уже давно решена — http://algs4.cs.princeton.edu/61event/
а где можно поиграться в эти клевые танчики?
Все выглядит как желе, потому что ваша модель твердого тела является реологической. Это более или менее подходит для сыпучего грунта. Но для моделирования твердого кристаллического тела нужны более сложные законы (кристаллическая решетка, упругая деформация, пластическая деформация и т.д.)
Нет, по-моему, основная проблема в статье верно указана. Чем жёстче материал, тем выше его коэффициент упругости, тем выше скорость распространения взаимодействия в среде. Шаг времени должен быть таким, чтобы за одну итерацию это взаимодействие не прошло больше одной пространственной ячейки (частицы в данном случае). Иначе модель разойдётся и частицы просто разлетятся в стороны. По-этому, чтобы симулировать такое большое количество частиц в реальном времени приходится уменьшать коэффициент упругости и материал становится больше похожим на желе.
Именно.
Можно заметить, что земля и строения выглядят как желе. Это исправляется за счёт производительности.
Предлагаю очевидное решение: устанавливаем название игры «Jelly tanks». Устанавливаем мир игры — желейная вселенная. Всё состоит из желе. Получаем, что у игры есть идея™, которая отражена в основе геймплея. Профит и целостность проекта. И ещё оптимизация. Можно сделать несколько огромных уровней, с более желейной физикой.
Или можно использовать это в сюжете: злой злодей собрал зловещее устройство, которое в зловещих целях превратило весь мир в зловещее желе. Он также расставил везде своих роботизированых прихвостней-танков (тоже зловещих)
P.s. отличный снеговик, хе хе.
Эти более сложные типы взаимодействия есть, но из-за дискретности шага симуляции возникает ошибка, делающая материю нестабильной. Ряд решений, смягчающих эту ошибку (например, злоупотребление вязкостью, реализованной как распределение скорости и импульса частицы по соседям) создают эту желейность.
Но если заплатить немного производительности, отказаться от вязкости в пользу хрупкости и усилить жёсткость связи (риск нестабильности снижается уменьшением шага дискретизации), то материя ведёт себя в большей степени как твёрдое тело. Вопрос лишь в том, каким количеством производительности я готов пожертвовать.
В дальнейшем я планирую создать несколько типов вещества: твёрдое тело, землю, дерево и песок. И у них будут различные жёсткость/хрупкость/текучесть.
Но если заплатить немного производительности, отказаться от вязкости в пользу хрупкости и усилить жёсткость связи (риск нестабильности снижается уменьшением шага дискретизации), то материя ведёт себя в большей степени как твёрдое тело. Вопрос лишь в том, каким количеством производительности я готов пожертвовать.
В дальнейшем я планирую создать несколько типов вещества: твёрдое тело, землю, дерево и песок. И у них будут различные жёсткость/хрупкость/текучесть.
Суровые мармеладки! Вот только избыток красного после взрывов вызывает ассоциацию с кровищей. Что удивляет там, где её взяться неоткуда. А так физика прикольная. Особенно когда с разгона хоботом в мясе застревают.
Подразумевалось, что это расплавленная взрывом материя. Хотя, и правда, многовато.
Расплавленная материя в зависимости от температуры будет светиться сначала красным, потом жёлтым, потом вообще голубым.
http://www.digcode.ru/BlackBodySpecrtrum.html
Типичные взрывы дают всё же жёлтый цвет: https://ru.wikipedia.org/wiki/Температура_взрыва
Почему внешне выглядит так твердо?
Можно же красочно раскрасить все под тортики, пироженки, желе — и никаких вопросов.
Можно же красочно раскрасить все под тортики, пироженки, желе — и никаких вопросов.
Вовсе не многовато. Вот только, чтобы казалось, что материя нагрета до красного каления, красным должен быть только «ореол». То есть, тёплые частицы могут краснеть, а вот самые горячие частицы желтеют аж до белого.
Что можете сказать об PixelJunk Shooter?
Игры давно не играю, но эта, основанная на физике, заставила пройти до конца.
Игры давно не играю, но эта, основанная на физике, заставила пройти до конца.
Выглядит здорово. Частиц для жидкости — минимум, но благодаря хорошей математике взаимодействия, они довольно реалистично изображают жидкость. Ну и с графикой правильно сделали: множество частиц покрывается сплошной динамической текстурой. Я думал тоже нечто подобное сделать, но пока не копал в этом направлении.
UFO just landed and posted this here
Основной метод — использовать защищённую запись. В HLSL используются Interlocked операторы, а в процессорной многопоточности есть разные методы, в подробности которых я не вдавался и не могу ничего подсказать, но этому посвящено много статей, легко гуглится.
Насчёт Powder Toy — не знаю. Судя по динамике работы, эта однопоточная программа, но я могу ошибаться.
Насчёт Powder Toy — не знаю. Судя по динамике работы, эта однопоточная программа, но я могу ошибаться.
Меня в свое время шокировала физика песка из игры Earthworm Jim на Sega. Думаю что чем больше игра предлагает способов прохождения, чем больше вызывает интерес.
Признаться честно, от GPU после прочтения статьи я ожидал большего, чем у вас на видео.
Но, с другой стороны, если отвлечься от технических деталей — я бы с удовольствием в это порубился, выглядит очень интересно. Похоже, вормсами вдохновлялись? :)
Еще никуда не выкладывали?
Но, с другой стороны, если отвлечься от технических деталей — я бы с удовольствием в это порубился, выглядит очень интересно. Похоже, вормсами вдохновлялись? :)
Еще никуда не выкладывали?
Да, вдозновился вормсами и scorched earth. А на видео многое скрыто. Например, тот факт, что за каждый фрейм запускается 10 циклов симуляции, чтоб шаг был в 10 раз меньше. С меньшей точностью у меня и 500 тысяч частиц летало. Это было зрелищно, но не подходило для игры. А тут точность большая, но это не бросается в глаза.
Игру уже выложил в гринлайт:
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Игру уже выложил в гринлайт:
http://steamcommunity.com/sharedfiles/filedetails/?id=845215183
Не смотрели в сторону более продвинутых методов решения дифуров, чем прямой прогон вперёд? Кажется, что методы имеющие ошибку второго порядка (вместо первого, как у вас) могут заметно помочь.
Ну и если ещё больше углубляться, то для моделирования частиц и действующийх на них сил есть неплохой метод particle-in-cell (гуглится), используемый в том числе для серьёзных физических симуляций. Здесь, конечно, оверкиллом будет :)
Ну и если ещё больше углубляться, то для моделирования частиц и действующийх на них сил есть неплохой метод particle-in-cell (гуглится), используемый в том числе для серьёзных физических симуляций. Здесь, конечно, оверкиллом будет :)
Спасибо, погуглю.
А более продвинутые методы могут сработать, я пока не пробовал. Если вместо величины поля в текущей точке использовать усреднённое значение по текущей и следующей (по вектору скорости), то можно уменьшить ошибку.
А более продвинутые методы могут сработать, я пока не пробовал. Если вместо величины поля в текущей точке использовать усреднённое значение по текущей и следующей (по вектору скорости), то можно уменьшить ошибку.
насколько я проверял, не помогают другие, более сложные формулы на практике с целью оптимизации.
в плане характеристик кипения в зависимости от величины шага дискретизации, тупо .pos += .vel; ничем не отличается от формул с кучей переменных и компенсациями ошибок второго порядка, а алгоритм от более сложной математики ещё начинает притормаживать
в плане характеристик кипения в зависимости от величины шага дискретизации, тупо .pos += .vel; ничем не отличается от формул с кучей переменных и компенсациями ошибок второго порядка, а алгоритм от более сложной математики ещё начинает притормаживать
Вспоминается стрелялка про танки на Flash… Только управление было поподробнее, и не придумали лазерные снаряды.
Простите, но я бы не назвал физику в видео хоть сколько бы реалистичной. Вот совсем, скорее забавный физический эксперимент.в мире "желе". Если вам нравятся игры с физикой, посмотрите тот же Cortex Command (И следующую игру от них же). Несмотря на отвратность разработчиков, физика у них сносит мозг.
«Желейность» я могу пофиксить, вот сегодня записал гифку, получше стало?
http://i.imgur.com/qcGOQgW.gif
http://i.imgur.com/qcGOQgW.gif
Теперь не желе а торт. Думается нужны разные свойства для разных материалов
Гораздо лучше.
Не пожалейте 15 минут, посмотрите видео
Как бы вы молодец, и я восхищен вашими навыками написания физики, но, если честно, то не впечатляет =(
Очень хорошая статья. Давно думал сделать подобное, но руки не доходили. Была так же идея сделать библиотеку для обработки достаточно сложных операций не через ЦП, а предоставить это GPU.
Это всё не так уж и сложно, если делать с помощью compute shader на юнити. Так что если давно думал сделать, есть смысл попробовать.
Можете взглянуть на thrust
Возникает противоречие: нам нужна быстрая real-time симуляция. Но шаг должен быть очень маленький. Это противоречие я разрешил уменьшив шаг в десять раз по сравнению с первыми экспериментами, и производя десять циклов симуляции в каждом Update(). Цена этого решения — производительность. Так что пришлось сильно уменьшить количество частиц. Но всё же их осталось достаточно для сложного поведения всей системы.
А шаг динамическим сделать нельзя? При наличии близких частиц уменьшать шаг обсчета, при дальних взаимодействиях где погрешность намного медленней накапливается считать крупными шагами.
Определить наличие близких частиц — это значит уже сделать полноценный шаг. А определять наличие дальних частиц при отсутствии ближних стоит дорого в вычислительном смысле.
Попробуйте температуру или еще какой аналог.
Или инверсию зависимостей.
Читал по диагонали статью, но меня смутило что у вас время везде равномерно.
От этого приходится ждать «медленные» потоки, или считать что лежачий камень всё еще лежит.
Помню в школе когда еще не знал о нейронных сетях, придумал что-то похожее. Только у меня веса лежали не у принимающей стороны а у нейрона который выдает спайк. Это усложняло обучение, но упрощало симуляцию на процессоре — те нейроны которым спайки не приходили (импульсные), те и не пересчитывались.
Что-то похожее можно и у вас сделать. Частица изменила свои координаты и вектор. Посчитали кого это может задеть, добавили их в очередь.
Чтобы понимать кто где — можно не просто координаты хранить, но разбить вселенную на сектора и иметь массив частиц находящихся в секторе. Ну или по графу двигаться. Просчитали каждому кто рядом с ним. Навесили связи. Частица сместилась — поменяли связи. Кого убрать понятно, кого добавить — полюбому будет кто-то из соседей наших соседей. Если скорость слишком большая — уменьшили квант времени в этом секторе.
Я понимаю что это звучит как поток сознания, но основная мысль у меня — удорожание просчета одной частицы даже в два раза, легко окупится если за счет этого 90% частиц мы пересчитывать не будем.
Да, про температуру я здесь упомянул в том смысле, что температура это некая интегральная мера количества движения/суеты. Если сделать поле температуры (сглаженное значение модулей кинетических энергий) и пропорционально температуре распределять локальную частоту квантования времени, то можно существенно сэкономить мощности без существенной потери точности, а на сэкономленное — повысить точность там, где оно важнее.
Опять таки — отказ от однородности времени даст Вам возможность вводить более сложные алгоритмы для частных случаев (предмет+частица и другие) не опасаясь что это повредит распараллеливанию.
Или инверсию зависимостей.
Читал по диагонали статью, но меня смутило что у вас время везде равномерно.
От этого приходится ждать «медленные» потоки, или считать что лежачий камень всё еще лежит.
Помню в школе когда еще не знал о нейронных сетях, придумал что-то похожее. Только у меня веса лежали не у принимающей стороны а у нейрона который выдает спайк. Это усложняло обучение, но упрощало симуляцию на процессоре — те нейроны которым спайки не приходили (импульсные), те и не пересчитывались.
Что-то похожее можно и у вас сделать. Частица изменила свои координаты и вектор. Посчитали кого это может задеть, добавили их в очередь.
Чтобы понимать кто где — можно не просто координаты хранить, но разбить вселенную на сектора и иметь массив частиц находящихся в секторе. Ну или по графу двигаться. Просчитали каждому кто рядом с ним. Навесили связи. Частица сместилась — поменяли связи. Кого убрать понятно, кого добавить — полюбому будет кто-то из соседей наших соседей. Если скорость слишком большая — уменьшили квант времени в этом секторе.
Я понимаю что это звучит как поток сознания, но основная мысль у меня — удорожание просчета одной частицы даже в два раза, легко окупится если за счет этого 90% частиц мы пересчитывать не будем.
Да, про температуру я здесь упомянул в том смысле, что температура это некая интегральная мера количества движения/суеты. Если сделать поле температуры (сглаженное значение модулей кинетических энергий) и пропорционально температуре распределять локальную частоту квантования времени, то можно существенно сэкономить мощности без существенной потери точности, а на сэкономленное — повысить точность там, где оно важнее.
Опять таки — отказ от однородности времени даст Вам возможность вводить более сложные алгоритмы для частных случаев (предмет+частица и другие) не опасаясь что это повредит распараллеливанию.
Забавный факт: Miles Macklin et.al. (http://mmacklin.com/uppfrta_preprint.pdf) находят соседей только один раз на несколько итераций солвера.
Не совсем полноценный — пересчет сил, скоростей и координат можно не делать же в этом случае, а в следующем шаге посчитать их один раз за удвоенное/утроенное/учетверенный отрезок внутриигрового времени.
Ну или если полноценный, то при отсутствии близких частиц можно просто следующий шаг или несколько целиком пропустить.
В грубой реализации допустим сейчас есть цикл который делает 10 или 20 итераций как у вас на каждое обновление. Но сделать его не на простом счетчике i=1..10; i++, а на условном — были при обсчете текущего шага близкие частицы делаем в конце итерации i+1, если таких не было значит в конце итерации будет i+2 или i+3.
Естественно время во всех формулах расчета сил и координат частиц будет не фиксированными шагами меняться, а пропорционально номеру шага/итерации.
Ну или если полноценный, то при отсутствии близких частиц можно просто следующий шаг или несколько целиком пропустить.
В грубой реализации допустим сейчас есть цикл который делает 10 или 20 итераций как у вас на каждое обновление. Но сделать его не на простом счетчике i=1..10; i++, а на условном — были при обсчете текущего шага близкие частицы делаем в конце итерации i+1, если таких не было значит в конце итерации будет i+2 или i+3.
Естественно время во всех формулах расчета сил и координат частиц будет не фиксированными шагами меняться, а пропорционально номеру шага/итерации.
А на карточках от amd как работает?
Желейная реализация физики показалась очень забавной. Очень сильно раззадоривает момент после выстрела, когда вся конструкция складывается. Дома обязательно ребятишкам покажу эту игру. И да, я бы купил эту игру (с ностальгией вспоминаю времена Scorched Earth).
Ваша игра напомнила демки Phyz, который вышел когда ещё, и, вроде, не использует никакого GPGPU.
Как считали?
Не только «хорошо распараллеливаема», там ещё должен быть достаточно простенький алгоритм без ветвлений.
Я конечно знал, что видеокарточка мощней процессора, но я не знал, до какой степени. В среднем геймерском компьютере производительность видокарты в 50-100 раз выше производительности центрального процессора.
Как считали?
Конечно, задача должна быть хорошо распараллеливаема, этот бонус актуален не для любого алгоритма. Но моделирование тысяч частиц идеально распараллеливается.
Не только «хорошо распараллеливаема», там ещё должен быть достаточно простенький алгоритм без ветвлений.
там ещё должен быть достаточно простенький алгоритм без ветвлений.
Почему?
Ну, то есть, понятно что ветвления это минус в прозиводительности.
Но особых требований по этому поводу сейчас уже минимум.
Там не требования, ветвиться-то можно, но оно, насколько я помню, просаживает производительность куда хуже, чем ошибка в branch prediction на CPU. Выполняются всегда все ветки кода, потом ненужное выкидывается. Возможно, мои сведения устарели, не знаю.
Нет, все верно. Каждый мультипроцессор в видеокарте работает по принципу Single Instruction Multiple Data, выполняя за один такт одну и ту же инструкцию на каждом из ядер, но на разных участках памяти. Соответственно, если какая-то строчка сработала на одном из ядер, она займет время и всех остальных ядер мультипроцессора.
насколько я знаю, блокируется на ветвлении не весь мультипроцессор, а только WARP_SIZE.
в WARP'е всего 16-32 потоков, так что немного веток таки можно делать, это снизит производительность, но не фатально за счёт небольшого размера WARP'а
в WARP'е всего 16-32 потоков, так что немного веток таки можно делать, это снизит производительность, но не фатально за счёт небольшого размера WARP'а
на NV — 32 нити, на AMD — 64
А ветвление — это когда используются операторы if и case? Я, признаться, ничего не знал об этом ограничении, и понатыкал их всюду довольно много. Я не замечал особо явного влияния на fps. Видимо, оно не слишком велико. По сравнению, например, с переходом от незащищённого read/write к защищённым Interlocked-функциям.
Ну каждое ветвление может снизить скорость до 2х раз. Максимально возможная потеря скорости (если весь код покрыть кучей вложенных ветвлений) — 32 раза (для NVIDIA). Не сказать что мало. Но это худший случай.
Для CUDA (про AMD не знаю): потерь на ветвление не будет, если для всех нитей в warp предикат, по которому выполняется ветвление, принимает одно и то же значение (т.е. все нити в warp переходят по одной и той же ветке). Если в warp есть и нити для которых условие перехода true, и есть нити для которых false, то будет замедление в ~2 раза (реально для всех нитей будет обсчитан и один и другой переход, просто сохранён только нужный результат)
Т.е. условие «if (thread_num % 2 == 0)» даст сильное замедление, а условие «if (thread_num > N/2)» замедления почти не даст.
Для CUDA (про AMD не знаю): потерь на ветвление не будет, если для всех нитей в warp предикат, по которому выполняется ветвление, принимает одно и то же значение (т.е. все нити в warp переходят по одной и той же ветке). Если в warp есть и нити для которых условие перехода true, и есть нити для которых false, то будет замедление в ~2 раза (реально для всех нитей будет обсчитан и один и другой переход, просто сохранён только нужный результат)
Т.е. условие «if (thread_num % 2 == 0)» даст сильное замедление, а условие «if (thread_num > N/2)» замедления почти не даст.
А на самом деле желе это круто.
Только надо вписать в гемплей.
Война в мире желе )) Сделать какой желейный сеттинг.
Конфетная артиллерия и прочее )
Только надо вписать в гемплей.
Война в мире желе )) Сделать какой желейный сеттинг.
Конфетная артиллерия и прочее )
Очень верное направление мыслей. Но на видеокарту я бы не стал загружать функции, которые должен выполнять процессор, она должна выводить поток уже обработанной и структурированной информации, ничего не вычисляя.
Верное направление мыслей в плане реалистичных физ. взаимодействий, не занимаясь при этом графодрочерством. Всё должно быть оптимизировано и с большой свободой действий для пользователя, а все зачем-то хотят из игр фильмы делать) в общем + вам.
Верное направление мыслей в плане реалистичных физ. взаимодействий, не занимаясь при этом графодрочерством. Всё должно быть оптимизировано и с большой свободой действий для пользователя, а все зачем-то хотят из игр фильмы делать) в общем + вам.
Простите, а почему это вы бы не стали считать физику на видеокарте? О_О Физика частиц — отлично оптимизированная для видеокарты область вычислений.
Пруф.
Пруф.
Я не утверждаю, а сказал «в целом» что переложить вычисления с процессора и оперативки на видеокарту — это не выход. Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено. В общем в аналогии с человеком — это перевести часть обязанностей участков мозга, ответственных за вычисление и дать дополнительную нагрузку на глаза
Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено
Как там в 90-ых, Doom уже вышел?
Тут другой вопрос, в 2017 году видеокарта и так еле пережевывает графику, особенно если мы говорим о чем-то вроде 4к, загружать её сверх этого — ну не знаю… Сейчас наблюдается какой-то баланс между физикой и графикой, если его сместить, графика резко пострадает. А как мне кажется, сейчас это золотая жила для всяких EA, и вряд ли они решатся сильно от нее отказаться. Желейные войны — это забавно, но когда эффект новизны пройдет, люди все равно пойдут в игры с не такой уж чудесной физикой, но зато нормальным геймплеем — цива, стелларис и т.п. Просто потому, что у "желейных войн" сеттинг не предполагает серьезности и существенной реиграбельности. Единственное исключение — червячки (в плане реиграбельности, но серьезности там опять же нет), но за годы педалирования одного и того же даже они поднадоели. Сыграть разок с друзьями в армагеддон — пожалуйста, но на выходные лучше засесть в цивилизацию.
На данный момент это верно. Хотя, качество геймплея не является следствием графики. Просто так вышло, что графика — высокое требование для всех игр, среди которых нашлись интересные. И вряд ли графика способна создать предпосылки для новых идей в гейм-дизайне.
А вот физика способна дать что-то новое. Но идеи невидимы, надо думать, изобретать, пробовать, общаться. Не исключено, что найдутся возможности сделать интересную игру, невозможную при классическом скриптовом подходе.
А графика не исключается физикой. Существует многообразие стилей и шейдерных трюков, которые дают визуальную конфетку без насилия над видеокартой. В моём случае визуализация слабенькая, но можно сделать гораздо лучше малыми средствами.
Так что, всеобъемлющая физика — это не исключительная альтернатива, а скорее дополнительная степень свободы именно для гейм-дизайна.
А вот физика способна дать что-то новое. Но идеи невидимы, надо думать, изобретать, пробовать, общаться. Не исключено, что найдутся возможности сделать интересную игру, невозможную при классическом скриптовом подходе.
А графика не исключается физикой. Существует многообразие стилей и шейдерных трюков, которые дают визуальную конфетку без насилия над видеокартой. В моём случае визуализация слабенькая, но можно сделать гораздо лучше малыми средствами.
Так что, всеобъемлющая физика — это не исключительная альтернатива, а скорее дополнительная степень свободы именно для гейм-дизайна.
Главное чтобы дизайнер был толковый умеющий этим пользоваться.
А то в DOOM III при наличии динамического освещения не нашлось дизайнеров умеющих им пользоваться так, чтобы это хоть как-то влияло на геймплей. Хотя старенький Aliens vs Predator 1999 года, имея лишь лайтмапы, использовал в геймплее динамическое освещение на полную катушку.
Другой пример Red Faction — с разрушаемым окружением, и дизайнерами не умеющими это использовать, более того топорно влепившими ничем неразрушаемые стены.
Хорошим примером можно назвать использование физики в геймплейе Half-Life 2. Тут дизайнеры дали возможность почувствовать её наличие вовлёкши её в геймплей.
А то в DOOM III при наличии динамического освещения не нашлось дизайнеров умеющих им пользоваться так, чтобы это хоть как-то влияло на геймплей. Хотя старенький Aliens vs Predator 1999 года, имея лишь лайтмапы, использовал в геймплее динамическое освещение на полную катушку.
Другой пример Red Faction — с разрушаемым окружением, и дизайнерами не умеющими это использовать, более того топорно влепившими ничем неразрушаемые стены.
Хорошим примером можно назвать использование физики в геймплейе Half-Life 2. Тут дизайнеры дали возможность почувствовать её наличие вовлёкши её в геймплей.
не воспринимайте так близко к сердцу, я имел ввиду в целом, понятно что графический процессор создан в помощь основному, но только лишь в помощь, а не как полноценная альтернатива. Если вы думаете что выход из положения — проблемы реалистичности игрового физ. мира кроется в том что процессор не может справиться с этой задачей и надо её перекладывать на видеокарту — вот с этим я крайне не согласен. Помочь — да, полностью заменить — бред.
вот с этим я крайне не согласен
Из религиозных соображений? Вы не обижайтесь, но я искренне не понимаю, почему делать расчёты на ЦП — канонично, а на ГП — нет. Вам-то какое дело, как игроку, да и как разработчику тоже?
Потому что каждый должен выполнять свою задачу) объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП? Ну хорошо, сделаете вы игру, где вам хватит мощности вашей крутой видеокарты для рассчёта 2000 частиц)) а дальше? А вы знаете что у большинства пользователей НЕ игровые видеокарты? Это перекос не туда, я уже говорил что автор словил верное направление, что надо не на графику ориентироваться, а на реалистичность физики и свободу действий, а не линейные фильмы из игр делать, но в остальном остаюсь при своём мнении — ресурсы видеокарте нужны для обработки и вывода на экран уже более-менее обработанной информации, насиловать её вычислениями не надо. Спасибо за обсуждение.
объясните, а зачем тогда ЦП, если рассчёт физики будет на ГП?
Обработка игровой логики, ИИ, динамическая подгрузка ресурсов?
А вы знаете что у большинства пользователей НЕ игровые видеокарты?
У автора поста тоже, у него вообще ноутбучная из позапрошлого поколения.
насиловать её вычислениями не надо
3д-ускорители изначально изобретали для «насилования» их вычислениями. Если бы это было не так, мы бы до сих пор сидели в тех самых 90-х с тем самым Doom.
Аналогия неуместна. Уже лет 8 функция видеокарты — выполнение параллельных алгоритмов, которые хорошо ложатся в идеологию SIMD.
Это началось с программируемых шейдеров, которые позволили выполнять не фиксированные функции на каждом этапе отображения, а самописные подпрограммы: шейдеры геометрии, вершинные, тесселяции, фрагментные.
А в наши дни эта концепция развилась до General Purpose программирования на видеокартах: нейронные сети, кодирование/декодирование видео, симуляция физики.
Если вы находите мои рассуждения обоснованными, можете просто согласиться, не обязательно продолжать спор)
Это началось с программируемых шейдеров, которые позволили выполнять не фиксированные функции на каждом этапе отображения, а самописные подпрограммы: шейдеры геометрии, вершинные, тесселяции, фрагментные.
А в наши дни эта концепция развилась до General Purpose программирования на видеокартах: нейронные сети, кодирование/декодирование видео, симуляция физики.
Если вы находите мои рассуждения обоснованными, можете просто согласиться, не обязательно продолжать спор)
А CPU предназначен, чтобы вояджеры в космос отправлять. Зачем вы на них предлагает игровую физику считать?
Вобщем и целом — переносить жирные вычисления на GPU — это норма в современном мире. И не просто норма, это правильно.
Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
Ну вот тако вот мир ПК развивается, никуда не деться.
Полагаю вы просто мало понимаете/знаете о внутренностях, поэтому и делаете столько абсурдные заявления.
ТС идёт на 100% верным путём.
Вобщем и целом — переносить жирные вычисления на GPU — это норма в современном мире. И не просто норма, это правильно.
Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
Ну вот тако вот мир ПК развивается, никуда не деться.
Полагаю вы просто мало понимаете/знаете о внутренностях, поэтому и делаете столько абсурдные заявления.
ТС идёт на 100% верным путём.
Я вам больше скажу — скоро видеокарты вообще станут основным источником вычислительных мощностей на ПК, а процессор будет лишь сопровождающим устройством.
Действительно, у Nvidia сейчас огромные наработки в области многоядерного железа. А интел всю дорогу шёл по пути мощных одноядерных вычислителей, и упёрся в ограничения по частоте работы и размеру транзистора. А миру нужны вычислительные мощности. Акции Nvidia за полтора года выросли на 300%, и это говорит о том, что они вышли далеко за пределы рынка только графических карт.
Функция видеокарты — ОТОБРАЗИТЬ то, что уже было вычислено.
Вообще-то, на видеокартах Вертексные Шейдеры появились ещё ДО появления CUDA и OpenCL Более того они появились раньше, чем Ageia PhysX. И на них с самого появления можно было считать простейшую физику в духе «сложить два вектора».
Проголосовал в гринлайте.
Можно ли объединять точки в твёрдые тела? У вас там есть танки, но они тоже желейные. Для вариативности не хватает некоторого количества твёрдых тел.
Можно ли объединять точки в твёрдые тела? У вас там есть танки, но они тоже желейные. Для вариативности не хватает некоторого количества твёрдых тел.
Эти желейные миры и танчики выглядят невероятно весело! Срочно на Greenlight!
Отличная идея на мой взгляд. Со временем может получиться очень хорошая вещь! Если бы не недостаток знаний, тоже бы попробовал что-то такое написать или влиться в разработку.
Могу проверить и рассказать, как работает на Radeon 270X, если нужно.
Могу проверить и рассказать, как работает на Radeon 270X, если нужно.
Я прочитал статью и понял, как отстал. С игровой индустрией, как разработчик попрощался в далеком 2004г, завершив его единственной 2D игрой — логические шарики. Вся 'физика', да простят меня спецы, решалась анимацией (сжатие и расширение шаров) 8-10 кадрами в гифки.
Спасибо за статью.
Спасибо за статью.
Для 3D уже делают вполне реалистичные разрушения.
Довольно реалистично, но уже долго оно выглядит до убогого одинаково. Постоянно одинаковые куски, которые просто сваливаются в кучу. Изначально более мелких и крупных частиц мы не получим, раздробить уже полученные — тоже. И вот так и выглядит это с 2008 года без существенных изменений.
Да, не хватает в этом ощущения «хряп!», которое как раз и достигается измельчением осколков, выглядит как-то малость «пенопластово». Но при помощи адаптивных разбиений в местах контакта и добавлением облаков пыли при падении на землю, а не только при попадании снаряда, можно и это допилить. Здесь видимо решили что для игрового процесса большего не нужно. Есть интерактивный ландшафт, и этого достаточно.
А этого в Red Faction в начале 2000-х не было случайно? Выглядит довольно примитивно для уровня современного GPU.
UPD: Видео 2012 года, это частично объясняет.
UPD: Видео 2012 года, это частично объясняет.
А что вы думаете о нейросетевых вычислениях?
https://www.youtube.com/watch?v=iOWamCtnwTc
https://www.youtube.com/watch?v=iOWamCtnwTc
> «Или те же гоночки: до чего приятней на полной скорости сшибать людей...»
Ох, зря вы слово «людей» вставили в эту фразу. Я бы убрал, оставив только неодушевленные предметы.
Ох, зря вы слово «людей» вставили в эту фразу. Я бы убрал, оставив только неодушевленные предметы.
Кроваво-красная земля при взрывах выглядит жутко. Надо бы что-то более нейтральное, ну хотя бы цвет грязи или вообще черное, типа обуглилось в этом месте.
Очень согласен с утверждением, что современным играм не хватает физики! Графика на высоте, а физика — так себе. KSP и некоторые другие — исключение :-)
А под Linux (Mint) игра планируется?
А под Linux (Mint) игра планируется?
Подобную задачу давным давно решили без велосипеда, новомодной вещей с расчётами на видеокарте и при этом работающей быстро:
http://www.gamedev.ru/code/articles/PositionBasedPhysics#v_chyom_je_profit_
С виду простой метод возволяет моделировать вполне внушительное количество взаимодействующих объектов:
На этом просчитывается взаимодействие 5000 шариков, расчёт всей физики занимает чуть больше 2мс на одном ядре процессора Core2Duo E6600 2.4GHz.
http://www.gamedev.ru/code/articles/PositionBasedPhysics#v_chyom_je_profit_
С виду простой метод возволяет моделировать вполне внушительное количество взаимодействующих объектов:
На этом просчитывается взаимодействие 5000 шариков, расчёт всей физики занимает чуть больше 2мс на одном ядре процессора Core2Duo E6600 2.4GHz.
Есть хорошая статья о моделировании сеточной физики:
http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html
идеи там близкие к тому что вы описали в статье, только более формализовано.
http://http.developer.nvidia.com/GPUGems/gpugems_ch38.html
идеи там близкие к тому что вы описали в статье, только более формализовано.
Еще здорово смотрится физическое моделирование в дополненной реальности.
Как раз эта технология мне доставляла наибольшие страдания, связанные с величиной диссонанса между идеалом и нынешним положением.
Представь то же самое, но нарисованная вода действительно размывает песок. То есть, программа не ограничивается накладыванием текстуры, а способна двигать материю. Чтоб за несколько секунд можно было построить город, заложенный в виде 3д-модели в программе. Или чтобы происходили реалистичные взрывы. И прочее в этом духе.
И если сравнивать виртуальную модель песочницы, в которой песок подвластен контролю со стороны программы, и реальную, в которой песок недвижим, я предпочёл бы пока первую, ибо совсем другой объём возможностей открывается. Но было бы здорово, если б сделали живой песок в реальности.
Теоретически это было бы возможно с помощью конфигурируемого магнитного поля высокого разрешения и управляемо ионизируемыми частицами. Но практической реализации этой идеи пока не существует.
Так что приходится довольствоваться вирутеальным песочком, что тоже, в общем, довольно занятно.
Представь то же самое, но нарисованная вода действительно размывает песок. То есть, программа не ограничивается накладыванием текстуры, а способна двигать материю. Чтоб за несколько секунд можно было построить город, заложенный в виде 3д-модели в программе. Или чтобы происходили реалистичные взрывы. И прочее в этом духе.
И если сравнивать виртуальную модель песочницы, в которой песок подвластен контролю со стороны программы, и реальную, в которой песок недвижим, я предпочёл бы пока первую, ибо совсем другой объём возможностей открывается. Но было бы здорово, если б сделали живой песок в реальности.
Теоретически это было бы возможно с помощью конфигурируемого магнитного поля высокого разрешения и управляемо ионизируемыми частицами. Но практической реализации этой идеи пока не существует.
Так что приходится довольствоваться вирутеальным песочком, что тоже, в общем, довольно занятно.
Приветствую,
я правильно понял, что вместо формулы потенциала 6-12 вы на деле использовали упрощенную для вычислений 4-8?
я правильно понял, что вместо формулы потенциала 6-12 вы на деле использовали упрощенную для вычислений 4-8?
Было 4-8, сейчас 6-12. Хотя, разницы особой нет, я всё равно коэффициентом добивался максимально возможной крутизны графика в точке нулевоко коэффициента.
Кстати, а насколько реально совмещать частицы с разными свойствами, чтобы действительно сделать что-то наподобие OE-Cake GPU Version?)
Реально, вот сейчас как раз доделал, теперь есть несколько материалов с разными свойствами — камень, песок, снег, грязь, металл, и т.д. Но взаимодействие между ними я не слишком прорабатывал. Масса и теплоёмкость у всего одинаковая, динамика жидкости — так себе. Я бы не против поглубже в эту сторону покопать, но сейчас хочется закончить с физикой и аняться геймплеем.
Допустим, Rigid-axis body (твердое тело с осью вращения) или даже сложные механизмы, которые успешно создавались в том же OE-Cake
Тела сами слипаются из частиц, мне этого пока достаточно, изначально цель была в том, чтобы получитьреалистично разрушаемый мир из частиц.
А механизмы будут простенькие. Я ввёл сущность, вроде кости, которая упруго задаёт расстояние между частицами. Такими костями можно усилить строения и заскриптовать анимацию уровней, вроде катающихся туда-сюда мостиков. А сам танк в демке — тоже механизм, сделанный из частиц, и работающий как молекулярная машина.
В качестве врагов для синглплеерного аркадного режима я создам ещё несколько разных механизмов с локомоцией, реализуемой через физические свойства мира.
А механизмы будут простенькие. Я ввёл сущность, вроде кости, которая упруго задаёт расстояние между частицами. Такими костями можно усилить строения и заскриптовать анимацию уровней, вроде катающихся туда-сюда мостиков. А сам танк в демке — тоже механизм, сделанный из частиц, и работающий как молекулярная машина.
В качестве врагов для синглплеерного аркадного режима я создам ещё несколько разных механизмов с локомоцией, реализуемой через физические свойства мира.
а можно где то скачать эту вашу игру?)
UFO just landed and posted this here
У человеческого мозга есть несколько интересных особенностей при работе с изображениями. Во-первых, он страшно медленный по сравнению с электронными Гигагерцами, во-вторых — синтез изображения развит плохо у мозга, зато очень быстрое распознавание. И ещё, у мозга отсутствует общая шина. Скорость мозга обусловлена его Гигапараллельностью.
Бредятину пишите.
Не ставьте человеческому мозгу задач, которые хорошо щелкают компьютеры.
Пусть человек решает то, что компьютеры делают хуже.
Кстати, подкину идею. Если вместо земли использовать воду, а вместо танков кораблики, то волны от взрывов могут сильно разнообразить игру.
А вы случаем не знакомы с очень похожей демкой от майкрософта?:)
https://code.msdn.microsoft.com/windowsdesktop/DirectCompute-Graphics-425de5a8
https://code.msdn.microsoft.com/windowsdesktop/DirectCompute-Graphics-425de5a8
UFO just landed and posted this here
UFO just landed and posted this here
За такие комментарии стоит минусовать)
- Придрались к незначительной части комментария
- Обвинили автора комментария в том, что он минусует карму ТС
- Упомянули никому неизвестного человека(гугл не находит буквально ничего по запросу "Маша Лёрнинко")
- Высказали поверхностное суждение, не нагуглив, что действительно есть работа, которая с помощью нейронных сетей улучшает результат физических солверов.
WTF?
Большая часть ваших комментариев о том, что все такие плохие-нехорошие и минусуют, а большая часть оставшихся комментариев — не аргументированная критика.
Статей нет.
Как следствие, и карма у вас в минусах.
Видимо, Маша Лёрнинко — это Машин Лёрнинг :)
А, блин, нормальная анаграмма.
Этот пункт беру обратно) Остальные остаются)
UFO just landed and posted this here
И?)
UFO just landed and posted this here
Нейросети медленно развиваются, и пока умеют только довольно специфические вещи. Но в принципе сетевая топология вычислителей на нечёткой логике — это то, что рано или поздно сможет делать всё, что умеет мозг. Нейросети сейчас на той же стадии технологического взросления, как первые самолёты братьев райт. До мёртвых петлей и сверхзвука далеко, но понятно, что всё будет.
Нейросеть, которая водит машины, вас не устраивает? Просто обучение оной поведению лягушки мало кому интересно и не несёт практической пользы, тогда как обучение её видеть трассу, других участников дорожного движения, дорожные знаки и успешно доезжать из точки А в точку Б без ДТП и соблюдая ПДД имеет огромную практическую пользу. Соответственно на последнее выделяются огромные средства и вычислительные ресурсы, и уже есть рабочие результаты. Или вам это кажется значительно более простой задачей, чем ловля мух?
Естественно если вы хотите смоделировать весь организм лягушки целиком со всеми происходящими в ней процессами, то вам просто не хватит вычислительных мощностей или модель будет крайне грубой. С одной стороны это всё крайне полезно для понимания того как работают реальные живые организмы, но физическое моделирование работы мозга сравнимо с запуском программы в эмуляторе другой физической архитектуры. Невероятно полезно для понимания его устройства и совершенно бесполезно для решения прикладных проблем в разумные сроки.
UFO just landed and posted this here
Ты правда не знаешь на кой в поиске Гугла используются кавычки? О_о
Впрочем, даже так вы лжете так-как Гугл сам их за вас удаляет и таки находит много чего, а если конкретно, то почитайте про те же наработки nVidia в области AI — они ещё в прошлом году показывали рабочую машинку.
Ну а зачем военным нейросеть, способная ловить мух, я без понятия. Я могу понять если им нужно распознавать самолёты и ракеты в воздухе, чтоб максимально быстро их сбивать, но для этого нужно учить нейросеть распознавать самолёты и ракеты, а не мух. Иначе она мух сбивать и будет.
Впрочем, даже так вы лжете так-как Гугл сам их за вас удаляет и таки находит много чего, а если конкретно, то почитайте про те же наработки nVidia в области AI — они ещё в прошлом году показывали рабочую машинку.
Ну а зачем военным нейросеть, способная ловить мух, я без понятия. Я могу понять если им нужно распознавать самолёты и ракеты в воздухе, чтоб максимально быстро их сбивать, но для этого нужно учить нейросеть распознавать самолёты и ракеты, а не мух. Иначе она мух сбивать и будет.
У человека фобия по нейронным сетям.
У меня индуктивный метод обучения: сделать самому, обобщить проблематику, ознакомиться с литературой. Так что это вопрос не шишек, а оптимального способа приобретения знаний и навыков.
> аппроксимация точных уравнений нейронными сетями (т.е. сеть учится делать симуляцию, чтобы это выглядело для человека достаточно хорошо, выше уже дали ссылку на подобную работу)
Очень интересно, задумывался о подобном способе оптимизации. Кроме обозначенной выше ссылки, можете подсказать ещё по теме?
Если не секрет, у вас довольно широкий кругозор по деталям симуляций, это профессиональный интерес?
Я несколько лет занимаюсь созданием симуляций, основанных на SPH моделях и регулярно смотрю SIGGRAPH, но пару интересных вещей узнал только по ссылкам из ваших комментариев.
Очень интересно, задумывался о подобном способе оптимизации. Кроме обозначенной выше ссылки, можете подсказать ещё по теме?
Если не секрет, у вас довольно широкий кругозор по деталям симуляций, это профессиональный интерес?
Я несколько лет занимаюсь созданием симуляций, основанных на SPH моделях и регулярно смотрю SIGGRAPH, но пару интересных вещей узнал только по ссылкам из ваших комментариев.
Наткнулся на интересную работу, близкую по теме статьи (с исходниками), может Вам будет интересно: статья.
Статья о моделировании песка в 3D и получилось у них довольно реалистично.
Статья о моделировании песка в 3D и получилось у них довольно реалистично.
Sign up to leave a comment.
Что если в играх использовать видеокарточку для физики, а не для графики