Jump to content

Limbu

Developers
  • Content Count

    382
  • Joined

  • Days Won

    4

Limbu last won the day on May 11

Limbu had the most liked content!

Community Reputation

471 Отличная

About Limbu

  • Rank
    Продвинутый

Дополнительная информация

  • Место в рейтинге
    6806
  • Конфигурация компьютера
    Intel Core i5-4670;Asus H81M-K;RAM Team Group Team-Elite-1600 CL11 4096mb;PNY GeForce GTX 1050 Ti 4GB XLR8 OC GAMING;WDC WD10EZEX SCSI Disk Device(1000gb,7200rpm,sata3);Kingston SV300S3 SCSI Disk Device(60gb):OS Windows 7 sp1 x64

Profile Information

  • Gender
    Male
  • Location
    Ukraine

Recent Profile Visitors

976 profile views
  1. Продолжение: Для сравнения хочу показать фото из реала сделанные скромным бюджетным смартфоном, фото конечно не профессионального качества, но тем не менее способны передать всю идею съемки: Вот так вот хотелось скрасить однообразие облаков в препаре. В реале конечно всё освещение намного сложнее и разнообразнее, как уже упоминалось выше, при сложной многослойной облачности игра теней и света намного сложнее, и эта сложность и разнообразие обусловлена главным образом тем, что облака могут затенять друг друга (в разной степени к тому же), отбрасывая друг на друга тени. Но это в шейдерах препара уже никак не реализовать без переписывания движка сима. Единственное что можно ещё сделать - это реализовать вид облаков при котором более плотные части выглядят притемненными а края светящимися, причем можно сделать так, чтобы такой вид был на директионале Солнца, а на остальной части небосвода они отображались бы обычным образом, с плавным переходом. Но при большом количестве слоев все это будет уже не правдоподобно и не реалистично, если бы в шейдеры через буфер передавался ряд кое каких переменных данных(количество слоев, порядковый номер слоя, плотность и т.д.) то ещё можно было бы что то упрощенно сымитировать, а так ничего здесь больше не попишешь.
  2. Перистая облачность препара, в отличие от остальной, пожалуй является самой реалистичной и красивой облачностью этого сима. Не смотря на всё же имеющихся ряд незначительных недостатков эту облачность можно сделать и настроить почти что до уровня mfs 2020. Поэтому в первую очередь я взялся за эксперименты именно с перистой облачностью. На этот раз в качестве тестируемых образцов я взял перистые облака от REX SSF3D. А что же не так с цветом и освещением перистых облаков в препаре? Давайте возьмем сначала день, поставим пару слоев перистой облачности средней интенсивности ближе к оверкасту, и осмотрим облачность по различным направлениям азимута. Куда ни глянь - цвет и яркость облаков по азимуту везде одинакова, и только при приближении к горизонту их обычно притеняет дымка. Если полностью отключить дымку (в файле General.fx ), то цвет облаков так же не будет зависеть и в зависимости от удаления от линии горизонта. Но в реале вовсе не так! Яркость облаков в реале зависит от углового удаления от главного источника освещения - Солнца. Чем ближе к Солнцу тем облака ярче, правда заметное изменение яркости есть в относительно узком секторе директионала Солнца. На директионале Солнца они буквально "светятся" на относительно тёмном фоне неба. Правда когда перистые облака плотнее и утолщаются, переходя в перисто-слоистые, или при сложной многослойной облачной обстановке, то светятся только края облаков а центральные зоны кажутся притемненными, но к этому мы ещё вернемся, а сейчас просто частный случай. Такой вид обусловлен законом рассеяния частиц света в аэрозольных и газовых средах, но давайте сейчас не будем углубятся в теоретические основы этих физических законов. Что касается дымки, то в реале дымка не притемняет облака а поглощает, маскирует их. При приближении взгляда к горизонту, перистые облака тонут в дымке и поглощаются ею. Ну а как происходит на закате и после? В симе в дефолте при приближении солнца к горизонту, на закате и после, цвет облаков определяется соответствующими пикселями в текстурах, и так же одинаков по всем направлениях азимута. Но в реале то вовсе не так! При приближении Солнца к горизонту, цвет облаков на директионале Солнца обычно яркий желто-белый, в то время как над головой уже желто - кремовый оттенок, а на противоположном Солнцу азимуте угадываются оранжевые оттенки. На закате над головой уже больше желто-оранжевый оттенок, а на противоположном азимуте они уже краснеют немного, и их освещение теряется по мере приближения к горизонту. После заката, по мере опускания Солнца под горизонт освещение теряют облака находящиеся ближе к наблюдателю, пока не перестанут светится и облака над головой, и так далее по направлению к Солнцу. При этом цвет облаков меняется постепенно в порядке от желто-кремового к оранжевому и в заключение к красноватому оттенку. Полагаю каждому приходилось наблюдать картину: Солнце некоторое время назад уже зашло за горизонт, на большей части неба облака уже в тени, в тусклом общем освещении, но низко над горизонтом, над тем местом куда погрузилось Солнце ещё видны светящиеся оранжевым цветом облака... Такие свето - цветовые метаморфозы обусловлены постепенным перемещением вслед уходящему Солнцу гигантского градиента ориентированного перпендикулярно направлению на Солнце(параллельно терминатору), и который накладывается на облачность в зоне градиента раскинувшись на десятки и сотни километров. Нечто подобное неплохо было бы сделать и в препаре, добавив ему хоть немного реалистичности. Ниже на скринах хочу представить некоторые результаты работы над соответствующим твиком:
  3. Если вы имеете в виду крайнюю версию для четвертого препара, то для того что бы она смогла запустится на пятерке в ней нужно отредактировать одну строку на которую ругается компилятор пятерки. Однако в пятом прапаре НА для V4.5 выглядит совсем иначе. Я сейчас уже не помню подробностей, но я тогда забраковал вид НА в пятерке. Основная причина такой разности заключается в том, что в пятом препаре совсем другие параметры обработки HDR, а так же могут быть и другие факторы. Поэтому я ещё весной начал разрабатывать версию для пятого препара, которая сейчас почти готова... Но! Я решил что этого мало, и уже давно я хотел взяться за правку облаков которые особенно в сумерках не смотрятся с НА и портят всю картину. Проблема заключается в том, что управление цветом и яркостью облаков по мере течения суток осуществляется из движка сима, динамика процесса и его длительность зависит не только от цвета соответствующих пикселей в текстурах неба, но и от закона прописанного в самом движке сима. Я убедился в этом когда попытался стабилизировать цвет и яркость облаков на протяжении суток скопировав одинаковые пиксели во все текстуры, однако яркость облаков падала в сумерках как ни в чем не бывало, по тому самому закону что и яркость неба, в точности синхронно. А длительность сумерек в препаре как известно резко обрезана. А в НА заложены свои (реалистичные) законы сумерек и падения яркости неба, поэтому в сумерках облака препара выглядят совсем черными провалами как темные туманности на ещё достаточно светом фоне НА. Что бы решить эту проблему мне пришлось исследовать закон изменения яркости, и на основании полученных табличных данных построить корректор яркости нивелирующий воздействие из движка сима. Эта задача для первого раза была решена в какой то мере упрощенно, компромиссно, но не лучшим образом. Конечно если бы у меня был исходник препара, я бы смог этот закон подсмотреть там, и всё было бы намного проще( ещё проще было бы отключить этот закон в самом движке сима). Я планировал выложить версию НА ещё в июле, но не тут то было, так как чуть раньше я открыл ещё метод управления яркостью облаков в зависимости от углового удаления от горизонта и по азимуту, и мне не терпелось попробовать применить этот метод на облаках, но в результате я не уложился в планируемые сроки разработки, которая в конце июля почти полностью приостановилась в связи с критической нехваткой свободного времени. В добавок, всё выше сказанное к сожалению относится только к перистой облачности имеющей свой отдельный упрощённый рендеринг. Что касается остальной облачности, то там всё отдельно и по другому, и в отдельном шейдере который ещё предстоит доработать. Что дает управление яркостью и цветом облаков по высоте и по азимуту, и каких вообще удалось достичь результатов я постараюсь выложить в следующем посте ниже как будет свободное время.
  4. Буквально на днях только обновился до первого хотфикса, а тут на тебе. Я было подумал что исправили некоторые графические косяки, коих хватает, особенно в верхней половине симулятора, которой они практически никогда не уделяют должного внимания. Но вот смотрю что то не очень стараются, и других багов и без того хватает. И одну графическую бяку я выловил на днях, когда занимался настройкой освещения облаков в рамках предстоящего выхода Н.А. для пятого препара. Суть косяка заключается в том, что при взгляде снизу вверх на небо и облака, слой перистых облаков который располагается выше над кучевыми отображается на преднем плане, что неправильно и неестественно. Никому ещё не приходилось наблюдать ? Когда все облака почти одного цвета это мало заметно, но если например перистые облака окрасить в другой цвет, например в оранжевый то это очень бросается в глаза: Такая бяка отображается при определенном диапазоне дистанций, если перистую облачность переместить в стратосферу, то правильный порядок наложения слоев восстанавливается, соответственно на дальней дистанции ближе к горизонту облака то же рисуются правильно. Примечательно то, что в четвертом препаре я такого никогда не наблюдал. Могу предположить только что что то сломали в движке сима когда вероятно запихивали туда трускай, ведь в остальном в V5 ничего практически не изменили в верхней половине симулятора. В шейдерах то же ничего революционного, хотя изменений конечно достаточно по сравнению четвертым, но я сомневаюсь что причина может быть в шейдерах, ведь порядок рендеринга и наложения слоёв по идее должен быть заложен в движке сима. Так что скорее всего я с этим косяком ничего поделать не смогу, если только LM не исправили это в новом хотфиксе. Сегодня нашел и перевел в "Исправления и улучшения клиента" два кое каких пункта - фикса: Improved transparent object sorting with Enhanced Atmospherics. Fixed issues with additive effects sorting incorrectly with clouds. перевод: Улучшена сортировка прозрачных объектов с помощью Enhanced Atmospherics. Исправлены проблемы с неправильной сортировкой аддитивных эффектов с облаками. Хотелось бы знать точно что этим имелось ввиду. Могут ли эти два перечисленных фикса иметь отношение к исправлению обнаруженному мною косяку? Может быть кто нибудь из пользователей это проверить и сообщить в тему ? Если в хотфиксе нет никаких графических улучшений, особенно в верхней половине симулятора , то пожалуй для меня нет никакой необходимости спешить обновляться ко второму хотфиксу, разве что шейдеры проверить которые навряд ли претерпели кардинальные изменения.
  5. Никому не мешали, если только какие либо "важные клиенты" не заказали (непонятно зачем), а так это такая отсебятина предназначенная для того что бы новый продукт обязательно отличался от предыдущего, кроме того интерфейс править легче всего, чем разбираться в сложных математических алгоритмах и багах. Это точно так же как "улучшают" с каждым выходом браузеры, периодически меняя их интерфейсы.
  6. Странное какое то влияние 3D Autogen Vegetation. Интересно, этот косяк так же перекочевал в V5 ? Никогда не обращал внимание, так как меня эта фича мало интересовала, и я её не включаю. Надо будет когда нибудь изучить этот косяк.
  7. Твики какие нибудь используете? Вообще то все рекомендуют деревья ORBX как самое оптимальное решение.
  8. На моих скринах выше какое то текстурное небо, сейчас я занимаюсь разработкой не текстурного а процедурного неба. В новой версии Н.А. для препара V5 которую я планирую выложить в ближайшее время как раз реализован некоторый избыток зеленого цвета: Чуть позже постараюсь выложить аналогичную версию и для V4.5 : Но солнце в обеих версиях не будет достигать насыщенного красноватого оттенка, пока моделируется "умеренно чистая" атмосфера .
  9. В реале цвет солнца на закате зависит от состояния атмосферы - насыщения различными аэрозолями, которые действуют на солнечные лучи как цветовой светофильтр, а красноватый цвет образуется прежде всего за счет относительно крупных и непрозрачных частиц пыли которые вносят наибольший вклад в поглощение в синем и зеленом участке солнечного спектра. Крупные аэрозоли, поскольку они тяжелее то концентрируются к поверхности планеты, и потому цвет солнца на закате приобретает яркий красновато-оранжевый оттенок. И такое состояние атмосферы довольно не редкое, особенно над сушей. Но и над морем могут образовываться аэрозоли состоящие из мелких водяных капель - тот же туман и облака могут вносить существенный вклад в покраснение нашего дневного светила. Ещё в прошлом году, когда я ещё начинал работу над Н.А., я параллельно работал над одной моделью солнца в котором цвет менялся по мере приближения к горизонту. К этому солнцу мне удалось подобрать какие то почти идеально подходящие текстуры. Но когда была создана Н.А. , то это солнце не очень подошло её фону, поэтому эта модель претерпела множество изменений... В этой модели цвет солнечного диска меняется по мере приближения к горизонту от ослепительно-белого цвета, к ослепительно-желтому, и далее к желто-оранжевому, и на самом горизонте к насыщенному красно-оранжевому цвету. Эта модель у меня где то сохранена в архивах, но кроме того я сделал серию последовательных скринов, на основе которых хотел сделать качественную gif-анимацию, но размер gif-ки не позволял выложить его на этот ресурс. Тем не менее папку со скринами я далеко не закидывал, так как всё равно собирался когда нибудь сделать и выложить gif-ку, так как этот вариант и скрины я считаю почти что шедевральными, и сама модель заслуживает возрождения, возродить которую я надеюсь ближайшей осенью. В самой Н.А. имеется собственное солнце которое тоже меняет цвет по мере приближения к горизонту, однако достичь такого же ярко -насыщенного красного оттенка затруднительно из-за ярких градиентов Н.А. Более подробно о проблемах цветосинтеза можно почитать в моей теме на 1-ой странице: https://www.avsim.su/forum/topic/189159-нежная-атмосфера/#comments
  10. Мне кажется что коллега имел в виду тут нечто другое. В случае если Active Sky использует для отрисовки облака REX Sky Force 3D, то их вершины и верхний край располагается выше и соответственно ближе к эшелону полета, потому и нет ощущения высоты полета. Сами по себе модели облаков REX Sky Force 3D пышные, но довольно крупные и высокие по сравнению с дефолтными и формируют довольно толстую облачность. К примеру: дефолтные облака на Few1/8 довольно мелкие, и на Few1/8-2/8 смотрятся довольно приплюснутыми, но и в остальных моделях(Scattered, Broken...) верхушки пониже смотрятся. Так же, к примеру в самом REX Sky Force 3D на вкладке настроек 3д моделей есть внизу опция переключения между двумя вариантами грозовой кучевки : Но по факту даже во втором варианте вершины этих облаков смотрятся все равно немного выше заявленных в опциях. Такие высокие верхушки облаков (свыше 15000 м) характерны(и то изредка) разве что для тропиков и экватора, но никак не для средних и высоких широт. Попробуйте полетать для сравнения с дефолтными облаками.
  11. Если я правильно понял, то вопрос касается как моего эксклюзивного файла, так и стандартного кода твиков. В стандартном коде твиков за зависимость эффекта релея от высоты ("Depends on altitude" ) отвечает выражение * saturate(1.0f - cb_Altitude/15000) . Это выражение линейно уменьшает эффект до высоты 15000 м , но не смотря на линейность, за счет того что оно является сомножителем в нелинейной функции, довольно резко на вид тушит эффект при непосредственном приближении к порогу 15000 метров. Поэтому в своей редакции я удалил это выражение. В моей редакции за высотную коррекцию отвечает другое выражение (static float RlFACorr = 1-( 1-exp( -pow(abs( 0.5 *Altit1), 5 )) )*(1-saturate(exp(-0.2*Altit1))) ;) , которое плавно корректирует эффект в большем диапазоне высот, но не уменьшает его до нуля. Эту коррекцию я настроил на свой вкус, считая что в реале эффект релея не может уменьшатся с подъемом на высоту, а уж тем более резко пропадать. Это пропадание противоречит любым законам природы. И формула рассчитывающая уровень эффекта на основании дистанции до пикселя вполне соответствует этим законам, но не совсем точно, поэтому во всех вариантах и применяется высотный корректор. Так же я предупреждал на счет настроек по умолчанию в своем файле, что особо тщательно я настройку произвести не успел, и все настройки по умолчанию ориентировочные и соответствуют моим вкусам и оборудованию, поэтому рекомендовал их до настроить, но можно конечно же попрбовать и скопировать настройки из какого нибудь ini-файла. Разница на приведенных вами скринах едва заметна на глаз. Если допустить что на верхнем скрине вы использовали мой эксклюзивный файл в который перенесли настройки из какого то сета то тут могут играть роль несколько факторов. Во первых высотная коррекция на уменьшение в стандартном коде более стремительна как выше уже упоминалось. Во вторых, значение Green на верхнем скрине равно 0.060 , а на нижнем 0.050 , и такой разницы в определенных условиях может быть достаточно (жалоба на зеленку). В третьих, я уже предупреждал что на вид эффекта релея может оказывать включенный эффект Haze Effect. В стандартном коде для включения и выключения эффектов ПТА соответственно добавляет или удаляет фрагменты кода в файл FuncLibrary.fxh. Для каждого эффекта это два почти одинаковых фрагмента в двух разных местах отстоящих не так далеко друг от друга. В случае если вы переносите в мой файл настройки из какого то сета в котором отсутствует эффект Haze Effect , то в моем файле этот эффект нужно не забыть отключить, и только тогда можно вести речь о каком то сравнении картинки. У меня не было ПТА для четвертого препара, поэтому чтобы не добавлять/удалять фрагменты кода, (что менее удобно) я придумал более удобную опцию - выключатель в текстовое меню. Это та самая уже упоминавшаяся опция для плавной регулировки на 390-ой строке : static float GenInEff = 0.35 ; //0 ~ 1 // Общая интенсивность эффекта. для выключения Haze Effect достаточно просто записать : static float GenInEff = 0 ; //0 ~ 1 // Общая интенсивность эффекта. Если хотите в моем файле высотную зависимость для релея как в стандартном коде, то следует произвести следующее редактирование : 1) Пристыковать к выставленному значению DensFactor в 401-ой строке выражение * saturate(1.0f - cb_Altitude/15000) : static float DensFactor = 0.0000000050 * saturate(1.0f - cb_Altitude/15000) ; // Density Factor Для менее стремительного убывания эффекта, верхний порог 15000 метров в выражении можно установить и по выше. 2) Удалить выражение 1-( 1-exp( -pow(abs( 0.5 *Altit1), 5 )) )*(1-saturate(exp(-0.2*Altit1))) в 403-ей строке ниже и заменить его на 1 : static float RlFACorr = 1 ; В таком случае эффекты в моем файле будут работать точь в точь как и в стандартном коде от ПТА. При этом не забудьте ещё проверить и выставить "Fog Gamma Correction" в 407-ой строке : static float FogGammaCorr = 1.0 ; // 1 // и "Усиление тонирования горизонта дымкой" в 410-ой строке : static float FogHorToneC = 1 ; // 0 ~ 1 ~ 2 //. Потому как таких твиков в стандартном коде ПТА нету. И только потом можно будет вести речь о сравнении картинок.( картинки должны быть вполне идентичны).
  12. Это недоработка препара. В ПТА есть твик который регулирует общую силу эффекта, но заложено ли в этом твике желаемое исправление в зависимости от наличия облачности я сомневаюсь, но точно утверждать не буду. Вот у томата множество более продвинутых твиков по части ЛА, и там возможное наличие исправления более вероятно, но опять же, я никогда не обращал на это внимание и не изучал томатовские твики. Сам я занимаюсь верхней половиной симулятора, на всё подряд не хватает времени. Если же в томатовских твиках нет такого исправления то теоретически я думаю, если найти переменную указывающую на наличие или интенсивность облачности( я такую переменную ищу давно но результата пока нет) то нужное исправление легко сделать и в ПТА, иначе нужно изучать томатовские твики, на наработках которых я думаю можно было бы найти какое то косвенное решение.
  13. Н.А встраивается непосредственно в стандартные шейдеры препара являясь полностью зависимой от их архитектуры твиком. А trueSKY - это отдельные шейдеры, которые при переключении накладываются сверху на шейдеры препара а значит и на Н.А. Всем процессом управляет какой то механизм в самом движке сима который не доступен, и некоторая часть кода trueSKY (или часть кода которая отвечает за взаимодействие между основными объектами препара и объектами trueSKY ) так же располагается в не доступном движке сима, сами по себе шейдеры это всего лишь вызываемый код. Поэтому ни о какой совместимости или компоновке между Н.А. и trueSKY не может быть и речи, либо Н.А , либо trueSKY .
  14. С вращением текстур в шейдерах я не разобрался как и со многими другими вещами. Советы Юрия мне бы очень помогли бы, но от него не слышно вестей уже давно и мне не охота его беспокоить. Но работа у меня развернута на очень широком фронте, вот и не знаю я когда закончу хотя бы Н.А. с облачными твиками. Так как облака тесно смотрятся вместе с Н.А. то сделать нормальное освещение облаков просто необходимо, ибо они портят всю картину, особенно в сумерках.
  15. Подобный алгоритм : обесцвечивание - окраска объекта собственными твиками можно попробовать применить и для ЛА и для террайна, по крайней частичным образом. Точно проверить руки ещё не дошли. В крайнем случае если для одного какого то объекта(например ЛА) возникнут какие то трудности, то для такого объекта можно задавать цвет обесцвеченными пикселями в текстурах. Как минимум должны быть обесцвечены первые пять пикселей слева в верхнем углу в текстурах неба.
×
×
  • Create New...