Фотографичность в Unity? Повышаем четкость картинки.

Научился сам? Помоги начинающему.

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение waruiyume 23 июл 2019, 03:24

Для фанатов, у которых нет времени скачать... скриншоты:
Изображение Изображение Изображение Изображение Изображение Изображение Изображение
Особенно мне нравится кресло с покрытием из вздутого шпона!
Аватара пользователя
waruiyume
Адепт
 
Сообщения: 6143
Зарегистрирован: 30 окт 2010, 05:03
Откуда: Ростов на Дону

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение AngryCat 23 июл 2019, 12:09

Ну кстати есть взять последнею картинку и отбросить тот факт, что модели там либо сделаны на скорую руку либо бесплатны, то могу сказать, что касается самой четкости картинки - Это очень неплохой результат! Заменить модели и я бы не поверил, что это игровой движок!
Здесь могла бы быть ваша реклама.
Аватара пользователя
AngryCat
Старожил
 
Сообщения: 716
Зарегистрирован: 20 июл 2018, 22:29
Skype: Дискорд - Флеш#4099

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 23 июл 2019, 13:45

Вчера перепутал билды и выложил билд в котором был запечен свет без дополнительных источников света. А вот билд, который был запечен с дополнительными источниками света, но сейчас они отключены. https://yadi.sk/d/q8wawnLWokFDMw
Разница хорошо видна. Первый случай, мы наблюдаем глубокую констрастность, как раз по тому что есть только отраженный свет. Стена у окна и вовсе темная, поскольку на нее меньше всего попадает отраженного от поверхностей света. В реальности, атмосферное рассеивание света происходит постоянно, имеет свой коэффициент, благодаря чему небо у нас голубое, а даль синеватая. Во втором билде, дополнительные источники света как раз и пытаются этот недостаток невилировать, что конечно фиксируется в картах света. И если потом их отключить, то у нас остается вот такая светлая комната, как будто за окном день, а комнату освещает солнце.
Я хочу особо подчеркнуть, что два билда абсолютно идентичны, с одинаковыми настройками, используют одни и те же вычислительные мощности, но с разными приемами при запечении карт. Результат получаем так же разный.

Есть еще один очень важный момент, который как раз показал waruiyume. Если не использовать дополнительные источники света, то появляются "артефакты" тени на коробках которые лежат на верхних полках стелажа. Я взял в кавычки слово "артефакты", по тому что на самом деле, с точки зрения движкак каз раз все в порядке. Свет отражаясь от стены, попадает только на часть коробок, а другую часть закрывает стена стелажа. В самой же ячейке стелажа, свет отражаясь от стенок, освещает ячейку, поэтому она не затенена как та часть коробки. Единственный способ избежать подобного без дополнительного освещения - это снижать общее качество просчета освещения. Чем выше будет качество просчетов, тем сильнее будет выражен "артефакт". Это прямое следствие того, что обсчет идет только по отражаемым поверхностям.
Умные люди отсюда могут сделать вывод, что идеальная среда для Юнити и прочих движков - безвоздушное пространство, например космическое. В остальных случаях придется готовить бубны и разучивать танцы.

Итак, теперь вывод. Для получения наивысшего качества, необходимо:
1) Совмещать Realtime Lighting и Baked Global Illumination. Baked Global Illumination должен быть в режиме Shadowmask.
2) Настройки Lightmapping должны быть высталены на Enlighten.
3) Indirect Resolution по прежнему должен быть не более 1.
4) Lightmap Resolution иметь как можно более высокое значение.
5) Lightmap Padding иметь как можно более высокое значение. Покрайней мере не менее 5.
6) Lightmap Size иметь максимально возможное значение.
7) Compress Lightmaps должен быть отключен.
8) Final Gather должен быть включен
9) Ray Count у Final Gather должен иметь как можно большие значения
10) Denoising отключен, во избежания появления артефактов от применения фильтра.
11) Directional выставлен на Indirect Intensity
12) Lightmap Parameters иметь настройки озвеченные выше.

waruiyume писал(а):Для фанатов, у которых нет времени скачать... скриншоты:
Особенно мне нравится кресло с покрытием из вздутого шпона!

Благодарю. Я не думал что это занимает много времени. Я не выкладываю скриншоты по тому что в конце концов они попадают в архив хостинга и становятся недоступны для читателей. Я в затруднении как отнестись к последнему высказыванию, поскольку не предполагалось что на него будут смотреть так близко. Цели последних билдов в показе освещения.
AngryCat писал(а):Ну кстати есть взять последнею картинку и отбросить тот факт, что модели там либо сделаны на скорую руку либо бесплатны, то могу сказать, что касается самой четкости картинки - Это очень неплохой результат! Заменить модели и я бы не поверил, что это игровой движок!

Абсолютно верно. Весь билд затачивался именно под это расстояние. Все модели либо очень дешевые, либо бесплатные.
Действительно качественные модели и текстуры будут применены для финального результата.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 17 авг 2019, 16:07

Обновление темы.

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

Progressive CPU
Предисловие.
Система довольно старая и как следствие по ней тонны всякой и разной информации. Думаю можно составить отдельное исследование по этому вороху информации. Я же по понятным причинам не буду делать обзор на эту информацию, а приведу ссылки которые как мне показалось, достойны внимания.
Для того что бы оперативно находить нужную информацию в приведенных ссылках, надо использовать ctrl+f.

В версии 2019.1 был добавлен новый функционал и изменен функционал некоторых систем. Я буду отмечать эти моменты если вдруг вы еще на версии 2018.3/4.

Скриншоты waruiyume навели на мысль о контроле сложных мест. Очень часто, на невооруженный взгляд некоторые места не кажутся сложными, однако с точки зрения расчетов, они могут быть предельно сложными. К сожалению в Юнити с визуальными средствами контроля все очень слабо, что конечно огорчает и я считаю именно это в большинстве случаев приводит к посредственным графическим результатам проектов.
Один из инструментов контроля который напрашивается сам, это визуальное представление пускаемых лучей при просчете сцены. Т.е. что бы можно было увидеть источник луча, его направление, отскок и где он закончил свои расчеты. Я не разбирался можно ли такое сделать, но если кто заморочится на эту тему то сделает большое одолжение сообществу. Скорее всего этот инструмент нельзя будет использовать на сложных сценах, но в большинстве случаев это и не нужно. Если есть сомнения, то можно просто взять часть сцены и воссоздать в отдельной сцене примерное освещение, чтобы понять что идет не так в конкретном случае.
В любом случае когда вы начинаете работать с освещением, то надо представлять как идут лучи света. Пока что алгоритмы систем освещения находятся на таком уровне, что наилучший результат вы увидите только тогда, когда камера будет смотреть в полусферу не в направлении света, а полусферу обращенную в сторону источника света. Из чего можно сделать вывод, что расставлять дополнительные источники света следует в противоположную сторону от основного освещения, так что бы всякий раз когда камера будет повернута в ту же сторону что и основной источник света, неточности алгоритмов освещения компенсировались дополнительными источниками света. Так следует поступать во всех программах где вы используете свет, не только в Юнити.

Так же, хочу предложить простой и надежный способ для объективного сравнения полученных результатов. Для этого понадобится Паинт и все. Когда вы провели расчет сцены, то просто нажимаете Принт Скрин и вставляете этот скрин в Паинт. Снимаете выделение. Затем делаете новый расчет и снова делаете скрин с результатом. Снова вставляете его в Паинт. Снимаете выделение. Теперь простым ctrl+z и ctrl+y сравниваете результаты. Важно лишь не менять ракурс камеры и вы сможете заметить мельчайшие изменения результатов.

Теперь начнем.
За перевод спасибо гуглу.

Progressive Lightmapper - это система Lightmapper, основанная на быстрой трассировке пути, которая обеспечивает запеченные карты и световых с прогрессивными обновлениями в редакторе. Это требует неперекрывающихся ультрафиолетовых лучей с небольшими площадными и угловыми ошибками и достаточного заполнения между диаграммами.
Progressive Lightmapper делает короткий подготовительный шаг для обработки геометрии и обновлений экземпляров, а также генерирует G-буфер и маски диаграмм. Затем он немедленно производит вывод и постепенно улучшает его для значительно улучшенного процесса интерактивного освещения. Кроме того, время выпечки намного более предсказуемо, потому что Progressive Lightmapper обеспечивает приблизительное время выпечки.
Progressive Lightmapper также испускает глобальное освещение (GI) с разрешением карты освещения для каждого текселя в отдельности, без схем повышающей дискретизации или использования каких-либо кэшей освещенности или других глобальных структур данных. Это делает его надежным и позволяет запекать отдельные части световых карт, что ускоряет тестирование и итерацию вашей сцены
Подробное видео, демонстрирующее интерактивный рабочий процесс, см. В пошаговом руководстве по видео для Unity: в разработке - Progressive Lightmapper (YouTube) https://youtu.be/foMZJrwRGr0 .

Settings
Чтобы использовать Progressive CPU Lightmapper, выберите Window > Rendering
> Lighting Settings, перейдите к настройкам Lightmapping и установите Lightmapper
к Progressive CPU . Посмотрите Настройки Lightmapping для получения дополнительной информации об этом окне.

Prioritize View
Включите это, чтобы Progressive Lightmapper применял изменения к текселям, которые в данный момент видны в представлении сцены, затем примените изменения к текстам вне поля зрения.

Multiple Importance Sampling
Включите этот параметр, чтобы использовать выборку с несколькими значениями для выборки из среды. Как правило, это приводит к более быстрой конвергенции при создании световых карт, но может привести к более шумным результатам в определенных низкочастотных средах. Это отключено по умолчанию.
Добавлена в версии 2019.1 и ее описание выглядит так:
Multiple Importance Sampling for Environment (MIS Environment) is a new sampling method which samples the most important areas in the cubemap/HDRI. This sampling technique avoids shooting a large number of GI rays into the hemisphere, and instead focuses them on the important areas (such as bright spots, like the sun). With this feature, it’s possible to bake scenes with measured HDRI environment maps that are highly non-uniform. A new Environment Samples parameter has been added to the lighting window. This value controls how many rays are traced directly into the environment per lightmap texel.
Выборка по нескольким значениям для среды (MIS Environment) - это новый метод выборки, который выбирает наиболее важные области в кубической карте / HDRI. Этот метод выборки позволяет избежать попадания большого количества GI-лучей в полушарие и вместо этого фокусирует их на важных областях (таких как яркие пятна, такие как солнце). С помощью этой функции можно запекать сцены с помощью карт измерений среды HDRI, которые сильно неоднородны. Новый параметр Environment Samples был добавлен в окно освещения. Это значение контролирует, сколько лучей попадает непосредственно в среду на один пиксель карты освещения.
Ссылка - https://blogs.unity3d.com/ru/2019/04/16 ... ty-2019-1/.
Ссылка на разъяснения отличий старого подхода и нового - https://forum.unity.com/threads/confusi ... rs.683041/
Разъяснения по эффекту, правда не в Юнити, а вообще – https://3dyuriki.com/2013/09/06/renderi ... ng-luchej/

От себя. Эффект проявляется при использовании дефолтного скайбокса (в моем случае, либо скайбокс есть, либо его нет). Во всех моих случаях, он осветлял тени. Однако в видео, где человек как раз разбирает этот эффект - https://www.youtube.com/watch?v=ESODq5KBOVw как раз хорошо показывается работа алгоритма. Я же проведя подобные тестирования получил сходные результаты.
Следует помнить, что используя этот эффект без фильтра, вы добавите на сцене «светлых пятен» у теней.
Еще одна ссылка - https://twitter.com/pigselated/status/8 ... 1109727232

Direct Samples
Количество образцов (путей), снятых с каждого текселя. Этот параметр контролирует количество образцов, которые Progressive Lightmapper использует для расчетов прямого освещения. Увеличение этого значения может улучшить качество световых карт, но увеличивает время выпечки.

Indirect Samples
Количество образцов (путей), снятых с каждого текселя (размеры текселей регулируется в Lightmap Resolution). Этот параметр определяет количество образцов, которые Progressive Lightmapper использует для расчетов непрямого освещения. Для некоторых сцен, особенно для наружных сцен, должно хватить 100 образцов. Для внутренних сцен с излучающей геометрией увеличивайте значение, пока не увидите желаемый результат.
Если значение слишком низкое, то тени будут с проплешинами.

Основной параметр который повлияет на конечный результат. Как видно из справки, чем выше значение, тем лучше.
Создается впечатление, что этот параметр увеличивает разрешение текселя из Lightmap Resolution. Условно говоря, если размер текселя будет равен 1, а значение Indirect Samples равно 8, то он разобьет тексель на 8 ячеек.
Если Lightmap Resolution будет равен значения по умолчанию 40, то чем меньше значение Indirect Samples, тем хуже будут просчитаны тени. Но чем меньше значения Lightmap Resolution, тем ситуация будет становиться «лучше». Сложно сказать когда это будет преимуществом, но факт так сказать на лицо. Наверное это даст плюс если на первом месте производительность, а не качество.
Имеет рационально максимальное значение, которое к сожалению определить не удастся, поскольку нет ни каких объективных средств контроля за этим. Единственный способ определить оптимальное значение, это либо на глаз, либо используя Паинт и ctrl+z / ctrl+y вычисляя момент когда качество картинки становится неизменной, если вы увеличиваете значение, либо когда картинка остается неизменной, если вы снижаете значение.

Environment Samples
Введен в версии 2019.1.
Определите количество образцов, которые Lightmapper использует для расчетов освещения окружающей среды. Более высокие значения могут улучшить качество световых карт, но увеличить время, необходимое для выпечки. Это устанавливается на 500 по умолчанию.
Далее, выдержка из https://blogs.unity3d.com/ru/2019/04/16 ... ty-2019-1/
Новый параметр Environment Samples был добавлен в окно освещения. Это значение контролирует, сколько лучей попадает непосредственно в среду на один пиксель карты освещения.
Еще одна ссылка с примерами – https://learn.foundry.com/modo/content/ ... ation.html
Determines the number of samples taken of the environment used for global illumination. More detailed environments benefit from additional samples, increasing the accuracy of the final render, but also increasing render time. On low resolution or low detail environments, you can keep this value low to reduce render time.

The image on the left has importance sampling disabled and uses an HDR image for environment lighting with a bright spot (sun). With 128 IC rays, undesirable splotches are visible that are eliminated in the middle image by increasing the IC rays 8 times to 1024 rays. The third image enables Importance Sampling at default values and resets the IC rays back to 128 rays. Note the crispness of the shadow and the complete lack of any splotches, producing superior result with only a slightly longer render than the left image.
Note: When Environment Importance Sampling is enabled, the same option is available in the Settingstab, called Environment.
На всякий случай скопировал, если вдруг тот сайт куда то исчезнет.
В моем же случае, эффект проявился только с дефолтным скайбоксом (либо скайбокс есть, либо либо его нет) и полностью подтверждает выше сказанное. Из чего можно сделать вывод что использование Environment Samples целесообразно либо для того что бы снизить значения Importance Sampling, либо вы уже используете масимальное значение Importance Sampling, то улучшить качество расчетов за счет более высоких значений Environment Samples (поскольку объективных данных Importance Sampling получить невозможно, то скорее будет преобладать первый случай).

Bounces
Используйте это значение, чтобы указать количество косвенных отказов, которые нужно выполнять при трассировке путей. Для большинства сцен достаточно двух отскоков. Для некоторых внутренних сцен может потребоваться больше отскоков.
Тут все просто. Наиболее емкое описание взято отсюда - https://sites.google.com/site/rusewyl/g ... -v-detalah. Правда информация настолько старая, что практически не пересекается с текущим состоянием дел. Последняя активность на сайте наблюдалась в 2015г…
Количество переотражений света в симуляции глобального освещения. Как минимум одно отражение или преломление требуется для обеспечения мягкого, реалистичного непрямого освещения. 0 означает, что будет рассчитываться только прямой свет.

Filtering
В 2019.1 был изменен.
Фильтр просто дает размытие теней по какому то выбранному алгоритму, что поможет замазать некоторые косяки, а заодно и все преимущества. +100 в карму разработчика, который замыливает все что не попадя для придания неповторимого шарма его творению. Как именно размывать тени дело сугубо личное.
Ссылки на документацию.
https://docs.unity3d.com/Manual/Lightmapping.html
https://unity3d.com/ru/how-to/progressi ... ation-tips
https://docs.unity3d.com/Manual/Progres ... apper.html

Статистика

Панель под опциями Auto Generate и Generate Lighting отображает статистику по картированию освещения, в том числе:

Количество созданных Unity световых карт
Memory Usage: объем памяти, необходимый для текущего отображения света.
Occupied Texels: количество текселей, занятых в УФ-пространстве карты освещения.
Lightmaps in view: количество карт освещения в представлении сцены.
Lightmaps not in view: количество карт освещения, которые находятся вне поля зрения.
- Converged: все расчеты для этих лайтмапов завершены.
- Not Converged: выпечка для этих лайтмапов еще продолжается.
Bake Performance : количество лучей в секунду. Если это низкий уровень (т. Е. Меньше 2), вам следует отрегулировать настройки или аппаратное обеспечение, чтобы обрабатывать больше световых лучей одновременно.

Кроме того.

В ходе экспериментов была выявлена зависимость Lightmap Resolution, Lightmap Size и Tranform Scale объекта на сцене.
Размер текселя строго коррелируется между Lightmap Resolution, Lightmap Size и Scale объекта на сцене. Можете подобрать оптимальное разрешение создаваемого файла световой карты по следующему алгоритму:
Переключаетесь на Baked Lightmap. Если вы считаете что Lightmap Resolution у вас настроен, то просто перебираете от меньшего к большему Lightmap Size до тех пор, пока размеры текселей не перестанут меняться. Как только дальнейшее увеличение значение не приведет к увеличению, это и будет порог оптимального Lightmap Size.
Можно собрать следующую тестовую сцену что бы увидеть эту зависимость. Для этого создаете куб и растягиваете его скажем до размера 10*10, обнулите позицию и задайте значение Y -0,5. Создаете еще один куб, оставляете размер по умолчанию. Lightmap Resolution по умолчанию равен 40, этого значения для тестирования более чем достаточно. Оставляете его без изменений. Ставите Lightmap Size минимальное значение в 32. Теперь вы видите, что размеры текселей у большого куба, не совпадают с размерами текселей у малого куба. Какими бы не были высокими значения Lightmap Resolution, размеры текселей останутся прежними. Вам необходимо добиться либо равных размеров текселей у обоих примитивов, для чего необходимо увеличивать Lightmap Size, либо, если Lightmap Size умеет нужное значение, снижать значения у Lightmap Resolution до тех пор, пока сетка не начнет увеличиваться. При дальнейшем снижении значения Lightmap Resolution, можно сравнять размеры сетки до большого куба, но при этом вы начнете терять в качестве.
При увеличении значения Lightmap Resolution и низком для него Lightmap Size, результат остается неизменным, из чего можно сделать вывод, что есть рационально максимальное значение для Lightmap Resolution, которое завит от Lightmap Size и scale игровых объектов. Развивая вывод, можно сказать что для наиболее прогнозируемых результатов, необходимо выдерживать на сцене одинаковые размеры объектов.
Вообще это довольно интересная штука, которая была случайно обнаружена. Ни где я не видел информации о такой зависимости. Это наводит на мысль, что можно регулировать подробность освещения, для каждого отдельно взятого объекта на сцене, просто масштабируя его соответствующим образом. Так же не стоит растягивать объекты, поскольку сетка растягивается в строгом соответствии давая по растянутой оси растянутые текстели.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 21 авг 2019, 13:34

Обновление темы

Ссылка на файл с текстом - https://yadi.sk/i/Ved_-rc4DzzDNQ

Из проведенных исследований можно сделать следующий вывод:
1) Multiple Importance Sampling - Наилучшим образом он себя проявит когда у вас есть освещенные HDR Скайбокс помещения с одним источником света. На открытом пространстве, если вы не используете фильтры, он скорее усугубит ситуацию добавив неоднородности теням, чем улучшит ее.
2) Direct Samples – Ситуация немного странная. По идее, непрямое освещение должно отталкиваться от прямого сета, но об этой зависимости не упоминается вообще нигде. По крайней мере я не нашел ее и не выявил. Максимум что я увидел, это более светлую картинку при более высоких значениях и то, это далеко не всегда заметно. Стоит трогать на сложных сценах, один из первых параметров для настройки. И конечно чем выше значение, тем лучше, хоть вы и не всегда увидите результат.
3) Indirect Samples – этот параметр должен быть как можно более высоким. Работает в строгой связке с Lightmap Resolution. Начинать надо от меньшего к большему. Субъективно, максимально видимый результат дает значение превышающее Lightmap Resolution в 10 раз. Иначе говоря если вы поставили значение Lightmap Resolution 10, то ставить значение Indirect Samples 200 лишено смысла. Однако повторюсь – это выведенное соотношение, субъективно. Так же не стоит для себя принимать какие строгие рамки. На одной сцене значение Lightmap Resolution может достигать максимума в скажем 100, для другой сцены этот максимум может достигать 400 и более. Соответственно значение Indirect Samples так же будет меняться.
4) Environment Samples – должен быть как можно более высоким. Начинать надо от меньшего к большему. Как только будет получен удовлетворительный результат, можно снижать значение Indirect Samples до тех пор, пока результат не будет изменен.
5) Bounces – чем больше, тем лучше. Много отражений не бывает, однако не стоит забывать что на сложных участках могут появиться артефакты из – за того что одни лучи отразились один раз и улетели, другие отразились 3 раза и осветили, третьи должны были отразиться больше раз чем возможно и дополнительно осветить, но не осветили и не дали скажем градиента. Наиболее предсказуемый результат будет при значениях 1 и 2, дальше смотрите за ситуацией – улучшается – увеличивайте, ухудшается – уменьшайте.
6) Filtering – если по какой-то причине у вас нет возможности использовать высокие вышеперечисленные значения, то фильтр сделает тени более равномерными. Во всех остальных случаях применять следует строго ситуативно и если ваша задача состоит в фотографической точности картинки, по возможности избегать применения.
По сути, его применение будет зависеть от значения Lightmap Resolution. Лесенки на тенях которые вы будете получать, будут соответствовать значениям Lightmap Resolution, проплешены значениям Indirect Samples. Не всегда есть возможность выкручивать значения на максимум, что приведет к слабому качеству, поэтому применение Filtering ситуацию может скорее улучшить, чем ухудшить.

Общие выводы по освещению.
От себя.
Детально рассмотрев не одну систему Юнити, у меня все больше укрепляется мнение что движок похож на некий Мех (mech), который создает какой-то безумный японец. Или француз, если бы был изящен. У меха нет прожектора? Берем прожектор и прикручиваем к роботу. Сразу четыре, разной системы - видимого освещения, инфракрасного, ультрафиолетового и… Хм, а пусть еще раз инфракрасный. Логично же? У меха есть ноги? Теперь у него будет нога и колесо. Раз есть колесо, то почему бы не прикрутить радар? Так, радар есть, нет унитаза в кабине. Косяк. Хитро вылюблиный унитаз теперь тоже есть. Прям в кресле пилота или кто там им управляет. В кресле тракториста, ибо наши родные чиновники по любому мех признают трактором. И т.д. Какое-то нагромождение внешних решений, которые между собой имеют мало общего, с чудовищно урезанными интерфейсами, без средств контроля. И вот все это приходит в движение, как-то двигается, куда-то то ли едет, то ли идет и стреляет во все стороны.
Я хочу что бы меня поняли правильно. Я очень уважаю этот движок за его неповторимую гибкость, но черт возьми, он иногда доводит до белого каления своими внешними прикрученными кое как решениями. Я не понимаю, почему нельзя взять одну систему и развивать ее? Дать ей исчерпывающие средства контроля, чтобы люди могли получать результат именно такой, какой они ожидают получить. Любая разработка — это прежде всего контроль результата. Без объективных глубоких систем контроля того, что получилось, нет никакого смысла браться за что-либо.

Теперь полу объективно.
После рассмотрения систем освещения, я пришел к выводу что Юниты не стремятся сделать картинку из движка приятную на глаз. Точнее их понимание «приятной» картинки несколько иное, чем привыкло большинство людей, ну или по крайней мере я. Они стремятся к фотографичной картинке. Поэтому каждый раз когда вы стремитесь создать приятный образ вашего творения, то скорее всего терпите неудачу или после продолжительных мук, получаете более менее то что задумали. Напротив, когда вы задаетесь целью создать фотографичную картинку, то начинаете получать приличный результат практически сразу же (конечно при условии что понимаете функционал систем).

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

О самом освещении.
Три вида освещения – динамическое, статическое с динамическими тенями (которое принято обозначать как освещение в реальном времени), полностью статическое. И четыре вида методики освещения - динамическое, полностью статическое, статическое с динамическими тенями, симбиоз полностью статического освещения и освещения с динамическими тенями.
По качеству наихудшее освещение – динамическое. Идет просчет только прямого освещения в реальном времени.
Затем статическое освещение у которого есть три алгоритма просчета: Enlighten, Progressive и Realtime Global Illumination. Будет неправильно говорить о том какое из них лучше, тут скорее правильнее сказать что каждый из них хорош в определенном случае. Enlighten имеет меньше настроек, как следствие вы имеете меньше контроля над ресурсами и результатом, отчего он может не подойти для слабых устройств и некоторых сцен. Основной плюс в том что есть возможность подключения динамических теней для этого режима, что значительно улучшит качество освещения, но потребует к себе дополнительных ресурсов.
Progressive дает больший контроль над ситуацией, что даст лучший результат в тех же условиях что и Enlighten, однако о динамических тенях надо забыть.
Ну и конечно если у вас есть движущиеся источники света, то без динамических теней не обойтись и тогда надо использовать Realtime Global Illumination. Если Enlighten и Progressive с натяжкой еще можно между собой сравнить, то Realtime Global Illumination стоит полностью на отдельной позиции.
Четвертый метод – симбиоз Enlighten и Realtime Global Illumination в теории должен дать наиболее правдоподобное освещение, ведь то что не смогла просчитать Enlighten, может просчитает Realtime Global Illumination и наоборот. Это прекрасно работает в маркетинге, а вот в голых расчетах нельзя забывать и о том, что косяки которые будут допущены в Enlighten, Realtime Global Illumination может не исправить, а наоборот добавить новых и наоборот.

Наиболее предсказуемый результат дает Progressive. Остальные режимы статического освещения, постоянно дают какие-то непрогнозируемые артефакты. Доходит до абсурда, когда стена нормально освещена, а скажем шкаф который стоит около нее и мало чем отличается, полностью выпадает из расчетов, что бы вы не делали, а когда вы на его место ставите другой объект с более сложной геометрией, то он спокойно обсчитывается системой. При этом отдельно шкаф нормально освещается. Видимо есть какие-то конфликты объектов, которые спрогнозировать опять же, нет возможности. Такого рода артефакты можно нивелировать дополнительным освещением, которое будет для них динамическим.
Если вы точно уверены что динамические тени вам не нужны, то я бы рекомендовал использовать именно Progressive. Если вы не уверены или точно знаете что у вас будут динамические источники света, то конечно надо использовать остальные системы.
Динамическое освещение лишено вообще всех недостатков. И преимуществ. Хотя в данном случае отсутствие недостатков это как раз преимущество, из чего получается что оно имеет только преимущества и можно сделать вывод что это самое лучшее освещение. Хе-хе. Шутка юмора.

Еще раз об атмосферном рассеивании.
Отражения есть, но нет рассеивания. Это рассеивание придется имитировать ручками. Возможно следующее будет сложно к пониманию, но в атмосфере пучок света так же является источником света, а не только сам источник света. Иначе говоря, в локальном понимании нашу планету освещает не только Солнце, но и атмосфера. Не небо, не отраженные поверхности, а именно сам воздух во всей своей массе, через которую проходит и рассеивается луч света. Благодаря скайбоксу который дает освещение на все части объекта в пределах горизонта, на открытом пространстве отсутствие атмосферного рассеивания не так заметно. Это становится критично в помещениях. Для того что бы грамотно сымитировать это, надо будет прикинуть углы отражения света, учесть количество отражений и расставить дополнительные источники света. Возможно впервые в жизни вы видите реальную причину для дополнительного освещения, а не по тому что так надо, этот участок слишком темный и по другому не красиво. Источников света которые заточны именно под это нет, как следствие придется брать в руки бубен и подбирать наиболее подходящие решение для каждого случая. Очень неплохо в качестве дополнительного освещения себя показывает «эммисионное» освещение, так что не забывайте о слоях.

Билд обсчитывается и будет добавлен позже
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 22 авг 2019, 00:09

Обещанный билд.

Хочу напомнить, что цель билда в показе освещения на высоких настройках. Все разрешения текстур и вообще текстуры настроены под дефолтную позицию персонажа, поэтому при смене позиции, возможна потеря качества.
Теперь о самом билде. Освещение настроено так, что бы продемонстрировать и высокие настройки, и в тоже время показать тени без применения фильтра. Интенсивность освещения увеличена в два раза по сравнению с предыдущими билдами. Дополнительного освещения нет.
https://yadi.sk/d/iiY2tNPDHuMKgg
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 22 авг 2019, 16:38

Обновление темы

Карты нормалей текстуры (Normal map)

Текст с наглядными примерами скриншотов - https://yadi.sk/d/HVwG9WUkNX_WPQ

Влияние разрешения на качество карт нормалей выражено довольно слабо. Явное снижение качества наблюдается только у текстур разрешением ниже определенного порога и слабо наблюдается у текстур с более высоким разрешением. Т.е. в примере на расстоянии 1,4 метра, явное снижение качества есть только у карты нормалей с разрешением в 256. Карты нормалей с разрешением в 512, 1024, 2048, 4096 между собой различаются крайне слабо. Эта закономерность наблюдается всякий раз как меняется расстояние до объекта – чем ближе, тем более высокое

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

Предварительный вывод.
Так же как и с текстурами Albedo, на текстуры Normal map влияет их разрешение и примененные к ним фильтры. Однако подбор разрешения не так хорошо выражено как в случаях с Albedo, тем более что их качество будет теряться за цветами Albedo и если не требуется показывать объекты на близком расстоянии, то вполне можно обойтись разрешением в 512. На более близких расстояниях так же придется подбирать оптимальное разрешение для достижения наилучшего качества.
Что касается применения Filter mode и Mip maps, то без них ситуация становится лучше. Однако, если разрешение подобрано не верно или расстояние до объекта по какой – то причине изменилось, а разрешение не поменялось, то потеря качества будет крайне значительной.
Применение алгоритма Kaiser у Mip Maps немного улучшает ситуацию, но не настолько что бы можно было им ограничиться.
Применения алгоритма Box, ситуацию спасет.
На близких расстояниях без фильтра Filter mode и неправильно подобранным разрешением будет хорошо заметна пиксельность текстуры Normal map. Эту ситуацию и исправит фильтр.

Вывод.
1) Наилучшее качество будет достигнуто без Filter mode (point) и Mip Maps (на всякий случай делаю акцент что я не говорю о том что Mip Maps не нужен. Я даю голый фактаж о его влиянии на результат), с правильно подобранным разрешениями под конкретные расстояния.
2) Если по какой-то причине нет возможности использовать для каждого расстояния свои разрешения, необходимо включить Mip Maps на Box. По факту это оптимальное решение которое позволяет и сохранить приемлемое качество без лишних танцев с бубном, и не размазать текстуру в симулятор пластилина.
3) Если предполагается что на объекты будут смотреть с небольших расстояний на которых будет заметна писксельность текстуры Normal map, а возможности вручную подбирать разрешения для этих расстояний нет, то следует включить Filter mode.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 19 сен 2019, 04:02

Обновление темы.
Развитие темы фотографичности подходит к своему логичному завершению. Осталось рассмотреть лишь индивидуальные настройки объектов которые как я надеюсь помогут исправить косяки Real-time lighting, несколько глобальных настроек и пройтись по Probe - в них есть несколько особенностей. Не знаю точно когда я этим займусь, возможно только в следующем месяце. Но в целом, предварительные результаты уже можно демонстрировать. Индивидуальные настройки критически не повлияют на общую картину - они исправят местечковые косяки, где по какой то причине освещение обсчитывается криво. Пробы работают довольно хорошо, поэтому так же серьезно на результат не повлияют.
Значит что касается предварительных результатов. Собрал я 4 билда с Viking Village. Насколько я помню ее делали для 4й Unity и перестали поддерживать в пятой. Очень достойная демонстрация движка для того момента. Я ее немного доработал в соответствии со своими результатами и я думаю вы оцените получившуюся разницу.
Ссылка на архив - https://yadi.sk/d/P6anXfEaAv-4MA

В архиве 4 билда.
Билд 1 - дефолтные настройки.
Билд 2 - отключена вся пост обработка.
Билд 3 - отключены только сглаживания, блюры и прочие замыливания. Текстуры выставлены на Point и отключен Mip Map у albedo. Игрался с этими параметрами только с паре случаев - у текстур травы земли (пиксельность), соломенной крыши (потеря качества из-за перспективы) и пришлось оставить дефолные настройки у атласа normal map отвечающий за торец бревен у хижин. Вроде все что менял.
Билд 4 - все тоже что и у предыдущего билда, но еще выкручены настройки освещения на максимальные.
И последняя сцена собрана в ассет. Версия Unity 5.5.4f1.
Соответственно между первым билдом и последним будет заметна наиболее существенное различие в изображении. Что бы в полной мере это увидеть, надо запустить билд 1, не трогая ничего сделать скриншот и вставить его в Паинт. Затем запустить билд 4 и так же ничего не трогая сделать скриншот. Вставить его в Паинт. И теперь с помощью ctrl+z / ctrl+y, вы сможете увидеть насколько существенно отличаются эти два скриншота. Хочу отметить, что это было доступно в "released Feb 28, 2015".

Что плохо в этой деревне. Текстуры с разрешением 1024 - так что в упор будет хорошо заметна потеря качества из-за низкого разрешения самих текстур. Некоторые собраны в атласы с разрешением 1024, что конечно еще хуже. Так же я пока не заморачивался с созданием "лодов" (или что там подойдет под эти цели) опираясь на качество тектурирования, что бы поддерживать высокое качество изображения подставляя оптимальные разрешения текстур с ростом расстояния.

Так же хочу напомнить что я не являюсь профессиональным художником. Возможно применяемые мной методы исключительно не правильные, противоречат всем канонам и вообще сами по себе принципиально бесчестные. Моя цель - добиться максимально возможного качества используя стандартные возможности Unity.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Re: Фотографичность в Unity? Повышаем четкость картинки.

Сообщение sledo 08 мар 2020, 16:01

Обновление и дополнение темы.

При работе над сценой по предложенной мной методике, выяснилось следующее. (Далее все справедливо для разрешения экрана 1920х1080, размером ГО в 1м) Разрешения текстур 2048 нужно только лишь когда на ГО смотрят в упор, затем с ростом расстояния разрешение этого ГО на экране резко снижается и уже примерно на 0,77 метрах становится 1024. В 1,34м от камеры уже 512 и в 3,08 метрах 256. 6,16 метров -128 соответственно.
Честно говоря для меня это было открытие, что на расстоянии уже в 6,16 метров, необходимое качество текстур для четкого изображения нужно всего в 128 пикселей. Иначе говоря, для конкретно этой сцены все предметы которые находятся дальше чем 6 метров, можно считать далеким от камеры, применять к ним текстуры с разрешением в 128 и вообще считать фоном.
И тут я снова задумался над тем — что же сделать то что-бы качество изображения в динамической сцене всегда было высоким? И... Я снова посмотрел на ЛОДы, но уже под другим углом и тут внезапно понял, почему они именно такие, какие есть. ЛОДы в Юнити не привязаны к расстоянию от камеры, а работают по принципу «Процент на полоске LOD означает долю глубины в пирамиде видимости, на которой данный LOD-уровень становится активным». И в который раз я поразился насколько все продумано в Юнити и насколько это не освещено в широких массах. Потому что зависимость переключение объектов от его размеров непосредственно на самом экране, это именно то что нужно.
Я хочу чтобы вы прониклись этим моментом и хорошенько его осознали, поскольку это критически важно. Когда вы будете искать информацию о ЛОДах, когда вы будете спрашивать о них у матерых дизайнеров, вы всегда будете получать ответ - они нужны для того чтобы применять упрощенную геометрию модели к игровому объекту с ростом расстояния от камеры. Из чего вы скорее всего сделаете вывод, что а) ЛОД привязан к дистанции, б) ЛОД необходим для оптимизации. Потом вы идете в Юнити и... Не понимаете как вообще с ними работать. Так вот, это лишь малая часть того, для чего нужны нативные ЛОДы. И слава Богу, менять этот подход юниты не собираются.
Что бы убедиться в своих догадках, я немного покопал историю и оказалось что система ЛОДов была создана еще в 1976 (если верить английской Вики) когда 3D графика была еще чем то фантастичным. Значит, наиболее популярное мнение о них — ошибочно. Впрочем, лично я к этому уже привык, собственно я сижу и пишу тонны текста из-за этого.
Иначе говоря, правильно настроенный ЛОД, это такой, который находится и переключается не на определенном расстоянии от камеры, а когда ГО занимает определенную площадь на экране. И переключает он не только геометрию, но и само текстурирование на более упрощенное. Если исходить из этой логики, то для того что бы можно было использовать ЛОДы в паре с текстурированием, на ГО должна быть одна текстура которая натянута на этот ГО с подходящим для конкретного размера на экране разрешением (еще раз обращаю внимание на то, что рассматривается не трехмерный мир, а исключительно только экранная плоскость). И вот теперь открывается смысл для использования атласов (обращаю ваше внимание на популярное ошибочное мнение об атласах, как исключительно о средстве для оптимизации) как «едином наборе» текстур которые полностью покрывают ГО и регулируя разрешение атласа, можно с помощью стандартных ЛОДов всегда предоставлять наилучшее качество изображения до тех пор, пока будет справедливо соотношение разрешения атласа, к разрешению экрана.
Это очень тонкий момент когда вы делаете свой игровой мир красивым. В данном случае идет очень серьезная зависимость от размеров ГО и разрешения текстуры которая к нему применена. Чем больше ГО, тем больше должно быть разрешение примененной к нему текстуры, для того что бы этот ГО можно было показывать в камеру на меньшем расстоянии без потери качества. Из чего следует, что если у вас скажем высотный жилой дом и вы хотите что бы подойдя к нему в плотную игрок увидел высококачественную текстуру, то этот дом должен быть разбит на квадраты и к каждому квадрату должен быть применен свой материал. И теперь, с точки зрения движка это будет не дом, а серия ГО к которым можно применять свои настройки в зависимости от того, какую площадь на экране они занимают, или говоря простеричием — применять ЛОДы. Значит когда этот дом находится вдалеке и виден полностью, к нему применены материалы с атласами, а как только он становится настолько большим что не помещается на экране, показываются уже разбитый на части дом с простыми текстурами. И далее, только держа в голове это, уже проводить оптимизацию, в зависимости от того где игрок может ходить. Ведь понятно что нет ни какого смысла делать высококачественную крышу или верхние этажи, если у игрока нет технической возможности на нее попасть и он на это все всегда будет смотреть издалека

Очень важно.
Калибровка разрешения текстур и расстояние до предмета необходимо совершать в полноэкранном режиме при целевом разрешении (в моем случае, я настраивал под разрешение 1920 х 1080). Я и вовсе вырезал из бумаги квадраты по которым калибровал на экране изображение, поскольку это оказалось значительно удобнее и быстрее.

Итак, подводя итог всему выше сказанному, можно сказать следующее: использовать ЛОДы надо всегда и везде, вне зависимости от расстояния и отправной точкой для их использования должна быть площадь изображения игрового объекта на экране. Рассматривать ЛОДы как средство оптимизации и привязывать их в к расстоянию - ошибочно и крайне вредно. ЛОДы необходимо рассматривать исключительно исходя из площади изображения игрового объекта на экране. Ни в коем случае не рассматривать игровой объект как какой-то единый и нераздельный предмет под названием "табуретка" - еще раз повторюсь - важна только лишь та площадь игрового объекта, которая есть на экране в данном конкретном случае.

Шаги при применении ЛОДов должны быть следующие:
1) Если у вас в сцене объект который при приближении к нему в плотную не помещается на экране и имеет несколько материалов с разными текстурами, например дом, он должен иметь атлас текстур который полностью его покрывает. Причем это не оптимизация. Это обязательный шаг.
2) Иметь атласы разных разрешений которые должны быть применены к геометрии подготовленных ЛОДов.
3) ЛОД должен быть настроен таким образом, чтобы его смена происходила ровно тогда, когда необходимо сменить разрешение примененного к нему атласа. Иначе говоря, эти атласы применять только когда дом полностью виден на экране и на экране, занимает площадь равную разрешению применяемого атласа.
4) После того как будет применен атлас максимального разрешения, следующий ЛОД, должен содержать группу ЛОДов с более мелкими объектами, к которым применены соответствующие разрешения текстур и настраивать их так же начиная с пункта 1.

Теперь выявленные слабые места.
Хоть и используется правильные алгоритмы для ЛОДов, применять высокое разрешение для них не целесообразно, из-за чего количество групп ЛОДов может серьезно увеличиться. В моем случае, переход ЛОД 0 на ЛОД 1 имел на экране разрешение в примерно 300 пикселей, при разрешении экрана в 1920х1080 и размером игрового объект в 1м, это 3,5м дистанции камеры и ГО. Это значит, что использовать стандартные ЛОДы для того чтобы иметь высококачественную картинку на всех диапазонах расстояний игрового объекта от камеры, нельзя. Иначе говоря, это очень мощный инструмент, но увы не панацея.

P.S.
Возможно как только починят фильтры и сжатие текстур, сам движок все это будет выполнять на высоком уровне. И скорее всего, именно по тому что эти вещи были переложены на разные автоматические инструменты и забылось основное назначение ЛОДов.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

Пред.

Вернуться в Уроки

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5