Уважаю такой подход. Я однажды делал игру (другую), и в какой-то момент всё больше играл в неё, вместо того, чтоб доделывать, слишком увлекательно было.
Нет, я в этом деле совсем ничего не понимал, и взялся за первый вариант, попавшийся под руку, которым оказался compute shader под юнити. Я могу билдить в openGLCore, но почему-то оно не работает, тоже какое-то насовпадение API. Пытаюсь разобраться, хочется и под другие платыормы выпустить.
PhysX вроде бы заточен на размерные тела в 3д, взаимодействующие ударениями, а я сделал для точек в 2д, чтоб взаимодействовали полями. Так-то в Юнити есть физика, но десятки тысяч тел тормозят изрядно. А у меня к своему движку полный доступ, оптимизировал где мог, так что десятки тысяч частиц работают с пристойной скоростью.
Модульность танка я обдумываю. Сейчас пока есть прямая прокачка. Купил апгрейд двигателя — едет мощнее. Но новые разновидности танков понадобятся, так что скорее всего сделаю конструктор из универсальных деталей.
С летсплейщиками свяжусь когда кампания будет готова, чтобы им было во что поиграть. Пока только hot seat есть, это не так зрелищно.
Мультиплеер — в ближайших планах. Пока есть технические трудности, но вроде решаемые.
С трейлером пока непонятно, как поступать. Я его по сути собрал из гифок, которые привлекли внимание раньше на реддите. Почитаю что-нибудь на эту тему.
Там про CUDA написано; это всё применимо к случаю, когда шейдерный код компилится в directx или openCL?
Или вот вопрос, там говорится про int и float, а у меня компилятор говорит: чтоб быстрей считать, используйте uint вместо int. А в таблице этого различия не упомянуто, в чём может быть дело?
Я тоже собираю, все уровни так строятся, частицы размещаются в узлах шестиугольной решётки, чтоб сразу попасть в равновесие. А в первых экспериментах этого не делалось, частицы просто вбрасывались на уровень кучей. И там можно было наблюдать интересный эффект, как внутри тела существуют конкурирующие кристаллы с разным углом кристаллизации, и если нагревать эту материю, то одни области поглощаюд другие, распространяя на них свой порядок.
Да, именно такой способ оценки эффективности меня интересует. Спасибо, что поделились опытом сравнения интеграторов с этих позиций.
Насчёт неравномерного интегрирования я тоже думал, но есть ощущение, что выигрыш упразднится стоимостью вычислений, позволяющих исключить некоторые частицы из обсчёта. По этой дорожке луче идти до конца, и большую часть материи держать в виде полигональных коллайдеров, а там тоже всякие сложности возникают…
Если использовать формулу леннарда-джонса, то кривая потенциала пересекает точку равновесия под углом. А в случае приведённой вами формулы точка равновесия совпадает с пиком v-образной кривой. Вблизи пика кривая почти горизонтальна. Из-за чего возникает эдакий микро-люфт у точки равновесия. То есть, покоящаяся материя несколько расхлябана.
Уход кинетической энергии в нагрев, кстати, есть, я сейчас подумал. При обмене нормальной компонентой относительной скорости часть энергии гасится. Но вязкость у меня считается не для каждой пары достаточно близких частиц, а только если между ними возникает «связь». У каждой частицы есть аналог валентности. Связь может возникнуть с шестью частицами или меньше. Условия возникновения и разрыва связей зависят от типа физического материала. А если делать вязкость для всех частиц, вне зависимости от связей, то материя проявляет жидкостную динамику более, чем динамику твёрдого тела. Для песка или крошашегося бетона это не очень хорошо.
А определять, к чему относится частица — не накладно, там просто у меня есть две маски — гравитации и плотности. Они обновляются тоже через многопоточность, математика там тривиальная, так что считается быстро. Но пересечение эти масок позволяет выделить подмножества частиц, из которых можно отбирать избыток кинетической энергии, возникающий из-за ошибки большого шага, и в результате иметь больший коэффициент сил при большем шаге, то есть без оплаты производительностью.
Симуляция работает из-под Update(), а не из-под FixedUpdate(), то есть, у каждого со своей скоростью, которая зависит от производительности видеокарты. Поэтому, в любом случае при одновременной игре придётся ориентироваться на самого медленного игрока. Я на принципиальном уровне представляю, как это нужно организвать, чтобы всё работало синхронно, без пропусков. Но сетевого кода никогда не писал, так что подводных камней предвидеть — знаний не хватает.
Касательно интов — да, мне говорили, что видеокарты внутри себя всё во float считают, а инты будут медленней. При этом, существует ряд intrinsic atomic functions, которые пишут общие данные в защищённом режиме, так вот, эти функции существуют только для целы чисел, а для с плавающей точкой — нет. Странно.
А компилятор говорит, что вместо интов лучше использовать uint, потому что они быстрей. Так что сделаю на uint, всего вероятней. Потому что обработать граничные случаи, чтоб разные карточки не имели вольности можно, а вот если производительность потеряю, это будет хуже.
Но отзывы я почитал и управление мышью добавил, просто оно не включено по умолчанию, его в опциях надо ставить.
Модульность танка я обдумываю. Сейчас пока есть прямая прокачка. Купил апгрейд двигателя — едет мощнее. Но новые разновидности танков понадобятся, так что скорее всего сделаю конструктор из универсальных деталей.
С летсплейщиками свяжусь когда кампания будет готова, чтобы им было во что поиграть. Пока только hot seat есть, это не так зрелищно.
Мультиплеер — в ближайших планах. Пока есть технические трудности, но вроде решаемые.
С трейлером пока непонятно, как поступать. Я его по сути собрал из гифок, которые привлекли внимание раньше на реддите. Почитаю что-нибудь на эту тему.
Или вот вопрос, там говорится про int и float, а у меня компилятор говорит: чтоб быстрей считать, используйте uint вместо int. А в таблице этого различия не упомянуто, в чём может быть дело?
Насчёт неравномерного интегрирования я тоже думал, но есть ощущение, что выигрыш упразднится стоимостью вычислений, позволяющих исключить некоторые частицы из обсчёта. По этой дорожке луче идти до конца, и большую часть материи держать в виде полигональных коллайдеров, а там тоже всякие сложности возникают…
Уход кинетической энергии в нагрев, кстати, есть, я сейчас подумал. При обмене нормальной компонентой относительной скорости часть энергии гасится. Но вязкость у меня считается не для каждой пары достаточно близких частиц, а только если между ними возникает «связь». У каждой частицы есть аналог валентности. Связь может возникнуть с шестью частицами или меньше. Условия возникновения и разрыва связей зависят от типа физического материала. А если делать вязкость для всех частиц, вне зависимости от связей, то материя проявляет жидкостную динамику более, чем динамику твёрдого тела. Для песка или крошашегося бетона это не очень хорошо.
А определять, к чему относится частица — не накладно, там просто у меня есть две маски — гравитации и плотности. Они обновляются тоже через многопоточность, математика там тривиальная, так что считается быстро. Но пересечение эти масок позволяет выделить подмножества частиц, из которых можно отбирать избыток кинетической энергии, возникающий из-за ошибки большого шага, и в результате иметь больший коэффициент сил при большем шаге, то есть без оплаты производительностью.
Касательно интов — да, мне говорили, что видеокарты внутри себя всё во float считают, а инты будут медленней. При этом, существует ряд intrinsic atomic functions, которые пишут общие данные в защищённом режиме, так вот, эти функции существуют только для целы чисел, а для с плавающей точкой — нет. Странно.
А компилятор говорит, что вместо интов лучше использовать uint, потому что они быстрей. Так что сделаю на uint, всего вероятней. Потому что обработать граничные случаи, чтоб разные карточки не имели вольности можно, а вот если производительность потеряю, это будет хуже.