Согласен, мультиплеер — основной источник интереса. Мультиплеер я запланировал, но для этого нужно сначала исправить недетерминированность симуляции, чтобы синхронизация была не слишком сложной.
Так тоже делают, с разбиением пространства. Хотя, обычно каждый кусок протранства считают на отдельной видеокарте.
И да, у меня десятки тысяч потоков, по числу частиц. А когда текстура рендерится — по потоку на пиксель -> миллион потоков. Архитектура GPU очень развита для работы с таким количеством.
Структура данных, которая хранит ссылки на ближайших соседей, обновляется каждый тик, да. Это занимает ничтожную долю вычислительного времени.
У меня он и используется, но упрощённо — чистый леннард-джонс.
Но тут проблема в том, что высокая крутизна кривой вблизи точки равновесия необхоима, но она уводит величину силы отталкивания слишком быстро в запредельную область. Так что приходится либо уменьшать шаг, либо резать пик силы отталкивания.
То есть, борьба идёт за удешевление жёсткости взаимодействия в валюте производительности. Но борьба эта идёт уже в области высокой ошибки из-за большого шага, так как это неизмежный компромисс. И поэтому признаные оптимальные решения для областей с малым шагом и малой ошибкой могут быть неприменимы в данном случае, так как они могут быть слишком чувствительны к ошибке. Я использовал силу леннард-джонса с крутым коэффициентом, но обрезал пик. Это уже очень грубое решение. Но оно позволяет получить большую жёткость для слабых взаимодействий между частицами. Так что мой случай несколько в стороне от типичных расчётов, и приходится искать оптимальные решения самостоятельно.
На данный момент у меня есть два вопроса: какой интегратор покажет лучшие резальтаты меньшей ценой производительности. И можно ли на что-то заменить силу ланнарда-джонса, с тем же критерием.
Я сделал пару уровней с кондитерской тематикой. В остальном, пока хочется придерживаться реализма в декорациях. А дальше посмотрю по массовой реакции игроков. Если для людей будет неприемлема желейность в бетонных столбах, придётся менять стиль.
Параллелизация идёт по частицам. На каждую частицу — один поток на каждом шаге вычислений.
Сцена разделена на сегменты ради того, чтоб каждая частица взаимодействовала только с соседями, а не просматривала весь объём частиц в поиске соседей. Но радиус взаимодействия меньше размера просматриваемой в поисках соседей области сетки, так что проблема стыков отсутствует.
Я на леннарде-джонсе использовал высокие коэффициенты, так что тела ближе к упругости. Использовал бы ещё более высокие, но это потребовало бы уменьшения шага, чтоб всё не взрывалось из-за ошибки большого шага.
Но я тут подумал, что леннард-джонс вообще-то для трёхмерных тел вычислен. В двумерном случае силы должны быть выше, для достижения того же эффекта. Выяснение оптимальной формы и кривизны кривой сил вблизи точки равновесия — интересный вопрос. Оптимальной — именно с точки зрения количества производительности, затрачиваемой на единицу жёсткости. Я бы подэкспериментировал с этим, но хочется от физики перейти к геймплею, чтоб игру закончить.
Кстати, разрыв связей при привышении порога я тоже сделал. То есть, у меня две системы наложены. Примерно такая, что у вас действует до разрушения, а после — чистый леннард-джонс без запрета на разрыв связи.
Для параллельных вычислений лучше для каждого потока использовать в один и тот же объём вычислений, иначе быстрые потоки будут ждать медленных в пределах группы. Тогда уж лучше для всех вычислений использовать боее точные медленные.
Для настройки типов физики у меня сейчас используется что-то около десяти параметров взаимодействия частиц. Это даёт довольно широкий простор для изменений. Единственное ограничение — сила связи. Но мне выше посоветовали использовать другой интегратор, и есть шанс, что он уменьшит ошибку большого шага, что позволит увеличить потолок сил, и это расширит диапазон физических свойств материалов.
Хвост всё равно будет, потому что придётся использовать огромный коэффициент у функции второй степени, чтобы создать значительную силу уже на небольшом расстоянии от точки равновесия, иначе материя будет кашей.
А затухание у меня задаётся вообще читерским способом. Дело в том, что если что-то делать с абсолютной скоростью, то летящие в воздухе куски материи будут неестественно тормозиться. А если через вязкость распространять между частицами доли их относительной скорости, то общая энергия системы не будет падать, а это нужно, чтоб после взрывов всё успокаивалось.
Поэтому, я ввёл систему, которая на каждом шагу выясняет для каждой частицы, является ли она частью большого покоящегося на земле куска или летит в воздухе. И если является. то из её абсолютной скорости вычитается малая доля.
А формулы для вязкости сейчас таковы, что отсутствует обмен тангенциальной компонентой скорости между соседями. Потому что это тормозило вращение небольших кусков материи. Обмен происходит только долями нормальной компоненты скорости.
Да, 10 шагов между кадрами, то есть 300 в секунду на 30 fps. Для примерно 20000 частиц. Я бы с удовольствием сделал шаг поменьше, но приходится ориентироваться на свою карточку gtx 750m, чтоб не тестировать игру на низких fps.
Насчёт функции силы я согласен, наверняка есть более эффективная альтернатива. Я поэкспериментирую с предложенным вами вариантом, когда снова возмусь за физику.
А уход от двенадцатой степени не самоценнен, intrinsic вункции языка HLSL на удивление быстрые, видимо там на низком уровне много ускорения математики. Важна в основном кривая в узкой области вблизи равновесия, её вклад в реакцию материи на толчки — наибольший. У функции U=k(x-x0)^2 вблизи точки равновесия иная кривизна, чем у леннарда-джонса, и сложно предсказать, что даст лучшее поведение материи. Так что поэкспериментирую.
Здорово! А это оно в реальном времени так прыгает? И сколько частиц в сцене? В моей модели тоже жёстко получается, если сделать лчень маленький шаг, и увеличить силу взаимодействия. Но это повлияло бы напроизводительность, потому что ради быстрых вычислений в реальном времени пришлось бы сократить число частиц в сцене.
Да, технически это возможно, но у меня нет машины на Линуксе, чтоб сделать билд, так что я пока игру доделаю до более вменяемого вида, и тогда выпущу для Линукса и МакОС.
Если получится сделать мультиплеер с одновременной игрой в рилтайме, непременно попробую, должно быть круто. Но симуляция пока недетерминирована, так что мультиплеер только в задумке.
Но как минимум я сделаю редактор уровней. И ещё добавлю разные сорта оружия, влияющего на материю. Уже сейчас можно копать в какой-то мере. И это довольно кайфово.
Ага, как раз над полётом думаю. Вероятно, на некоторых уровнях вместо танка будет летающий кораблик с реактивной тягой. Я это даже отчасти с танком реализовал, когда сделал у огнемёта слишком большую отдачу от выстрела, и танк летал с хвостом пламени.
В VoxelFarm, кажется, тот же подход, что в Red Faction. Коллайдеры динамически натягиваются на оставшиеся без опоры меши. Но в видео заметно, что если меш хоть маленькой стеночкой соединён с основным зданием, то эта стеночка не сломается, хотя должна бы. То есть, этот подход требует учёта большого объёма частных случаев. Разработчики Red Faction тоже жаловались на эту сложность. Возможно, в ней кроется медленное развитие направления воксели+физика. Слишком сложно.
Масса одинаковая. Кажется, я решил не усложнять вычислений вводя различие масс. Но если будет необходимость, можно ввести. Я подумывал о жидкостях с разной плотностью, чтоб в каких-то плавать, в других тонуть. Но возможно, до этого не дойдёт.
А формы у частиц нет, они как точки взаимодействуют, столкновений не происходит, только взаимные силы с градиентом величины по расстоянию.
И да, у меня десятки тысяч потоков, по числу частиц. А когда текстура рендерится — по потоку на пиксель -> миллион потоков. Архитектура GPU очень развита для работы с таким количеством.
Структура данных, которая хранит ссылки на ближайших соседей, обновляется каждый тик, да. Это занимает ничтожную долю вычислительного времени.
Но тут проблема в том, что высокая крутизна кривой вблизи точки равновесия необхоима, но она уводит величину силы отталкивания слишком быстро в запредельную область. Так что приходится либо уменьшать шаг, либо резать пик силы отталкивания.
То есть, борьба идёт за удешевление жёсткости взаимодействия в валюте производительности. Но борьба эта идёт уже в области высокой ошибки из-за большого шага, так как это неизмежный компромисс. И поэтому признаные оптимальные решения для областей с малым шагом и малой ошибкой могут быть неприменимы в данном случае, так как они могут быть слишком чувствительны к ошибке. Я использовал силу леннард-джонса с крутым коэффициентом, но обрезал пик. Это уже очень грубое решение. Но оно позволяет получить большую жёткость для слабых взаимодействий между частицами. Так что мой случай несколько в стороне от типичных расчётов, и приходится искать оптимальные решения самостоятельно.
На данный момент у меня есть два вопроса: какой интегратор покажет лучшие резальтаты меньшей ценой производительности. И можно ли на что-то заменить силу ланнарда-джонса, с тем же критерием.
Сцена разделена на сегменты ради того, чтоб каждая частица взаимодействовала только с соседями, а не просматривала весь объём частиц в поиске соседей. Но радиус взаимодействия меньше размера просматриваемой в поисках соседей области сетки, так что проблема стыков отсутствует.
Но я тут подумал, что леннард-джонс вообще-то для трёхмерных тел вычислен. В двумерном случае силы должны быть выше, для достижения того же эффекта. Выяснение оптимальной формы и кривизны кривой сил вблизи точки равновесия — интересный вопрос. Оптимальной — именно с точки зрения количества производительности, затрачиваемой на единицу жёсткости. Я бы подэкспериментировал с этим, но хочется от физики перейти к геймплею, чтоб игру закончить.
Кстати, разрыв связей при привышении порога я тоже сделал. То есть, у меня две системы наложены. Примерно такая, что у вас действует до разрушения, а после — чистый леннард-джонс без запрета на разрыв связи.
Для настройки типов физики у меня сейчас используется что-то около десяти параметров взаимодействия частиц. Это даёт довольно широкий простор для изменений. Единственное ограничение — сила связи. Но мне выше посоветовали использовать другой интегратор, и есть шанс, что он уменьшит ошибку большого шага, что позволит увеличить потолок сил, и это расширит диапазон физических свойств материалов.
А затухание у меня задаётся вообще читерским способом. Дело в том, что если что-то делать с абсолютной скоростью, то летящие в воздухе куски материи будут неестественно тормозиться. А если через вязкость распространять между частицами доли их относительной скорости, то общая энергия системы не будет падать, а это нужно, чтоб после взрывов всё успокаивалось.
Поэтому, я ввёл систему, которая на каждом шагу выясняет для каждой частицы, является ли она частью большого покоящегося на земле куска или летит в воздухе. И если является. то из её абсолютной скорости вычитается малая доля.
А формулы для вязкости сейчас таковы, что отсутствует обмен тангенциальной компонентой скорости между соседями. Потому что это тормозило вращение небольших кусков материи. Обмен происходит только долями нормальной компоненты скорости.
Насчёт функции силы я согласен, наверняка есть более эффективная альтернатива. Я поэкспериментирую с предложенным вами вариантом, когда снова возмусь за физику.
А уход от двенадцатой степени не самоценнен, intrinsic вункции языка HLSL на удивление быстрые, видимо там на низком уровне много ускорения математики. Важна в основном кривая в узкой области вблизи равновесия, её вклад в реакцию материи на толчки — наибольший. У функции U=k(x-x0)^2 вблизи точки равновесия иная кривизна, чем у леннарда-джонса, и сложно предсказать, что даст лучшее поведение материи. Так что поэкспериментирую.
Но как минимум я сделаю редактор уровней. И ещё добавлю разные сорта оружия, влияющего на материю. Уже сейчас можно копать в какой-то мере. И это довольно кайфово.
А формы у частиц нет, они как точки взаимодействуют, столкновений не происходит, только взаимные силы с градиентом величины по расстоянию.