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

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

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

Сообщение sledo 21 окт 2018, 22:30

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

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

Фотографичность

Небольшое предисловие.
Расследование показало, что как такой дисциплины по фотографичности нет. По факту это то что путают с художественной дисциплиной "фотореалистичность", а именно - просто набор приемов которые могут серьезно отличаться друг от друга в зависимости от условий создания изображений высокой четкости в различных условиях среды, которые максимально копируют что либо. Это чисто технические моменты и думать об этом надо только с точки зрения механики. Определенную пользу фотографичность может принести и даже в зависимости от условий поставленной задачи, принести серьезную пользу. В частности существенное повышение качества конечного изображения, его честкости, выявление технических недостатков инструментов и прочее.
Надо для себя понять, что будь вы художник который создает пока несущестующий мир, или программист который использует строгую логику, для достижения конечного результата вы используете инструменты -все с помощью чего вы творите, это инструменты для вашей работы. Нет ни каких строгих правил, нет ни каких ограничений. Все эти правила и ограничения сидят у вас в голове и вы сами себя ограничиваете. Если для достижения положительного результата вам надо использовать фотографичность - используйте. Это точно такой же инструмент, как и все остальное. Просто, не увлекайтесь этим и уж тем более не ставьте его в правило. У вас есть лишь технические ограничения с которыми придется считаться, но это лишь значит что в большинстве случаев вы не сможете решить проблему в лоб и только.
Так же крайне важно понять что человек не способен сразу понимать что хорошо, а что плохо. Это понятия относительные и мыслим мы именно относительно чего либо. До тех пор пока вы не увидите что такое хорошо, вы не сможете понять что такое плохо и наоборот. Поэтому можно и нужно ошибаться (но лучше конечно учиться на чужих ошибках), делать плохие вещи и стремиться к лучшему, если вы хотите стать истинным профессионалом. Отсюда же вытекает, что если выдостигли как вы считаете совершенства, то развиваться сможете только в худшее. Позволю себе небольшое отступление, для того что бы привести аналогию. Не так давно был отснят очередной эпизод Звездных войн - Последние джедаи. Мне нравятся сказки и на мой субъективный взгляд ничего стоющего в этой картине нет кроме одного. Примерно в конце фильма когда главные герои сражаются друг с другом, каждый из них пытается перетянуть другого на свою сторону силы и что самое интересное, они оба правы в своих взглядах. Что самое забавное и что вообще лишает смысла всю Вселенную Звездных войн, это то что тут они прямо говорят о том что не может быть только добро или зло, они могут существовать только вместе и всегда будут уравновешенны друг другом. Т.е. кто бы не победил, всегда найдется тот кто перейдет на темную сторону или на светлую сторону, просто по определению. Для баланса. Как бы не банален был сюжет, но эта сцена прямо показывает что, что бы узнать что такое добро, нужно что бы было зло (привет атеистам и их игнорированию Библии с эпизодом райского дерева познания добра и зла). Отсюда же выходит - если не будет зла, то и добра, тоже не будет.
Так вот - фотографичность с точки зрения изобразительного творчества - это абсолютное зло. Однако не познав его, вы не сможете узнать что такое истинное творчество.

Так же следует понимать что все предоставленные демонстрации лишь плашки которые показывают возможности вашего творчества.

Теперь приступим.

Определимся, что это такое фотографичность.
Конкретно к слову фотографичность определения я не нашел. Везде даются ссылки на какое то другое слово которое в конце концов приводит к
ФОТОГРАФИГЧЕСКИЙ, фотографическая, фотографическое.
1. прил. к фотография в 1 знач.; служащий для фотографии. Фотографический аппарат. Фотографическая пластинка.
2. Полученный посредством фотографии. Фотографический снимок.
3. перен. Совершенно точный, очень сходный, как будто сделанный при помощи фотографии (книжн.). Фотографическое описание. Фотографическое изображение. Фотографически (нареч.) точно.

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

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

Просмотрев десятки примеров фотографичности, для себя я определил несколько общих особенностей благодаря чему достигается этот эффект:
1) Высокая четкость изображения
2) Лучше всего использовать контраст, что бы было видно максимум деталей и предметов.
3) Высокая отражающая способность предметов, что создает ощущение глубины.

Высокая четкость изображения, задает серьезную планку к качеству конечного изображения на мониторе, и использование разных постэффектов и других искажающих эффектов, крайне не рекомендовано. Единственно что полезно и скорее всего придется использовать это сглаживание или использовать какой то подобный эффект. Сглаживание смажет лесенки что даст ровность воспроизведения поверхности, но смажет и сами текстуры. Поэтому увлекаться этим не стоит и на мой взглят вполне достаточно сглаживания в 2х у MSSA.
Есть много других алгоритмов сглаживания, которые могут подойти в каждом конкретном случае. Это ваш инструментарий, вы должны изучить его (это отдельная серьезная тема).
Соответственно для использования сглаживания, придется использовать Forward Rendering https://docs.unity3d.com/Manual/RenderingPaths.html/ который в последних версиях Юнити переключается у камеры в строке Rendering Paths.

Сглаживание даст искажения текстур, к этому надо быть готовым.
Так же критически важно подбирать верное разрешение текстур, что бы уже сами текстуры не давали искажения. Разрешение играет едва ли не ключевую роль в качестве текстурирования. Каждое разрешение хорошо в определенных условиях когда оно будет давать 100% качества.
В большинстве случаев, максимальное разрешение мониторов равно 1920x1080. В некоторых случаях оно больше и вроде как максимум достигнут в так называемом 4к разрешении которое равно 4096 х 3072. Очень важно понимать для какой аудитории вы создаете продукт, для того что бы использовать текстурирование верного разрешения. Если вы будете использовать текстуры например с разрешением в 8192, то ни монитор, ни телевизор физически не сможет отобразить эту текстуру, а значит он ее сожмет, что даст искажения. Т.е. практического смысла в использовании такого рода разрешения текстур нет ни какого. То же самое и для разрешения текстур в 4096, если ваша целевая аудитория имеет типичный монитор с максимальным разрешением в 1920x1080, который пока что наиболее популярен среди пользователей. Т.е. в большинстве случаев максимальное разрешение текстур должно составлять 2048, которое даст наименьшее возможные искажения при нахождении камеры в упор к предмету. Однако надо понимать, что чем дальше вы отодвигаете камеру от предмета, тем больше искажений будет получать текстура.
Теперь про минимальное разрешение. В теории с минимальным разрешением текстур все немного сложнее. Если с разрешением в 2048 вы можете не бояться показывать предмет в упор, и даже полезно это делать, то с разрешением в 1024, без потери качества вы можете показывать предмет только на определенном расстоянии. Потому что если вы будете давать возможность посмотреть игроку на текстуру с разрешением в 1024 пикселей в упор, то он увидит качество в 2 раза хуже чем у номинальной текстуры в 2048, потому что она будет растянута до разрешения в 2048. Т.е. когда вы показываете игроку высококачественную текстуру в 1024 в упор, ее качество в 2 раза хуже чем если бы вы ее показывали на расстоянии когда она имеет номинальный размер в 1024 - человек будет видеть размытую текстуру.
Отсюда же следует понимать, как именно было добыто разрешение текстуры. Если с помощью фотоаппарата, это одно, если с помощью сжатия, это другое. Я лично изменял размер обычным Paint'ом.

На практике же в Unity дальнейшие эксперименты с текстурами показали следующее - критически важно использовать номинальное разрешение текстур для предметов которые будут на определенном расстоянии. Получить такое же качество как и у текстуры с разрешением в 512 из текстуры с разрешением в 1024 на данный момент не получится. Поэтому использование текстур сугубо одного разрешении - крайне не желательно. Получается, что в идеале надо заменять качество текстур на подобии лодов для того что бы картинка имела высокую четкость изображения или же сами лоды настроить так что бы они имели оптимальные разрешения текстур.

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

Видео текстуры 1


показывает качество вместе с картами освещения. Разрешение 1024 меняется на и обратно 512. (лучшее качество у 1024)
Видео текстуры 2


показывает качество только текстур без карт освещения. Расстояние до объектов - предмет полностью помещается по высоте в экран

Видео текстуры 3 и 4



показывает обратную ситуацию когда качество у разрешения 512 выше чем качество у разрешения 1024. Сначала высокое разрешение, потом низкое.
Тоже самое с картами освещения

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

и текстуры 8


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


Задайтесь вопросом - кто из вас об этом задумывался? Видимо отсюда и растут ноги вечно замыленых и мультяшных картинок из Юнити.
Я бы предложил перед текстурированием, создать текстуру с сеткой шагом в 1 пиксель для каждого разрешения. Это будет ваша калибровочная сетка. На каждый предмет в сцене необходимо применять эту калибровочную сетку, для определения наиболее оптимальных разрешений текстур для объектов в сцене на разных расстояниях (видео текстуры 10


). В моем случае для текстур разрешением в 1024 наибольшее качество достигается когда объект занимает примерно половину экрана по горизонтали (куб 1х1), соответственно для текстур с разрешением в 512, в четверть. Для вас это значение может быть иным, поэтому если вы занимаетесь этим серьезно, то я бы рекомендовал определить калибровочное железо и на нем сделать калибровочную таблицу расстояний и размеров сетки, когда достигается максимальное качество.
Но в принципе можно просто иметь текстуры нескольких разрешений и попеременно применять их на материал выявляя наилучшее качество. Текстуры 11 (К сожалению технические ограничения похоже не позволили наглядно продемонстрировать прием)

Теперь что касается настроек текстур.
Из всех настроек, если не считать streaming mip maps, на качество влияют следующие:
1) Generate Mip Maps
2) filter mode
3) MAx size
4) resize algorithm
5) compression

Сравнивать будем с номиналом где все настройки выставлены по умолчанию, но галочка Generate Mip Maps снята.
Generate Mip Maps
Все выставлено по умолчанию - результат искажен. Видео Текстура 13


Юниты настоятельно рекомендуют использовать Generate Mip Maps для улучшения производительности. По сути именно эта функция отвечает за то что бы более низкое разрешение текстур накладывались на предметы которые находятся далеко от камеры. Т.е. она преобразует текстуру с разрешением 1024 в более низкое. Работает криво.
Она имеет дополнительные настройки. посмотрим на искажения в них.
1) border mipmaps - работает с границами текстуры, что и видно на видео.
Текстуры 14


2) Mip Map Filtering - как видно из названия, способ фильтрации. Наилучшее качество дает фильтр Kaiser
Текстуры 15


Попробуем его сравнить с номиналом
Текстуры 16


Как видно, ситуация все равно хуже чем без использования Generate Mip Maps, но лучше чем с использованием фильтра box

3) mip maps preview ни как не влияет на качество
4) Fade Out Mipmaps ни как не влияет на качество

Filter Mode
Наилучшее качество дает Point(no folter), но вблизи дает пиксельность.
Видео текстуры 17


Сначала сравнение с Bilinear у которого отключен Generate Mip Maps. Затем с Bilinear и включенным Generate Mip Maps с фильтром box, затем с фильтром Kaiser.

Фильтр Trilinear.
Текстуры 18


Сначала сравнение с Bilinear у которого отключен Generate Mip Maps. Затем с Bilinear и включенным Generate Mip Maps с фильтром box, затем с фильтром Kaiser.

Далее resize algorithm.
Как ни странно, но на качество не повлиял. Юниты утверждают что Bilinear в некоторых случаях может улучшить качество.

compression
Так же на качество не повлиял.

Итог: Наилучшее качество достигается с отключенным Generate Mip Maps, и у Filter Mode выставленным Point(no folter).
Если у текстуры появилась зернистость, то без Generate Mip Maps не обойтись, выставляем Mip Map Filtering в Kaiser. На горизонтальных поверхностях могут появиться артефакты. Тогда переключаем на Box. И если все это не помогло, то включайте фильтры Filter Mode.
И конечно все это надо применять непосредственно к текстурам, а не к картам освещения. С картами освещений вроде как косяков нет, но это мы еще посмотрим позднее.
Из общих настроек интересен только Texture Quality.

Ну что же, давайте попробуем добиться максимальной четкости изображения.
Я откалибровал сцену сеткой что бы понимать какие разрешения текстур применять и начал применять это к материалам. И вот выяснилось еще одна нехорошесть - стена выполнена одним мешем, а значит к ней я могу применить только одну текстуру. Но стена вокруг меня и на разном расстоянии. Пришлось дублировать ее и на дальнюю стенку применять текстуры с разрешением в 256, в то время как к первичной стене применил текстуры с разрешением в 1024. И вот если стоять строго на одном месте мы получаем четкую картинку практически без размытий и искажений.
Видео текстуры 12


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

Немного иная ситуация с текстурами на которые действует перспектива. Например пол. Тут уже высокая четкость текстурирования скорее зло, чем добро. Что получается? Когда отрисовывается наиближайший ряд пикселей текстуры к камере, то показывается 100% информации. Следующий ряд пикселей из за перспективы, уже будет меньше, а значит часть информации должно быть утеряно. Третий ряд еще меньше, а значит информации остается еще меньше и так далее.
Видео Текстуры 19


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


и
текстуры 21


(линии в видео 21 прямые. Добро пожаловать в мир оптических иллюзий), а сама потеря информации уже не будет так заметна, поскольку сама текстура не высокого качества. С другой стороны, на определенном расстоянии, текстура будет иметь 100% качество, что может так же бросаться в глаза. Поэтому тут использование различных фильтров в Filter Mode скорее благо, чем нет.
Кроме того, при смене ракурсов камеры, на полу может появиться зернистость из за того что в каждом кадре происходит разная потеря информации.
Тут же нюанс с атласами. Многие разработчики загоняют в атласы все что не попадя, считая это аксиомой оптимизации. Потом искренне недоумевают почему их игра выглядит как кусок обмылка. Смысл атласов в том, что уменьшается количество проходов по материалам, но так ли это важно если решать проблему в лоб? Вот представим что вы имеете высококачественные текстуры с разрешением в 2048 и все выглядит хорошо и даже не особо тормозит. Вы решаете все это дело оптимизировать. Первое что должно возникать у вас в голове - зачем вы хотите это делать? Я пришел к выводу что не разработчик должен подстраиваться под все разнообразие ПК, а игроки должны иметь железо под конкретные задачи. А эти задачи должны задавать разработчики, как это происходит в консолях. Только тогда игроки смогут получить номинальное качество, что и нужно разработчикам. Так вот, вы должны четко понимать свою целевую аудиторию. Если вы создаете игру для калькуляторов, то нет ни какого смысла использовать высококачественные текстуры. Если вы создаете свою игру для средних ПК, или хороших ПК, то надо всегда подходить к оптимизации очень осторожно (главное правило - не навредить. И вообще это должно стать руководством в жизни). Итак атласы. Вот значит вы используете текстуры с разрешением в 2048, у вас их 10 штук и вы загоняете 10 этих текстур в один атлас с разрешением в 4096. Оптимизация? На первый взгляд - безусловно. Но в итоге вы получаете качество текстурирования в 1024. Т.е. что бы без потери качества загнать эти текстуры в один атлас, ваш атлас должен иметь разрешение в как минимум 8192. Но в такой атлас у вас поместится 16 текстур с разрешением 2048, а не 10. И вопрос - что вы оптимизировали? А теперь немного математики - то отчего так корежило некоторых товарищей. Для просты счета будем брать только одну ось разрешения. 10 текстур по 2048 пикселей = 20480 проходов по ним. Сожмем их в атлас до 1048, атлас получится в 4096 в который поместится 16 текстур и того по атласу будет 65536 проходов. Я думаю ясно что в данном случае с атласом ни какой оптимизации не получится, он будет занимать и места больше, и проходов по нему будет больше и качество ниже. Единственный плюс остается только в том что не надо брать для обработки новый материал, для обработки его текстуры.

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


Затем важно понимать технические ваши ограничения. Вам придется использовать высококлассные средства визуализации, такие как мониторы, видеокарты и программное обеспечение. Если у вас будет дешевый монитор, который например не сможет точно передать цветовую текстуру изображения которое на него приходит, то вы физически не сможете увидеть качественный результат, а значит физически не сможете добиться высококачественной картинки. Тонкое место в том, что у большинства пользователей те же мониторы далеко не высококачественные, а значит они физически не смогут увидеть высококачественную картинку которую вы для них подготовили на высококачественном железе. Кроме того, очень важен размер монитора. Чем меньше его размер и выше разрешение, тем более мелкая зернистость матрицы и как следствие более четкая картинка с монитора. Т.е. одно и то же изображение может выглядеть по разному в одном и том же разрешении, но с разным дюймовым размером экрана. Увидеть вы это сможете если запустите какую то игру в окне с разрешением 800х600 и запустите тоже самое на старом мониторе с его общим разрешением в 800х600. Поэтому я повторюсь, что убежден что разработчикам давно пора вводить градацию конфигурации ПК, под конкретно которое была создана игра, от и до. Писать вплоть до моделей железа, версии драйверов в котором игра будет выглядеть номинально. Более того, если человек купил самый дешевый монитор, который у него еще и весь выцвел, то увидеть он может совсем не то что видят остальные. Поэтому если вы серьезный разработчик, у вас должно быть несколько тестовых сборок для того что бы вы могли увидеть свое творение так, как могли бы это увидеть люди с разными конфигурациями ПК.

В связи с недавно вышедшим обновлением Таркова, сделал билд где можно наглядно увидеть разницу между дефолтными настройками текстур с не подобранным разрешением и настроенной комнатой. Вообще конечно надо было его сделать намного раньше, но как всем нам известно, время, это именно то чего вечно не хватает. Выкраил пару часиков на это благое дело.
Пример полностью показывает разницу между двумя подходами и демонстрирует насколько слабо Юнити работает с текстурами. Так же он демонстрирует артефакты зернистости и проигрыш в качестве перед дефолтными настройками. Надеюсь теперь даже у самых ярых скептиков не останется сомнений в том что подбор разрешения текстур и настройка самих текстур является критически важным аспектом в графическом качестве игр.
Примеры ошибок:
1) Книги, дверь и фото кошки внизу у стенки, имеют артефакты зернистости. Разрешение текстур кошки 256, книг 1024, дверь 2048. Ошибки при создании перспективы. Разрешение надо снижать, либо все замыливать.
2) Стол имеет большую четкость как раз при дефолтных настройках текстуры, при том что разрешение текстур у них одинаковое. Ошибка подбора разрешения текстуры.
Сам билд - https://yadi.sk/d/w50gX9YszV1kNw

Еще один билд, который демонстрирует сохранение качества текстуры с ростом расстояния, посредством использования верно подобранного разрешения. Так же потеря качества при использовании текстуры высокого разрешения на расстоянии. https://yadi.sk/d/MnBetCGP2Ja88g
Интересная ошибка при билде комнаты. Я не стал заменять материалы в комнате, а просто создал еще одну и при нажатии кнопки отключаю какую то из них. Так вот если создавать билд с заранее отключенной настроенной комнатой, то появляется странная ошибка с текстурой на стелаже. https://yadi.sk/d/1dw5u93a1wTczg
Обобщая тему с разрешением текстур и настройкой фильтров, можно сделать следующие выводы:
1) Очень важно понимать на каких расстояниях будут смотреть на объект и в зависимости от этого подбирать разрешение текстур и фильтры
2) Если стоит задача добиться максимального качества, то в лодах использовать подходящие текстуры и настройка отключения лодов должна происходить исходя из потери качества текстур
3) При большом воздействии перспективы, низкое разрешение это как раз хорошо.

Пожалуй на этом можно закрывать тему с текстурированием.


Пояснения от Zulllus.

Для остальных, беглое пояснение исследования:
0. Мипмапы - это версии текстуры с разным разрешением, сделанные не только ради экономии памяти ускорителя, но для предотвращения дребезжания точек. Если взять очень большую текстуру и положить ее на очень маленький треугольник (на экране треугольник помещается в 10 точек, а текстура, например, в 100 точек), то ускоритель сам не смешает 100 точек, он тупо возьмет каждую 10 точку с текстуры. Но проблема в том, что когда треугольник поворачивается, то количество точек может плавать от (скажем) 9 до 11, и тогда точки со 2 по 8(9,10) будут отличаться для этих трех версий (с 9, 10 и 11 точками соответственно) и это будет выглядеть как дребезг. А вот если на этот треугольник положить текстуру с 10 точками, то дребезга не будет, т.к. точки будут одинаковые для всех трех версий (почти одинаковые). Вот в этом суть мипмапинга! На ускорителе есть версии текстуры под разный размер треугольника. Когда он шириной 100 - то текстура 100. Когда 10 - 10.
1. Мипмапы нужны, без них никак, но юнити генерит их откровенно плохо. Нужно включать коррекцию границ и фильтр кайзера, получается хуже фотошопа, но что делать.
2. Лучше всего мипмапы делать фотошопом, 10 лет назад другого нормального способа их сделать не было, сейчас вообще нет нормального способа для Юнити. В магазине дополнений есть несколько дополнений, которые позволяют немного улучшить ситуацию, но не сильно.
3. Теперь про фильтрацию. Фильтрация нужна для смешивания мипмапов. Если их нет, то и фильтрация работать не будет. Фильтрация борется с границей переходов между мипмапами, соответственно, отключая ее мы повышаем четкость текстуры до стыка, но зато получаем галимый стык между текущим и следующим мипом.
4. Я не смотрел, что делает юнити с текстурами не кратными двойке, вроде есть галка, которая объясняет, что он может работать с любыми, но что по факту происходит - хз. Но скорее всего не очень важно, является ли текстура кратной 2 (на современных ускорителях проблемы быть не должно). Но есть момент, который реально важный, чем кратность и нужно его понять. Ускоритель из двух мипмапов выбирает тот, что больше подходит короткой стороне. Тут как раз автор рассказывает про проблему пола. Так вот, если короткой стороне нужен самый маленький мип, то текстура будет жутко замыленной. Но чаще всего это получается из-за того, что неправильно сделана UV карта, и берется не 0 мип, а 1 или 2 (о чем говорит автор, но не понимает суть).
5. И еще, может кто-то не понял, мипы всегда отличаются в 2 раза, т.е. между 1024 и 512 нет промежуточных мипов, и ускоритель без фильтрации перепрыгнет с 1024 на 512 щелчком, т.е. если треугольник по горизонтали меньше 1024 точек, то без фильтрации на следующем кадре ускоритель перейдет на текстуру в 512 точек. И именно фильтрация это лечит. Она смешивает по сложному паттерну, включая учет угла между камерой и треугольником. Она СЕЙЧАС бесплатная с точки зрения производительности, поэтому включаем максимальную, трилинейную.

Теперь для тех, кто хочет сделать круто: сделайте свое дополнение, которое будет заменять встроенные в юнити мипмапы на мипмапы, сделанные вручную. Это единственный способ сделать текстуры четче. То, что предлагает автор вообще это не способ. Но если вы не можете сделать свое дополнение, то следуйте следующим советам:
1. Для одного объекта все мипы должны быть одного уровня. Грубо говоря, если у нас текстурирование где-то более растянутое, а где-то более сжатое, то ускорителю фиолетово. Он все равно возьмет не оригинальную текстуру: мип номер 0, а ту, что лучше подходит: мип номер 2, а это значит, что вместо хорошей четкой текстуры мы получим текстуру, сгенерированную убогим алгоритмом юнити из нее.
2. Чтобы понять, какие мипы используются в дополнениях есть бесплатное, которое показывает номер мипа. Номер мипа напрямую не зависит от разрешения экрана, он зависит от текстурной развертки (UV map). И только удивив на экране номер можно подгонять текстуру под это разрешение. Разумеется, нельзя всегда получать идеальный мип, т.к. юнити не дает нарисовать в ручную все мипы, но для (скажем) главного героя от третьего лица можно подобрать лучший мип и параметры этого мипа. Важность этого дополнения еще в том, что вы можете увидеть, что если объект у вас раскрашен разными мипами, но использует одну текстуру - карта UV сделана не правильно.
3. Карту UV нужно делать очень внимательно, это в 10 раз эффективнее, чем следовать советам автора. А чтобы понять, что все правильно, нужны инструменты, которых в юнити нет. Но! Есть дополнения, которые позволяют частично решить проблему, как платные, так и бесплатные. Я их специально не исследовал, рекомендую этим заняться автору. Тогда может будет толк в этой теме.
Последний раз редактировалось sledo 07 мар 2019, 01:55, всего редактировалось 6 раз(а).
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 21 окт 2018, 22:32

Свет

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

В Юнити есть два варианта освещения - динамическое и заранее вычисленное.

Если использовать только динамическое освещение, то тени будут очень темными, а светлые участки очень светлыми. Юниты это объясняют тем, что в таком случае не просчитывается отраженный свет.
Тут надо немного более подробно изъясниться.
Динамическое освещение, это когда у вас отключены галки на Realtime GI и Baked global illuminationили по какой то причине не была запечена световая карта. при настройках по умолчанию, скорее всего у вас будет очень темная сцена, с практически черными тенями даже в местах где есть интенсивное освещение. Это как раз следствие того что свет не отражается от поверхностей и тем самым дополнительно не освещает их. Никакими ползунками осветления это не исправить, кроме как изменить значение Source со Скайбокса например на Color в окне Lighting, графе Environment lighting. Чем светлее цвет, тем светлее вся сцена.

Соответственно в Юнити это самое худшее по качеству освещение. Долго останавливаться на нем нет смысла, поскольку тут ничего не сделаешь и отсутствуют вообще какие либо настройки (конечно если не учитывать глобальные настройки проекта и сцены).
Юниты говорят, что самое реалистичное освещение это комбинация Real-time lighting и Baked global illumination, или иными словами комбинация запеченных теней и света в реальном времени.
Для того что бы использовать эти типы освещения, надо поставить галку "Статик" у объекта, т.е. сделать их статичными.
Получается, что для всех динамических объектов, будет применяться динамическое освещение, т.е. наихудшее качество света.
Соответственно при использовании комбинации Real-time lighting и Baked global illumination, правильнее будет сказать что используются динамические тени для статического объекта. Следует четко понять, что Real-time lighting это статическое освещение, а не динамическое как иногда многие считают.

Ситуация скверная и Юниты немного подправили ее с помощью light probe. Light probe нужно как раз для того что бы были динамические тени у динамического объекта по качеству немного лучше чем у простого динамического освещения, т.е. что бы отражения света от поверхности обсчитывались и для динамических объектов, необходимо использовать light probe.
Кроме того, на больших сценах или где использование подробных запеченных карт освещения Realtime GI нецелесообразно, для мелких предметов как раз так же можно использовать light probe. Проблема light probe в том, что он может использоваться только локально и так же запекается, а значит не может быть привязан к динамическому объекту, а обсчет происходит только когда динамический объект попадает в зону light probe.
Например есть динамическое помещение, например трейлер. Влияние на его помещение окружающей средой минимально. Соответственно в данный момент, иметь хорошо освещенное внутренне помещение трейлера возможности нет, поскольку запеченная карта освещения будет находиться статично на одном месте, а не передвигаться вместе с трейлером. Соответственно для помещения трейлера будет применяться real-time lighting который просто освещает поверхность без отражения света от нее. Ситуация немного улучшится, когда он войдет в зону действия light probe, однако по сравнению с Realtime GI уровень освещения все равно существенно ниже, да еще и будут появляться артефакты. Сюда добавляем полное отсутствие отражений от воздуха и получаем, что получить хорошо освещенные динамические объекты в Юнити нет ни какой возможности стандартными средствами. Такие дела.

Большое значения разрешения световой карты для Realtime GI, может привести к сбою.
Юниты говорят о том, что высокие разрешения для Realtime GI не нужны. Для больших карт надо делать низкое разрешение и если требуется детальное разрешение то использовать локальные карты. Недостатки освещения компенсировать light probe. Все это нет нужды описывать заново, есть очень подробная инструкция
https://unity3d.com/ru/learn/tutorials/ ... g-clusters
Однако в версии Юнити 2018.2,6 есть странный, скажем так баг. Свет Realtime GI не всегда запекается, даже если вроде как все настроено правильно. Поэтому обязательно надо проверять после обсчета:
1) наличие ошибок (если есть ошибки при обсчете, значит у вас не будет запеченных карт света)
2) Включать слой отображения кластеризации Lit Clustering, в правом верхнем углу окна Scene.
Lit Clustering вам покажет насколько хорошо был произведен обсчет статичных объектов на сцене. В идеале, он должен быть равномерным, без рваных дыр. Добиться этого можно настройками LightmapParameters.
Если же в этом режиме у вас нет ничего на сцене, или же только какие фрагменты, то карта света не была создана или создана только для тех фрагментов которые вы видите. Это очень важно знать и понимать и обязательно проверить.


https://docs.unity3d.com/Manual/class-L ... eters.html
Теперь попробуем разобраться с настройками для Real-time lighting.
Если три параметра Resolution:
1) Indirect resolution
2) Resolution
3) Cluster Resolution
Первый в настройках окна Lighting, другие два в настройках Lightmap Parameters.
Из справки можно сделать вывод, что Resolution из LightmapParameters имеет преимущество над Indirect resolution, однако прямо об этом не говорится.
Для того что бы получать корректные результаты при использовании своих настроек Lightmap Parameters, значение Indirect resolution должно быть равно 1. Это надо запомнить.
Вероятно, значение в поле Indirect resolution необходимо использовать тогда, когда вы используете Defoult настройки поля Lightmap Parameters.
Resolution задает разрешение текселей на метр.
https://docs.unity3d.com/ScriptReferenc ... ution.html
При значении 1 размер кластера будет равен одному метру. При увеличении значения, размер кластера уменьшается, при уменьшении значения размер кластера увеличивается, т.е. при значении 2, размер кластера будет равен 0,5 метру, при значении 0,5, размер кластера будет равен 2 метрам. (немного забегая вперед, при значении 1 у Cluster Resolution)

Третий параметр Cluster Resolution. По названию создается впечатление что это разрешение самого кластера, т.е. кластер бьется как бы на подкластеры которые создают дополнительную детализацию кластера.
Справка говорит что отношение разрешения кластера (разрешение, при котором отраженные источники света рассчитываются внутри кластера) к окончательному разрешению карты освещения.
https://docs.unity3d.com/ScriptReferenc ... ution.html
Разрешение кластера умножается на разрешение карты освещения в реальном времени.
Для расчета корректных результатов окончательного размера кластера, можно следовать следующей формуле: Размер кластера в метрах = 1 / (Resolution * Cluster Resolution), где единица это один метр.

Справка так же настойчиво утверждает что Cluster Resolution это непосредственно разрешение отражаемого света. Это проявляется в виде так называемой "плесени" в местах затенения, т.е. не равномерной тени, а как бы со светлыми проплешинами. Инструментов что бы как то иначе увидеть это разрешение, Юниты не предоставили.

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

При том что максимальное значение Cluster Resolution равно единице, то по факту максимально возможно устанавливаемое значение для Resolution без потери качества, так же должно соответствовать единице. Или проще говоря, размер кластера будет равен одному метру для достижения наилучшего качества. Соответственно нименьшее значение для Resolution будет равно 0,1.

Irradiance Budget - определяет сколько памяти выделяется для одного texel. Ничего сверхестественного тут нет, подробно описывается в https://unity3d.com/ru/learn/tutorials/ ... parameters
Из написанного может сложиться впечатление что этот параметр так же влияет на артефакт "плесень", но лично я подтвердить это не могу. Во всех моих случаях, просто просчет освещения был менее точным, что выражалось в нелогичном распределении затенения.

Irradiance Quality - количество лучей которое генерируется для одного кластера до других объектов.
Так же ничего сложного, подробно описывается в https://unity3d.com/ru/learn/tutorials/ ... parameters

Итог.
Для того что бы получить наилучшее качество освещения, необходимо выставить параметр Indirect resolution на единицу, иметь параметр Resolution не выше единицы, Cluster Resolution выставить так же на единицу, параметры Irradiance Budget и Irradiance Quality поставить на максимум.

Все это приведет к максимально долгому расчету и занимаемой памяти. Для оптимизации, необходимо играть параметрами, а именно:
Indirect resolution должен оставаться без изменений и равен 1.
Resolution не должен быть ниже 0.1 и выше 1. Чем ниже, тем быстрее будут произведены расчеты, меньше использовано памяти, как следствие хуже качество освещения. Например для больших площадей, где у вас допустим один кубик метр на метр, на площади в 100*100, это значение может быть минимально возможным, поскольку смысла в подробном освещении нет никакого.
Cluster Resolution должен находиться в строгой корреляции с Resolution. Изменения должны находиться в минимальном диапазоне. Условно говоря, вы должны запечь карту с равными параметрами Resolution и Cluster Resolution, и только после этого играть параметром Cluster Resolution для достижения наилучшего (при условии конечно значения Resolution ниже 1) или неизменного результата, при более низком значении Cluster Resolution.
Irradiance Budget - тут все немного сложнее. Лучше конечно играть от большего к меньшему, но при больших картах, лучше от меньшего к большему и например остановиться там где кажется что обсчет идет непозволительно долго.
Irradiance Quality - тоже самое.

Билд - https://drive.google.com/open?id=1RCgtB ... MF37qt4tvk




Продолжение темы.
Билд выложу позже. За перевод спасибо гуглу.
Так же не стал рассматривать разные степени освещенности.

Часть 1.

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

Продолжим.
Теперь наши вкладки в выпадающем левом меню для Baked Global Illumination. Сама визуальная карта, в Baked Lightmap.
Перво-наперво сталкиваемся с режимами освещения Lighting Mode в поле Mixed Lighting где и ставим галку на использование статического освещения. Тут все просто – справка все исчерпывающе объясняет, поэтому я просто дам на нее ссылку и общими словами дам краткое описание. Обязательно прочитайте ее, там есть некоторые ограничения в использовании. Ссылка - https://docs.unity3d.com/Manual/LightMode-Mixed.html

Есть три режима:
1) Shadowmask
Наилучшее качество теней и наиболее ресурсоемкий вариант.
2)Baked Indirect
Как бы урезанный вариант Shadowmask. Если в Shadowmask тени просчитываются «до горизонта», то здесь до определенного расстояния («menu: Edit > Settings , then select the Quality category, and navigate to the Shadows»).
3) Subtractive
Наихудший вариант, но очень легкий. Рекомендуется для слабых устройств.


Потом идет поле Lightmapping Setting с непосредственными настройками режима освещения.

Lightmapping
Какой алгоритм обработки использовать для расчета освещения. Имеет три варианта:
1) Enlighten
Этот вариант как раз может использоваться для Realtime Lighting, но также может и без Realtime Lighting.
2) Progressive CPU
Статичное освещение в чистом виде.
3) Progressive GPU (Preview)

Начнем с Enlighten. https://docs.unity3d.com/Manual/GI-Enlighten.html

Indirect Resolution
Это свойство доступно только при включенном глобальном освещении в реальном времени.
Используйте это значение, чтобы указать количество текселей на единицу, которое будет использоваться для расчетов непрямого освещения. Увеличение этого значения улучшает визуальное качество непрямого света, но также увеличивает время, необходимое для выпечки световых карт. Значение по умолчанию - 2. См. Учебник Unity по разрешению в реальном времени для получения подробной информации о косвенном разрешении. https://learn.unity.com/tutorial/precom ... lumination

Расматривалось ранее.

Lightmap Resolution
Определяет количество текселей на единицу, используемых для световых карт. Увеличение этого значения улучшает качество карты освещения, но также увеличивает время выпечки.

Довольно непонятное заявление. При значении равной 1, наши тексели равны чуть больше 1 метру. При увеличении значения, тексели как раз становятся меньше, что сразу же проявляется во времени запекания и размере файла карты освещения (в моем случае, значение 1 давала карту размером 32х32 и вес 2.7 кб, в то время как значение 100, давало одну карту размером 1024х1024 весом в 2.7мб, а значение в 200 дало уже две карты 1024х1024 и размер соответственно 5.3 мб). Т.е. справедливо полагать, что значение 1 дает 1 тексель на 1 единицу. Отсюда выходит, что чем больше текселей на единицу, тем лучше. Похоже, что Lightmap Resolution это соотношение, выраженное в числовом значении, что бы это ни значило. Получается, что Baked Global Illumination может дать более подробную карту освещения чем Realtime Lighting.
Проблема может возникнуть в определении верхней границы Lightmap Resolution. В идеале, нет смысла создавать тексель меньше, чем минимальная поверхность отражения объекта. Для простоты примера, возьмем сцену, где будут находиться три куба размером 1 метр которые находятся по одной оси в ряд на одной высоте без зазоров друг у друга. Для максимально возможного результата освещения, значения Lightmap Resolution должен быть равен 1, поскольку минимальный размер отражающей поверхности равен 1 метру. Если сделаем значение 2, то улучшения результата не будет, значит можно считать верхней планкой для Lightmap Resolution значение 1. Если какой, то из кубов поднять над другим на 0.5 метров, то минимальный размер отражающей поверхности у нас уже будет 0.5 метров. Следовательно, для максимально хорошего освещения, значение Lightmap Resolution должно будет равно 2. И так далее. Так что если вы раньше думали, что раз вы художник, то вам не нужна ни физика, ни математика, ни геометрия, вы глубоко ошибались. Увы.

Lightmap Padding
Определяет разделение (в единицах текселя) между отдельными фигурами в запеченной карте освещения.

При низких значениях, по краю объекта может появиться такая темная полоска, как будто там есть маленький заступ или кантик. Как правило проявляется на стыке двух освещенных поверхностей, на которые непосредственно падает свет, одна из которых освещена лучше. Вот на той поверхности, которая темнее, появляется темная полоска. Так вот этим параметром можно его ликвидировать.
Вообще отследить его проявление специально не каждый раз получается. Я вообще, по сути, совершенно случайно его таки увидел, когда уже собирался писать о том, что не нашел его проявления. Поэтому я тут размещу скрин, а вы кликайте на него, что бы он не отправился в архив файлообменника.https://cdn1.savepice.ru/uploads/2019/7 ... f-full.jpg

Lightmap Size
Размер (в пикселях) полной текстуры карты освещения, которая включает отдельные области для отдельных текстур объекта.

Тут можно сказать, что задается верхнее ограничения для размера текстуры карты освещения. Если вы укажите размер 1024, но его будет с избытком хватать что бы разместить в ней всю информацию, то будет создана одна карта освещения. Если же вы укажите размер в 32, то будет создано несколько карт освещения каждая из которых будет размером в 32х32 пикселя, в которых будет содержаться вся необходимая информация, которую можно было запихнуть в этот размер.
Лучше всего, если у вас все поместится в одну карту освещения. При низких значениях начинают возникать артефакты в виде нечеткого края объекта с затененной стороны, или более темной поверхности у мелких предметов, примерно так что они плохо просчитаны или не просчитаны вовсе. Собственно, если разрешение текстуры не будет позволять занести информацию о мелких предметах в карту освещения, то хоть они и будут обсчитаны, но к ним эти обсчеты применяться не будут, ибо информации об этом не сохранится или сохранится частично.
Безусловно, более высокие значения существенно влияют на время обсчета, поэтому конечно в идеальном случае необходимо подбирать оптимальное разрешение. Но если у вас время и место на диске, то тут чем больше, тем меньше ошибок.

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

Тут комментировать нечего.

Ambient Occlusion
Открывает группу настроек, которые позволяют вам контролировать относительную яркость поверхностей в окружающей окклюзии. Более высокие значения указывают на больший контраст между окклюзированными и полностью освещенными областями. Это относится только к косвенному освещению, рассчитанному системой GI. Это свойство включено по умолчанию.

Max Distance
Устанавливает значение для управления тем, как далеко система освещения отбрасывает лучи, чтобы определить, применять или нет окклюзию к объекту. Большее значение создает более длинные лучи и вносит больше теней в карту освещения, в то время как меньшее значение создает более короткие лучи, которые дают тени только тогда, когда объекты расположены очень близко друг к другу. Значение 0 приводит к бесконечно длинному лучу без максимального расстояния.

Indirect Contribution
Используйте ползунок, чтобы масштабировать яркость непрямого света (то есть окружающего света или света, отраженного от объектов) в итоговой карте освещения, от значения от 0 до 10. Значение по умолчанию равно 1. Значения меньше 1 уменьшают интенсивность, а значения больше 1 увеличивают ее.

Direct Contribution
Используйте ползунок, чтобы масштабировать яркость прямого света от 0 до 10. Значение по умолчанию равно 0. Чем выше это значение, тем больше контраст, применяемый к прямому освещению.

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

Ray Count
Определяет количество лучей, испускаемых для каждой конечной точки сбора.

На первый взгляд может показаться что Ray Count и Lightmap Resolution резонируют друг с другом перекрывая себя. Но не надо забывать, что Lightmap Resolution это обязательный параметр, а Ray Count опционный. Чем больше будет пущено лучей, тем, конечно, лучше. Так же надо учитывать, что если вы пустите овед дохрена лучей, но разрешение карты освещения не позволит их зафиксировать, то смысла от них будет не много. Да, точность вычислений будет высокой, но результат скорее всего будет посредственный.
Кроме этого, надо всегда стараться придерживаться вычислений, не дающих бесконечный остаток, как правило это четные числа. У Юнити и вовсе на этом пунктик.

Denoising
Применяет шумоподавляющий фильтр к выходу Final Gather .

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

Directional Mode
Вы можете настроить карту освещения для хранения информации о доминирующем входящем свете в каждой точке на поверхностях ваших игровых объектов. См. Документацию по Направленному Lightmapping для получения дополнительной информации. https://docs.unity3d.com/Manual/Lightma ... ional.html

Directional
В Направленном режиме Unity генерирует вторую карту освещения, чтобы сохранить доминирующее направление входящего света. Это позволяет диффузным картографическим материалам работать с ГИ. Направленный режим требует примерно вдвое больше места для хранения дополнительных данных карты освещения. Unity не может декодировать направленные световые карты на оборудовании SM2.0 или при использовании GLES2.0. Они откатываются к Non-directional световым картам.

Non-directional
В ненаправленном режиме Unity не генерирует вторую карту освещения для доминирующего направления входящего света, а вместо этого сохраняет всю информацию о освещении в одном месте.
Indirect Intensity
Управляет яркостью непрямого света, который Unity сохраняет в режиме реального времени и запеченных световых картах, от значения между 0 и 5. Значение выше 1 увеличивает интенсивность непрямого света, а значение меньше 1 уменьшает интенсивность непрямого света.

Albedo Boost
Контролирует количество света, которое Unity отражается между поверхностями, усиливая альбедо Материалов в Сцене, от значения между 1 и 10. При увеличении этого значения альбедо притягивается к белому для вычисления непрямого света. Значение по умолчанию равно 1, что является физически точным.

Lightmap Parameters
Unity использует набор общих параметров для отображения освещения в дополнение к свойствам окна освещения. Для этого свойства доступно несколько значений по умолчанию, но вы также можете использовать опцию Create New, чтобы создать свой собственный файл параметров карты освещения. См. Страницу параметров Lightmap для более подробной информации. https://docs.unity3d.com/Manual/class-L ... eters.html

Рассматривалось ранее.

Обещанный билд.
Интересный момент. Я писал о том что Юнити, как и собственно любой другой движок, не учитаывает отражения света от воздуха. Из за этого, если не применять дополнительные источники света, все выглядит как в вакуме. Проблема дополнительных источников света в том, что они дают дополнительныю нагрузку на видеокарту, что конечно довольно плохо. Так вот, с Baked Global Illumination эту проблему можно решить, просто просчитав карту света с дополнительными источниками света, а затем отключить эти дополнительные источники света. Получится естественное дешовое освещение. Помните я писал о необходимости знаний физики для художников? Сам билд - https://yadi.sk/d/YNrgnO6lnYb9uQ.

Вчера перепутал билды и выложил билд в котором был запечен свет без дополнительных источников света. А вот билд, который был запечен с дополнительными источниками света, но сейчас они отключены. 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 иметь настройки озвеченные выше.
Последний раз редактировалось sledo 23 июл 2019, 13:47, всего редактировалось 5 раз(а).
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 21 окт 2018, 22:34

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 игровых объектов. Развивая вывод, можно сказать что для наиболее прогнозируемых результатов, необходимо выдерживать на сцене одинаковые размеры объектов.
Вообще это довольно интересная штука, которая была случайно обнаружена. Ни где я не видел информации о такой зависимости. Это наводит на мысль, что можно регулировать подробность освещения, для каждого отдельно взятого объекта на сцене, просто масштабируя его соответствующим образом. Так же не стоит растягивать объекты, поскольку сетка растягивается в строгом соответствии давая по растянутой оси растянутые текстели.

Ссылка на файл с текстом - 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 ситуацию может скорее улучшить, чем ухудшить.

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

Общие выводы по освещению.
От себя.
Детально рассмотрев не одну систему Юнити, у меня все больше укрепляется мнение что движок похож на некий Мех (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. Если вы не уверены или точно знаете что у вас будут динамические источники света, то конечно надо использовать остальные системы.
Динамическое освещение лишено вообще всех недостатков. И преимуществ. Хотя в данном случае отсутствие недостатков это как раз преимущество, из чего получается что оно имеет только преимущества и можно сделать вывод что это самое лучшее освещение. Хе-хе. Шутка юмора.

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



Карты нормалей текстуры (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.


Развитие темы фотографичности подходит к своему логичному завершению. Осталось рассмотреть лишь индивидуальные настройки объектов которые как я надеюсь помогут исправить косяки 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, что конечно еще хуже. Так же я пока не заморачивался с созданием "лодов" (или что там подойдет под эти цели) опираясь на качество тектурирования, что бы поддерживать высокое качество изображения подставляя оптимальные разрешения текстур с ростом расстояния.


Обновление и дополнение темы. Работа с ЛОДами


При работе над сценой по предложенной мной методике, выяснилось следующее. (Далее все справедливо для разрешения экрана 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 08 мар 2020, 16:03, всего редактировалось 6 раз(а).
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 21 окт 2018, 22:35

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

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

Сообщение lawson 22 окт 2018, 11:39

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

И не понятно ваше замечание по поводу "типичных" граждан, кто эти люди!?
lawson
UNIверсал
 
Сообщения: 481
Зарегистрирован: 14 сен 2012, 21:20

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

Сообщение sledo 23 окт 2018, 15:27

lawson писал(а):Поздаравляю Вас, наконец вы смогли привести материал к надлежащему виду, надеюсь вы не будете как всегда критично воспринимать чужие советы, но я бы лучше спарятал видео под спойлеры чтобы было удобней читать. Хотя, в некоторых примерах даже записи не нужны, можно просто два изображения до изменений и после.

Спасибо. Я не часто пишу посты, поэтому конечно опыта создания сразу удобного формата поста у меня нет. Но, я работаю над этим.
К обоснованной критике и предложениям я всегда отношусь положительно. Меня раздражают высказывания типа - "это все овно, а автор удак. -Почему? -Потому.". Ничего поделать с собой не могу.
Насчет спойлеров у меня мысль возникала, но я от нее отказался поскольку мне показалось что будет разрыв в повествовании. Т.е. когда человек что то воспринимает, у него складываются определенные ожидания. В данном случае я предлагаю посмотреть видео с результатами и читатель по идее должен ожидать видео с результатами, но вместо него будет спойлер который скрывает ожидаемую информацию. С другой стороны, практического смысла в видео не много, поскольку технические ограничения не позволяют продемонстрировать разительную разницу в качестве текстуры в предложенных случаях, а они действительно в некоторых случаях очень существенны и видео по сути являются лишь предоставлением факта того что на моем мониторе это было действительно так. Но все же решил что оправдывание ожиданий важнее практичности.
lawson писал(а):Хотя, в некоторых примерах даже записи не нужны, можно просто два изображения до изменений и после.

Картинки надо заливать на какие то хосты, которые хранят их в зависимости от популярности картинки и если популярность низкая, то они отправляются в архив, а значит здесь их не будет. Поэтому для демонстрации я выбрал формат видео. Принципиальной разницы в этом нет. Когда человек займется этим вопросом, то практика покажет то же самое что и видел я. А тут заняться практикой придется и довольно плотно, что бы самому понимать что и когда выгоднее использовать, ибо часто разрешение текстур в 512 дает лучшее качество чем разрешение 1024 в разных условиях, а иногда наоборот.
lawson писал(а):И не понятно ваше замечание по поводу "типичных" граждан, кто эти люди!?

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

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

Сообщение lawson 23 окт 2018, 20:13

Меня раздражают высказывания типа - "это все овно, а автор удак. -Почему? -Потому.". Ничего поделать с собой не могу.

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

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

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

Прошу Вас, хватит упоминать ваших личных врагов в тексте, это очень мерзко выглядит.
lawson
UNIверсал
 
Сообщения: 481
Зарегистрирован: 14 сен 2012, 21:20

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

Сообщение sledo 23 окт 2018, 21:15

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

Честно говоря я не вижу в этом проблемы. Если нажить ctrl+F и набрать интересующее слово, то любой браузер его найдет в тексте. Мне кажется это намного удобнее чем скакать по темам, тем более которые идут в одном ключе. Я думаю что улучшу структуру текста разбив его на части по ключевым словам, которые вынесу на верх по типу оглавления с инструкцией к поиску, что бы человек мог быстро перейти на интересующий его раздел. Я думаю это будет намного лучше, поскольку информации соберется довольно много и ее можно будет использовать как справочную. Я уже сейчас вижу у стандартного освещения 4 разных подхода в Юнити каждый из которых надо раскрыть и подробно описать. Уверяю, тут спойлеры для экономии места, не помогут. Я даже смею надеяться что стандартные возможности движка могут позволить создавать очень правдоподобную игру света в лесном массиве - одно это займет очень много места, если конечно предположения подтвердятся.
lawson писал(а):Складывается ощущение будто вы с каким то пренебрежением относитесь к этим гражданам, так бы и написали: "так как у большинства пользователей установлен такой то монитор поэтому будем использовать такую то технологию". Ну это так мелочи.

Исправлено.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 27 дек 2018, 18:30

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

В связи с недавно вышедшим обновлением Таркова, сделал билд где можно наглядно увидеть разницу между дефолтными настройками текстур с не подобранным разрешением и настроенной комнатой. Вообще конечно надо было его сделать намного раньше, но как всем нам известно, время, это именно то чего вечно не хватает. Выкраил пару часиков на это благое дело.
Пример полностью показывает разницу между двумя подходами и демонстрирует насколько слабо Юнити работает с текстурами. Так же он демонстрирует артефакты зернистости и проигрыш в качестве перед дефолтными настройками. Надеюсь теперь даже у самых ярых скептиков не останется сомнений в том что подбор разрешения текстур и настройка самих текстур является критически важным аспектом в графическом качестве игр.
Примеры ошибок:
1) Книги, дверь и фото кошки внизу у стенки, имеют артефакты зернистости. Разрешение текстур кошки 256, книг 1024, дверь 2048. Ошибки при создании перспективы. Разрешение надо снижать, либо все замыливать.
2) Стол имеет большую четкость как раз при дефолтных настройках текстуры, при том что разрешение текстур у них одинаковое. Ошибка подбора разрешения текстуры.
Сам билд - https://yadi.sk/d/w50gX9YszV1kNw
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 30 дек 2018, 04:57

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

Еще один билд, который демонстрирует сохранение качества текстуры с ростом расстояния, посредством использования верно подобранного разрешения. Так же потеря качества при использовании текстуры высокого разрешения на расстоянии. https://yadi.sk/d/MnBetCGP2Ja88g
Интересная ошибка при билде комнаты. Я не стал заменять материалы в комнате, а просто создал еще одну и при нажатии кнопки отключаю какую то из них. Так вот если создавать билд с заранее отключенной настроенной комнатой, то появляется странная ошибка с текстурой на стелаже. https://yadi.sk/d/1dw5u93a1wTczg
Обобщая тему с разрешением текстур и настройкой фильтров, можно сделать следующие выводы:
1) Очень важно понимать на каких расстояниях будут смотреть на объект и в зависимости от этого подбирать разрешение текстур и фильтры
2) Если стоит задача добиться максимального качества, то в лодах использовать подходящие текстуры и настройка отключения лодов должна происходить исходя из потери качества текстур
3) При большом воздействии перспективы, низкое разрешение это как раз хорошо.

Пожалуй на этом можно закрывать тему с текстурированием.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение Zulllus 28 фев 2019, 11:18

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

Для остальных, беглое пояснение исследования:
0. Мипмапы - это версии текстуры с разным разрешением, сделанные не только ради экономии памяти ускорителя, но для предотвращения дребезжания точек. Если взять очень большую текстуру и положить ее на очень маленький треугольник (на экране треугольник помещается в 10 точек, а текстура, например, в 100 точек), то ускоритель сам не смешает 100 точек, он тупо возьмет каждую 10 точку с текстуры. Но проблема в том, что когда треугольник поворачивается, то количество точек может плавать от (скажем) 9 до 11, и тогда точки со 2 по 8(9,10) будут отличаться для этих трех версий (с 9, 10 и 11 точками соответственно) и это будет выглядеть как дребезг. А вот если на этот треугольник положить текстуру с 10 точками, то дребезга не будет, т.к. точки будут одинаковые для всех трех версий (почти одинаковые). Вот в этом суть мипмапинга! На ускорителе есть версии текстуры под разный размер треугольника. Когда он шириной 100 - то текстура 100. Когда 10 - 10.
1. Мипмапы нужны, без них никак, но юнити генерит их откровенно плохо. Нужно включать коррекцию границ и фильтр кайзера, получается хуже фотошопа, но что делать.
2. Лучше всего мипмапы делать фотошопом, 10 лет назад другого нормального способа их сделать не было, сейчас вообще нет нормального способа для Юнити. В магазине дополнений есть несколько дополнений, которые позволяют немного улучшить ситуацию, но не сильно.
3. Теперь про фильтрацию. Фильтрация нужна для смешивания мипмапов. Если их нет, то и фильтрация работать не будет. Фильтрация борется с границей переходов между мипмапами, соответственно, отключая ее мы повышаем четкость текстуры до стыка, но зато получаем галимый стык между текущим и следующим мипом.
4. Я не смотрел, что делает юнити с текстурами не кратными двойке, вроде есть галка, которая объясняет, что он может работать с любыми, но что по факту происходит - хз. Но скорее всего не очень важно, является ли текстура кратной 2 (на современных ускорителях проблемы быть не должно). Но есть момент, который реально важный, чем кратность и нужно его понять. Ускоритель из двух мипмапов выбирает тот, что больше подходит короткой стороне. Тут как раз автор рассказывает про проблему пола. Так вот, если короткой стороне нужен самый маленький мип, то текстура будет жутко замыленной. Но чаще всего это получается из-за того, что неправильно сделана UV карта, и берется не 0 мип, а 1 или 2 (о чем говорит автор, но не понимает суть).
5. И еще, может кто-то не понял, мипы всегда отличаются в 2 раза, т.е. между 1024 и 512 нет промежуточных мипов, и ускоритель без фильтрации перепрыгнет с 1024 на 512 щелчком, т.е. если треугольник по горизонтали меньше 1024 точек, то без фильтрации на следующем кадре ускоритель перейдет на текстуру в 512 точек. И именно фильтрация это лечит. Она смешивает по сложному паттерну, включая учет угла между камерой и треугольником. Она СЕЙЧАС бесплатная с точки зрения производительности, поэтому включаем максимальную, трилинейную.

Теперь для тех, кто хочет сделать круто: сделайте свое дополнение, которое будет заменять встроенные в юнити мипмапы на мипмапы, сделанные вручную. Это единственный способ сделать текстуры четче. То, что предлагает автор вообще это не способ. Но если вы не можете сделать свое дополнение, то следуйте следующим советам:
1. Для одного объекта все мипы должны быть одного уровня. Грубо говоря, если у нас текстурирование где-то более растянутое, а где-то более сжатое, то ускорителю фиолетово. Он все равно возьмет не оригинальную текстуру: мип номер 0, а ту, что лучше подходит: мип номер 2, а это значит, что вместо хорошей четкой текстуры мы получим текстуру, сгенерированную убогим алгоритмом юнити из нее.
2. Чтобы понять, какие мипы используются в дополнениях есть бесплатное, которое показывает номер мипа. Номер мипа напрямую не зависит от разрешения экрана, он зависит от текстурной развертки (UV map). И только удивив на экране номер можно подгонять текстуру под это разрешение. Разумеется, нельзя всегда получать идеальный мип, т.к. юнити не дает нарисовать в ручную все мипы, но для (скажем) главного героя от третьего лица можно подобрать лучший мип и параметры этого мипа. Важность этого дополнения еще в том, что вы можете увидеть, что если объект у вас раскрашен разными мипами, но использует одну текстуру - карта UV сделана не правильно.
3. Карту UV нужно делать очень внимательно, это в 10 раз эффективнее, чем следовать советам автора. А чтобы понять, что все правильно, нужны инструменты, которых в юнити нет. Но! Есть дополнения, которые позволяют частично решить проблему, как платные, так и бесплатные. Я их специально не исследовал, рекомендую этим заняться автору. Тогда может будет толк в этой теме.
Zulllus
UNец
 
Сообщения: 1
Зарегистрирован: 28 фев 2019, 10:12

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

Сообщение seaman 28 фев 2019, 15:06

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

Unity поддерживает импорт dds текстур, в которых есть mipmap. Так что дополнение по сути не нужно, нужно просто мипмпы сделанные вручную загонять в dds.
Одно замечание:
You can import Textures from DDS files, but only DXT, BC compressed formats, or uncompressed pixel formats are supported.

Там в dds есть несколько разных типов - поддерживаются не все.
Второе замечание.
Я правда давно пробовал, но ранее если в dds были не все мипмапы, то юнити их не воспринимал.
seaman
Адепт
 
Сообщения: 8352
Зарегистрирован: 24 янв 2011, 12:32
Откуда: Самара

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

Сообщение sledo 07 мар 2019, 01:48

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

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

В Юнити есть два варианта освещения - динамическое и заранее вычисленное.

Если использовать только динамическое освещение, то тени будут очень темными, а светлые участки очень светлыми. Юниты это объясняют тем, что в таком случае не просчитывается отраженный свет.
Тут надо немного более подробно изъясниться.
Динамическое освещение, это когда у вас отключены галки на Realtime GI и Baked global illuminationили по какой то причине не была запечена световая карта. при настройках по умолчанию, скорее всего у вас будет очень темная сцена, с практически черными тенями даже в местах где есть интенсивное освещение. Это как раз следствие того что свет не отражается от поверхностей и тем самым дополнительно не освещает их. Никакими ползунками осветления это не исправить, кроме как изменить значение Source со Скайбокса например на Color в окне Lighting, графе Environment lighting. Чем светлее цвет, тем светлее вся сцена.

Соответственно в Юнити это самое худшее по качеству освещение. Долго останавливаться на нем нет смысла, поскольку тут ничего не сделаешь и отсутствуют вообще какие либо настройки (конечно если не учитывать глобальные настройки проекта и сцены).
Юниты говорят, что самое реалистичное освещение это комбинация Real-time lighting и Baked global illumination, или иными словами комбинация запеченных теней и света в реальном времени.
Для того что бы использовать эти типы освещения, надо поставить галку "Статик" у объекта, т.е. сделать их статичными.
Получается, что для всех динамических объектов, будет применяться динамическое освещение, т.е. наихудшее качество света.
Соответственно при использовании комбинации Real-time lighting и Baked global illumination, правильнее будет сказать что используются динамические тени для статического объекта. Следует четко понять, что Real-time lighting это статическое освещение, а не динамическое как иногда многие считают.

Ситуация скверная и Юниты немного подправили ее с помощью light probe. Light probe нужно как раз для того что бы были динамические тени у динамического объекта по качеству немного лучше чем у простого динамического освещения, т.е. что бы отражения света от поверхности обсчитывались и для динамических объектов, необходимо использовать light probe.
Кроме того, на больших сценах или где использование подробных запеченных карт освещения Realtime GI нецелесообразно, для мелких предметов как раз так же можно использовать light probe. Проблема light probe в том, что он может использоваться только локально и так же запекается, а значит не может быть привязан к динамическому объекту, а обсчет происходит только когда динамический объект попадает в зону light probe.
Например есть динамическое помещение, например трейлер. Влияние на его помещение окружающей средой минимально. Соответственно в данный момент, иметь хорошо освещенное внутренне помещение трейлера возможности нет, поскольку запеченная карта освещения будет находиться статично на одном месте, а не передвигаться вместе с трейлером. Соответственно для помещения трейлера будет применяться real-time lighting который просто освещает поверхность без отражения света от нее. Ситуация немного улучшится, когда он войдет в зону действия light probe, однако по сравнению с Realtime GI уровень освещения все равно существенно ниже, да еще и будут появляться артефакты. Сюда добавляем полное отсутствие отражений от воздуха и получаем, что получить хорошо освещенные динамические объекты в Юнити нет ни какой возможности стандартными средствами. Такие дела.

Большое значения разрешения световой карты для Realtime GI, может привести к сбою.
Юниты говорят о том, что высокие разрешения для Realtime GI не нужны. Для больших карт надо делать низкое разрешение и если требуется детальное разрешение то использовать локальные карты. Недостатки освещения компенсировать light probe. Все это нет нужды описывать заново, есть очень подробная инструкция
https://unity3d.com/ru/learn/tutorials/ ... g-clusters
Однако в версии Юнити 2018.2,6 есть странный, скажем так баг. Свет Realtime GI не всегда запекается, даже если вроде как все настроено правильно. Поэтому обязательно надо проверять после обсчета:
1) наличие ошибок (если есть ошибки при обсчете, значит у вас не будет запеченных карт света)
2) Включать слой отображения кластеризации Lit Clustering, в правом верхнем углу окна Scene.
Lit Clustering вам покажет насколько хорошо был произведен обсчет статичных объектов на сцене. В идеале, он должен быть равномерным, без рваных дыр. Добиться этого можно настройками LightmapParameters.
Если же в этом режиме у вас нет ничего на сцене, или же только какие фрагменты, то карта света не была создана или создана только для тех фрагментов которые вы видите. Это очень важно знать и понимать и обязательно проверить.


https://docs.unity3d.com/Manual/class-L ... eters.html
Теперь попробуем разобраться с настройками для Real-time lighting.
Если три параметра Resolution:
1) Indirect resolution
2) Resolution
3) Cluster Resolution
Первый в настройках окна Lighting, другие два в настройках Lightmap Parameters.
Из справки можно сделать вывод, что Resolution из LightmapParameters имеет преимущество над Indirect resolution, однако прямо об этом не говорится.
Для того что бы получать корректные результаты при использовании своих настроек Lightmap Parameters, значение Indirect resolution должно быть равно 1. Это надо запомнить.
Вероятно, значение в поле Indirect resolution необходимо использовать тогда, когда вы используете Defoult настройки поля Lightmap Parameters.
Resolution задает разрешение текселей на метр.
https://docs.unity3d.com/ScriptReferenc ... ution.html
При значении 1 размер кластера будет равен одному метру. При увеличении значения, размер кластера уменьшается, при уменьшении значения размер кластера увеличивается, т.е. при значении 2, размер кластера будет равен 0,5 метру, при значении 0,5, размер кластера будет равен 2 метрам. (немного забегая вперед, при значении 1 у Cluster Resolution)

Третий параметр Cluster Resolution. По названию создается впечатление что это разрешение самого кластера, т.е. кластер бьется как бы на подкластеры которые создают дополнительную детализацию кластера.
Справка говорит что отношение разрешения кластера (разрешение, при котором отраженные источники света рассчитываются внутри кластера) к окончательному разрешению карты освещения.
https://docs.unity3d.com/ScriptReferenc ... ution.html
Разрешение кластера умножается на разрешение карты освещения в реальном времени.
Для расчета корректных результатов окончательного размера кластера, можно следовать следующей формуле: Размер кластера в метрах = 1 / (Resolution * Cluster Resolution), где единица это один метр.

Справка так же настойчиво утверждает что Cluster Resolution это непосредственно разрешение отражаемого света. Это проявляется в виде так называемой "плесени" в местах затенения, т.е. не равномерной тени, а как бы со светлыми проплешинами. Инструментов что бы как то иначе увидеть это разрешение, Юниты не предоставили.

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

При том что максимальное значение Cluster Resolution равно единице, то по факту максимально возможно устанавливаемое значение для Resolution без потери качества, так же должно соответствовать единице. Или проще говоря, размер кластера будет равен одному метру для достижения наилучшего качества. Соответственно нименьшее значение для Resolution будет равно 0,1.

Irradiance Budget - определяет сколько памяти выделяется для одного texel. Ничего сверхестественного тут нет, подробно описывается в https://unity3d.com/ru/learn/tutorials/ ... parameters
Из написанного может сложиться впечатление что этот параметр так же влияет на артефакт "плесень", но лично я подтвердить это не могу. Во всех моих случаях, просто просчет освещения был менее точным, что выражалось в нелогичном распределении затенения.

Irradiance Quality - количество лучей которое генерируется для одного кластера до других объектов.
Так же ничего сложного, подробно описывается в https://unity3d.com/ru/learn/tutorials/ ... parameters

Итог.
Для того что бы получить наилучшее качество освещения, необходимо выставить параметр Indirect resolution на единицу, иметь параметр Resolution не выше единицы, Cluster Resolution выставить так же на единицу, параметры Irradiance Budget и Irradiance Quality поставить на максимум.

Все это приведет к максимально долгому расчету и занимаемой памяти. Для оптимизации, необходимо играть параметрами, а именно:
Indirect resolution должен оставаться без изменений и равен 1.
Resolution не должен быть ниже 0.1 и выше 1. Чем ниже, тем быстрее будут произведены расчеты, меньше использовано памяти, как следствие хуже качество освещения. Например для больших площадей, где у вас допустим один кубик метр на метр, на площади в 100*100, это значение может быть минимально возможным, поскольку смысла в подробном освещении нет никакого.
Cluster Resolution должен находиться в строгой корреляции с Resolution. Изменения должны находиться в минимальном диапазоне. Условно говоря, вы должны запечь карту с равными параметрами Resolution и Cluster Resolution, и только после этого играть параметром Cluster Resolution для достижения наилучшего (при условии конечно значения Resolution ниже 1) или неизменного результата, при более низком значении Cluster Resolution.
Irradiance Budget - тут все немного сложнее. Лучше конечно играть от большего к меньшему, но при больших картах, лучше от меньшего к большему и например остановиться там где кажется что обсчет идет непозволительно долго.
Irradiance Quality - тоже самое.



Zulllus писал(а):Эх. Изучаю Юнити, прочитал эту ахинею. Ужаснулся. Автор, ты может и не плохой исследователь, но зачем это все было исследовать, если ты не понимаешь принципа работы графического ускорителя с текстурами?

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

Дело в том, что я не ограничен правилами.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

Сообщение sledo 20 июл 2019, 20:21

Продолжение темы.
Билд выложу позже. За перевод спасибо гуглу.
Так же не стал рассматривать разные степени освещенности.


Часть 1.

Статическое освещение.
Как и Realtime Lighting, Baked Global Illumination просчитывается заранее и во время игры берутся уже готовые результаты просчета, потому это называется статичным освещением. По сравнению с Realtime Lighting, тут настроек намного больше и как заявляют Юниты именно симбиоз Baked Global Illumination и Realtime Lighting, дает наилучший результат. Так что давайте разбираться, что к чему.
Вообще во время тестирования у меня началось складываться стойкое ощущение того, что разработчики знают, как работает их движок исключительно из теории. Они что-то делают, по их расчетам и алгоритмам это должно работать определенным образом, но на самом деле все работает только в строгом диапазоне настроек. Точно с этим же я столкнулся уже при исследовании Baked Global Illumination. В какой-то момент, карты освещения просто не создавались, точнее сами файлы были, а вот информации в них не было. Это конечно прилично усложняет проведение тестирования. Так что я хочу особо подчеркнуть и обратить ваше внимание на то, что после просчета освещения, обязательно проверяйте результаты, а начальные настройки подбирайте только на малых тестовых сценах. Еще хорошо активно использовать бекапы зафиксированных результатов и уже от них отталкиваться дальше. Так что если вы получили более менее приличный результат, вы могли их просто подгрузить его в случае неудачного нового просчета, а не тратить время на просчет с откатаными настройками.
Теперь наши вкладки в выпадающем левом меню для Baked Global Illumination. Сама визуальная карта, в Baked Lightmap.
Перво-наперво сталкиваемся с режимами освещения Lighting Mode в поле Mixed Lighting где и ставим галку на использование статического освещения. Тут все просто – справка все исчерпывающе объясняет, поэтому я просто дам на нее ссылку и общими словами дам краткое описание. Обязательно прочитайте ее, там есть некоторые ограничения в использовании. Ссылка - https://docs.unity3d.com/Manual/LightMode-Mixed.html
Есть три режима:
1) Shadowmask
Наилучшее качество теней и наиболее ресурсоемкий вариант.
2) Baked Indirect
Как бы урезанный вариант Shadowmask. Если в Shadowmask тени просчитываются «до горизонта», то здесь до определенного расстояния («menu: Edit > Settings , then select the Quality category, and navigate to the Shadows»).
3) Subtractive
Наихудший вариант, но очень легкий. Рекомендуется для слабых устройств.


Потом идет поле Lightmapping Setting с непосредственными настройками режима освещения.
Lightmapping
Какой алгоритм обработки использовать для расчета освещения. Имеет три варианта:
1) Enlighten
Этот вариант как раз может использоваться для Realtime Lighting, но также может и без Realtime Lighting.
2) Progressive CPU
Статичное освещение в чистом виде.
3) Progressive GPU (Preview)
Начнем с Enlighten. https://docs.unity3d.com/Manual/GI-Enlighten.html

Indirect Resolution
Это свойство доступно только при включенном глобальном освещении в реальном времени. Используйте это значение, чтобы указать количество текселей на единицу, которое будет использоваться для расчетов непрямого освещения. Увеличение этого значения улучшает визуальное качество непрямого света, но также увеличивает время, необходимое для выпечки световых карт. Значение по умолчанию - 2. См. Учебник Unity по разрешению в реальном времени для получения подробной информации о косвенном разрешении. https://learn.unity.com/tutorial/precom ... lumination

Lightmap Resolution
Определяет количество текселей на единицу, используемых для световых карт. Увеличение этого значения улучшает качество карты освещения, но также увеличивает время выпечки.
Довольно непонятное заявление. При значении равной 1, наши тексели равны чуть больше 1 метру. При увеличении значения, тексели как раз становятся меньше, что сразу же проявляется во времени запекания и размере файла карты освещения (в моем случае, значение 1 давала карту размером 32х32 и вес 2.7 кб, в то время как значение 100, давало одну карту размером 1024х1024 весом в 2.7мб, а значение в 200 дало уже две карты 1024х1024 и размер соответственно 5.3 мб). Т.е. справедливо полагать, что значение 1 дает 1 тексель на 1 единицу. Отсюда выходит, что чем больше текселей на единицу, тем лучше. Похоже, что Lightmap Resolution это соотношение, выраженное в числовом значении, что бы это ни значило. Получается, что Baked Global Illumination может дать более подробную карту освещения чем Realtime Lighting.
Проблема может возникнуть в определении верхней границы Lightmap Resolution. В идеале, нет смысла создавать тексель меньше, чем минимальная поверхность отражения объекта. Для простоты примера, возьмем сцену, где будут находиться три куба размером 1 метр которые находятся по одной оси в ряд на одной высоте без зазоров друг у друга. Для максимально возможного результата освещения, значения Lightmap Resolution должен быть равен 1, поскольку минимальный размер отражающей поверхности равен 1 метру. Если сделаем значение 2, то улучшения результата не будет, значит можно считать верхней планкой для Lightmap Resolution значение 1. Если какой, то из кубов поднять над другим на 0.5 метров, то минимальный размер отражающей поверхности у нас уже будет 0.5 метров. Следовательно, для максимально хорошего освещения, значение Lightmap Resolution должно будет равно 2. И так далее. Так что если вы раньше думали, что раз вы художник, то вам не нужна ни физика, ни математика, ни геометрия, вы глубоко ошибались. Увы.

Lightmap Padding
Определяет разделение (в единицах текселя) между отдельными фигурами в запеченной карте освещения.
При низких значениях, по краю объекта может появиться такая темная полоска, как будто там есть маленький заступ или кантик. Как правило проявляется на стыке двух освещенных поверхностей, на которые непосредственно падает свет, одна из которых освещена лучше. Вот на той поверхности, которая темнее, появляется темная полоска. Так вот этим параметром можно его ликвидировать.
Вообще отследить его проявление специально не каждый раз получается. Я вообще, по сути, совершенно случайно его таки увидел, когда уже собирался писать о том, что не нашел его проявления. Поэтому я тут размещу скрин, а вы кликайте на него, что бы он не отправился в архив файлообменника.https://cdn1.savepice.ru/uploads/2019/7 ... f-full.jpg

Lightmap Size
Размер (в пикселях) полной текстуры карты освещения, которая включает отдельные области для отдельных текстур объекта.
Тут можно сказать, что задается верхнее ограничения для размера текстуры карты освещения. Если вы укажите размер 1024, но его будет с избытком хватать что бы разместить в ней всю информацию, то будет создана одна карта освещения. Если же вы укажите размер в 32, то будет создано несколько карт освещения каждая из которых будет размером в 32х32 пикселя, в которых будет содержаться вся необходимая информация, которую можно было запихнуть в этот размер.
Лучше всего, если у вас все поместится в одну карту освещения. При низких значениях начинают возникать артефакты в виде нечеткого края объекта с затененной стороны, или более темной поверхности у мелких предметов, примерно так что они плохо просчитаны или не просчитаны вовсе. Собственно, если разрешение текстуры не будет позволять занести информацию о мелких предметах в карту освещения, то хоть они и будут обсчитаны, но к ним эти обсчеты применяться не будут, ибо информации об этом не сохранится или сохранится частично.
Безусловно, более высокие значения существенно влияют на время обсчета, поэтому конечно в идеальном случае необходимо подбирать оптимальное разрешение. Но если у вас время и место на диске, то тут чем больше, тем меньше ошибок.

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

Ambient Occlusion
Открывает группу настроек, которые позволяют вам контролировать относительную яркость поверхностей в окружающей окклюзии. Более высокие значения указывают на больший контраст между окклюзированными и полностью освещенными областями. Это относится только к косвенному освещению, рассчитанному системой GI. Это свойство включено по умолчанию.

Max Distance
Устанавливает значение для управления тем, как далеко система освещения отбрасывает лучи, чтобы определить, применять или нет окклюзию к объекту. Большее значение создает более длинные лучи и вносит больше теней в карту освещения, в то время как меньшее значение создает более короткие лучи, которые дают тени только тогда, когда объекты расположены очень близко друг к другу. Значение 0 приводит к бесконечно длинному лучу без максимального расстояния.

Indirect Contribution
Используйте ползунок, чтобы масштабировать яркость непрямого света (то есть окружающего света или света, отраженного от объектов) в итоговой карте освещения, от значения от 0 до 10. Значение по умолчанию равно 1. Значения меньше 1 уменьшают интенсивность, а значения больше 1 увеличивают ее.

Direct Contribution
Используйте ползунок, чтобы масштабировать яркость прямого света от 0 до 10. Значение по умолчанию равно 0. Чем выше это значение, тем больше контраст, применяемый к прямому освещению.

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

Ray Count
Определяет количество лучей, испускаемых для каждой конечной точки сбора.
На первый взгляд может показаться что Ray Count и Lightmap Resolution резонируют друг с другом перекрывая себя. Но не надо забывать, что Lightmap Resolution это обязательный параметр, а Ray Count опционный. Чем больше будет пущено лучей, тем, конечно, лучше. Так же надо учитывать, что если вы пустите овед дохрена лучей, но разрешение карты освещения не позволит их зафиксировать, то смысла от них будет не много. Да, точность вычислений будет высокой, но результат скорее всего будет посредственный.
Кроме этого, надо всегда стараться придерживаться вычислений, не дающих бесконечный остаток, как правило это четные числа. У Юнити и вовсе на этом пунктик.

Denoising
Применяет шумоподавляющий фильтр к выходу Final Gather . Довольно важная штука, если вы пускаете мало лучей. Проявляется в виде проплешины в тени, так, как будто не хватает какого-то куска тени. Скорее всего количество пущенных лучей будет достаточно, но если у вас есть множество мелких предметов, то в их локальном масштабе количества лучей может быть недостаточно, отчего могут появиться разные артефакты, что и исправит фильтр. Или, добавит новых)
Directional Mode
Вы можете настроить карту освещения для хранения информации о доминирующем входящем свете в каждой точке на поверхностях ваших игровых объектов. См. Документацию по Направленному Lightmapping для получения дополнительной информации. https://docs.unity3d.com/Manual/Lightma ... ional.html

Directional
В Направленном режиме Unity генерирует вторую карту освещения, чтобы сохранить доминирующее направление входящего света. Это позволяет диффузным картографическим материалам работать с ГИ. Направленный режим требует примерно вдвое больше места для хранения дополнительных данных карты освещения. Unity не может декодировать направленные световые карты на оборудовании SM2.0 или при использовании GLES2.0. Они откатываются к Non-directional световым картам.
Non-directional
В ненаправленном режиме Unity не генерирует вторую карту освещения для доминирующего направления входящего света, а вместо этого сохраняет всю информацию о освещении в одном месте.
Indirect Intensity
Управляет яркостью непрямого света, который Unity сохраняет в режиме реального времени и запеченных световых картах, от значения между 0 и 5. Значение выше 1 увеличивает интенсивность непрямого света, а значение меньше 1 уменьшает интенсивность непрямого света.

Albedo Boost
Контролирует количество света, которое Unity отражается между поверхностями, усиливая альбедо Материалов в Сцене, от значения между 1 и 10. При увеличении этого значения альбедо притягивается к белому для вычисления непрямого света. Значение по умолчанию равно 1, что является физически точным.

Lightmap Parameters
Unity использует набор общих параметров для отображения освещения в дополнение к свойствам окна освещения. Для этого свойства доступно несколько значений по умолчанию, но вы также можете использовать опцию Create New, чтобы создать свой собственный файл параметров карты освещения. См. Страницу параметров Lightmap для более подробной информации. https://docs.unity3d.com/Manual/class-L ... eters.html
Рассматривалось ранее.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

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

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

Обновление темы.
Обещанный билд.
Интересный момент. Я писал о том что Юнити, как и собственно любой другой движок, не учитаывает отражения света от воздуха. Из за этого, если не применять дополнительные источники света, все выглядит как в вакуме. Проблема дополнительных источников света в том, что они дают дополнительныю нагрузку на видеокарту, что конечно довольно плохо. Так вот, с Baked Global Illumination эту проблему можно решить, просто просчитав карту света с дополнительными источниками света, а затем отключить эти дополнительные источники света. Получится естественное дешовое освещение. Помните я писал о необходимости знаний физики для художников? Сам билд - https://yadi.sk/d/YNrgnO6lnYb9uQ.
sledo
Старожил
 
Сообщения: 831
Зарегистрирован: 05 янв 2014, 15:44

След.

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

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

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


cron