Dynamic Raycaster – Загрузка Геометрии Порциями

В отличие от базового движка рейкастинга под названием Static, динамический Dynamic Raycaster позволяет динамически загружать лишь определенную часть геометрии, необходимую в данный момент рендеринга.

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

Рендеринг с помощью Dynamic Raycaster позволяет избавиться от проблемы переполнения оперативной памяти не только благодаря лимитированию оперативной памяти используемой рендерером. Динамический рейкастер использует возможности операционной системы по распределению памяти. Даже если для просчета текущей части изображения придется загрузить объекты, общий размер которых превышает установленный нами лимит памяти, то операционная система сможет выделить ресурс для успешного продолжения рендеринга. В частности Windows, будет использовать т.н.свопинг, сохранение на жесткий диск не поместившихся в физическую оперативную память данных.

Как бы ни было хорошо с динамической загрузкой геометрии, следует понимать, что если бы она была на самом деле универсальным решением, то ненадежный «вылетающий» Static рейкастер был бы просто не нужен. Однако V-Ray по умолчанию использует именно static raycasting engine.

Вполне ожидаемо, что, как и на любые операции, на загрузку и выгрузку информации тратится драгоценное время. Даже если мы установим идеально подходящий под нашу ситуацию лимит ОЗУ, использование Dynamic Raycaster существенно скажется на общем времени рендеринга, увеличив его. А в случае необходимости использовать свопинг – время просчета возрастет еще больше.

Вкратце это и есть все основы работы рейкстера с оперативной памятью и причины проблем ее использования им. Теперь, когда мы познакомились с сутью работы Raycaster, давайте взглянем на практические настройки и хитрости управления им.

Raycaster Params – Настройки Двоичного Дерева

Начнем с настроек, представленных в зоне Raycaster parameters свитка V-Ray:: System.

Первые три параметра задают свойства акселерационной структуры, двоичного дерева BSP tree. Они несколько абстрактны, поэтому для начала определимся с действием каждого.

Max tree depth – параметр, ограничивающий глубину разветвлений дерева. То есть, этот параметр определяет количество делений пространства сцены. Числовое значение этого параметра отражает максимальное количество уровней от корня Root до листьев Leaf. Чем больше значение Max tree depth, тем более разветвленным становится дерево.

Min leaf size – параметр, ограничивающий структуру бинарного дерева минимальным размером листьев. Этот параметр позволяет прекратить деление геометрии в сцене, указав величину минимального размера листьев в системных единицах измерения. Маленькие значения Min leaf size позволяют не ограничивать степень разветвления дерева, и таким образом дают ему разрастись настолько, насколько это позволяет предыдущий параметр.

Face/level coef. – параметр, определяющий максимальное количество треугольников (минимальных единиц геометрии) в одном листке Leaf. Меньшие значения этого параметра, как и с предыдущим Min leaf size, позволяют получать более разветвленное дерево, с большим количеством листьев.

Как нам известно, организация данных о геометрии в сцене в виде двоичного дерева BSP tree призвана ускорить процесс рейкастинга. Вполне логично предположить, что чем ветвистее наша древовидная структура, чем мельче у нее листья и чем меньше единиц геометрии содержит каждый лист, тем больше будет потенциал ускорения и тем больше места в оперативной памяти потребуется для удержания ее ветвей.

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

Как найти этот предел, а с ним и оптимальный размер BSP tree, настроив скорость работы рейкастера с геометрией сцены на максимум?

Ответ на этот вопрос не самый ободрительный: исключительно экспериментальным путем. Не существует настроек, которые бы дали максимальную производительность в любой сцене с любым количеством геометрии. Для каждой конкретной сцены оптимальная глубина BSP tree индивидуальна.

Для рендеринга статичных изображений возня и многочисленные эксперименты с вышеописанными параметрами совершенно неоправданы. Просто потому, что для определения оптимальных параметров BSP tree, их необходимо подбирать, тратя уйму времени. Согласитесь, это абсурд, проводить 10 раз финальный рендеринг в поисках оптимальных настроек BSP tree, чтобы в итоге провести его же в одиннадцатый раз, но на 10 минут быстрее :D

Как бы там ни было, параметры создания BSP tree это не просто демонстрация технических возможностей рендер-движка. Их назначение становится понятным, когда речь заходит об анимации. Например, необходимо просчитать секвенцию в 1000 кадров. Тогда можно смело проводить экспериментальный подбор оптимальных параметров BSP tree. Даже если для выбора лучших значений потребуется просчитать 10 или 20 финальных рендеров, но при этом скорость рендеринга каждого кадра увеличится на 20 секунд, то настройка будет весьма полезной. Ведь такой оптимизацией будет с легкостью сэкономлено более 5 часов вычислительного времени.

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

В универсальных стартовых настройках V-Ray, в параметрах, отвечающих за структуру BSP tree, следует оставлять номинально установленные значения, не внося в них свои коррективы без реальной необходимости.