Limbu

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

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

Что то не получилось или пошло не так ?

Если только просвечивание у облаков рекс, то такое просвечивание от того что у их облаков слабый уровень альфа-канала. Уровень альфа-канала закладывается как в текстурах облаков, так и в их моделях, поэтому редактирование текстур не всегда может исправить ситуацию. Я не знаю, сильно ли отличаются текстуры того рекса что используете Вы от тех(очевидно более ранних версий) что видел раньше я. Мне тогда показалось что уровень альфы в текстурах занижен незначительно, и такого значительного просвечивания как описываете Вы я тогда не заметил, но во первых я тогда испытывал их в своем облачном твике который не использует никаких цветовых данных из моделей, так что в Вашем случае значительный вклад в просвечивание может давать как раз альфа из моделей. Прежде чем отказываться от облаков рекс, могу предложить попробовать испытать последнее средство - простейший твик усиливающий альфа-канал в пиксельном шейдере. Всего можно попробовать два варианта и это займет не долго. Для этого нужно открыть текстовым редактором файл Cloud.fx, и отыскать в конце строчку 635 : float4 cColor = In.diffuse * txBindless(cloudMaterial.uBaseTextureID).Sample(samWrap, In.uv); // ( эта строка перед строкой // Apply IR if active ) и вставить после неё такой вариант твика : cColor.a = pow((cColor.a), 0.7 ) ; Коэффициент выделенный жирным возможно следует уточнить - увеличить или уменьшить. Значения рекомендую от 0.5 до 1.0 . значение 1 - это дефолт, при котором значение альфы в формуле не изменяется. Однако сильно уменьшать коэффициент так же не рекомендую, так как это может сделать облака пластилиновыми на вид и возможно с артефактами. Поэтому нужно искать оптимум. Однако может получится что альфа облаков занижена на столько, что что данная формула не поможет, так как она всего лишь производит гамма-коррекцию, оставляя общий уровень альфы неизменным. Уровень альфы тогда можно поднять простым умножением её на коэффициент больше единицы, но тогда нужно проследить чтобы уровень альфы не вышел за пределы [ 0, 1], так как тогда на облаках могут появится артефакты. Тогда можно применить следующую формулу : cColor.a = pow(saturate( 1.1 *cColor.a), 0.7 ) ; Здесь коэффициент выделенный красным и является тем коэффициентом который увеличит общий уровень альфы, а функция saturate ограничит её значения в пределах [ 0, 1]. Но и тут нужно быть осторожным, и подбирать умножающий коэффициент понемногу умеренно и оптимально, так как в случае ограничения альфа-канала сверху вид облаков тоже будет портится. Попробуйте прямо в работающем симе, в меню девелопера, - шейдер по команде перезагружается очень быстро.

PS. Имел в виду, что после окончания настроек, после разкомментирования моего фрагмента твиков нужно оставить этот файл в симе. Это чтоб не запутались.

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

В файле General.fx, из упомянутого набора со строки 271 есть такое текстовое меню : // Настройка освещения кокпита const float SetLigCsun = 3.4 ; // Освещенные участки солнечного освещения const float SetLigCmoon = 1.0 ; // Освещенные участки лунного освещения const float SetShaCsun = 1.2 ; // Теневые участки солнечного освещения const float SetShaCmoon = 1 ; // Теневые участки лунного освещения // Настройка освещения крафта const float SetLigKsun = 1 ; // Освещенные участки солнечного освещения const float SetLigKmoon = 1 ; // Освещенные участки лунного освещения const float SetShaKsun = 1 ; // Теневые участки солнечного освещения const float SetShaKmoon = 1 ; // Теневые участки лунного освещения Изменяете нужные значения согласно комментариям, Вам необходимо уменьшать значения, приближая их к дефолтным. Значение для дефолтных шейдеров везде равно 1. Значения могут быть положительными больше или меньше 1 ( до 0 ). Вам нужно уменьшать указанные выше значения. Открываете файл General.fx в папке ShadersHLSL симулятора нормальным текстовым редактором, изменяете нужные значения и сохраняете файл General.fx. Затем следует сделать перекомпиляцию кеша шейдеров. Я рекомендую делать это сначала без предварительной очистки кеша шейдеров в работающем симе по команде с клавиатуры, назначив на перезагрузку шейдеров любую клавишу. Так как при таком способе в данном случае будет перекомпилироватся один General.fx, то время перезагрузки шейдеров значительно сократится. Изменяете значения в General.fx, сохраняете результат, даете команду на перезагрузку - смотрите результат в работающем симе, и так повторяете пока не достигнете нужного результата. На всякий случай замечу, что описанный способ перезагрузки в работающем симе без предварительной очистки кеша шейдеров годится не для всякого редактирования, и не для любых исходных файлов шейдеров. Редактирование например FuncLibrary.fxh требует в любом случае предварительной очистки кеша шейдеров. Так же не забываем, что в качестве разделителя целой и дробной части десятичных дробей можно использовать только точку.(!) Тем не менее мои твики обычно вызывают довольно длительную перезагрузку шейдеров, поэтому для ещё большей быстроты, в случае General.fx рекомендую на период настройки закомментировать фрагмент моих твиков. Вот в этом архиве, в файле General.fx из упомянутого набора это уже сделано : General.fx.test.rar Рекомендую заменить на период настройки файл General.fx в папке ShadersHLSL симулятора этим тестовым General.fx, сделать начальную предварительную полную очистку кеша шейдеров, а затем произвести настройки без предварительной очистки кеша как описано выше. После окончания настроек следует разкомментировать мой фрагмент твиков, для этого следует удалить символы начала комментариев /* в строке 1244 , и конца комментариев */ в строке 1692 файла General.fx, и сохранить General.fx. И только потом , напоследок, рекомендую сделать последнюю полную очистку кеша шейдеров, и перезагрузить их. (Это можно сделать в работающем симе).

Новости разработки. Работа в четвертом Препаре на не определенный срок практически закончена . "Нежная атмосфера" на данный момент успешно переехала в Препар 5.3 и дорабатывается. На данном этапе проводится большая работа по оптимизации и настройке твиков. Некоторые результаты доработки твика перистой облачности на скринах ниже. Сначала некоторые избранные лучшие скрины. При настройке использовалось текстурное небо с текстурами собственной разработки : Текстуры правда нуждаются в дальнейшей доработке. А на следующих скринах показан вид перистой облачности с большой высоты, выше над уровнем облачности: Цвет облачности естественно зависит от высоты Солнца над горизонтом, и если обратить внимание то почти совпадает с цветом Солнца. Правда сделать красноватый цвет Солнца у горизонта практически не удалось, но если это не брать во внимание и представить что цвет Солнца при приближении к горизонту приобретает постепенно красноватый цвет, то можно увидеть что цвет облачности почти совпадает с цветом Солнца. Ну это понятно и естественно то, ведь окрашенный солнечный свет и является источником освещения и придания цвета, но есть одна загвоздка. Красноватый цвет Солнца достигается только у самого горизонта, однако на разных высотах нахождение солнечного диска у края горизонта соответствует различным моментам времени, и чем выше тем такой момент наступает позже. А в твике функции управления цветом облачности в упрощенном варианте привязаны к высоте Солнца над нормалью в нормализованной системе координат. Сделать привязку нормали к видимому горизонту не составляет особых трудностей, и это сделано уже давно, но только для наблюдателя. Используемая для этого величина смещения нормали к истинному горизонту как раз и зависит от высоты расположения наблюдателя. Для реалистичного расчета динамики изменения цвета облачности, величина смещения нормали должна соответственно сдвигать все графики управляющих функций в зависимости от высоты, но проблема в том что слои облачности могут располагаться на разных высотах, и для разных высот расположения требуются различная величина смещения. А шейдер то всего один ! И этот шейдер обрабатывает все слои облачности совершенно одинаково ! То есть настроишь величину смещения для облаков расположенных например на высоте 7 км, - на этой высоте освещение облачности с такими настройками будет вполне реалистично, а для другого слоя расположенного на высоте например 15 км динамика изменения цвета с такими настройками будет уже неправильной. Для создания реалистичной динамики для разных слоев облачности в шейдерах требуются идентификаторы слоев облачности и соответствующие им параметры - порядковый номер слоя, высота расположения и др, а шейдер может быть тот же самый. LM ничего бы не стоило передать данные параметры из приложения в шейдерный буфер. АУ, LM - НУЖНО БОЛЬШЕ ДАННЫХ В ШЕЙДЕРНЫЙ БУФЕР ! А пока можно придумать только компромиссные настройки, например настроить смещение для высоты 10 км. При этом в диапазоне от 7 до 13км освещение облачности будет более соответствовать реалу, но при выходе из данного диапазона уже не реалистично, и чем дальше от опорной высоты 10 км в любую сторону - тем более не реалистично. Ещё немного скринов на которых показан вид облаков при изменении высоты наблюдателя:

Я написал выше что мод в DeferredComposite.fx не может влиять на смещение градиента, а уж тем более мой твик если Вы его имели в виду. Следовало бы уточнить о чем идет речь. Спорить о вкусах и научных теориях у меня нет желания. За эмайзинги вообще промолчу, не ради них я на форуме. Моё дело маленькое - поступил запрос на проблему - я предложил решение. Твик не удался или не понравился - дело хозяйское. За сим предлагаю закончить дискуссию.

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

Ещё раз повторяю - синие оттенки вполне подходят для ясного неба. Даже с физической точки зрения Вы забываете что снег - это отражающий материал, и он отражает цвет неба. Если Вы этого не понимаете, или Вам такое сочетание не нравится - это дело вкуса и спорить тут не о чём. Настраивайте твик себе по вкусу или сделайте собственный. А вот тут я вообще ничего не понял о чем речь. Где я упоминал об "угле света теней" и их влиянии ?

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

Вы внимательно перечитали мои посты ?

Да , я это умею, и за кашу прошу прощения. Файлики кидать в папку ShadersHLSL, и соглашаться на замену. Предварительно сделайте бекап дефолтной папки ShadersHLSL.

Ошибочка вышла, прошу прощения. Полностью исключены крафт и кокпит, а деревья и здания автогена имелось в виду от повторной обработки, но вот только не 100% надежно. Деревья так вообще и не планировалось исключать из обработки, хотя это возможно. Вообще то у меня было мало времени и возможностей что бы проверить все объекты и какие из них могут перекрывать друг друга в шейдерах Terrain.fx и PBRBase.fx. Нумерация кодов объектов в препаре известная мне начинается от 0 и до 28. Из этих 29 объектов мне известно о назначении только о 15-ти. А сколько всего реально в препаре используется кодов объектов доподлинно мне не известно.