Создание своего рендер движка (не реального времени)

В интернете куча статей и уроков по созданию рендер движков для игр, то есть реального времени. А никто не знает похожих уроков по созданию не реалтайм рендера? Мне просто интересно их устройство и хочется написать простейший. Даже не знаю как правильно загуглить данный вопрос, вечно получаю игровые движки. Интересно нечто похожее (но сильно упрощенное разумеется) на corona, vray. И интересно не плагин для 3д студий а как самостоятельная программа. Посмотреть исходники открытых вариант так себе, тупо код для меня мало полезен. Интересно на сколько много отличий от игровых движков и поиграться с результатами, очевидно что фотореализм не по силам но интересные результаты можно получить.

0

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

+ т.к. нам не нужен реал-тайм, то мы можем разбить конечное изображение (то что видит камера) на блоки и делать обработку в определенной последовательности.

0

Просто на примере тех же corona, vray изначально они были только cpu, и только потом появилась возможность gpu рендера (сначала сильно уступало cpu версиям). И одна и та же сцена на одном и том же движке но при разных методах (gpu cpu) дает всегда различные результаты (не всегда сильно, но заметить просто).
Игровые движки пишутся грубо говоря на directx, opengl (и его разновидностях) и vulkan, а они используют для рендера gpu, а компы для статик рендера обычно с очень мощными многопоточными процессорами, кучей оперативки и видеокартами затычками (чтото уровня gtx-хх50, например gtx1050).
Вот отсюда я и сделал выводы что начинка этих движков совсем иная...
Это если не брать в расчет физически корректные рендеры по типу maxwell, которые так же больше нацелены на cpu.
При статик рендере количество полигонов измеряется миллионами, что для реального времени очень много. И нормальным считается использовать highpoly модельки без карт нормалей.
Про разделение хорошая идея, только как это реализовать у меня идей нету совсем.

0

alecss131, в посте ссылка на статью, посвященную софтверному рендеру Алгоритмы закраски фигур

0

Сообщение от alecss131 Просто на примере...

подожди, не городи все в одну кучу... так все только сильнее запутывается...
OpenGL и DirectX это API для работы с 2D и 3D графикой.
Шейдеры, CUDA, OpenCL это развитие технологий, которые расширяют функционал работы с 2D\3D графикой, предоставляя возможности GPU
Свет, Камеры, Материалы, Бамп и карты Нормалей, Шумы, Voronoi etc.
это все не более чем алгоритмы работы, но они сами по себе не несут тот факт что это будет реал-тайм или статичная картинка

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

Добавлено через 37 минут
образно говоря, real-time это лишь кол-во кадров в секунду.
представь, что ты рендеришь анимацию и у тебя тоже будут кадры в секунду, чем сложнее сцена тем меньше "fps"

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

0

То есть выходит что то что мне нужно написано тут грубо говоря? https://habr.com/ru/post/248153/ я помню недавно сам находил эту ссылку, пока так сказать добавил в список для чтения)
Видеокарты уже давно прилично мощные но для статичного рендера странно что редко кто их использует и крупные платные плагины только недавно начали развивать использование gpu.
Хотя сейчас после прочтения перевода сайта learnopengl и принятия во внимание того что принцип везде один становится понятным возможность статик рендера не в 1 картинку а в, так сказать, набор картинок одной и той же сцены но разных аспектах

0

Ну, собственно как ты наверное заметил там в самом начале сказано, что объясняется как сам OpenGL устроен.
т.е. конечно при максимальном погружении ты можешь писать свой "OpenGL", хотя я не совсем понимаю какой в этом смысл, если рассматривать в общем, а не частные случаи или как в статье придти к пониманию КАК это работает

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

По крайней мере как мне это представляется, но я могу и ошибаться
В любом случае, да, очень похоже, что тобой приведенная статья неплохое начало пути в этом вопросе

0

У меня была идея написать свой opengl, используя vulkan))) В смысле написать библиотеку с использованием вулкана но с простотой использования opengl. Но пока не разберусь в opengl вулкан больше трогать не хочу.
Я лучше всего знаю джаву и мне приятней писать на нем, так что привязки к ос не будет.
Да и в целом по сути писать свои игровые движки не имеет смысла, конкурировать с существующими невозможно. Но люди зачем то пишут, включая одиночек. Для меня написание этого больше как обучение и понимание существующего.

0

Сообщение от alecss131 Для меня написание этого больше как обучение и понимание существующего

В любом случаи это похвально Если попадется что-нибудь интересное по теме, то буду иметь ввиду и маякну

0

Сообщение от alecss131 В интернете куча статей и уроков по созданию рендер движков для игр, то есть реального времени. А никто не знает похожих уроков по созданию не реалтайм рендера?

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

0

Наверно гуглить “cофтверный рендер”.
Поищите инфу про даты выхода старых игрушек doom 1, quake 1 и т.п. когда там вроде еще не было видеокарт. Вот тех времен книги в стиле “компьютерная графика на ЭВМ“ и нужно искать.

0

еще немного добавлю...
если в играх мы знакомы с ray casting
то в не реал-тайм рендринге для фотореализма у нас добавляются более тяжелые алгоритмы ray tracing (трассировка луча) (постепенно вводится и в игры с подачи nVidia), path tracing (Трассировка пути), photon mapping (Метод фотонных карт), Radiosity (метод излучательности(?))
сюда пожалуй еще можно добавить композитинг, когда рендер имеет возможность накладывать слой за слоем добавляя все больше реализма к конечному изображению.

впрочем это уже немного дальше от "простого рендера"

0

Я уже точно не помню но в настройках vray были на выбор (добуквенно не помню, могу спутать слова, давно не пользовался) irradiance map, light cache и brute force. Почти во всех гайдах ставили первые два, причем первый на первое место, второй на второе, то есть рендер мог использовать 2 и надо было выбрать, потом отдельно каждый настроить. Только сейчас пришли мысли погуглить эти штуки.
Еще что меня приводило к мыслям о отличии от реального времени это критерии остановки. На выбор 3 критерия, это время (очевидно), шум (совсем не понятно) и количество проходов (passes, вот тоже не понятно, ведь в реальном времени каждый кадр заново, а как несколько раз одно и тоже при этом используя старые данные для уточнения).
И еще рендер в реальном времени отображал прогресс и квадратик над которым идет обработка. Вот такие части мне плохо понятны, ведь как можно обрабатывать маленькие кусочки картинки когда влиять могут другие даже не соседние части.
Про слои знаю, некоторые люди даже сами их смешивают в итоговую картинку в других программах.

0

Сообщение от alecss131 И еще рендер в реальном времени отображал прогресс и квадратик над которым идет обработка. Вот такие части мне плохо понятны, ведь как можно обрабатывать маленькие кусочки картинки когда влиять могут другие даже не соседние части. Про слои знаю, некоторые люди даже сами их смешивают в итоговую картинку в других программах.

vray - это трассировочный рендер. Т.е. он не растеризирует через z-буффер (что в принципе есть оптимизация первого шага трассировки), а честно трассирует лучи до пересечения с геометрией с отражениями/преломлениями на некоторую глубину. Причем в квадратике такая трассировка быстрее - если брать в качестве начального пересечения с криволинейной поверхностью точку пересечения соседнего луча то метод Ньютона для нахождения пересечения сходится за гораздо меньшее количество итераций.

Добавлено через 9 минут

Сообщение от alecss131 ведь как можно обрабатывать маленькие кусочки картинки когда влиять могут другие даже не соседние части

В трассировке даже соседние пикселы результирующей картинки друг от друга не зависят от слова совсем. Рендер хранит всю геометрию сцены и рассчитывает все исключительно на основе положения 3D объектов, в отличии от g-Buffer в котором эта информация о 3D геометрии частично теряется, частично хранится в растровом виде в плоскостях полученных при рендере глубины.

Добавлено через 7 минут

Сообщение от alecss131 шум (совсем не понятно)

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

0

То, что тебе нужно:

https://habr.com/ru/post/248153/

Разжёвано буквально всё, очень круто описано.

В целом да, есть два подхода к решению этой задачи - это когда треугольнички проецируют на плоскость экрана (растеризация), и когда из каждого пикселя виртуальной камеры вылетают невидимые лучи, отражаются/преломляются и вот на что они попадут, такого цвета пиксель и будет (трасировка). Первый быстрый, второй реалистичный, но жрёт. И у того, и у другого есть куча всяких подвидов, к тому же в реальных продуктах их часто миксуют. В играх юзают первый подход, в продакшене (3д макс и прочий не реалтайм) - второй. Первый подход аппаратно ускоряется видеокартами. Второй - до поколения GeForce 2000 ускорялся, но не очень эффективно, а начиная с этой серии - получил полное аппаратное ускорение. Но даже с аппаратным ускорением, трасировка лучей - очень суровый алгоритм. В новых играх обычно его используют чуть-чуть, для отражений и света, а остальное спихивают на классическую растеризацию, иначе тебе для 1080p не хватит даже двух GeForce 3090. Такие дела.

0