Limbu

Проверьте используемый suneffect.cfg. Установите корректный suneffect.cfg для используемой версии Н.А. Конечно. Как интегрировать Н.А. в пресет подробно описано в теме и ридми. Главное нужно обращать внимание на не совместимые твики и отключать(удалять) их. Но не любой пресет будет удачно сочетаться с Н.А.

Если разобрались с кодировкой цвета в файле то вопрос можно считать на половину решенный. Конечно если целью изменения есть 1-2 десятка самых ярких звезд, то можно это все проделать в ручную. А как на счет сотни и более ? Если хотите сместить спектр большего количества звезд, то рекомендую табличный фрагмент скопировать и поместить в эксель, разложив данные по столбцам. Далее Вам придется составить формулу для коррекции кода цвета, размножить её по дополнительным столбцам/столбцу, и заменить столбец с цветом результирующим столбцом. Затем, (удалив все лишнее) экспортировать эксель в текстовый csv, а из него уже копировать полученный табличный фрагмент в star.dat. То же собирался когда то проделать такую штуку в АЫЧе, а затем в препаре, но меня в первую очередь интересовал не цвет звезд а их блеск. Но в препаре это можно сделать все в шейдерах, не прибегая к табличной рутине. К стати в твике для звезд препара я по началу тоже хотел сместить спектр звезд в сторону синего(никто этого не заметил), однако слишком заметный поголовный голубой оттенок смотрится не естественно, но я хотел это сделать с целью что бы звезды не выделялись на фоне высотного атмосферного градиента белыми дырами. По идее звезды с голубым оттенком должны были не так резко контрастировать с голубым атмосферным градиентом, но на практике такая мера оказалась очень мало эффективной, но не большое смещение в сторону синего я всё же оставил. Что касается редактирования блеска звёзд, то тут у меня есть другая цель. Дело в том что на существующем в препаре звездном небе многие созвездия не узнаваемы, что не позволяет соответственно уверенно ориентироваться ночью. А обстоит дело так по тому, что при разработке алгоритма трансляции и таблицы star.dat не было учтено то как соотносится справочные данные блеска звезд, с тем как воспринимается они с монитора. Вообщем не удачный алгоритм трансляции "табличный блеск" >> " количество+яркость пикселей" . Вот с этим нужно что то делать. Тоже самое рассказывал мне мой внучатый племянник любуясь ночным небом когда гостил у меня летом. У нас же звездное небо то же не очень тёмное но гораздо лучше. Я к стати астрономию и все созвездия (кроме южных) знаю на зубок как свои пять пальцев, и за пару секунд смогу сориентироваться на незнакомой местности в любое время года и любой час ночи. В препаре же я не могу узнать почти ни одного созвездия.(причину объяснил выше).

Для коррекции освещения крафта откройте файл General.fx . Отыщите в начале файла основной фрагмент кода твика, который начинается со строки 268. Ниже под спойлером, жирным шрифтом выделены интересующие строки: На против этих строк, и над этими строками и под ними я добавил комментарии после "//" . Так же я добавил строку с переменными для тестовых настроек, она выделена жирным курсивом. Этой строки и комментариев нет в оригинальном коде твика, так что не путайтесь. Можете эту строку или весь фрагмент вставить в свой General.fx на замену такого же фрагмента(!) Строку с переменными для тестовых настроек я вставил на случай если захотите использовать методику описанную на 2-ой странице этой темы. Коэффициенты выделенные соответствующими цветами соответствуют цветам комментариев расположенным над интересующими коэффициентами. Крутите выделенные цветами коэффициенты в соответствии с комментариями. Под спойлером все коэффициенты равны единице, это дефолтное значение по умолчанию, в вашем фрагменте могут быть другие начальные значения, имейте это в виду в случае копирования всего фрагмента . Для регулирования насыщенности отыщите следующий фрагмент в конце этого же файла, обычно этот фрагмент расположен после кода НА: Выделенные цветом коэффициенты отвечают за насыщенность согласно комментариям. Для коррекции освещения террайна откройте файл GPUTerrain.fx . Отыщите где то в конце файла основной фрагмент кода твика, который должен начинается со строки 1304. Ниже под спойлером, жирным шрифтом выделены интересующие строки: Тут примерно все аналогично. Между дефолтным комментарием и основным фрагментом, а так же под, я вставил аналогичные строки с комментариями объясняющими назначение нужных коэффициентов. Если захотите и здесь воспользоваться переменными для тестовых настроек, то не забудьте вставить над комментариями в этом фрагменте строку с тестовыми переменными, иначе получите краш шейдеров при перекомпиляции.

Рекомендованные настройки - не догма, они примерные и зависят от используемого оборудования и вкусов. Я к стати например не люблю вообще каких либо пересветов. Каждый пользователь должен индивидуально подстраивать под себя сим согласно своему оборудованию и вкусам. Что касается ваших настроек, то в первую очередь у вас слишком накручен блум. Прежде всего уменьшите блум до значения 0.1-0.15 , или даже вообще до нуля. Если этого будет не достаточно, то можно ещё немного пожертвовать яркостью - уменьшите яркость до 1.0 -1.2 . Так же насыщенность можно уменьшить до 1, будет вполне достаточно и нормально. Если этих мер будет все равно не достаточно, или же в результате другие детали сцены будут выглядеть тускло то придется с помощью ПТА добиваться каких то компромиссных настроек с помощью других твиков. Чрезмерные пересветы на фоне с другими деталями сцены с нормальной яркостью могут быть особенностями конкретных портов, в этом случае то же рекомендуются компромиссные настройки.

На сколько я помню, проблемы с некоторыми портами есть только в сторону увеличения яркости и обработки насыщенности. С потемнением земли при подъеме на высоту проблем нет, Вы ведь сами когда то упоминали об этом. Так что пока можно ограничится обработкой только освещенности. Если необходима обработка насыщенности, то есть пара идей которые надо разрабатывать, но когда я до этого доберусь неизвестно. К стати есть предположение почему некоторые порты выпадали из твиков обработки насыщенности и не выпадали при этом при обработки освещенности. Дело в том что стандартная обработка насыщенности предполагает обработку cColor.rgb на определенном этапе конвейера в котором отсутствует rgb определенных деталей некоторых портов, в то время как твик обработки освещенности осуществляет воздействие(локальная коррекция) на источник освещения - Солнце и Луну.

Если Вас интересует твик Gradual flare up Stars, то он опубликован в составе архива версий V2.2 . В последнюю публикацию V2.3 я этот твик положить вроде как забыл, так как внимание было сосредоточено на обновлении предыдущей версии. Кроме того этот достаточно популярный твик неоднократно публиковался в теме "Делаем красиво V4" , держите: Stars.fx

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

Так как WinterGntlAtmV2.30.21BRIGHT - это версия без "Золотистого солнца" то Геннадий положил в комплект suneffect.cfg где применено Солнце Киви и ссылки на дефолтные текстуры лунного гало. В общем моя догадка полностью подтвердилась. Ещё один гарантированный вариант - удалить названия файлов, пример: [MoonCorona.1] // waxing crescent Texture=" " Intensity="0.3" На всякий случай напомню, что разработанные мною текстуры Луны предназначались в первую очередь для использования под управлением лунного твика, доделать который у меня уже давно никак не доходят руки. Если они нравятся, и не замечено никаких недоработок, то конечно можете дальше пользоваться, или применить любые другие.

У многих производителей бывают нормальные и отбракованные партии. Это как лотерея. У меня например уже 5 лет трудится планка памяти Wilk Elektronik GR1600D364L11S/4G (1333Мгц) в паре с другой планкой Team Group Team-Elite-1600. Причем работает на XMP на 1600 Мгц. (Extreme Memory Profile v1.1 имя профиля Enthusiast (Certified) ). Режим работы контроллера -двухканальный. Проблем никогда не замечалось.

В общем, коллега Predatorus выше объяснил всё правильно. Единственное что смущает так это то, что в изображении лунного гало на вашем скрине заметны угловатые формы и имеет заметный оттенок, что напоминает дефолт. Мои же текстуры имеют нейтральный оттенок и не имеют такой чрезмерной угловатости. Это даже заметно на скринах коллеги выше. Но если что или в любом случае, в секциях suneffect.cfg обведенным красным на скрине выше уменьшите параметр Intensity в каждой фазе, или вообще сделайте его нулевым: Intensity = "0" , и проблема будет решена. Это будет проще всего. ЗЫ. ещё раз посмотрел на скрины, так похоже на то, что Вы применили Луну из моего комплекта с размером для Солнца SetSu = 2 со своим suneffect.cfg в котором прописаны дефолтные текстуры лунного гало. Заметна не соразмерность гало к размерам Луны. Если я прав, и если в таком случае желаете увидеть как выглядят текстуры из из моего комплекта предназначенных для Луны то же из моего комплекта, то необходимо секции moonglow обведенные красным скопировать из моего suneffect.cfg и вставить в используемый Вами suneffect.cfg. Так же можно поиграться с параметром Size подгоняя желаемый размер лунного гало к размеру Луны. В таком случае можно даже применять оригинальные текстуры с первоначально заданным размером.

Ну что же, время покажет. Я его и не бросаю пока. Успехи и вдохновение вещи периодические и иногда проходящие. А вот времени лишнего взять неоткуда. Спасибо за пожелания!

Что смешного то? При чем здесь дальтоники, спортивный интерес и реал? Кому здесь был обещан реал? Намешали всё в кучу. Не умеете изъяснятся яснее?

А куда девались скрины? (404 Not Found). Но я конечно успел кое как разглядеть 4 часа назад в телефоне пока был на работе. Это то что я и имел в виду. Более правильный без баговый и корректный способ регулировки, позволяющий так же отрегулировать и необходимую контрастность. Аналогичные условия содержащие defined(PS_NEEDS_TANSPACE) и (cb_mObjectType != 19) (19 -общий код объекта крафт) располагаются в начале файла General.fx. А фрагмент приведенный мною вчера предназначен для регулировок насыщенности. Но и общую яркость текстур крафта упомянутым накануне способом тоже можно изменять, но не намного, и если контрастность находится в устраиваемых пределах. Я такой способ применял для высотной коррекции при разработке альтернативного "Turn off HDR luminance adaptation effect" когда работал с сетом Фрост. Так что Вы на правильном пути.

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

"Нежная атмосфера" делалась с учетом особенностей человеческого зрения. В остальном я полагался на свою наблюдательность и память, так как не имею ни профессиональной фотоаппаратуры позволявшей в любой момент иметь под рукой необходимые образцы-снимки, ни высококачественного монитора позволяющего идеально без искажений воспроизводить правильные градиенты. Поэтому мне приходилось не просто при разработке, и было затрачено много лишнего времени... Что касается градиентов неба как таковых, то в природе тоже есть некоторое разнообразие, но на моё имхо не такое широкое как предлагает тот же рекс и уж тем более дефолт. Но тут нужно понимать особенность конкретных сетов и их целевой уклон. Одни сеты ориентированы на реалистичность, другие на художественность. Многим однообразие со временем начинает надоедать, и по этому в симе был придуман 10-дневный суточный цикл с разнообразными градиентами. Так что если сет с художественным уклоном и ориентирован на то что бы подчеркнуть какие либо детали сцены и неба, то это тоже не плохо. Но делать это нужно не как попало, а искусно и в гармонии с реальным миром. Не простая задача для художника. У Геннадия например это получается лучше чем у рексов, а дефолтные текстуры так вообще не в пример. Что касается НА, то первоначально она была ориентирована на реалистичность, но затем я попытался придать ей чуток и художественного уклона, стараясь балансировать на золотой середине между двумя аспектами. Поэтому я продолжаю работу и конкретно над НА далее, с целью несколько разнообразить её градиент.