Обнаружил проблему, почему-то сразу пропустил это. Кроме того, что траверс рекурсивен, еще нужно собрать лучи в один массив. А как же быть с тем, что сама трассировка рекурсивна :) ? Первичные лучи могу собрать без проблем, а вот дальше... Первичные могут создать лучи преломления/отражения как минимум, короче рекурсия еще та. Как избавиться?
Ну можно пускать всегда только один отраженный луч - тогда рекурсии не будет.
Но это проблема конечно. Я юзаю path tracing, чтобы рекурсия жить не мешала.
В pathtr проблема сходная, как я понимаю. Я начал оптимизации с фотон маппинга и сразу уперся в то, что на каустики порождается много новых лучей, которые еще каскады лучей создают (или не создают) рекурсивно.
Глубина рекурсии известна, но похоже проблема всё-таки есть.
Задался такой проблемой. Можно ли предвычислить какую-то часть общего рекурсивного процесса, при трассировке? Короче ищу что можно распараллелить, сохранив при этом качество процесса. Сложный алгоритм явно просядет на стороне девайса, тем более есть много виртуальных функций (материалы, источники осв.), что уже делает невозможным перенос алгоритма с сохранением качества движка.
Делай path tracing
Есть у меня и он тоже :)
Но проблемы остаются. Изложи что бы я мог в нем сделать классно и впараллель.
http://www.handsfreeprogramming.com/masters/
Вот тут один предлагает такой подход. Делать "хранилище" для новых лучей, т.е. для порожденных. Насколько это быстро не знаю. Лучей появляется предсказуемое количество. Как он борется с ограниченной памятью, не знаю.
Вышло бы Fermi на полгодика раньше... Ну как не крути, или алгоритм должен быть примитивен или фейк прийдется сделать.
Так что в pat tracing-ге то непонятного? Он идеально параллелиться и никакой рекурсии.
На счет того о чем ты говоришь - я не знаю. Я думал над этой проблемой, но забил, потому что сложно очень. А я не люблю сложные алгоритмы, потому что на деле они работают очень плохо.
Я думал, сделаю precomputing для части лучей, назначу лучу индекс, а потом на CPU буду брать результат. Но с глубиной рекурсии уже в 6 мне надо будет пару гиг памяти :)
Понимаешь, у меня есть готовый двиг. Одна из его черт - качество. Он на статик в основном рассчитан. Накручены материалы и лайты. + интеграторы объема. Код построен так: нашли пересечение, берем материал, материал дает нам что делать дальше, тут луч может быть добавлен в обработку в волум интегратор. Похоже выбора нет, в том случае, если не удается выделить простую часть алгоритма. Это не зависимо от способа трассировки. В pathtracing таже картина тут, хотя немного проще чем в случае photonmap и тем более bidirectional.
Всю избыточную сложность можно с лихвой убить через precomputing. Но вопрос в доступном объеме памяти. Идея такая - есть объем памяти на все лучи - пусть это 3-5 гиг. Можно и на диск скинуть, о реалтайме речь не идет, один кадр делается от пару часов до суток. Потом брать порции лучей, генерить их рандомом, считать пересечения, назначать индексы. Потом на CPU идти по готовым индексам, подгружая в память нужный объем с диска. Может это супер тупая идея, но пока что легче ничего не придумал.
http://www.youtube.com/watch?v=Soyr1sQmro4
Посмотрел и заело меня че они могут а я не ))
http://www.youtube.com/watch?v=Soyr1sQmro4
Блин, да это отстой полный. Ты лучше посмотри как IRay работает - вот то и правда впечатлает. И переименовал бы тему что-ли OpenCL-ем и не пахнет.
А насчет прекомпьютинга -ну.. я не поддерживаю идею, так как по шине PCI-e гонять данные - дорого а с диска еще дороже. Просто может оказаться что это вдруг станет боттлнеком. Лучше все сразу на GPU вычислять. И не страшно что будет немного лишней работы. Зато код простой и масштабироваться будети легко.
Тема в архиве.