Что такое VRayProxy и в каких ситуациях нужно конвертировать геометрию в прокси

Привет!

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

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

Несложно догадаться, что при загрузке этой люстры в 3ds Max, эти 400 мегабайт перекочуют с диска в оперативную память, ведь именно там содержится информация о загруженной сцене. То есть сходу, физически установленная в текущем компьютере оперативная память, сократиться на эти 400 мегабайт. Вроде бы нечего страшного, если в компе хотя бы 6 Gb. Однако если таких люстр две или три, да еще пару классических кресел, да еще кровать с резным изголовьем, плюс остальной декор и так все 6 гигабайт улетучиваются. Что в свою очередь, приведет к вылету 3ds Max.

А еще чего сложнее ситуация, когда нужно просчитать лесной массив из 1000 елок, каждая из которых сделана геометрией и «весит» не меньше люстры…

Такой массив попросту не загрузиться даже во вьюпорт.

Разумеется, что ставить сервера с сотнями гигабайт ОЗУ не выход, собственно как и отказаться от рендеринга таких сцен.

Именно по этому было придумано оригинальное решение – выносить сложные объекты за приделы сцены.

Как это происходит?

Объект помещается в сцену. Затем, из нее он сохраняется в специальный файл на жесткий диск, содержащий информацию о геометрии объекта. А сам объект, замещается условным контейнером, остающимся на его месте в сцене и дающим лишь формальное представление о габаритах этого объекта.

В итоге сцена уже не содержит этот высокополигональный объект, а содержит контейнер со ссылкой на файл с информацией о геометрии сцены.

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

Теперь, подошло время стартовать рендеринг.

Сцена начинает просчитываться.

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

Когда же, при просчете новых бакетов не в один из них не попадает этот контейнер, то информация о нем выгружается, освобождая место в ОЗУ, для новой порции геометрии.

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

Собственно это и есть суть работы динамического рейкастера (Dynamic Raycaster), которым все такие объекты и считаются.

И так происходит со всеми такими контейнерами в сцене.

Я настоятельно тебе рекомендую полностью прочесть нашу статью о работе рейкастера в VRay, чтобы лучше понимать о чем вообще идет речь

Возвращаясь к нашим прокси, то этот контейнер собственно и есть Proxy объект.

Слово proxy по английски, буквально обозначает замещающий или уполномоченный, что идеально характеризует наш контейнер, замещающий геометрию, и являющийся уполномоченным представителем ее в сцене

Так как мы работаем в V-Ray, то его прокси объекты, без излишней оригинальности, названы VRayProxy, хотя прокси объекты используют и многие другие рендереры, а внешние файлы для выноса геометрии, имеют расширение *.vrmesh.

Собственно это и вся базовая теория по поводу VRayProxy.

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

Это полнейшая глупость.

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

Привет!

Очень странное поведение, если ты просто создаешь прокси из объекта (Selected Object => Vray mesh export =>…). Возможно, это последствия применения какого-то модификатора к этой модели. Например, меппинга и при переводе в прокси он или его настройки сбиваются.

Чтобы исключить это, тебе следует, во-первых слить все в один объект (команда Attach), во-вторых применить ко всей модели утилиту Reset XForm, а в-третьих, после этого, воспользоваться утилитой Collapse и превратить эту модель в один цельный объект Editable Mesh.

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

Обе утилиты находятся в меню Utilities панели Command.

После чего переводи модель этого кресла в прокси.

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

Привет!

Сама по себе карта, точнее текстура, это лишь часть материала. Наверняка, твое дерево имеет мульти-материал. То есть материал ствола, материал листьев (на разных ID) и т.д., а текстуры, которые идут в комплекте с это моделью, это текстуры использующиеся в этих материалах.

Кидая текстуру на любой объект, в сцене, 3ds Max автоматически применяет на него стандартный материал (Standard), с этой текстурой в канале Diffuse. Именно так и происходит у тебя, когда ты кидаешь текстуру на свое прокси дерево. По этому твое дерево и выглядит как «цвет текстуры»

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

Однако, прописывать пути лучше автоматически, через специально предназначенную для этого утилиту