астрономия и нейросети

[yacc]

Вы правы, для больших задач необходимы параллельные вычисления, на что интерпретатор Питона в принципе не  способен, или ползает со страшными костылями. Тут только C++ или Object Pascal (в коробке Delphi есть модуль Threads.Parallel.Library на ядрах, не считая Cuda/OpenCL на GPU), Фортран идёт лесом.

Современный Фортран-компилятор великолепно все распараллеливает.
Современный питон с нужными утилитами тупо вычислительную функцию транслирует в С и ровно также запускает - наглядно в аттаче.

Меня порой поражает наивный взгляд на языки программирования.
Джун читает "передовицы" и "спеки" и сравнивает "фичи" - типа - у языка А есть нативно OpenMP, у языка Б - нет. Значит А - рулез, Б - сакс.
Программист поопытнее понимает, что далеко не все алгоритмы хорошо формализуются в параллельные алгоритмы, а вообще чтобы параллельные алгоритмы писать надо хотя бы матчасть посмотреть - книжки профильные изучить ( именно по параллельным алгоритмам ), попробовать, а не просто декларировать на уровне "фич" -  чего джуну будет откровенно влом.
Опять же более опытный программист не болеет монотеизмом в отношении языков программирования ( хотя бывают исключения, в особенности у самоучек, а не профильных выпускников мат. обеспечения  ), он прекрасно знает, что математические формулы в целом достаточно просты для программирования и практически любое математическое выражение можно транслировать в С практически с любого языка программирования - хоть с Фортрана, хоть с Лиспа, хоть с Питона или MathLab. Поэтому задача вполне ясная - код, который надо распараллелить надо просто отдать утилитам, которые ее переведут в С, скомпилируют и свяжут с Питоном.
Т.е. числодробилку можно смело писать на том же питоне, а фреймворк за сценой сделает так, чтобы он работал быстро.
Например OMP4Py

И все!

[crimchik]

Solar Orbital Simulator — Отчет по завершению Этапа 2

Мы завершили основной объем работ по Этапу 2, превратив плоский 2D-прототип в высокотехнологичный 3D-инструмент для научных расчетов.

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


🚀 Реализованные функции и улучшения

• 3D Визуализация (Qt 3D):
  
  • Полный переход от QGraphicsView к аппаратно-ускоренному 3D-движку.
  • Реализована система освещения: Солнце как точечный источник света (QPointLight), создающий реалистичные тени на планетах.
  • Интерактивная камера (QOrbitCameraController) с управлением через мышь и дублирующими кнопками в интерфейсе.
• Научное ядро (Advanced Physics):
  
  • 3D Математика: Переход на трехмерные векторы состояния (X, Y, Z).
  • RK4 (Runge-Kutta 4): Внедрен высокоточный интегратор 4-го порядка, обеспечивающий профессиональную точность траекторий.
  • General Relativity (GR): Реализованы релятивистские поправки первого пост-ньютоновского приближения, позволяющие моделировать прецессию орбит.
• Интерфейс и Интерактивность:
  
  • Raycasting (Picking): Реализована возможность выбора объектов кликом мыши в 3D пространстве.
  • Object Inspector: Боковая панель («Инспектор»), выводящая массу, скорость, дистанцию и координаты выбранного тела в реальном времени.
  • Визуальные помощники: Добавлена полярная координатная сетка (кольца дистанции в АЕ) и динамические подписи планет (Billboards), всегда развернутые к пользователю.
  • Управление видимостью: Добавлены переключатели для мгновенного скрытия/показа траекторий и названий.

🏗 Состояние кодовой базы (Архитектурный анализ)

Код прошел глубокий рефакторинг и соответствует стандартам Modern C++ (C++17):

• Инкапсуляция: Логика физического расчета (PhysicsEngine), визуальных треков (OrbitTrail) и вспомогательной сетки (OrbitGrid) вынесена в отдельные модули, что упрощает поддержку.
• Безопасность ресурсов (RAII): Управление 3D-сущностями переведено на безопасный механизм Qt (deleteLater()), что исключает краши при сбросе сцены или загрузке файлов.
• Связность: Интерфейс (MainWindow) и ядро (PhysicsEngine) взаимодействуют через механизм сигналов и слотов, сохраняя архитектурную чистоту (Decoupling).

⚡ Произведенные оптимизации

В рамках Этапа 2 мы уделили особое внимание производительности, чтобы программа могла работать с большими наборами данных:

• Многопоточность (OpenMP): Главный цикл расчета гравитации распараллелен. Теперь вычисления распределяются на все доступные ядра процессора, что дает ускорение до 400-800% на современных CPU.
• Zero-Allocation Physics: Мы устранили постоянные аллокации памяти в физическом цикле. Внедрена система преаллоцированных буферов для RK4 и Verlet, что минимизирует нагрузку на сборщик памяти и кэш-промахи.
• Geometry Batching (Сетка): Сетка орбит генерируется один раз и хранится в видеопамяти как статический буфер линий, не нагружая процессор при отрисовке.
• Trail Skipping: Обновление траекторий оптимизировано — новые точки добавляются не каждый кадр, а с заданным интервалом, что снижает нагрузку на шину PCI-E между CPU и GPU.

✅ Итоговое заключение

Проект Solar Orbital Simulator успешно прошел этап технологического усложнения. На текущий момент:

• Математическая точность соответствует научным стандартам.
• Техническая реализация стабильна и оптимизирована.
• Интерфейс удобен для навигации в 3D.

За исключением чисто декоративной части (текстуры планет и Skybox), Этап 2 полностью завершен.

Подтверждаю: проект архитектурно и функционально готов к переходу на Этап 3 (Дополнения и финальные оптимизации). 🚀



Компилированный exe файл со всеми библиотеками https://disk.yandex.ru/d/T39sWV3_reHw1w
исходники в архиве в аттаче

[crimchik]

Теперь приглашаю всех протестировать, чтобы можно было ловить баги

[crimchik]

Заметил, что даже при таком минимальном количестве у меня загрузка процессора на 100% . попросил сетку объяснить этот момент

[Ph_user]

По основному смыслу нужной науки - научный симулятор должен научно предсказывать будущее. Потому крутить в симуляторе стабильные системы мало смысла.

Оверофигительная скорость математики симулятору нужна чтобы можно было вместо реальности 60фпс предсказывать будущее системы на овермного времени вперед. Потому в програме должна быть ось времени с указанием в какое будущее хочет посмотреть хозяин. Или хотя бы окно для ввода одного значения времени из будущего под осмотр. И програма должна разумно нарезать все взаимодействия имени дедушки ньютона на куски чтобы смочь показать будущее за разумное время без существеных косяков от алайзинга во времени во всяких периодических системах.

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

И разница в производительности типа у фуфловой програмы можно только моделировать звезду с одной планетой с ускорением времени в 100 раз. Ну для нарушения стабильности бросить туда еще один камень с десяток планет весом снаружи чтобы встал на орбиту.

А в чотко пацанской програме с годным мультитредингом и симдом можно за вечер просмотреть столкновение пары галактик с ускорением времени в милион-милиард раз.

Пока что видно по мультитредности - опенмп наложен на каждый мелкий луп. https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L54
А надо каждому потоку вырезать большой кусок полной задачи с синхронизацией всех потоков только в конце шага.

Что видно по симду - нифига. А надо по симду - сделать 3 переключаемых по выбору в настройках и с автовыбором наилучшей доступной или ограничения до выбраной пользователем архитектуры исполнения на симд сопроцесорах от ссе128 до авх512.
Для перевода на полную ширину симда +суперскалярность математики типа https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L56 продумать перевод всей информации програмы с аос на соа. Иначе толку от симда будет весьма ограниченое количество при сборке части параметров под математику в симд слово и потом разборку обратно.
Робот должен оценить все варианты переборки структуры информации програмы по максимуму скорости с учетом замедления сборки байтов в симд слова из соа где надо делать математику по 3 компонентам сразу типа в https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L147

Иметь возможность вместо дабл деления пользовать умножение на примерное обратное симд (опция в настройках програмы). Типа в https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L156 . Это понижает точность счета но увеличивает скорость.
Тоже самое про квадратный корень где нужен - типа в https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L153.

Чтобы годно симдить науку - робот должен вынести методы из внешних либ в свою програму. Типа https://github.com/fortser/solar_cplus/blob/4ff86f9fa5130ff84193ba66d20d74b5f9c935bc/src/core/PhysicsEngine.h#L159

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

[crimchik]

Попросил сетку сгенерировать систему из 3 звезд, приблизительно напоминающих своими масштабами и комплектом солнечную систему .
получилось вот такое моделирование, здесь на видео видно сближение звезд, вокруг которых вращаются планеты  https://disk.yandex.ru/i/IALlkbc3r6LOzA

В аттаче приложен файл с начальными координатами, которые нужно загрузить в программу для начала моделирования системы из этих 3 звезд

[jaker]

Теперь приглашаю всех протестировать

1 Zoom бы сделать посильнее , а то надо крутить колесико мыши минуту чтобы увидеть дальние планеты или  долго нажимать + -
2 После нажатия Reset Logic названия пропадают
3 При зуммировании названия уменьшаются до нуля

[Ph_user]

Zoom бы сделать посильнее

Зум в космосе может надо логарифмический делать. И остальные изменения положения камеры и угла обзора. И еще надо делать поля для показа значений положения камеры и направления и угла обзора и возможность туда рукопашных вводов.

Еще для внушающих мувиков может быть полезно добавлять много разных авторежимов камеры - типа вместо внешней камеры привязывать камеру к одной из симулируемых вещей с разными автовекторами направления - от на системую звезду или на другую вещь или на условный полюс вселеной и др. Чтобы можно было посмотреть-записать вид с телескопа на симулируемой планете во времени. Т.к. симуляция физики и сетап3д весьма сложные и рендер готовой 3д сцены намного проще - можно пробовать делать многооконый вывод. Типа в одном окне вид общей камеры для понимания че как там полетело - в другом окне вид с камеры на одной из летящих вещей и др. При столкновении трех звездных систем можно одновремено смотреть общий разлет и вид системной звезды с одной из планет улетающей наружу из системы и др.

Практически надо сказать роботу делать многооконое приложение с набираемым перед началом симуляции нужным набором окон 3д рендера и разными режимами камеры для каждого 3д вида.

Файлик 3body_v2.rar  скачивает 24байта и архиватор выдает ошибку распаковки.

Для теста скорости симуляции можно пробовать просто режим вызова степинга без остановки и без отправки на 3дрендер если он так тормозит. И показ в окне вывода текста скорость симуляции в исполненых шагах за секунду. И для сравнительных тестов скорости симуляции на разных счетно-решающих машинах надо будет заготовить файлики начальной задачи на вмеру приличное количество вещей чтобы размер задачи влезал в л1/л2/л3 кеши или требовал перегрузки больше половины задачи через шину хострамы. Итого надо порядка 4..5 разных наборов входных параметров - типа на л1 и л2 кеши (32кбайт и 1 (0.25.. 5 ?) мегабайт) и на какой-нить 10 и 100 мегабайт (ну до 1000) чтобы точно было больше кешей многих машин (ну кроме амд х3д и зионов макс).

При годном распаралелении счета еще и на симд сопроцесор и оптимизации размеров задач порядка л2 кеша и больше по перемещению в подсистеме памяти машины - скорость симуляции должна быть во много раз больше скалярной версии для каждого потока.

[crimchik]

да, все пожелания записал
заново прикладываю файл

[crimchik]

если кто хочет попробовать смоделировать собственную систему, то в любой приличной генеративной модели надо дать 3 этих последовательных запроса :

Проанализируй эти данные в формате Джейсон для программы симулятора солнечной системы . определи структуру, формат файла для хранения данных , определи и пойми суть данных, которые сохраняются в этом формате . в дальнейшем ты должен будешь мне в этом формате выдавать нужные мне ситуации для моделирования звездных систем . подтверди, что правильно все понял, после чем мы перейдем к работе .
[полное содержимое файла]

-----------

хорошо, сейчас я хочу смоделировать систему из 3 звезд. солнце находится своей фиксированной точки в начале системы координат . 2 другие звезды представляют вместе с солнцем равносторонний треугольник , со стороной равной 2 расстоянием от солнца до Нептуна .
самостоятельно придумай название для новых звезд , их масса составляет случайное число в диапазоне [0.4 ; 3] от массы Солнце. начальный вектор движения задай самостоятельно на основании твоего представления о звездной системе из 3 тел .
у каждой звезды есть от 4 до 8 собственных планет  . их параметры примерно соответствует распределению  планет солнечной системе . так что название и цвет ты придумай самостоятельно, все параметры дай в нужном мне формате .


--------


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


-----------

полученный файл json можно загружать в симулятор
в аттаче базовая конфигурация солнечной системы, на основании которой я делал при помощи сетки профили других звездных систем по этим запросам

[crimchik]

Простая двойная система, где после стабилизации планета Areson (красный цвет) интересно поочередно переходит с орбиты одной звезды на орбиту другой

[Ph_user]

Еще роботу надо заказать написать програму для космической радиосвязи с програмным синтезом фазированых антеных решеток обработкой принятых джоулей-чисел от набора приемников.

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

Можно даже радиомодулем космической связи к этому симулятору - на одной из планет системы работает передатчик координат и на другой в наличии 1 или больше приемников на карманах у планетян. При разлете планет на годное удаление 1 приемник теряет возможность приема с правильной контрольной сумой. Надо написать програму для обработки принятых чисел с больше 1 приемника чтобы увеличить дальность приема координат в космосе. В радиосвязном симуляторе должны быть поля для показа реальных координат и принятых приемником и значение сигнал-шума на выходе приемной антены приемника. Должно быть возможно задавать количество приемников у принимающих напланетян. Кнд передающей и приемной антен всех радиомодемов в симуляторе считать 0 дби. Модуляцию можно какую-нить вмеру простую типа бпск или купск. Скорость передачи передатчиком - один комплект из 3 координат в секунду. Синхронизации времени с передатчиком предполагать нету - приемники должны произвести поиск начала передаваемых символов по оси времени при сигнал-шуме меньше 1. Координаты подписаны каким-нить простой подписью типа црц или поприличнее чтобы выдать флаг наличия приема точно.

[Павел Васильев]

если кто хочет попробовать смоделировать собственную систему, то в любой приличной генеративной модели надо дать 3 этих последовательных запроса

А зачем? ИИ генерат должен сам это делать по имеющимся звёздным каталогам и последним файлам csv экзопланет. Если он их не в состоянии сам найти самостоятельно, дайте ему ссылку на базу Hyg ближайших к Солнцу 120 тысяч звёзд и открытых экзопланет  на сайте JPL.  Это будет практически полезней.

[crimchik]

Перевожу проект на видеокарту, чтобы можно было моделировать столкновение галактик . пока работает по упрощенной физике и всего по 20000 звезд в галактике
вот видео столкновения https://disk.yandex.ru/i/f95Qkmj_zBqFdQ . дальше пока не записывал, потому что очень долго приходится ждать, пока звезды начнут собираться обратно

[Ph_user]

потому что очень долго приходится ждать, пока звезды начнут собираться обратно

Вот потому и нужно ускорение вычислений. И полезно даже с регулируемой скоростью чтобы можно было подробнее просмотреть интересные места симуляции на малой скорости и пропустить мало интересные на большой скорости но без потери точности.

[crimchik]

Доделал mvp для моделирования галактик и моделирования столкновение 2 галактик . реализовал управление скоростью моделирования без потери точности расчетов
здесь можно скачать скомпилированный проект https://disk.yandex.ru/d/oNEri1MHvccbtQ
исходники в аттаче

до сих пор не удается перенести все расчеты на видеокарту , поэтому количество звезд в галактиках ограничено до 200000 . расчет идет на всех ядрах процессора, отображение идет через видеокарту

[crimchik]

ОТЧЕТ О РЕАЛИЗАЦИИ: Galaxy Simulator v3.0

Дата: 17 декабря 2025 г.
Версия: 3.0 (Collision Edition)
Статус: Стабильная работа (Release Candidate)


1. Ключевые достижения

🚀 Архитектура и Производительность

• Переход на гибридную модель:
  
  • Рендеринг: Полностью на GPU (OpenGL Core Profile 3.3/4.3). Используется Qt3D + кастомный QGeometryRenderer для отрисовки до 50 000 частиц как GL_POINTS.
  • Физика: Реализована на CPU с использованием OpenMP. Это позволило обойти ограничения и сложность Compute Shaders в Qt3D, сохранив при этом высокую производительность (60 FPS на 20k частиц).
• Решение проблемы "Черного экрана":
  
  • Успешно диагностирована и устранена проблема с отсечением геометрии (Frustum Culling) через явное задание атрибутов для Bounding Volume и корректную настройку QFilterKey в материалах.
  • Решена проблема с видимостью точек через использование gl_PointSize в шейдере и корректную передачу матрицы modelViewProjection.

🌌 Физика и Астрономия

• Алгоритм Барнса-Хата (Barnes-Hut):
  
  • Внедрен алгоритм пространственного разбиения (Octree) для расчета гравитации O(N log N). Теперь звезды взаимодействуют друг с другом (самогравитация), а не только вращаются вокруг центра.
• Реалистичная модель Галактики:
  
  • Используется суперпозиция трех потенциалов:
    
    • Балдж: Сфера Пламмера.
    • Диск: Потенциал Миямото-Нагаи.
    • Гало (Темная материя): Логарифмический потенциал.
  • Реализована калибровка начальных скоростей (коэффициент 0.5f), обеспечивающая стабильное вращение диска без "взрыва" или коллапса (Virial Equilibrium).
• Моделирование Столкновений:
  
  • Реализована логика взаимодействия N тел (галактик) с подвижными центрами масс.
  • Возможность задавать параметры столкновения: расстояние, количество звезд, радиусы для каждой галактики отдельно.

🖥️ Интерфейс (UI/UX)

• Панель управления:
  
  • Раздельные настройки для Галактики А и Галактики Б (количество звезд, радиус).
  • Слайдер дистанции с числовым отображением.
  • Слайдер скорости времени (Time Warp) с поддержкой sub-stepping (сохранение точности при ускорении).
• Визуализация:
  
  • Шейдеры рисуют красивые "мягкие" звезды с эффектом свечения и перспективы (размер зависит от удаленности).
  • Добавлен HaloRenderer: полупрозрачные сферы, показывающие границы гравитационного влияния (гало темной материи).

2. Технические детали реализации

Компонент	Технология	Описание
Рендеринг	OpenGL 3.3 Core	ParticleRenderer.h: Прямая работа с QBuffer, кастомные Vertex/Fragment шейдеры.
Физика	C++17 + OpenMP	GalaxyPhysics.h: Параллельный расчет сил. Интегратор Euler-Cromer.
Гравитация	Barnes-Hut Tree	BarnesHut.h: Оптимизированное дерево с пулом памяти (без аллокаций в цикле).
Генерация	C++ Random	GalaxyGenerator.h: Гамма-распределение для плотности, учет кривых вращения.
Сборка	CMake + VCPKG	Автоматическое развертывание зависимостей Qt6 и OpenMP.

3. Известные ограничения и План (Next Steps)

• Лимит частиц:
  
  • Текущий комфортный предел на i5: ~30 000 - 50 000 звезд (из-за сложности O(N log N) Барнса-Хата).
  • Решение в будущем: Возврат к попытке реализации Compute Shaders на чистом OpenGL (без Qt3D FrameGraph) для достижения 1M+ частиц.
• Визуальные эффекты:
  
  • Отсутствует эффект Bloom (свечение ярких областей).
  • План: Реализовать Post-Processing эффект в будущем.

Скачать можно тут https://disk.yandex.ru/d/sqqjdkd058dm2Q
исходники в аттаче

[crimchik]

оправдания сетки, почему проект до сих пор не на видеокарте 

ОТЧЕТ О ТЕХНИЧЕСКИХ ПРЕПЯТСТВИЯХ ПРИ ПЕРЕХОДЕ НА ПОЛНОСТЬЮ GPU-ОРИЕНТИРОВАННУЮ АРХИТЕКТУРУ

Введение

Изначальной целью проекта было создание симулятора, в котором и визуализация, и физические расчеты (движение звезд) выполняются исключительно на видеокарте (GPU). Это позволило бы моделировать миллионы частиц. На текущий момент (версия 3.0) мы достигли гибридной модели: рендеринг выполняется на GPU, а физика — на CPU. Ниже приведен детальный анализ причин, почему полный перенос физики на видеокарту через Compute Shaders в среде Qt3D оказался нецелесообразным на данном этапе.


1. Успешно решенные задачи по GPU

Нам удалось перенести на видеокарту самую тяжелую часть — визуализацию.

• Отказ от QEntity/QSphereMesh: Мы перестали создавать объекты для каждой звезды, что убивало производительность.
• Реализация ParticleRenderer: Мы научились упаковывать данные (позиция, цвет) в сырой байтовый массив (QBuffer) и отправлять его в видеопамять (VBO).
• Кастомные шейдеры: Мы написали GLSL-программы для Vertex и Fragment этапов, которые рисуют красивые звезды из простых точек (GL_POINTS).
• Проблема "Черного экрана": Была успешно решена через корректную настройку Bounding Volume (границ объекта) и QFilterKey, из-за отсутствия которых Qt3D отсекал геометрию.

2. Сложности с Compute Shaders (Физика на GPU)

Попытка перенести расчет гравитации на GPU столкнулась с архитектурными ограничениями фреймворка Qt3D.

Проблема А: Архитектура FrameGraph
В Qt3D нельзя просто запустить вычислительный шейдер "в фоне". Он должен быть частью Графа Отрисовки (FrameGraph).

• Мы пытались создать кастомный ComputeFrameGraph, внедряя узел QDispatchCompute перед отрисовкой.
• Сложность: Qt3DExtras::Qt3DWindow имеет свой жестко заданный граф. Замена его на кастомный приводила к потере очистки экрана, проблемам с камерой и инициализацией контекста OpenGL.
• Результат: Мы либо получали черный экран (шейдер не запускался), либо краш приложения при попытке вмешаться в стандартный цикл рендеринга.

Проблема Б: Передача параметров (Uniforms)
Физике нужны параметры: DeltaTime, G, Массы ядер.

• В C++ мы привыкли передавать аргументы в функции. В Qt3D параметры передаются через иерархию компонентов QParameter.
• Мы столкнулись с тем, что QComputeCommand в Qt6 не имеет прямых методов для установки параметров (addParameter), как это было в некоторых примерах Qt5 или как это логически ожидалось.
• Попытка привязать параметры к Материалу или Сущности не давала результата — шейдер их "не видел", так как QDispatchCompute в графе отрисовки изолирован от сцены сущностей.

Проблема В: Синхронизация памяти (Memory Barriers)

• Вычислительный шейдер пишет в буфер, а Вершинный шейдер читает из него.
• Если не поставить правильный барьер (QMemoryBarrier), видеокарта начинает рисовать кадр до того, как физика закончила расчет. Это вызывает мерцание и артефакты.
• Настройка барьеров в Qt3D крайне запутана (различия в именовании флагов IndexBuffer/ElementArrayBuffer в разных версиях Qt6), что приводило к ошибкам компиляции.

3. Почему мы выбрали откат на CPU (Barnes-Hut)

Вместо того чтобы тратить недели на отладку черного ящика Qt3D, мы реализовали алгоритм Барнса-Хата на процессоре.

Преимущества этого решения:

• Полный контроль: Мы точно знаем, как считается физика, и можем легко менять формулы (добавлять гало, трение, столкновения).
• Отладка: Мы можем вывести в консоль координаты любой звезды, если она улетела. На GPU это невозможно без специальных инструментов.
• Скорость разработки: Мы реализовали сложную научную модель (Ядра + Диски + Гало) за пару часов. На шейдерах это заняло бы дни.
• Достаточная производительность: Использование OpenMP позволило задействовать все ядра i5, обеспечив плавную работу с 50 000 - 100 000 частиц, что достаточно для научных целей.

4. Приоритетный список причин отказа от GPU-физики
(от важных к второстепенным)

• Ограничения архитектуры Qt3D: Фреймворк Qt3D спроектирован преимущественно для рендеринга сцен, а не для вычислений общего назначения (GPGPU). Интеграция Compute Shaders требует сложного переписывания FrameGraph, что ломает стандартный функционал окна.
• Отсутствие документации и примеров: Рабочих примеров использования QDispatchCompute и QComputeCommand для Qt 6.x практически нет. API менялся, и старые методы перестали работать, вызывая ошибки компиляции.
• Сложность отладки: Когда Compute Shader падает или работает неправильно (звезды исчезают), видеокарта не выдает ошибок. Мы видели просто черный экран, не понимая, где проблема — в загрузке данных, в запуске шейдера или в барьерах памяти.
• Научная гибкость: Реализовать алгоритм Барнса-Хата (дерево Octree) на GPU крайне сложно (требует стека и рекурсии, которые GPU не любят). На CPU это делается легко и позволяет моделировать реальную самогравитацию, а не просто вращение по формуле.

Итог:
Мы пожертвовали количеством звезд (снизили с 1 млн до 100 тыс.), но выиграли в качестве физики (реальное взаимодействие) и стабильности работы приложения.

[Ph_user]

Ну так пусть пробует добавить компут шейдеры на директ иксе. Там тоже в наличии директ компут. Пример компута через шейдеры директ икса (12) можно показать роботу в одном файлике https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/Sources/MVAnalyse.cpp . Но лучше чтобы начиная от вин7 работало на директ иксе 11 или меньше.

Если там кут такой ограниченый по реальным нужным вычислениям. Шейдеру кидают и исходные наборы чисел как текстуры (буфера 1-2-3 и др мерные) и шейдер сам выбирает какие числа с какими считать через сепмлинг текстур и дает результат в выходную текстуру (буфер).

В цпу физике все еще нету симда и потому на скалярном фпу оно тормозит в лишние разы. Под симд надо проверить совместимость типа 3д вектора Eigen::Vector3d с загрузкой в симд сопроцесор. При плохой совместимости и потенциально для удобства кратности 4 - завести свой отдельный тип 3+1д вектора (4флоата 32битных) для вычислений симд сопроцесором по 1 целому вектору на 128битах ссе и по 2 и 4 вектора паралельно на авх256 и авх512 архитектурах. Реализации физики и остальной математики делать в отдельных файликах _sse.c _avx.c _avx512.c для возможности компиляции разными компиляторами могущими только до заданой архитектуры (выбор файлов на сборку - в симейке). 

Пример вмеру простого проекта с авто и рукопашным выбором симд архитектуры и разбиением исходников функций по архитектурам в разные файлики для анализа роботом как можно делать - https://github.com/jpsdr/JincResizeMT

и позволяет моделировать реальную самогравитацию, а не просто вращение по формуле.

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

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

Код: [Выделить]

    QString name;
    double mass;       
    double radius;     
    QColor color;

    // Векторы состояния теперь 3D (x, y, z)
    Eigen::Vector3d position;     
    Eigen::Vector3d velocity;     
и оно должно полететь как галактика и без столкновений еще.

Реализовать алгоритм Барнса-Хата (дерево Octree) на GPU крайне сложно (требует стека и рекурсии, которые GPU не любят). На CPU это делается легко

Цпу взрослым дядям и делают с симд сопроцесором чтобы там математику с логикой считать быстрее. Более чем на скалярном фпу сопроцесоре уже примерно с пентиума 3 с первым ссе128 на 4 флоата (или 2 дабла). А к концу 2половины 21 века стандартный симд у малоимущих то авх256бит и у научников куча вариантов авх512.

пожертвовали количеством звезд (снизили с 1 млн до 100 тыс.),

Роботы гугля пишут про месный космос - Количество звёзд в разных галактиках варьируется: в гигантских эллиптических галактиках может быть до 100 триллионов звёзд, а в карликовых — около 30 миллиардов. Пока че-то слабовато.

[crimchik]

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

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

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

Да, для небольшого количества объектов, типа моделирования солнечной системы именно такой подход использовался . просчитывались взаимодействия каждого объекта с каждым оставшимся (то есть сложность расчетов n^2). при таком подходе у меня процессор тянет до 30000 объектов. то есть я могу загрузить начальное состояние всех 30000 коней в вакууме и программа для них рассчитает идеальную траекторию .
но я прошу увеличить количество объектов хотя бы до 1.000.000 и вынести расчеты на видеокарту на куда ядра. и тут как раз начинаются все эти пляски с бубнами, которые описаны чуть выше. 
да , завтра попробую попробуй скормить сетке предложенные вами примеры.