Проблемы Крэша V-Ray

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

Разумеется, речь идет о нехватке оперативной памяти во время рендеринга, которая является причиной крэша 3ds Max и вылета сцены.

Почему же это все-таки происходит? Что приводит к этой ошибке? Неужели нельзя ничего сделать? Неужели, чтобы завершить сложный проект, неминуемо потребуется увеличивать количество оперативной памяти, установленной в текущем компьютере? Правда ли что единственный выход это идти в магазин компьютерных комплектующих и банально докупать несколько планок ОЗУ?

Чтобы ответить на эти вопросы, давайте разберемся, как же V-Ray использует оперативную память и какие инструменты управления процессом ее использования нам доступны.

В любом программном обеспечении, управление оперативной памятью и способ размещения данных в ней, это очень сложный и рутинный материал. По крайней мере, для тридешника. Нет совершенно никакого смысла вдаваться в точнейшие подробности, описывая массивы данных и адресацию к ним, глубоко уходящие корнями в программирование. Для того, чтобы уметь гибко управлять оперативной памятью программы на уровне профессионального пользования, достаточно лишь условного представления о процессах, происходящих с ней. Тем более, что в любой программе, пользователь всецело ограничен ее интерфейсом. V-Ray – не исключение.

Raycasting, Основа Рендеринга V-Ray

Для того, чтобы V-Ray смог приступить к рендерингу, то есть, смог из трехмерной сцены сделать растровую картинку, ему перед началом просчета необходимо загрузить данные о геометрии в оперативную память, чтобы использовать их для вычисления цвета пикселей финального изображения. Это начальный аспект рендеринга. Осознав его, важность оперативной памяти в процессе визуализации сразу становится ясной. Но, конечно же, мы этим не ограничимся и пошагово последуем порядку рендеринга.

Как только данные загружены в память, V-Ray может начинать рендеринг. Просчет каждого пикселя начинается с базовой операции, а именно "прощупывания" геометрии с помощью специального алгоритма, так называемогоРейкастинга (Ray casting). Суть этого алгоритма в том, что из камеры выпускается луч по направлению сцены, который летит до первого столкновения с каким-либо объектом сцены. Каждое такое столкновение фиксируется и, таким образом, V-Ray определяет местоположение геометрии в сцене, ее базовые свойства и другую требуемую для последующего рендеринга информацию.

Недостатки Не Организованности Данных

Процесс просчета одиночного рейкаста, т.е. столкновения луча с геометрией и определение ее свойств, сам по себе не значителен по времени. Однако, количество таких рейкастов при фотореалистичном рендеринге, может во много раз превышать количество пикселей рендера, которых и самих немало. Например, рендер HD разрешения 1920х1080 состоит из более чем 2 миллионов пикселей. Такой масштаб кардинально меняет ситуацию, делая процесс рейкастинга очень ресурсоемким.

Давайте проведем формальную аналогию технически замысловатому алгоритму рейкастинга. Она здорово поможет понять конкретные проблемы использования оперативной памяти в V-Ray.

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

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

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

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

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

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

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