Pull to refresh

Comments 70

Интересно, скандальный Unlimited Details — unbiased или нет?
Кстати, вопросец. То, что на всех видео картинка рендеринга в реал тайме какая-то «черноточечная» — это комп не успевает обсчитать те районы чтоли?
может лучи улетают неизвестно куда и непонятно, что нужно для них рисовать? Это просто моё предположение.
Просто еще не просчитаны лучи попадающие в эти точки.
черные точки — луч не добрался до источника света
Кажется логичным совмещать разные виды рендеринга; то есть раскрасить чёрные точки при помощи менее ресурсоёмкого рендеринга, пусть и менее точного. Интересно, это реализовано?
Извиняюсь, не прочёл последние комментарии.
количество лучей для каждого пикселя на экране должно быть достаточно большим. но т.к. ресурсы ограничены, то лучей кидается мало и как следствие падает точность расчета освещенности. чем больше лучей, тем менее заметны резкие перепады темных/светлых пикселей. если уже совсем маниакально много лучей посчитать, то получится правильная картинка, но и не real-time)
Теперь у кого видеокарта круче будет не кадров больше, а картинка четче, качественнее. )
Игры перестанут тормозить! но крайзис будет черным черным.
И вспышки выстрелов будут не подсвечивать, а только еще глубже погружать во мрак.
Всё это интересно, но я так и не понял — чем принципиально различаются path tracing и ray tracing?
Прямое освещение рассчитывается аналогично. Вся хитрость в непрямом освещении. В RT есть несколько вариантов расчета глобального освещения, но являются упрощенными моделями, и имеют много настроек.
www.3dcenter.ru/tutors/read.php?sname=vray&articlealias=VRayGI
Кроме того, не видел, в RT вторичную каустику.

Различий вообще очень много, для этого надо написать статью про RT :)

Могу только добавить, что чем сложнее сцена и больше эффектов — тем больше в производительности выигрывает именно РТ.
А что-то вот я тоже не пойму принципиального различия.
И там и там трассируются лучи.
И там, и там есть проверка на путь к свету.
Вот развечто в PT эти проверки хитрее.

Если в RT выкрутить параметр diffuse bounces до жопы — чем это будет отличаться от PT?
как то натыкался на неплохое описание/сравнение:
Path tracing is a physically based rendering technique, based on ray tracing. Where regular recursive ray tracing (Whitted-style) is able to render reflections, refractions, and shadows, path tracing also handles diffuse reflections, indirect light, and even caustics. It does this by replacing the integrals involved in these effects by the expected value of a stochastic process: Soft shadows are calculated by sending several random rays to an area light source; anti-aliasing is calculated as the average of several random rays over the area of a pixel, and so on. Randomness means noise, and thus the resulting image quality depends on the number of samples. A path traced image converges over time, as more samples are added to previous frames.

автор поста молодец, главное что бы не перешло в «RT vs PT» и в срезе «мне нравиться больше это»
> “Идеальной” картинки никогда не будет
Ну смотря что считать идеальной. В глаз тоже за секунду прилетает определённое количество фотонов, которое можно посчитать. Другое дело, что оно очень велико, но не бесконечно :)
В природе имеет смысл «корпускулярно-волновой дуализм» чем выше частота излучения — тем больше свойства «корпускул», чем волн. Однако, в видимом спектре свет имеет волновые свойства. Если бы корпускулярные, то в темноте бы мы видели «Path Tracing на Pentium II» :)
Фотон может поглотиться лишь целиком. На сетчатке никаких волновых свойств уже нет. Так что в почти идеальной темноте именно так и будет. Только один фотон вносит слишком слабый вклад и почти неразличим, поэтому не будет ярких точек на чёрном фоне.
Для иллюстрации см. интерференцию электронов. На экране мы видим именно что индивидуальные точки, но большое количество складывается в интерференционную картину.

Волновые свойства электрона проявляются в том, что его волновая функция (квадрат которой есть вероятность его обнаружения) интерферирует сама с собой. Это кажется очень странным, но, грубо говоря, волновые свойства проявляет вероятность, а не сам электрон.
Дробовой эффект от фотонов вполне можно заметить глазом. Глаз может после длительной адаптации к темноте различить поток где-то 10 фотонов/сек с длиной волны 555 нм (максимум чувствительности палочек). Здесь колебания плюс-минус фотон уже очень даже заметны.
Если говорить об игровом движке, то главный плюс технологии в том, что скорость рендера не зависит от детализации сцены, а зависит от разрешения и необходимого качества получаемого изображения, верно?
Видео, демонстрирующее рендер на 2х видеокартах, впечатляет, шум даже добаляет реализма :)
Не зависит от количества треугольников, но зависит от количества источников освещения и количества поверхростей, от которых свет может отразиться, пока не доберется от источника освещения.
Зависит не сколько от количества источников света, сколько от сложности источника света. В инструкции к Максвеллу 1.7 рекомендовали делать источники света как можно проще. Сейчас не знаю, может алгоритм изменили, что-то оптимизировали. Как-нибудь проверю…
софтбокс вполне себе отлично выглядит! :)
Мне вспомнился Silent Hill:4, там графика сама по себе с шумом. В хоррорах, шум вообще в тему, как и размытие при резком движении, правда не при всем игровом процессе, но в отдельных моментах точно =)
В первом Silent Hill туман был средством обхода ограниченных возможностей железа.
И, вместе с тем, стал визитной карточкой серии.

Кстати, поскольку история развивается по спирали, то можно себе представить:
На PlayStation 5, характерной особенностью игр на каком-нибудь Unreal Engine 7 может быть будет «эффект киноленты» — такой вот шум и «зерно».

(Если бы в ролике из топика картинка не замирала вместе с камерой, а продолжала «шуметь» — было бы то, что надо.)
Хм, спасибо за интересную инфу по SH, не задумывался об этом)

Насчет замирания, да, пожалуй это второй минус рендера(первый, конечно же, 2 GTX580 для создания сцены, но думаю, скоро это будет уже не так страшно).
Это «минус» не рендера, а движка ;)
Сделано, чтобы во время остановки дать возможность бОльшему количеству семплов прочистить экран от шума.
В другой игре (Sfera) такой фичи нет.
Хм, а по моему в Sfera картинка тоже притормаживает при движении(особенно при резких), но там сцена не такая большая вроде(или окружение там тоже часть сцены??), поэтому не так и заметно.
Ну и да, минус скорее текущей реализации движка =)
Соглашусь на счет эффекта реализма.
Мне очень понравилось, когда останавливалось движение и через несколько мгновений сцена уже очень пходила на фотографию
Если оптимизировать уточнение картинки так, чтобы в центре она очищалась быстрее, наверное даже какая-то эмуляция восприятия человеком была бы…
Супер! Попугай — просто отпад))
не понимаю зачем мультяшной графике настоящие алгоритмы?
Она тут не мультяшная, а псевдопластелиновая.
ну как это зачем?
вспомните все пиксаровские мультики.
зацените шёлк на платьях в «Brave».
Возможно, покажусь банальным, но Хабр — Торт!

Спасибо, статья очень понравилась. Пишите ещё.
В максвеле поссорились разработчики, и появился фрайрендер. Вроде слухи такие были. Что касается теорем это круто, но мои нервы не выдерживают и даже обычного Global illumination на средней сцене на 4 ядрах. Это просто невозможно при подгоне материалов. Про максвел вообще молчу. Он хорош конечно но без рендерфермы никуда.
Пачка из четырёх прошлогодних ати стоит не так дорого
это все не так просто. 4 видеокартами не обойтись.
Всё равно долго рендерит превьюхи?
10х GTX580 думаю, уже будет норм.
Ура! Наконец-то кто-то раскрывает тему 3D. Пишите еще, пожалуйста! :)
Существует еще один метод оптимизации мутирующих лучей — Energy Redistribution Path Tracing, но его повсеместно не используют, и инфы о нем мало
неправда, достаточно, есть и на GPU, правда экспериментальное, не реализованое в промышленных рендерах
на youtube есть примеры. задайте только в поиске.

SmallGPU не полностью GPU
вот здесь www.luxrender.net/wiki/Luxrender_and_OpenCL#SmallLuxGPU пишут:
The idea is to use the GPGPUs only for ray intersections in order to minimize the amount of the brand new code to write and to not loose any of the functionality already available in Luxrender.
то есть, пересечения лучей просчитываются на GPU, а просчитывае сцену сам Luxrender
Буду признателен доброму человеку, который напишет статью про ERPT ;)

На одном из форумов нашел (и больше не могу найти), что ERPT делает рендер сильно зависимым от сложности геометрии, от чего основная фишка анбиасов (независимость от сложности геометрии) становится неактуальной.
неправда
не зависит от геометрии, это просто расширение-реорганизация MLT
добавьте кармы и напишу ;)
я веду thrlite.blogspot.com/ — там я тестирую всякие методы и готовые решения
а также пишу своё и ускоряю и улучшаю качество как могу
Просто идея для игр — наверняка можно адекватно совместить «быстрый» полигональный ренедринг с «медленным» PT?
Вряд ли. Слишком уж разные технологии.
Ну ладно, тогда другая идея для игр:
можно ли реализовать PT таким образом, чтобы низкодетальная картинка была не в крапинку, а размытыми пятнами, и уже по мере «разглядывания» детализировать их?
В некоторых рендерах делают так (размывают точку на 2-3 пикселя), и в этом действительно есть смысл. Грани теряются не сильно, но шум не так бросается в глаза.
Вот такое былобы идеально для игр.
Потомучто в динамических сценах погони и мочилова — никому каустика и рефлексы нафик не нужны.
А вот если стоять разглядывать замок в поисках подсказки — тогда уж и подетальнее рассмотреть.
На самом деле даже в современных играх чуть что дёрнется картинка какбы «размывается». Нарочно.
Это какбы многими отключается.
похоже вы соовсем не в курсе.
гляньте пожалуйста ресурс raytracey.blogspot.com/
там как раз PT в реалтайме в играх
«Изображение получается таким, каким должно быть в природе» — чересчур пафосное высказывание =)
Насколько я понимаю, рендеринг без допущений означает, что получаемая картинка со временем сходится (как-нибудь там по вероятности) к решению уравнения рендеринга. Так что выглядит оно не в точности как в природе: всё зависит от того, насколько хорошо решаемое уравнение соответсвует реальной физике. Причём уравнение рендеринга не является чем-то незыблемым: например, классическая версия, судя по всему, совсем не учитывает объемные эффекты.
Системная ошибка всегда есть, просто в случае рендереров без допущений она действительно крайне мала.

Не дай вам боже абиасед рендером рендерить дымы и взрывы =)
>Не следует, также, забывать, что небольшой шум придает изображению реалистичности.
Шум от анбиасед рендера к реалистичности отношения не имеет и выглядит как дефект рендеринга. Не следует путать этот шум с пленочным зерном, шумом камеры и т п эффектами. Глазом-то мы никакого шума не видим.
Попробуйте долго побыть в тёмном месте(ночью в лесу например при свете луны, минут через 40, чтоб глаза пообвыкли) можно заметить как-раз таки этот мелкозернистый шум… просто в рендере пиксели поболее будут(по сравнению с глазом) и шум заметнее, как мне кажется шум — это и есть отдельные фотоны которые довольно заметны, при недостатке освещения, человеческим глазом. При достаточном освещении фотонов так много, что они сливаются и зёрна не заметны… суть — рендер в реалтайме не успевает просчитать достаточное количество частиц и соотв. видны зёрна которые пропадают через время походу довычисления всё новых траекторий лучей.
А не лейкоциты ли это?
Проходящие через расположенные перед фоторецепторами капилляры лейкоциты при взгляде на синий свет могут восприниматься как мелкие светлые движущиеся точки. Данное явление известно как энтопический феномен синего поля (или феномен Ширера)

© wikipedia


От наличия синего ничего не зависит, тут эффект проявляется именно в условиях почти полного отсутствя освещения, очень похоже как раз на начало проявления картинки при рендеринге… только она не становится ярче со временем…
А как нынче анбиаседы решают проблемы шума при рендеринге анимации на ферме?
Думаю, заглушают шум в постобработке.
Примеров бы посмотреть, да найти всё не могу =)
Voxelisation по сути это процесс разбиения пространства в структуру, при расчете пересечений ускоряющую этот процесс. Сейчас популярны иерархические сетки, кд-деревья, иерархия ограничивающих обьёмов и другие.
Sign up to leave a comment.

Articles

Change theme settings