Обновить

Комментарии 39

Простой и увлечённый технический пост о переносе математической симуляции с Python на C++ для получения высокой частоты кадров при просчёте большого количества объектов. Автору респект, молодца!

Проект шикарный, одно замечание -- вы в гитхабе в репозиторий закинули ярлыки, аа не конфиги)

Спасибо за замечание:) Я заметил, но там на всякий случай конфиги автоматом в bin рядом с exe появляются, если их нет. Но думаю действительно стоит добавить, чтобы не было путаницы.

Добавьте сразу нормальный .gitignore, чтоб бинарники и ярлыки больше не летели в репу)

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

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

Мне очень приятно, что кого-то это вдохновило! Не могли бы вы поделиться, что за фэнтези рассказ, если это не секрет? Очень интересно было бы:)

Я думаю дальнейшее понятно. Где то там в мини-вселенной есть программист, который пишет свою микро-вселенную, а в той потом появится программист, который создаст кроха-вселенную...

Ну тогда согласно теории Ника Бострома нас тоже кто-то довольно таки активно симулирует вместе со всеми физическими законами, числами пи, блекджеками и прочими распутными девами.)

Найти бы этого двоечника

нас тоже кто-то довольно таки активно симулирует

Так это почти доказано... :)
https://erichware.name/mysli/simulator.htm

"ТВОЙ БЫДЛОКОД НАС ОГОРЧАЕТ" (c)

Да неплохо получилось же. Народ балансом ещё немного поработать.

Это отсылка к рассказу неизвестного (по крайней мере мне) автора. Если не читали, нагуглите, не разочаруетесь.

Тоже сразу про это подумал. :-)

Главное чтобы этот микро-программист не начал майнить крипту в своей мини-вселенной, иначе наш хост просто сгорит от перегрева)

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

Есть честные O(n log n) методы для просчета гравитации. Например Barnes-Hut. Там, конечно, тоже есть неточности, но не настолько ужасные. Там тоже использутеся сетка, но все далекие объекты в далеких ячейках групперуются и заменяются точечной массой и все-таки учитываются хотя бы аггрегированно.

Если же к этой идее приложить еще и жесткую математику, то получается O(n) метод для просчета гравитации глобально (fast multipole method). В отличии от вашего хака, там есть далекое взаимодействие и точность можно приближать сколь угодно близко к идеальной.

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

Тогда вам стоит отредактировать статью. Пока выглядит, как будто вы код в 1000 раз соптимизировали, а по факту всего в 2-3 раза (ускорив в 1000 только 2 из 3 правил).

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

О! Игра "жизнь" уже не та. Респект автору, красиво получилось.

Вспомнилась старая книжка "Этюды для программистов". Там в том числе описывалось моделирование гравитационного взаимодействия большого числа звёзд на слабых компах. Чем-то сиё напомнило.

Как думаете, стоит ли прочесть данную книгу?🤔

Да. Она старая, проблемы местами уже решены (всё-таки в компах уже не десятки кб памяти, к примеру), но читать было интересно.

Хорошо, я обязательно найду время, чтобы прочесть её, вы меня заинтересовали.

Нашел-таки. Книга называется "Жемчужины программирования".
https://publ.lib.ru/ARCHIVES/B/‘‘Biblioteka_programmista’’_(seriya)/%c1%e5%ed%f2%eb%e8%20%c4%e6._%20%c6%e5%ec%f7%f3%e6%e8%ed%fb%20%ef%f0%ee%e3%f0%e0%ec%ec%e8%f0%ee%e2%e0%ed%e8%ff.(2002).pdf

Судя по всему, читал ещё первое издание.

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

О, да, это классная тема. Но там, как и везде свои нюансы, которые надо изучать. Я думал перенести некоторые расчёты на видюху, но у меня почему-то не устанавливалась Cuda от Nvidia. Пробовал распаралелить на ядра процессора, особо ничего не изменилось, скорее всего я что-то не так делал, но я не знаю что именно.

Да не, в этой задаче все просто. Если уж тут все взаимодействия происходят парочками, то можно и все импульсы считать независимо. И потом их все применить к скоростям. Надо только их аккуратно аггрегировать. Тут достаточно atomic<double> v_x; v_x += imp_x; использовать.

Спасибо за совет!) Попробую так сделать. И можно будет потом распределить попробовать снова по потокам.

А Большой Взрыв там будет? Черные дыры? Аттракторы? Хотя бы схематично. А так глядишь кто-то из ученых найдет этот проект и придумает гениальную гипотезу, которая обьясняет вот прям всё! Маловероятно конечно, ну а вдруг.

Кто знает, кто знает;) Я конечно себе всё это в голове изначально и представлял, но очень непросто оказалось такое сделать. Например даже если просто сделать тор-образное пространство, уже будет надо очень много чего пересмотреть: гравитацию, пространственную сетку, визуализацию.

Посмотрите в сторону игрушки powder toy. Там и гравитация (в тч черные дыры) и взаимодействие 100500 частиц, взрывчатка, песок, ветер и даже атомный взрыв с некоторой условностью можно сделать. Физика там конечно довольно своеобразна но это детали. Советую также обратить внимание на механизм встроенного в игру захвата экрана, неважно с какой скоростью все эмулируется но игра генерирует один кадр за проход и сохраняет его в изображение. Затем это можно с "нормальной" скоростью преобразовать в видео и просто посмотреть видеоролик, как оно там что происходит.

Теперь смотрите в сторону CUDA. :)

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

building_foundation_for_future_nanite_like_tech/

Создал пустую вселенную на листке бумаги - познал дзен.

Какая скорость в итоге

вы показали кстати! 1000-5000, дальше можно отвязаться от stl(vector, hashmap) и попытаться наколбасить своё управление памятью.... я может не прав, но со своим аллокатором(который связан интрузивно с кор подсистемой памяти будет) и подсчетом байт удобнее чем с вектором, но отлаживать гемор(хотя кому как наверно), попробуйте посмотреть в сторону интрузивных счетчиков ссылок, как итог ваши буферы станут чуточку удобнее и тесты можно будет проводить на 10к-100к(тоесть в 3д уходить наверно не знаю в обьём(кубики или другие примитивы, тут я не знаю, но там тоже есть SpatialHashGrid/SpatialGrid/BVH(за счет того что ваши частички вроде не уникальны это можно будет отрисовывать через MultiDrawElementsIndirect закидывая матрицы в ssbo, за 1 вызов типо считайте сами какой прирост...) или еще что поидее)) наверно, плюс можно на С++ наколбасить свой модуль по SIMD(берете спецификацию файла симд по 4.1/4.2 и пишите бинды свои! в модуле именно в модуле .cppm), плавно переходящий в свои расчеты типо.... всё это конечно гемор....

ну и так по мелочи модули(именно модули .cppm). конечно, на любителя, на алгоритмы я последнее время в последнюю очередь смотрю, щас приоритет на архитектуру с кор системы...

Скрытый текст

у меня щас так выглядит все .cppm это модули, и скрипт свой на сборку проекта

Спасибо большое, что делитесь ценным опытом! Он очень мне пригодится, как во время улучшения этого проекта, так и в будущем:)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации