Tu154B-2 Advanced Development

[ShFsn]

Basically all changes showed here is modification of Tu-154B-2 from official FG hangar.

It will need some further reworks and maybe will be merged with @yuriknsk's github, and/or official hangar.

[ShFsn]

@ShFsn

P.S.: Этим летом я активно модернизировал Ту-154Б-2, ибо тот, что сейчас скачивается из официального ангара мягко говоря поломан. Накопилось более 40 изменений разной крупности, и было бы интересно дать посмотреть на результат человеку, который умеет нормально программировать под FG.

[ShFsn]

@Mike402

Давно присматриваюсь к Ту-154Б-2 и да, похоже что там много было сделано не по литературе, например АБСУ. У меня когда-то была идея портировать туда JSBSim АБСУ-144 которая писалась как раз с документации по АБСУ-154, плюс-минус режимы которые есть в Ту-144 и нет в Ту-154 и наоборот и немного другая СУУ -- осталось бы только убрать эти изменения, но даже портирование очень большая задача, пока так и не успеваю.

Кстати https://github.com/yuriknsk/tu154b или какой-то из форков может быть новее чем в официальном ангаре.

[ShFsn]

@ShFsn

Ну, в АБСУ я не залазил, мой навык реверс-инжиниринга пока что не настолько крут. 😄
Я в основном чинил очевидные проблемы, такие как звук и некоторые анимации. У меня есть "ченджлог", там можно будет подробнее узнать.

Про github Юрия я знаю, кое-что бесцеремонно позаимствовал. ;)

[ShFsn]

@Mike402

Сразу небольшое замечание: лучше было бы иметь все файлы в корне репозитория без дополнительной папки, как это было в оригинале. Если вы не против, я попробую сделать так и встроить ваши изменения как коммит наверху основной истории изменений, например Юрия, -- так будет проще всё отладить и протолкнуть в официальную версию. :)

[ShFsn]

@ShFsn

Можно, я не против. Только судя по форуму, ту-154 давным-давно заглох -- моё сообщение об изменениях уже вроде как месяца три ни один модератор одобрить не может.

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

И вообще, мержить две эти эти штуки должно быть будет непросто, т.к., например, панель заправки у меня реализована, но по своему, без литературы, т.к. я тогда не смог понять, как встроить её оригинал, не поломав при этом всё то, что я сам до этого делал. Или, ещё, я саму динамику не трогал, оставил как в оф. ангаре, но сам файл "tu154b.xml" менял, вроде бы для того, чтобы запись реплеев расширенную подключить.
В общем, там сложно и запутанно уже. (Только палками не бейте за такое, пожалуйста 😅)

[ShFsn]

@Mike402

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

Панель заправки не волнуйтесь, всегда будет время довести. ^^

[ShFsn]

@ShFsn

Да там тьма таких примеров, как эта панель, мне кажется. Ещё вот вспомнил: стеклоочистители я взял, но звук их мне не понравился, и я его вырезал. И вот такого много.

[ShFsn]

---

@Mike402

Да, вы правы: лайтмаповое освещение кабины смотрелось бы намного лучше. И со временем всё равно нужно избавляться от эмиссии: кто-то сказал что с переходом FG на современный OpenGL её поведение как-то нехорошо изменится, или может быть она совсем исчезла из стандарта, и будет реализована окольными путями со стороны FG.

Есть вариант в одном канале каждого лайтмапа сделать лампы, а в другом -- освещение кабины, но там нужно будет очень много делать, пока что лучше отложить до того как модели успокоятся, чтобы не пришлось переделывать.

Проблемы с эмиссией для табло и кнопок (их можно увидеть если задать шейдер Model = 0, она добавлена как резерв для случая когда нет лайтмапов) в том что:

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

[ShFsn]

@ShFsn

Гы, а ведь в Ту-154 ВСЁ освещение кабины для ALS изначально на эмиссии было построено. 😅

Надо будет переделывать, значит.

Ну, когда научусь работать с лайтмапами. А то я уже пытался подсветку лого там сделать (даже заготовки .eff у меня там можно найти), но получалось весьма стрёмненько. Такое ощущение было, что лайтмапы отключают освещение, выдаваемое ALS, но быть может это от того, как написана модель зависит.

[ShFsn]

@Mike402

Эмиссия в смысле emission материала, она ведь не только ALS? Может вы имеете в виду <light>? Это старая хорошая фича из Rembrandt которой недавно дали вторую жизнь в основном движке (но пока только в ночных сборках). Насколько помню, в 154 в кабине как раз эти <light>, и мне кажется что это стрельба из пушки по воробьям: там нет больших движущихся частей заслоняющих свет, поэтому лайтмапы справились бы так же хорошо и намного дешевле.

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

Лайтмапы не должны конфликтовать с освещением, но .eff могут конфликтовать друг с другом: каждый объект может только один .eff, поэтому нужно чтобы в .eff части наружной модели было повторено всё из основного .eff, например через inherits-from. Поэтому скорее всего просто несовпадение между основным и новым .eff.

[ShFsn]

@ShFsn

Понятия не имею, что это всё значит, но у меня есть хорошая иллюстрация:

Здесь слева АИ-модельки без лайтмапов, а справа -- с ними. И вот со 154-м происходило то же самое, когда я пытался к нему лайтмапы прикрутить (особенно кринжово это выглядело, если вспомнить, что у него фюзеляж состоит из двух полумоделей: передней и задней, и после применения лайтмапа они начинали различаться как по освещённости, так и по цветам).

Кстати, полагаю, по этим же причинам Ваш Ту-144 такой чёрный ночью.

[ShFsn]

@Mike402

Скорее всего это происходит потому что .eff с lightmap почему-то меняет настройки diffuse, а ещё вероятнее просто разные шейдеры по-разному рассчитывают освещённость: например, по умолчанию все модели model-default, но когда разработчик модели задаёт эффекты, обычно они основываются на model-combined -- и эти два шейдера иногда освещаются очень по-разному (что есть дичь со стороны FG, но имеем что имеем ^^).

Эту проблему можно увидеть например при попытке применить шейдер для изгиба крыла model-wingflex на модель которая раньше была model-combined, потому что он использует model-default.

Да, хоть в Ту-144 и нет лайтмапа, есть normalmap, который скорее всего тоже портит освещение ночью.

[ShFsn]

@ShFsn

Нет, в 154 карта не проекционная, там просто держатель бумажных карт с возможностью указателем поверх неё автоматически водить, если я правильно понимаю, конечно.

[ShFsn]

@mike 402

Кстати, карта называется "Планшет ПА-3", но информации по ней не очень много: https://www.avsim.su/forum/topic/137565-%D0%BA%D1%83%D0%BF%D0%BB%D1%8E-%D0%BF%D0%BB%D0%B0%D0%BD%D1%88%D0%B5%D1%82-%D0%BF%D0%B0-3-%D0%B8-%D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%83%D1%8E-%D0%BF%D0%BE%D0%BB%D0%B5%D1%82%D0%BD%D1%83%D1%8E-%D0%BA%D0%B0%D1%80%D1%82%D1%83-%D0%BA-%D0%BD%D0%B5%D0%BC%D1%83/

Понятно лишь что карты прозрачные, и по ним ходит указатель положения.

Ещё здесь картинки. Может быть что фильмированная карта на самом деле одна и таже в разных индикаторах, просто ПИНО её поворачивает, а ПА-3 показывает всегда вертикально.

https://reaa.ru/threads/kuplju-perfokarty-i-filmirovannye-poljotnye-karty.95255/

[ShFsn]

@ShFsn

О, интересная информация. Но всё же судя по описаниям, ИНО использует нечто вроде киноплёнки, небольшой ширины, а ПА-3 потребляет именно прозрачные рулоны, какие видно на одном из фото. Принцип работы таки разный, но теперь понятно, чем "обоснованы" 19 страниц чеклистов и таблиц.

[ghost]

Первое что бросилось в глаза: модели в Maintenance очень красивые, но наклоняются вместе с самолётом и проваливаются в землю когда ветер его шевелит. Как временное решение без необходимости переводить все модели в глобальное пространство можно сделать две анимации rotate по тангажу и крену с <expression>, которое рассчитывает угол отклонения моделей по отношению к самолёту из разности обжатия стоек шасси, например так: https://gitlab.com/mdanil/Tu-144D/-/blob/master/Models/Tu-144D.xml#L3720

[ShFsn]

Да, я знаю. И предложенное решение самое очевидное, и приходило даже мне. Но мне было ООООООЧЕНЬ лень придумывать и рассчитывать, как это сделать.

[ShFsn]

Как чистить историю коммитов?

[ghost]

А где вы хотите её почистить, в локальной копии или на гитхабе?

[ShFsn]

Везде.

[ghost]

т.е. хотите удалить вообще все коммиты из какого-то бранча?

[ShFsn]

Т.е. есть "First upload" и есть " Revert First upload" и я пытаюсь понять, как от них избавиться

[ghost]

ааа.... да, это нужно какой-то графический эквивалент команды $git rebase -i базовыйкоммит, она позволяет отметить коммиты на удаление.

[ShFsn]

Да, я как раз это накопал, сейчас пробую.

[ghost]

и потом чтобы переписать историю на гитхабе (в обычном режиме $ git push можно только добавлять коммиты, но не переписывать) нужен аналог $ git push --force

[ghost]

Баг: стёкла кабины заледенели сразу при спавне, и De-Ice Aircraft не делает их прозрачными

[ghost]

закомменчивание самого эффекта Glass помогает

[ShFsn]

Аууууу... Легче сделать прозрачную текстуру. 😅

Дело в том, что модель кабины была сделана с помощью какой-то дичи: 3dmax, ac3d, compass, и т.д. (судя по форуму). Как это всё держится вместе и работает -- одному богу известно. Но когда я пытался править её в блендере везде проступали артефакты прозрачности, и я без понятия, как их править.

[ShFsn]

Как вообще ведёт себя эффект Glass? Как он реагирует на температуру? А то я никаких ограничений на него не ставил, может он просто творит какую-то дичь, которую и должен?

[ghost]

ещё страннее то что пробую дать прозрачность в png, и всё равно так же... Может быть конфликт между шейдерами...

Ух, вспомню-вздрогну. Пришлось в своё время долго чистить результат ModelConverterX для Ту-144. Вручную сшивать все рёбра которые он порезал на стыках разных материалов, вручную именовать объекты, вручную менять затенение на smooth shading и теде.

[ghost]

Glass по умолчанию реагирует только на дождь, да и то там нужно свой вектор скорости прописывать. И что характерно, в wiki пример расчёта этого вектора какой-то убогий.

Вот более правильный расчёт, хотя он тоже не идеален:

https://gitlab.com/mdanil/Tu-144D/-/blob/master/PRules/animations.xml#L898

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

https://gitlab.com/mdanil/Tu-144D/-/blob/master/PRules/animations.xml#L1002

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

https://wiki.flightgear.org/ALS_technical_notes#Functional_masks

Через ту же вещь можно задать зоны, которые не обледеневают.

Может вы моделировали запотевание/обледенение стекла каким-то другим способом, и теперь он конфликтует?

[ShFsn]

Вектор скорости для дождя у меня свой, но совсем простенький (Нормали стекла направлены внутрь, поэтому дождь идёт из кабины наружу). Зато так капли по стеклу не елозят туда-сюда при любом тычке самолёта.

Нет, я больше никак не моделировал замерзание/запотевание стекла.

[ShFsn]

Замерзающее стекло: #2

[ghost]

Если нормали смотрят из кабины наружу то стекло вообще не видно, потому что в ФГ работает backface culling (это может быть не так если doublesided, но имхо лучше с doublesided не связываться). Поэтому внутрь так и должно быть.

[ShFsn]

Энивэй, дождь сейчас не самая большая проблема.

(Вынести в отдельный issue)

[yuriknsk]

Здравствуйте! Я рад, что интерес к модели не угас. сам я давно уже симуляторами не занимаюсь (интересы сдвинулись в сторону более реальных вещей), но репозиторий на гитхабе жив и если у сообщества есть полезные правки - я с удовольствием закоммичу. вс, 14 нояб. 2021 г. в 09:28, ShFsn ***@***.***>:

…

Энивэй, дождь сейчас не самая большая проблема. (Вынести в отдельный issue) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJJF6AMSQG7PQQLFQWXGE3UL4NDVANCNFSM5H6X4VBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ShFsn]

Здравствуйте, @yuriknsk!
Прошу прощения за долгое отсутствие, я помогал Михаилу с его Ту-144. Сейчас я перенёс все свои правки на актуальную версию самолёта, можете глянуть, что получилось.
Результат не финальный, есть ещё что перекопать и улучшить. Вроде бы всё самое значительное, что на данный момент на уме вертелось вынесено в отдельные issue.

[yuriknsk]

Надо будет найти время, поставить сим и самому вспомнить, что там и как:)
много лет уже прошло :)

[ShFsn]

А скажите, если вы вдруг помните, по сравнению с той старой версией, что осталась в FGAddon, много ли добавилось nasal-кода? А то просто производительность мало того что и так не блещет (много приборов с полупрозрачными текстурами, сейчас уже лучше не пожалеть вершин, и сделать полноценные 3-д приборы, будет эффективней), так она ещё и просаживается раза в два, а то и больше, за 4-х часовой полёт. Кроме назала пока грешить не на что.

[yuriknsk]

Здравствуйте!
Я новую версию и не видел даже.
но вообще, ни насал, ни динамика jsbsim никогда не были узкими местами модели. мы все время упирались в производительность именно графической системы. сами скрипты по ресурсам никак не должны бы серьезно влиять.

[ghost]

Судя по моим тестам с UFO, со временем просадка из-за 2 вещей:

• TerraSync -- понемногу
• Advanced Weather -- очень, причём заполняет память пока система не убьёт ФГ.

[yuriknsk]

если производительность падает со временем - логично предположить, что где-то память течет. возможно, что-то уже наколбасили в скриптах, но имхо это несложно отследить...

[ghost]

т.е. проблема не в Ту-154

[yuriknsk]

ну вот я тоже никогда не наблюдал именно утечек в скриптах. а в самом симуляторе много всяких чудес.
сеть поди может еще сильно влиять - там же перегружаются модели, в мультиплеере...

[ShFsn]

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

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

[ghost]

Там проблема И в Advanced Weather, И в TerraSync. Пересоздание переменных на стороне самолёта хоть и может вносить (и скорее всего вносит) свой вклад, но оно не такое большое по сравнению с этими двумя.

[ShFsn]

Значит, я прогнал самолёт по маршруту ULLI-LOWI, и вот результаты:

• Модель на старой базе из фгаддона с моими модификациями стартовала на 30-40 фпс, а долетела до Инсбрука с 18-25 фпс, что нормально, учитывая, что была включена Advanced Weather, и что Инсбрук сам по себе довольно тяжёлый порт.
• Модель на новой базе из репозитория без моих моих модификаций стартовала так же с 30-40 фпс, а вот закончила уже с 4-6 фпс.

Очевидно, что с новой версией что-то не так. Однако вряд ли виновата она сама. (Далее предположения.) Как мы с Михаилом продолжаем выяснять, nasal в последнее время немножечко продырявился. Отсюда же и утечки в Advanced Weather, и в TerraSync, и в новомодной генерации зданий на основе OSM, они все основаны на nasal-e (кроме, может быть, TerraSync, Михаил меня поправит, если что). Предположительно, nasal криво работает с памятью. Что именно он делает не так пока не ясно, Михаилу пока не удалось реализовать очевидный пример, показывающий проблему. Однако, если тыкнуть пальцем в небо, можно сказать, что со временем в памяти накапливаются мусорные данные, которые более не используются, но Garbage Collector не может от них по какой-то причине избавится, хотя пытается. Это вызывает сначала падение фпс (подтверждённый факт), что может быть вызвано безуспешными попытками Garbage Collector-a очистить всё больший и больший объём данных, а затем, на более длинных дистанциях, переполнение ОЗУ (подтверждённый факт) и вылет симулятора.

Большинству разработчиков удаётся плюс-минус обходить эти проблемы, как однажды сказали в дискорд-сервере ФГ: "Nasal не имеет большого количества задокументированных хороших практик, зато он имеет много относительно задокументированных плохих пракик" (хотя насчёт документирования я бы поспорил -- набор цитат разработчиков на вики-страничке слабо тянет на документацию). Так что я хочу всё-таки попробовать оптимизировать nasal-составляющую самолёта, а именно:

• по максимуму вынести создание переменных за пределы циклов, дабы избежать их пересоздания и возможного забивания памяти;
• заменить циклическое использование settimer-ов на maketimer-ы. Первые (возможно) требуют память для каждого своего пересоздания, а вторые создаются единожды, а затем могут быть циклически запущены и остановены по требованию;
• это уже не должно быть связано с памятью, но мне говорили, что node.getValue(), node.setValue() в долгосрочных перспективах использовать эффективнее, чем getprop(), setprop().

[ghost]

Может быть и так что проблема с утечкой (а может не утечкой, но пока это главная гипотеза) существовала и дольше, просто никто не замечал: пока удалось проверить только до 2020.3.6, дальше у меня всё не хочет компилиться -- хорошо было бы если бы кто-то мог прогнать бинарники последней 2019.x, последней 2018.x, может даже 2017.x и 2016.x вот с этим тестом: https://sourceforge.net/p/flightgear/codetickets/2710/#

Насколько знаю, node быстрее когда оно повтороно используется (т.е. в циклах), а {get,set}prop() когда однократный доступ (но опять же для однократного время не критично, поэтому можно везде node для единообразния).

[ShFsn]

Судя по датам последних коммитов в форках проекта, в 2017 году кто-то все ещё пытался улучшить модель. Надо полагать, что если бы проблема присутствовала в то время, её бы заметили.

[ghost]

Конечно, поэтому и лучше бы узнать когда сломалось, тем более когда "где сломалось" застряло. ^-^

[ShFsn]

А нельзя попытаться отследить проблему по архиву версий вот здесь: https://sourceforge.net/projects/flightgear/files/?

[ghost]

Если там есть линуховые бинарники то я могу попробовать.

[ShFsn]

В бинарниках не разбираюсь, но установщики (и вроде даже ченджлоги) там есть.

[ShFsn]

Спустя [МНОГО] дней я наконец-то нашёл проблему, вызывавшую деградацию производительности. Она действительно оказалась в назале. Дело в том, что:

1. В instruments.nas есть функция realias(), которая работает с хэш-таблицей Chase. При вызове realias() в словаре Chase._active[] создаётся новый объект, который по окончанию своего срока жизни заменяется на nil, но не вычищается из памяти полностью.
2. В какой-то момент, осенью 2015 некто Tomash Brechko переделывал топливную систему, и в коммите 26160b0 ("Add new fuel subsystem implementation."), который я нашёл при помощи git bisect, он добавил в instruments.nas две функции, вызывающие внутри себя realias().
3. Только вот сами эти функции вызывались из listenerов по обновлению (не по изменению значения) от jsbsim-овских переменных. А jsbsim, как мне говорил Михаил, обновляет свои переменные 120 раз в секунду. В итоге постоянно вызываемая realias() раздувала Chase._active[] в рекордно короткие сроки, и начинал беситься Garbage Collector, который ОООЧЕНЬ хочет, но не может вычистить данные прямо изнутри массива.

"Смягчением симптомов" явился перевод listenerов на срабатывание по изменению значения переменной, деградации более не наблюдается.

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

[ShFsn]

Ещё, я смотрел модель ПТ в FSX (она у меня, правда, не заработала от слова совсем), и в своих последних версиях она имеет заметно улучшенную кабину (а возможно ещё и внешку) относительно того, что есть у нас сейчас в ФГ. @yuriknsk , если вам не трудно, у вас не осталось каких-нибудь связей с авторами, чтобы можно было попросить разрешения использовать их наработки, как у меня дойдут руки подтянуть визуал до более современного уровня?

[yuriknsk]

Здравствуйте всем! Я, к сожалению, много лет не общался с командой ПТ, хотя когда-то мы были в отличных отношениях и они давали разрешения на использование графических материалов. Возможно, если с нашей стороны будет проявлена заинтересованность, то получить их разрешение на использование визуалки будет возможно. по крайней мере, можно будет попробовать. пн, 9 мая 2022 г. в 18:04, ShFsn ***@***.***>:

…

Ещё, я смотрел модель ПТ в FSX (она у меня, правда, не заработала от слова совсем), и в своих последних версиях она имеет заметно улучшенную кабину относительно того, что есть у нас сейчас в ФГ. @yuriknsk <https://github.com/yuriknsk> , если вам не трудно, у вас не осталось каких-нибудь связей с авторами, чтобы можно было попросить разрешения использовать их наработки, как у меня дойдут руки подтянуть визуал до более современного уровня? — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJJF6FRGIJXIU7GNPJZG63VJDWKLANCNFSM5H6X4VBA> . You are receiving this because you were mentioned.Message ID: ***@***.***>