Чего не работаете рендерится

Как не погореть со сроками. Варианты решения проблем долгого рендера.

Как развивать железо на котором работаешь и как избежать ситуации, когда 90% времени уходит на рендеринг. А то бывает, что все настроил, вроде бы круто,а после рендеринга что-то не устраивает, а он занял 10 часов…

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

Данная проблема не касается студий с рендер фермами, поэтому я поделюсь своими решениями этой ситуации для фрилансеров «одиночек».

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

Во-вторых, если есть возможность прикупить пару системных блоков, сделайте это! Но, это при условии, что у вас поток заказов, которые реально считать дома на 2-3 компьютерах, за желаемые клиентом сроки. Если такой заказ появляется разово, то используйте рендерферму.

Один раз мне надо было посчитать проект, я воспользовался услугами mozg4d.com, самым долгим было скачивать файлы рендера. То, что у меня считалось 4 часа, там было готово через 5 минут. А 20гб пассов, как раз и скачивал 2 часа. Это тоже надо учитывать.

Если же у вас нет денег на дополнительную технику, изучайте оптимизацию рендера. Не надо делать тесты на настройках middle и high. Со студентами отдельно рассматриваем тему «что замедляет рендер?», и получаем сокращение времени рендера в 1.2-3 раза. Для тестов можно считать просто вьюпорт, выбрав hardware/software rendering в меню «Make Preview». Рекомендую выставлять высокие параметры, перед самым финальным просчетом.

Я встречал ролики, которые считались с GI по 20-30 часов, а могли быть оптимизированны для просчета за 1-3 часа. Просто завышенные параметры не расчитаны на просчет на единичной машине.

• Не берите проект, который вы не можете потянуть на своём «железе»;
• Планируйте закупку нового оборудования, откладывайте деньги, если есть на это постоянный спрос;
• Арендуйте рендер фермы;
• Считайте тесты ролики в среднем и низком разрешении;
• Изучайте вопросы оптимизации рендера

Нет ничего обиднее того, что после даже шести часвого рендера заметить косяк, который вы увидели бы на превью и так, без GI и Area Shadows. Экономьте время, это тот ресурс, который нельзя восполнить или купить.

Источник

Рендеринг WEB-страницы: что об этом должен знать front-end разработчик

Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.

Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.

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

Процесс обработки WEB-страницы браузером

Для начала, рассмотрим последовательность работы браузера при отображении документа:

1. Из полученного от сервера HTML-документа формируется DOM (Document Object Model).
2. Загружаются и распознаются стили, формируется CSSOM (CSS Object Model).
3. На основе DOM и CSSOM формируется дерево рендеринга, или render tree — набор объектов рендеринга (Webkit использует термин «renderer», или «render object», а Gecko — «frame»). Render tree дублирует структуру DOM, но сюда не попадают невидимые элементы (например — , или элементы со стилем display:none; ). Также, каждая строка текста представлена в дереве рендеринга как отдельный renderer. Каждый объект рендеринга содержит соответствующий ему объект DOM (или блок текста), и рассчитанный для этого объекта стиль. Проще говоря, render tree описывает визуальное представление DOM.
4. Для каждого элемента render tree рассчитывается положение на странице — происходит layout. Браузеры используют поточный метод (flow), при котором в большинстве случаев достаточно одного прохода для размещения всех элементов (для таблиц проходов требуется больше).
5. Наконец, происходит отрисовка всего этого добра в браузере — painting.

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

Repaint

В случае изменения стилей элемента, не влияющих на его размеры и положение на странице (например, background-color , border-color , visibility ), браузер просто отрисовывает его заново, с учётом нового стиля — происходит repaint (или restyle).

Reflow

Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:

• Манипуляции с DOM (добавление, удаление, изменение, перестановка элементов);
• Изменение содержимого, в т.ч. текста в полях форм;
• Расчёт или изменение CSS-свойств;
• Добавление, удаление таблиц стилей;
• Манипуляции с атрибутом « class »;
• Манипуляции с окном браузера — изменения размеров, прокрутка;
• Активация псевдо-классов (например, :hover ).

Оптимизация со стороны браузера

Браузеры по возможности локализуют repaint и reflow в пределах элементов, подвергнувшимися изменению. Например, изменение размеров абсолютно или фиксировано спозиционированного элемента затронет только сам элемент и его потомков, в то время как изменение статично спозиционированного — повлечет reflow всех элементов, следующих за ним.

Ещё одна особенность — во время выполнения JavaScript браузеры кэшируют вносимые изменения, и применяют их в один проход по завершению работы блока кода. Например, в ходе выполнения данного кода произойдет только один reflow и repaint:

Однако, как описано выше, обращение к свойствам элементов вызовет принудительный reflow. То есть, если мы в приведённый блок кода добавим обращение к свойству элемента, это вызовет лишний reflow:

В итоге мы получим 2 reflow вместо одного. Поэтому, обращения к свойствам элементов по возможности нужно группировать в одном месте, дабы оптимизировать производительность (см. более подробный пример на JSBin).

Но, на практике встречаются ситуации, когда без принудительного reflow не обойтись. Допустим, у нас есть задача: к элементу нужно применить одно и то же свойство (возьмём « margin-left ») сначала без анимации (установить в 100px ), а затем — анимировать посредством transition в значение 50px . Можете сразу посмотреть этот пример на JSBin, но я распишу его и тут.
Для начала заведём класс с transition:

Затем, попробуем реализовать задуманное следующим образом:

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

Практические советы по оптимизации

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

• Пишите валидный HTML и CSS, с указанием кодировки. Стили лучше включать в , а скрипты — в конце .
• Стремитесь упрощать и оптимизировать селекторы CSS (этим часто пренебрегают разработчики, использующие препроцессоры). Чем меньше вложенность — тем лучше. По эффективности обработки селекторы можно расположить в следующем порядке (начиная с наиболее быстрого):
  1. Идентификатор: #id
  2. Класс: .class
  3. Тэг: div
  4. Соседний селектор: a + i
  5. Дочерний селектор: ul > li
  6. Универсальный селектор: *
  7. Селектор атрибутов: input[type=»text»]
  8. Всевдоэлементы и псевдоклассы: a:hover

  Следует помнить, что браузер обрабатывает селекторы справа налево, поэтому в качестве ключевого (крайнего правого) селектора лучше использовать наиболее эффективные — идентификатор и класс.

В скриптах минимизируйте любую работу с DOM. Кэшируйте всё: свойства, объекты, если подразумевается повторное их использование. При сложных манипуляциях разумно работать с «offline» элементом (т.е. который находится не в DOM, а в памяти), с последующим помещением его в DOM.

При использовании jQuery для выборки элементов придерживайтесь рекомендаций по составлению селекторов.

Для изменения стилей элементов лучше модифицировать только атрибут « class », и как можно глубже в дереве DOM, это и более грамотно с точки зрения разработки и поддержки (отделение логики от представления), и менее затратно для браузера.

Анимировать желательно только абсолютно и фиксировано спозиционированные элементы.

Можно отключать сложные :hover анимации во время скроллинга (например, добавляя к body класс « no-hover »). Статья на эту тему.

Надеюсь, каждый читатель извлёк из статьи что-нибудь полезное. В любом случае — спасибо за внимание!

UPD: Спасибо SelenIT2 и piumosso за верные замечания по поводу эффективности обработки CSS-селекторов.

Источник

Почему не работает RT рендер?

Jketov

Пользователь сайта

Столкнулся с пока неразрешимой проблемой.

У меня вообще не хочет работать RT рендер. Просто катастрофически пожирает память и в итоге вылет. Не работает ни один из режимов.

V-Ray перепробовал все версии. Сейчас стоит 3.60.03.

Сцена совсем небольшая. Комп хороший.

Буду очень признателен за помощь. Очень бы хотелось гпу рендер.

Boris Kulagin

Мастер

Jketov

Пользователь сайта

Win 10, SSD, 64gb DDR4, GTX 1070 8gb, i7 6700K 4GH.

Сам V-Ray быстро, прекрасно рендерит. Как только перевожу в режим RT, то сжирает все 64 гига и один хрен вылетает. Ничего не пишет по ошибкам. Текстуры все показывает что прогружает.

Итого попробовал еще сцену сократить, что то там запыхтел непонятно как. Картинка полный отстой, шум, гамма не та. Удалось запустить только на 2018.

Бабуин

Мастер

Boris Kulagin

Мастер

Мелкая такая сценка. Еще и текстур куча. Но вот почему естся оператива — это загадка.

Jketov

Пользователь сайта

Fedotov

Знаток

Скорее всего RT не видит видеокарту.

Как подключить VRay на GPU
1. Кнопка пуск.
2. Все программы.
3. Chaos Group.
4. V-Ray RT Adv for 3ds Max 2017 for x64.
5. Select OpenCL devices for V-Ray RT GPU.
6. В появившемся окне должны определиться все видеокарты. Нажимаем кнопку Set devices. Закрываем окно.
7. Запускаем Макс. Жмем F10.
8. Вкладка V-Ray RT => Engine type => CUDA

Бабуин

Мастер

Fedotov

Знаток

Бабуин

Мастер

Jketov

Пользователь сайта

В общем все определялось изначально.
В итоге на очень облегченной сцене. Хотя рендерят весьма большие, картинка просто ужасная. Огромное количество артефактов, фликов, непонятные черные квадраты местами. Подготовка к рендеру занимает чуть ли не минуту. Еще забавная вещь, что после использования RT сцена стала грузиться очень долго. Если раньше 10-15 секунд, то сейчас порядка минуты.

Итого V-Ray Adv все рендерит очень хорошо и довольно быстро.

Рендер фермы в принципе не интересуют. Очень уж дорого обходятся + сцена должна быть отлажена хорошо.
Интерактив тоже не интересует. Он прекрасно работает в V-Ray Adv.

Меня интересовал именно рендер на гпу , для конечной отрисовки.

Я рендерю сотнями картинок в разрешении 10000px*5000px. Короны и V-Ray Adv вешаются напрочь по времени.

Для меня хоть 4 1080 купить не проблема, если в этом есть смысл. Октан как то не зашел, пока.

Fstormrender что то так внятно и не ответил по поводу своей подписки, мол судятся и все. Че-каво я так и не понял.

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

Источник

Чего не работаете рендерится

Доброго времени суток. Суть проблемы такова. При рендере, не имея особых эффектов, а лишь цветокор и шум поверх — Премьер виснет намертво. При этом делает это в разных местах (то есть проблема не в конкретном, тяжёлом месте). Особенность проблемы в том, что после перезагрузки ПК рендер стабилен и обычно завершается без мёртвых зависаний. При этом ошибки никакой не выдаётся. Просто полоса рендера и таймер зависают.

Что уже было сделано и не помогло.
1. Чистка Кэша.
2. Перенос программы на быстрый SSD с последующим освобождением места на дисках под проекты.
3. Удаление сторонних кодеков KMPlayer Classic, Megapack и т.д.
4. Переустановка Виндовс на новую, чистую (образ не тронут и в нём всё как в оригинале, ничего не вырезано/изменено и т.д.)

До этого была версия CC2018 и более слабый ПК, а именно:
Проц: i5 3550 4 ядра 3,5 мГц.
ОЗУ: 8 Гб 2300 мГц.
Видеокарта: GTX 1060 6 Гб.
БП: 600 Вт.

После Апгрейда:
Проц: Ryzen R7 3700X 8/16 4,2 мГц.
ОЗУ: 32 Гб 3000 мГц.
Видеокарта: та же.
БП: Тот же.

По сути ПК, именно для монтажа стал в разы мощнее, однако на деле — появились только проблемы и нестабильность.

Да, я перешёл на новую версию CC 2020 (Версия 14.0.3), пользуюсь теми же плагинами, которых очень не много. В основном юзаю всё встроенное и плагины компании Red Gaint, что давно на рынке и явно созданы далеко не энтузиастами-не умельцами.

Хочу именно решить проблему, откатить версию, ибо привык разбираться с причинами, а не искать затычки. К тому же у многих, как я понял, всё работает стабильно и без нареканий, а я чем «хуже»?

Ещё один момент. Ранее я рендерил проекты с цветокором и шумами сверху, всё и всегда на GPU. Сейчас у меня проект без крутых наворотов приходится рендерить сначала без цвета, после с корректирующим слоем и цветокором, а уже после всего — с шумом, ибо рендер тупо не вывозит. А все эти действия — колоссальная трата времени (и нервов). Так что я хочу всё решить и работать в удовольствие! (как я и планировал, апгрейдя ПК)

Ах, вот ещё. Я так же после апгрейда не долго думая приобрёл 4К монитор диагональю 49″. Возможно и это как-то сказалось? Но ведь я не менял настроек рендера и до этого, работая с 4К форматом проблем не наблюдалось.

Последнее. Мои предположения, которые могут вызывать проблемы.
1. Так как после перезагрузки ПК рендер «оживает», то можно предположить, что проблема софтверного характера. Что-то загружает CPU/GPU/ОЗУ?! Ранее была проблема с перегрузкой ОЗУ (до апгрейда), после чего рендер зависал и я решил это программкой для активной чистки ОЗУ, но запустив её сейчас, я увидел, что оперативка не загружена, плюс — программа ничего не изменила и рендер так же зависал.
2. Нехватка мощности БП. Однако в серьёзных играх нагрузка на GPU, как по мне, и в целом на БП — не меньше, хотя, кто его знает?! (Купить новый БП смогу не скоро)
3. Проблемы с GPU.
4. Проблема именно с версией CC 2020.

Источник