Стоит ли париться насчет многопоточности (типа рендер в главном потоке,

физика и еще что-нибудь в отдельном потоке) в петпроекте для изучения графона + for fun? В целом планирую делать все в одном потоке пока что, попутно подключая второй поток, если будут очевидные какие-то места для распараллеливания. Могу ли попасть позже на масштабное переписывания кода/другой гемор, если все же решу добавить многопоточность и вообще как часто юзаются и оправданы такие схемы, когда рендер в отдельном потоке, другие задачи в других?
петпроект: тридэ, вулкан.

я бы рекомендовал пул потоков с тасками

Тобишь, рендерим и фигачим все в одном потоке, и, если есть, что отдать на параллель - кормим пулу потоков и все, независимо от типа задачи и подсистемы (логика, физика, итдитп), верно понимаю?

зависит от того, что ты делаешь

вообще всё что можно на пуле потоков

пул должен быть умный и уметь в «широкие» таски

что значит широкие?

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

тогда не парься и делай в один поток

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

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

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

Ну это самый простой вариант. Пока один поток считает логику для текущего кадра, другой - рисует предыдущий.

про память незабываем

в идеале, при полном распараллеливании update и render, первый должен непрерывно с фиксированной частотой (30 раз в сек например), генерировать полный стейт объектов сцены. Рендер тред будет выбирать два последних и интерполировать все поля (позицию, поворот и прочие параметры) между ними по текущему времени. Тогда render и update будут полностью независимы и никто никого ждать не будет. Плюс сам рендер тоже хорошо параллелится на CPU, например заполнение command buffer'ов для depth pre-pass, occlusion test, shadow pass, gbuffer pass, particles и transparent pass. Также можно подумать о GPU распараллеливании на async-compute очереди, например SSAO (tex fetch bound) можно запускать сразу после depth pre-pass, с чем-нибудь что упирается в ALU. Ещё можно подумать про async-present, это когда compute очередь работает параллельно с graphics очередью следующего кадра. Это например, позволит распараллелить постпроцессинг предыдущего кадра с depth prepass и gbuffer pass текущего. В идеале, чтобы всё это щупать и видеть разницу, у тебя должен быть достаточно "богатый" движок с тяжёлой игровой логикой и кучей пассов, а не просто спонза с парой шейдеров.

Моя твоя понимать, взято на заметку

А когда объект телепортируется? Флаг весить на это?

up to you