Народ, я тут обдумываю игровой движок идея которого будет заключаться

инкрементальности - а именно в том чтобы делать только небольшие инкрементальные вичисления между экранными кадрами (фреймами). Если проанализировать как один кадр отличается от другого то обычно это 1) небольшой поворот камеры 2) небольшой зум камеры 3) небольшое движение камеры по сцене 4) небольшое движение объектов сцены (включая источники освещения) на определенную дельту.
И идея заключается в том чтобы не вичислять заново все пиксели (то есть не рендерить всю сцену заново) а вычислять только то что изменилось. Например игрок редко потает камеру слишком резко и получится так что за 16мс произойдет поворот камеры лишь на некоторый угол при котором мы можем переиспользовать пиксели от предыдущего кадра плюс дорендерить ту новую полоску новых пикселей которые появились при повороте камеры. С зумом ситуация чуть иначе - при уменьшении зума мы можем переиспользовать пиксели которые были (делая небольшую downsampling трансформацию) и дальше из той рамки которая образовалась вокруг экрана дорендерить новые пиксели. При увеличении зума ситуация сложнее но мы можем переиспользовать пиксели следующего зум-уровня (нечто похоже на mips) также делая частичный downsampling

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

Дальше что касается ситуаций когда объект приближается либо отдаляется то идея такая же как и с зумом камеры (делая downsampling пикселей). Сложнее обстоит ситуация когда объект поворачивается и здесь есть идея в том чтобы поддерживать (переиспользовать при движении и инкрементально детализировать или уменьшать детализации при приближении и отдалении) некоторое пиксельное представление по периметру этого объекта. Что-то похожее на развертку (например для куба это будет пиксельное представление 6 граней) при котором мы можем дешево (путем легкой трансформации пикселей соседних разверток) получить пиксельное представление нужного угла объекта (но так чтобы качество не отличалось от полного рендера объектов из треугольников). Как в 3д называют это пиксельное представление объекта по его периметру? Где можно подробнее про это посмотреть/почитать?

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

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

Я отвечу очень очень кратко: это ресерчит нвидиа для нового DLSS. Текущий может интерполировать сигнал. Ты предлагаешь экстарполировать сигнал по умному если говорить в терминах теории обработки сигналов.

Развивая тему похожести с кодеками: частично попытка сделать шаги в эту сторону были в начале века в тексте стандарта MPEG-4, но в финале в жизнь пробился только один part 10, он же H.264/AVC. Остальное сильно опережало свое время - создание сцены, акторы, направления звука и т д.

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

Народ а какие есть еще движки кроме Dreams, UE5, Unbound (pdf) где применяется нестандартный подход к рендеру? Я правильно понимаю что эти движки объединяет то что они пытаются решить проблему "policount budget" или неограниченной детализацию за счет инкрементальности на уровне геометрии когда при зуме мы плавно/инкрементально (заодно избегая артефактов в случае переключения mip-уровней) трансформируем некое промежуточное представление из которого уже дальше получить экранные пиксели дешевле (чем из рендера полной геометрии которая может быть неограниченно детализированной) ? А идея которую я выше описал это скорее попытка обобщить подходы таких движков и взять за основу идею инкрементальности и вывернуть ее относительно экранных пикселей. То есть если представить рендер 3д сцены как чистую функцию которая от данных в которых представлены исходники сцены (то есть максимально детализированная геометрия или другими словами исходники в которых хранится созданная дизайнером сцена в 3д-редакторах плюс положение камеры и объектов на сцене плюс источники и характеристики освещения плюс формулы для вычисления текстурок и т.д) получаем конечные экранные пиксели, то идея которую я описал это идея как будто математически минимизировать инкрементальное вичисление сделующего кадра в зависимости от той дельты (угол поворота камеры, зум, положение на сцене между двумя кадрами) используя все предыдущее промежуточное состояние (включая сами экранные пиксели) неких вспомогательных структур данных

Что за dreams?

эксклюзив пс4

В vr примерно такое делают

Если делать женерик 3д движок, то будет больно: тебе надо за очень короткое время понять что и в каком блоке (если разбить весь экран на квадратные блоки(squarish)) поменялось - что бы создать маску, которая уйдёт в рендер и соответственно эти кадры будут перерисовываться. Если есть SSR, то количество перерисованых блоков растёт минимум вдвоё. Если непрямое - освещение, то в квадрат (а может и больше). Освещение вообще сложный вопрос - погасла лампочка, как узнать сколько всего перерисовывать? а если есть туман и прочая полупрозрачнасть? Сейчас подобныю дырку затыкают dlss3/fsr3, они берут два гарантированно правильных кадра и доклеивают между ними дополнительные, как раз за счёт предположение что будет лишь маленькое изменение картинки между ними. Движение как раз просчитать проще всего (для моушин блюра уже считаются вектора скорости каждого пикселя, вот у тебя вся нужная инфа в предыдущем кадре уже и имеется) То что ты говоришь про развёртку, немного напоминает, то как работает lumen в анриале последнем. Там тоже на объект вешают невидимый параллелепипед (или несколько) на его стенки запекают тени (плоские, скорее проекцию объекта), и из этих данных генерят на лету тень под каждый источник освещения. (считаем освещение для вывернутого куба(нормали внутрь), но накладываем маску соответствующую квадам, которые тень отбрасывают в результате просчёта) Получается немного криво, но за счёт мягких теней надо очень постараться, что бы это заметить. (у эпиков была или статья, или выступление на какой-то конференции на эту тему) Если делать 2д движок, тут у тебя гораздо больше возможностей это реализовать успешно. Для 3д (точнее для VR 3д на PS5 кажется), есть технология адаптивного разрешения, т.е. в какие пиксели смотрит игрок, те рисуются в большем разрешении, а для периферийного зрения рисуют в гораздо более "мыльном". На пк детектор взгляда надо дополнительно покупать, калибровать, что дорого и почти всем влом. Так идея неплохая (хотя больше напоминает как видеокодеки работают😅), если получится сделать рабочий вариант, её можно будет приспособить, но с освещением (динамическим) и полупрозрачными объектами будет большой головняк. Игрок то дёргает камеру часто и много, а вспышки от выстрелов, или искорки от оголённого кабеля, и прочие спецэффекты - юзаются тупо повсюду :( (Хотя это не прям "движок", просто специфическая техника рендера кадра, но дописать обвязку, хоть и муторная задача, но туторов в инете полно, и примеры откуда копипиздить тоже есть) (у меня когда-то была похожая идея, но я не придумал, как качественно решить эти вопросы, поэтому её отложил😅, Только то была идея различного фреймрейта, для разных блоков экрана, но как склеивать "более частый квадрат" с "менее" так что бы не было разрывов и мыла/поплывностей, я не придумал вовсе)

Для 2д подобное использовалосььв платформераз типа марио. Позволяло кардинально улучшить геймплей на очень слабых машинах В 3д такое используется для вычисления теней и света. Дерево обьектов - оно мало меняется между кадрами. Некоторые трюки с occlusion. Эффект засвета камеры от солнца или светошумовых гранат. Именно с пикселями в 3д такое не видел. Меш считывается, текстурирование происходит всё равно каждый кадр

Horizon forbidden west, doom eternal, call of duty новые Подобную систему юзает Assassin's creed начиная с unity (правда, они не стримили геометрию как это делает анрил и не имели визбуфера) по визбуферу на filmicworlds есть пара неплохих статей и папиры на гдц от нескольких студий, которые это делали

ну и, очевидно, посмотри как это реализовано в анриле, если еще этого не сделал

Идея то хороша. С практической реализацией пока трудно