Рейтинг темы:
  • Голосов: 0 - Средняя оценка: 0. Если голосов меньше 5 оценка не показывается.
  • 1
  • 2
  • 3
  • 4
  • 5
Оптимизация вьюпорта и сцены
#1
Information 
1. Оптимизация вьюпорта

Складывается из трех составляющих:
  • настройки OpenGL. Угу, это третье (стороннее, у DAZ нет своего) рендердвигло в составе DS, помимо 3Delight и Iray. Вернее даже первое, так как большую часть времени, работающие в DS, видят только его работу. OpenGL вполне себе реалтайм и используется помимо (всех?) 3D-редакторов, в куче 3D-игр, начиная с бородатого Quake 1 и заканчивая многими современными.
  • количество геометрии на сцене
  • объемы загружаемых текстур
---
OpenGL

Во вьюпорте, для работы, используется один из десяти OpenGL-режимов. 11й режим, Iray, обычно включается только при выставлении света от невидимых для OpenGL источников, специфичных для Iray (поверхности с emissive-шейдером и Dome). Работать в этом режиме даже на топовом бытовом железе в общем-то нельзя, за редкими исключениями

Можно сказать, что каждый OpenGL-режим заточен на "работу по специальности" и предполагает определенный пакет действий человека. Например, при первичном размещении объектов (также зачастую при позинге) не требуются ни отображение текстур, ни отображение сетки полигонов и наиболее подходящим будет Smooth shaded. В редакторе геометрии текстуры не нужны, зато постоянно требуется переключение между различными сетками. И так далее.

Самый скоростной OpenGL режим - Smooth shaded (гладкая поверхность без текстур). Есть еще два более скоростных box-режима, но сейчас они уже как копчик, остались от вымерших австралопитеков с уже забытыми предназначениями. В остальных режимах используются текстуры и/или идут дополнительные затраты на прорисовку границ полигонов и при неслабом кол-ве геометрии/текстур всё это дело может как следует затормозить.

Настройки OpenGL доступны по кнопе F2, вкладка Interface. Как правило, достаточно выставить "Best" в "Display Optimization" (для владельцев GF 9хх/1ххх обязательно). Остальное можно понижать, если ничего другое уже не помогает.
Настройки конкретного OpenGL-режима меняются в табсе Draw Settings (меню Window - Panes (Tabs)). Расписывать не буду, в общем тут  "свои фломастеры", а меня лично всё устраивает по дефолту.
---
Геометрия

Для затравки: сцена с 3 млн. полигонов в игровых движках Unity/Unreal считается сложной и для большинства железок, имеющихся на руках у населения планеты, реалтаймово тормозящей - без относительно дорогостоящих ручных оптимизаций странно звучащих хреновин. Nuff said.

Как всем известно, модели персонажей в DS весьма малополигональные (всего 16к-67к+ полигонов), но при этом очень многополигональные (аж целых 16к-67к+ полигонов). Первое жутко бесит тех, кто пытается работать с ними в Zbrush без навыков переноса геометрии (шутка с долей шутки), второе легко вызывает баттхерт при работе в самой DS с несколькими персами и окружением.

Sub-d
Оно же известно как subdivision surface (или subdiv),  используется для сглаживания поверхностей и тем самым повышения качества картинки (угловатые жопо-сиськи в варкрафт 3? они не использовали sub-d...). При включенном sub-d каждый полигон подразделяется на 4-8-16 (и так далее по степеням двойки) виртуальных полигонов и кубик довольно просто превратить в шарик, как это показано по ссылке выше. sub-d также попутно используется как хак для корректного отображения более мелкой детализации, чем позволено основной геометрией.

Обычный для Генезисов диапазон полигонов  в 16-67к это соответственно кол-во полигонов базовой модели и кол-во при включеном sub-d=1. По умолчанию sub-d у всех Genesis включен и для вьюпорта =1 (67к), а для рендера =2 (237к). Кол-во всех полигонов на сцене и на выбранной модели можно глянуть в табсе Scene Info (там показывается инфа для вьюпорта, не для рендера). Подразделение полигонов и сглаживание производит процессор за свой счет, затем хранит полученные результаты в памяти за счет памяти.

При работе с несколькими персонажами и проявляющихся тормозах имеет смысл снизить нагрузку на обсчеты и рендер сцены во вьюпорте - временно (или постоянно, при желании) выставить более низкий уровень sub-d, либо вообще выключить его. Настройки находятся в табсе Parameters - General/Mesh Resolution. За включение/отключение sub-d, отвечает Resolution Level - при "Base" будет использоваться только базовая геометрия (16к), при "High Resolution" - кол-во видимых полигонов регулируется ползунками ниже: SubDivision Level - отвечает за вьюпорт, а Render SubD Level (Minimum) - при рендере и его значение не может быть меньше чем вьюпортовское.

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

Отличие групп от простой вложенности объектов друг в друга (объект Eyelashes вложеный в объект Genesis 8), то, что действия с группой влияют сразу на все объекты группы. При этом можно легко управлять видимостью нескольких объектов, просто отщелкивая "значок глаза" рядом с названием группы в иерархии сцены. Скрытые таким образом группы не участвуют ни в каком рендере - ни в рабочем OpenGL, ни в финальном Iray/3Delight, соответственно снижая нагрузку на железо.
Группы можно вкладывать друг в друга. Например создана группа "House", в которую помещены две подгруппы "Furniture_Bedroom" и "Furniture_Kitchen" - теперь можно в 1 клик скрыть дом со всем содержимым, а можно только мебель на кухне или только в спальне, в зависимости от того, что именно в данный момент не требуется.
Иногда удобно помещать в отдельную группу даже одного персонажа - с волосами, ресницами, гениталиями, 10 одетыми на него предметами и с общим количеством полигонов в 1-2 млн.
Кстати про гениталии... все ли их скрывают/удаляют, когда одевают на перса платье или штаны? А ведь они, помимо доп.геометрии и доп.загрузки CPU для подгонки auto-fit и морфов задействованных на персонаже, еще содержат полноценный набор текстур (особенно "нестандартные" гениталии типа Golden Palace, которые просто копируют поверхность с торса персонажа)
---
Текстуры
OpenGL на самом базовом уровне "понимает" материалы для Iray/3Delight и не может отображать большинство параметров поверхностей подготовленных для этих рендеров. Будут показаны только текстуры или значения из Base Color (основной диффузный цвет) и из Cutout Opacity/Refraction Weight (полупрозрачность).
Тем не менее, при низком FPS во вьюпорте можно попробовать выбрать вышеупомянутый режим SmoothShaded. Видеокарте не придется делать "лишние телодвижения" по наложению и отрисовке текстур, хотя они всё же будут загружены в память.

С вьюпортом наверное всё. Оптимизация текстур будет рассмотрена отдельным постом.

 
1
1
1
Ответить
#2
2. Оптимизация сцены

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

Основной разбор настроек Iray имеется в соседней теме, так что можно не повторяться. С 3Delight я не работаю и поэтому не считаю себя вправе о нем писать всякую ахинею

Геометрия сцены
Базово почти 1 в 1 с вьюпортом. Разве что здесь надо плясать от кадра: учитывая его размер, степень видимости и удаления объектов от камеры.

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

Для корректного глобального освещения (отражение света от ближайших объектов) иногда возможно потребуется  выставить на примитив подходящий Base Color. У отраженного света нет детализации и натягивание текстурного шейдера (с хитрым позолоченным орнаментом по белой штукатурке) на плоскость изображающую потолок, для отражения света настольной лампы ничем не лучше покраски этой плоскости в однотонный почтибелый (вообще следует избегать чистых цветов, в природе они не встречаются) цвет - только отнимет память под текстуры и замедлит рендер.

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

Текстуры

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

Азы
Что такое текстура с точки зрения оптимизации?
Картинка с тремя измерениями: ширина x высота x разрядность цвета.

Первые два измеряются в точках-пикселях и в пояснениях не нуждаются. Последнее измеряется в битах на одну точку и отвечает за возможное количество оттенков цвета и часто, но не всегда, за степень прозрачность точки. Разрядность в абсолютном большинстве случаев равна 32 битам (3 цветовых канала RGB + канал прозрачности, по 8 бит на каждый канал). Таким образом довольно просто вычислить реальный объем текстуры.

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

Несжатый размер 32 битной текстуры 512х512 пикселей:
512*512 = 262144 точки * 32 бита (оно же 4 байта, 1 байт=8 бит) = 1048576 байт = 1 мегабайт

То есть, такая текстура, считанная с диска займет в памяти 1 мегабайт (неважно, залита она одним сплошным черным цветом или содержит многоцветный сложный рисунок). Вроде бы немного. Но тут два "но":
- при увеличении размеров вдвое, объем текстуры увеличивается вчетверо (1024x1024x32=4 мб, 2048x2048x32=16 мб, 4096х4096=64 мб, 8k = уже четверть гигабайта, одна текстура 16k = 1 гигабайт...  shok дальше считать пожалуй не будем)
- количество текстур на дазовском персонаже ~=30-35
Так что обе эти (вроде бы таких малозначительных поначалу) хреновины легко смогут построить комп так, что он будет бояться даже случайно пукнуть, а не то чтобы что-то рендерить.

Пример. Ставим в пустую стандартную сцену стандартную G8F c её стандартной двадцать одной 4k-текстурой (iray-материалы). Все текстуры хранятся сжатыми в .jpg и занимают на диске смешные 25 мегабайт. Запускаем рендер, после первых итераций останавливаем и смотрим лог-файл (Help - Troubleshooting - View log file):
IRAY   rend stat : Texture memory consumption: 549.001 MiB*
"Смешные мегабайты" заняли в памяти полновесные полгигабайта. А это всего лишь пустая сцена и голая лысая баба  big_boss  А что будет при надевании на неё волос, знойных влажных текстур кожи, каких-нибудь тряпочек с текстурами тряпочек, постановке стен с текстурами обоев, мебели с текстурами дерева, большой кровати и добавлении в эту кровать трех симпатишных, волосатых, бородатых и игривых пожарников в самом расвете лет... можете представить сами, но скорей всего будет уже не так весело, как казалось бы.

* На самом деле текстуры из примера должны были занять ~1.3 гигабайта (смотрим выше реальный объем текстуры 4к и умножаем на 21 штуку), но Iray получив "расжатые дазом из .jpg"-текстуры перепаковывает их снова, под свой внутренний формат (при подготовке сцены к рендеру). Выигрыш от этой скрытой перепаковки зависит от сцены, но обычно составляет около 2/3 от реального объема. Влиять особо на этот процесс нельзя, можно лишь задать размеры текстур, при достижении которых будет произведена либо средняя, либо высокая степень сжатия. Два параметра находятся в табсе Render Settings, вкладка Advanced - Texture Compression. По умолчанию текстуры выше 512х512 сжимаются средне, а выше 1024х1024 сильно. Разница между средним и сильным сжатием небольшая, судя по древней инфе от iraydevblog порядка 5%, причем это единственная на данный момент инфа, которая вообще нашлась на эту тему

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

 
1
Ответить


Переход:


Просматривают эту тему: 1 Гость(ей)