Я матчасть читал, Вы об этом не перживайте. Всё та же книга, например, лежит у меня сейчас на столе.
«Для того что-бы получить гладкие не-резкие тени нужно хрен-пойми сколько вторичных лучей(их количество порой может достигать 50 и даже больше) через каждый пиксель пропускать.»
Я всё об этот и талдычу: ray-tracing допускает множество вторичных лучей. Где тут принципиальная невозможность сделать area light?
Причем опять же, как работает path-tracing? Для того, чтобы изображение не было шумным, надо выпустить некоторое количество путей из каждого пикселя. Точно такой же трюк можно провернуть и с ray-tracing'ом, чтобы не воротить большое число вторичных лучей.
Кстати говоря, вторичные лучи — это лучи для BSDF, а не для прямого освещения (secondary lighting != direct [area] lighting). Прямое освещение тут вообще самая незначительная проблема; если отбросить глобалку, то ray-tracing с множеством direct-lighting лучей будет намного быстрее сходиться, чем path-tracing. А для глобалки — да, множество вторичных лучей неоправданно, т.к. вторичка вносит меньший вклад, чем первичка, причем чем больше номер отскока, тем меньше, а число лучей растет с геометрической прогрессией. В данном случае path-tracing работает намного более рационально. Именно поэтому ray-tracing с множественными отскоками практически не используется. Но ложность изначального утверждения «физически правильного изображения он не дает» это не отменяет.
А чем это отличается от ray-tracing? Еще раз повторяю: path-tracing — это raytracing, где вторичный луч только один, за счет чего и получается путь, а не дерево. Что мешает пустить несколько вторичных лучей и взвесить их согласно BSDF (кстати, именно BSDF, если уж мы говорим о реалистичности)?
Если Вы все равно не согласны, то, пожалуйста, объясните тогда, что вы понимаете под термином ray-tracing (огласите кратко алгоритм). Кстати говоря, Вы же выше ссылаетесь на книгу «Physically Based Rendering: From Theory to Implementation», где рассказывается о визуализаторе pbrt (PHYSICALLY BASED RAY-TRACER — обратите внимание на название). И этот самый ray-tracer, гад такой, использует path-tracing на пару с Metropolis light transport. Что же, Matt Pharr и Greg Humphreys не знают, что такое ray-tracing?
Извините, я объединю ответы в один комментарий, т.к. могу отвечать не чаще, чем раз в час.
Господину risenow:
«Даже тени приходится делать отчасти фейковые, что-бы смотрелись более-менее нормально»
Ну ничего себе, это что Вы имеете в виду, можете примеры изоражений привести что ли?
Господа, давайте так: объясните для начала, что вы понимаете под термином ray-tracing, а потом уже будем спорить. А то я вижу, что у нас с вами эти понятия отличаются. Еще лучше, если вы приведете ссылки, где говорится, что path-tracing это не ray-tracing и что ray-tracing не может дать физически-корректного изображения.
Он дает физически корректное изображение. В данном плане он не уступает ни одному из path-tracing алгоритмов, т.к. path-tracing суть частный случай рэйтрейсинга (в рэйтрейсинге вторичных лучей может быть сколько угодно, а в path-tracing строго один). Единственный критерий, по которому их следует сравнивать — это скорость сходимости.
Вы, наверное, под термином ray-tracing понимаете только его самый примитивный вариант какой-то.
«Сцена содержит порядка 100000 полигонов (kd-дерево строилось несколько минут)»
Что-то долго у Вас строится дерево. У меня сцена Стэндфорского дракона из ровно 100000 треугольников рендерилась ~0,9 секунды включая время построения дерева. Но у меня было тупое деление пополам, без SAH.
В самом начале, когда еще не кончились перки с низкой ценой, по графику было видно, что проект соберет как раз примерно 32 млн, если цена будет в районе $700. Но с тех пор уже много времени потеряно.
Это сработало бы, если бы их количество не было ограничено 5000.
Думаю, что они сами не знают, какая точно должна быть цена. Ибо чем дешевле телефон — тем больше их купят. Чем больше их купят — тем ниже себестоимость. И по кругу. Я не экономист, но полагаю, тут цена становится вроде свободной переменной. Не совсем свободной, но угадать оптимальное значение сложно.
Потому что тогда они стоили по $600.
Вообще, исходя из того, что чем крупнее серия — тем дешевле каждый аппарат, то вполне могут снизить цену, если желающих будет больше, чем изначально ожидалось.
«Для того что-бы получить гладкие не-резкие тени нужно хрен-пойми сколько вторичных лучей(их количество порой может достигать 50 и даже больше) через каждый пиксель пропускать.»
Я всё об этот и талдычу: ray-tracing допускает множество вторичных лучей. Где тут принципиальная невозможность сделать area light?
Причем опять же, как работает path-tracing? Для того, чтобы изображение не было шумным, надо выпустить некоторое количество путей из каждого пикселя. Точно такой же трюк можно провернуть и с ray-tracing'ом, чтобы не воротить большое число вторичных лучей.
Кстати говоря, вторичные лучи — это лучи для BSDF, а не для прямого освещения (secondary lighting != direct [area] lighting). Прямое освещение тут вообще самая незначительная проблема; если отбросить глобалку, то ray-tracing с множеством direct-lighting лучей будет намного быстрее сходиться, чем path-tracing. А для глобалки — да, множество вторичных лучей неоправданно, т.к. вторичка вносит меньший вклад, чем первичка, причем чем больше номер отскока, тем меньше, а число лучей растет с геометрической прогрессией. В данном случае path-tracing работает намного более рационально. Именно поэтому ray-tracing с множественными отскоками практически не используется. Но ложность изначального утверждения «физически правильного изображения он не дает» это не отменяет.
Если Вы все равно не согласны, то, пожалуйста, объясните тогда, что вы понимаете под термином ray-tracing (огласите кратко алгоритм). Кстати говоря, Вы же выше ссылаетесь на книгу «Physically Based Rendering: From Theory to Implementation», где рассказывается о визуализаторе pbrt (PHYSICALLY BASED RAY-TRACER — обратите внимание на название). И этот самый ray-tracer, гад такой, использует path-tracing на пару с Metropolis light transport. Что же, Matt Pharr и Greg Humphreys не знают, что такое ray-tracing?
Извините, я объединю ответы в один комментарий, т.к. могу отвечать не чаще, чем раз в час.
Господину risenow:
«Даже тени приходится делать отчасти фейковые, что-бы смотрелись более-менее нормально»
Ну ничего себе, это что Вы имеете в виду, можете примеры изоражений привести что ли?
Господа, давайте так: объясните для начала, что вы понимаете под термином ray-tracing, а потом уже будем спорить. А то я вижу, что у нас с вами эти понятия отличаются. Еще лучше, если вы приведете ссылки, где говорится, что path-tracing это не ray-tracing и что ray-tracing не может дать физически-корректного изображения.
Вы, наверное, под термином ray-tracing понимаете только его самый примитивный вариант какой-то.
Что-то долго у Вас строится дерево. У меня сцена Стэндфорского дракона из ровно 100000 треугольников рендерилась ~0,9 секунды включая время построения дерева. Но у меня было тупое деление пополам, без SAH.
Ну и в дополнение к последнему пункту статьи: чем автора не устроил View Call Hierarchy в студии?
Опоздал на секунды
www.reddit.com/r/Ubuntu/comments/1j0r31/ubuntu_edge_most_likely_based_on_nvidias_tegra_5/
Думаю, что они сами не знают, какая точно должна быть цена. Ибо чем дешевле телефон — тем больше их купят. Чем больше их купят — тем ниже себестоимость. И по кругу. Я не экономист, но полагаю, тут цена становится вроде свободной переменной. Не совсем свободной, но угадать оптимальное значение сложно.
Вообще, исходя из того, что чем крупнее серия — тем дешевле каждый аппарат, то вполне могут снизить цену, если желающих будет больше, чем изначально ожидалось.