Comments 46
А это просто совпадение, что скриншоты ну ооочень похожи например на это? rustrain3d.ru/sites/default/files/ed4m_pult_03.jpg Особенно рельсы. Плюс стиль изложения немного похож например на это: rustrain3d.ru/ru/main-train-simulators Да и описанную архитектуру (клиент-сервер, железки, отказ от игровых движков в пользу просто графического, Linux, Qt) я где-то уже видел… Вот честно — вы вдохновлялись рустрейновскими тренажёрами, или просто так совпало, что пошли почти тем же путем, только на несколько лет позже?
UPD. На всякий случай — речь про копирование кода не идёт, просто в целом всё очень похоже.
UPD. На всякий случай — речь про копирование кода не идёт, просто в целом всё очень похоже.
вы вдохновлялись рустрейновскими тренажёрами
Нет, про рустрейн я сам узнал только летом прошлого года
Что до схожести идей и подходов, так история науки и техники знает немало примеров, когда одна и та же мысль посещала нескольких исследователей, незнакомых друг с другом. Некоторые логические выводы проистекают из законов природы, естественного порядка вещей и базовых принципов отрасли знаний. Так что не удивительно это.
Особенно рельсы
Нюансом графики именно для ж/д симуляторов является то, что рельсы это всегда lowpoly-модель, ибо нет смысла рисовать каждый костыль, особенно учитывая протяженность этих самых рельс. Так что верхнее строение пути в разных симуляторах выглядит похоже. Плюс есть ряд текстур, кочующих из MSTS в ZDS и обратно. Дошли они и до нас.
Рельсы не вот эти случаем? imgur.com/a/KTs9riX
UFO just landed and posted this here
Я не знаю, чья разработка эти сапсаны
Есть очень крутой сайт, там все ответы на ваши вопросы. Если только вопрос задан не затем чтобы задать вопрос…
На сапсанах действительно такое обзорное дупло или это ограничение тренажера, чтобы удешевить?
на сапсане там нормальное лобовое стекло, а здесь телевизор
Три проектора на полукруг не делали или движок такое не позволяет?
Движок допускает многомониторные конфигурации, легко и непринужденно. Позволяет анаглиф-псевдостерео. Позволяет VR-шлем. Всему свое время
Нее, после трех проекторов — motion-платформу. На МВПС, конечно, это не актуально, а в грузе ничто так не стимулирует мозг, как сжатие состава в спину или раскачка налива…
Можно просто сделать тракинг головы, благо пилот (вроде) один. Стерео не даст, зато позволит посмотреть по сторонам. И цена вопроса копеечная.
Потому что тренажер от Альстома и Сименса будет стоить как два новых поезда.
* Из кокпита действительно не очень большой обзор (на фото пример ICE3 который конструктивно сильно похож), да и что машинисту разглядывать? главное чтоб сигналы были видны…
* Куча мониторов тк много информации которая является необходимой во время движения, либо для безопасности (показания скорости, индикаторы пож. безопасности, индикаторы ATP (automatic train protection)), одних тормозов у такого поезда 5 или 6(точно не знаю) видов, либо вспомогательная информация (расписание движения, состояние двигателей, текущая тяга/торможение и тд)
* ЭВС «Сапсан» (Velaro RUS) производства компании Siemens. Тренажеры есть для ICE. Для Сапсанов возможно РЖД не заказывала…
кокпит ICE
* Куча мониторов тк много информации которая является необходимой во время движения, либо для безопасности (показания скорости, индикаторы пож. безопасности, индикаторы ATP (automatic train protection)), одних тормозов у такого поезда 5 или 6(точно не знаю) видов, либо вспомогательная информация (расписание движения, состояние двигателей, текущая тяга/торможение и тд)
* ЭВС «Сапсан» (Velaro RUS) производства компании Siemens. Тренажеры есть для ICE. Для Сапсанов возможно РЖД не заказывала…
одних тормозов у такого поезда 5 или 6(точно не знаю) видов
ЭВС «Сапсан» оснащен:
1. Электродинамическим тормозом (рекуперация или реостат, в зависимости от насыщения контактной сети, переключение происходит автоматически)
2. Автоматическим непрямодействующим тормозом с пневматическим управлением
3. Электро-пневматическим непрямодействующим тормозом (реализуется за счет электроклапанов, разряжающих и заряжающих тормозную магистраль непосредственно около воздухораспределителя)
4. Пружинным стояночным тормозом с пневматическим отпуском (пружинные энергоаккумуляторы)
ICE3 в отличие от «Сапсана» оснащен ещё магниторельсовым тормозом, но РЖД отказалось от этого типа тормоза
Для Сапсанов возможно РЖД не заказывала
У РЖД есть тренажер Сапсана, причем на динамической платформе. Кем он разработан не знаю. Но, повторюсь, что наш вуз к подготовке локомотивных бригад не имеет никакого отношения и соответственно тренажеры, заточенные под это нас мало интересуют
У РЖД есть тренажер Сапсана, причем на динамической платформе. Кем он разработан не знаю. Но, повторюсь, что наш вуз к подготовке локомотивных бригад не имеет никакого отношения и соответственно тренажеры, заточенные под это нас мало интересуюттренажёр был изготовлен KMW (Krauss Maffei Wegmann в 2009г), но в середине 2017 года лично мной был разобран (кроме кабины и динамической платформы). Далее были установлены новые компьютеры и новое ПО. Органы управления не менялись, стоят оригинальные с реального Сапсана.
тренажёр был изготовлен KMW (Krauss Maffei Wegmann в 2009г), но в середине 2017 года лично мной был разобран
Этот?
Да, но это совсем старое фото (сбоку даже радиостанции нет). Сейчас там новая визуализация, новые ПО на приборах управления, новая мат. модель управления. Проектор остался старым т.к. там специальный выгнутый экран, а установка другого проектора привела только к ухудшению картинки. Разбирал и плакал. Немецкое качество. Всё закручено, всё подписано, качественные комплектующие, грамотное общее проектирование и т.д. P.S а разбирали т.к. очень дорогое обслуживание получается у немцев и долго всё очень.
Разбирал и плакал. Немецкое качество
Чего у нас, к сожалению не хватает. На примере нашего «Сапсана» — кабину мы купили на стороне, фирму называть не буду, чтобы не делать ей антирекламу (хотя следовало бы!). Пульт не содержит всего необходимого для реализации симулятора поезда, мы его дорабатывали: монтировали дополнительное оборудование, немного изменили схему проводки и т.п.
Сказать что там плохое качество, это не сказать ничего! Начиная от элементарной механики органов управления, заканчивая архитектурой УСО и его прошивкой — всё детский сад. Единственное — изготовленные на заводе платы. Остальное… я был настолько взбешен соотнеся увиденное с ценой, которую за это дали в 2015 году что даже забыл сфотографировать этот ужас.
Не смотря на этот саркастический комментарий, в отличие от господ из той фирмы у нас: большая часть механики, кроме не несущей серьезных нагрузок выполнена в металле; проводка выбрана с запасом с учетом опять таки механической надежности; распределенная архитектура УСО, позволяющая расширять систему. Да, сделано полукустарно, но надежно, для себя, и работает без сбоев. До совершенства, конечно как до Солнца.
Движок Unigine не рассматривали? Он как раз для тренажёров сделан.
Всё замечательно, но бросилась в глаза сломанная альфа на деревьях, отчего крона как будто светится или оконтурена. Почему так? Неверный порядок отрисовки, из-за чего в полупрозрачных местах просвечивает не следующее дерево, а небо?
Такая проблема существует. Несмотря на то, что движок самостоятельно сортирует грани, помеченные как допускающие прозрачность. В ресурсах маршрута прозрачными являются все грани на которые накладывается *.tga текстура, так что проблемы пометить не стоит. Разбираемся, думаю починим скоро
А это не тот артефакт, что обычно лечится с помощью premultiplied alpha?
*premultiplied. Не совсем, потому что при блендинге полупрозрачных фрагментов всё равно нужно знать, что поверх чего накладывается, так что без порядка отрисовки не обойтись.
Спасибо за поправку, на телефоне автоисправление иногда очень неожиданно и незаметно срабатывает.
Насчет того, что premultiplied alpha не отменяет порядка отрисовки полностью согласен, просто не имея перед глазами конкретного скриншота не совсем понятно какого рода там артефакт. А неудачная текстура без premultiplied очень даже может давать светлые ореолы на границах, даже при корректном порядке.
Насчет того, что premultiplied alpha не отменяет порядка отрисовки полностью согласен, просто не имея перед глазами конкретного скриншота не совсем понятно какого рода там артефакт. А неудачная текстура без premultiplied очень даже может давать светлые ореолы на границах, даже при корректном порядке.
Например, вот кадр:
Выглядит и правда странно, но если это все-таки проблема в порядке отрисовки, то по любому там еще и z-write не выключен на полупрозрачной геометрии, что по мне немного странное решение. С другой стороны — границы там далеко не все «прямые», хотя возможно это из-за дополнительного альфа-теста.
С другой стороны — границы там далеко не все «прямые», хотя возможно это из-за дополнительного альфа-теста
Испытываю искреннее уважение к людям, умеющим вести конструктивную дискуссию. Вашими советами (по всей ветке комментариев) и настроил альфа-тест и функцию смешения, получив такой результат
Огромное спасибо за участие, если удастся развернуть этот фикс на тренажер, покажу скрин с моста
Получилось как-то так…
Хало по границам крон деревьев, которое вы наблюдаете в видео — как раз из-за использования классического альфа-бленда вместо рекомендованного в таких случаях premultiplied. Идея вкратце:
1) исходные текстуры преобразовать как (rgb, a) -> (a*rgb, a)
2) использовать бленд-функцию src * ONE + dst * (1 — SRC_ALPHA)
Почему именно так — можно почитать тут:
www.realtimerendering.com/blog/gpus-prefer-premultiplication
blogs.msdn.microsoft.com/shawnhar/2009/11/02/texture-filtering-alpha-cutouts
blogs.msdn.microsoft.com/shawnhar/2009/11/06/premultiplied-alpha
Другой вариант — не использовать alpha blending вообще, вместо этого включить MSAA, и для листвы использовать режим alpha to coverage, эффект достаточно хороший, особенно при MSAA 4x и выше, при этом геометрию не обязательно сортировать — традиционный z-buffer при этом отлично работает. Минусы — если будете использовать полноэкранные эффекты и особенно технику deferred shading — включенный MSAA даст очень много мороки. Подробнее тут:
medium.com/@bgolus/anti-aliased-alpha-test-the-esoteric-alpha-to-coverage-8b177335ae4f
1) исходные текстуры преобразовать как (rgb, a) -> (a*rgb, a)
2) использовать бленд-функцию src * ONE + dst * (1 — SRC_ALPHA)
Почему именно так — можно почитать тут:
www.realtimerendering.com/blog/gpus-prefer-premultiplication
blogs.msdn.microsoft.com/shawnhar/2009/11/02/texture-filtering-alpha-cutouts
blogs.msdn.microsoft.com/shawnhar/2009/11/06/premultiplied-alpha
Другой вариант — не использовать alpha blending вообще, вместо этого включить MSAA, и для листвы использовать режим alpha to coverage, эффект достаточно хороший, особенно при MSAA 4x и выше, при этом геометрию не обязательно сортировать — традиционный z-buffer при этом отлично работает. Минусы — если будете использовать полноэкранные эффекты и особенно технику deferred shading — включенный MSAA даст очень много мороки. Подробнее тут:
medium.com/@bgolus/anti-aliased-alpha-test-the-esoteric-alpha-to-coverage-8b177335ae4f
Реализовал первый метод. Вот результат (кликабельно)
1) в исходной текстуре в прозрачных местах случайно не белый был? по хорошему в таких штуках цвет заливки должен хотя бы примерно совпадать с цветом границ, как например тут (смотреть на левую текстуру):
us.v-cdn.net/5021068/uploads/editor/b0/5mlwn87s58ip.jpg
2) перед тем, как загрузить текстуры в видеокарту вы точно сделали предумножение rgb канала на альфу? В итоге в прозрачных местах rgb того, что лежит в видеопамяти должно быть черным.
us.v-cdn.net/5021068/uploads/editor/b0/5mlwn87s58ip.jpg
2) перед тем, как загрузить текстуры в видеокарту вы точно сделали предумножение rgb канала на альфу? В итоге в прозрачных местах rgb того, что лежит в видеопамяти должно быть черным.
1) в исходной текстуре в прозрачных местах случайно не белый был?
Белый
2) перед тем, как загрузить текстуры в видеокарту вы точно сделали предумножение rgb канала на альфу?
Да, конечно, вот так
void convertTexture(osg::Image *image)
{
unsigned char *data = image->data();
for (unsigned int i = 0; i < image->getTotalDataSize(); i += 4)
{
pixel_t pixel;
pixel.r = data[i + 2];
pixel.g = data[i + 1];
pixel.b = data[i];
pixel.a = data[i + 3];
pixel.r = pixel.r * pixel.a / 255;
pixel.g = pixel.g * pixel.a / 255;
pixel.b = pixel.b * pixel.a / 255;
data[i + 2] = pixel.r;
data[i + 1] = pixel.g;
data[i] = pixel.b;
}
}
Ааааа! Я идиот! Восьмибитные числа перемножаю и кладу в восьмибитные!!! Умножай не умножай результат обрежется до восьми бит(((
Белый
Поправьте текстуры, и хало наконец уйдет (в фотошопе инструмент кажется defringe назывался, но могу ошибаться).
Кстати, судя по окнам локомотива альфа-тест у вас включен для всех текстур с альфа-каналом, что зря. Лучше все-таки разделять кейсы:
1) трава, деревья, возможно какие-то заборы — альфа-тест, в идеале — без альфа бленда, но со включенными MSAA, alpha to coverage и z-write, и можно не сортировать (но выводить все равно лучше после полностью непрозрачных объектов по соображениям производительности z-буфера)
2) действительно полупрозрачные объекты типа окон — z-test и альфа-бленд включен (и используется как раз premultiplied вариант), альфа-тест и z-write выключен, сортировка от дальнего к ближнему, выводить после полностью непрозрачных объектов
А интерфейс на мониторах у машиниста близок к реальности?
Неужели в реальной жизни интерфейс также уныл и запутан? На всех ЖК-экранах привет из 80-х.
Неужели в реальной жизни интерфейс также уныл и запутан? На всех ЖК-экранах привет из 80-х.
А интерфейс на мониторах у машиниста близок к реальности?
Да, это точная копия того что установлено на Сапсане
На всех ЖК-экранах привет из 80-х.
Вы знаете о существовании европейского стандарта на интерфейс дисплейных модулей машиниста? Кстати, центральный дисплей — КЛУБ-У — отечественный и он не соответствует этому стандарту
И вопрос — а какова, с вашей точки зрения примета 2010-х в этой области? Что должно быть?
Вы знаете о существовании европейского стандарта на интерфейс дисплейных модулей машиниста?
Честно говоря — не знал.
А «псевдообъёмные» кнопки — это тоже стандарт? А шрифты?
Убрав, например, (как минимум) заливку всех кнопок, расположенных по периметру монитора, можно значительно упростить и облегчить восприятие…
+ наверняка можно, например, уменьшить толщину горизонтальных линий на шкалах ТМ и ПМ.
… какова, с вашей точки зрения примета 2010-х в этой области? Что должно быть?
Не совсем понятна фраза «примета 2010-х в этой области». Полагаю, что Вы имеете в виду тренд 2010-х годов? :)
Я не специалист в области интерфейсов дисплеев комплексных локомотивных устройств безопасности, но здесь много что можно (читать: нужно) переделать для того, чтобы время считывания машинистом информации уменьшить в разы:
На самом деле, проектирование любого интерфейса — задача всегда интересная и связана с погружением в предметную область по самую макУшку.
А «псевдообъёмные» кнопки — это тоже стандарт? А шрифты?
На настоящем дисплейном блоке кнопки аппаратные. У нас — имитация на сенсорном дисплее. Кстати, центральная зона, где экран, невосприимчива к нажатиям. Чувствительна только имитация рамки дисплея с кнопками
Вот так выглядит настоящий дисплейный блок. Правда на фото — «Ласточкин» блок на котором другое ПО, но аппаратно он идентичен Сапсановскому
+ наверняка можно, например, уменьшить толщину горизонтальных линий на шкалах ТМ и ПМ
Это не к нам, это в фирму Siemens
но здесь много что можно (читать: нужно) переделать для того, чтобы время считывания машинистом информации уменьшить в разы:
а с этим вопросом нужно на Ижевский радиозавод
А выбор сразу такой сделали насчет движка? Ogre3d рассматривали? Qt3D появился с версии 5.5 — его не рассматривали?
А выбор сразу такой сделали насчет движка?
Ой не сразу...! Два года я водил команду как Моисей по пустыне в поисках удобной технологии и борясь с наследием в виде убеждения что задачу можно решить только на Unity (и с утверждениями типа «да я видел видео на ютубе, там же все просто, берешь мышкой вытягиваешь...»)
Qt3D появился с версии 5.5
Qt3D это средство для создания трехмерных презентаций
Ogre3d рассматривали?
Это был один из первых вероятных кандидатов. У меня даже где-то были тестовые примеры. Что смутило:
1. Две параллельные мажорные версии — официальная ветка 1.x и предвечная и не рожденная 2.x с различающейся архитектурой.
2. OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre. У них на сайте есть подробный список причин, который был нами изучен. Из яркого — в Ogre нет такой ультрамощной системы плагинов как в OSG, а мы уже успели оценить её по достоинству
3. В Windows Ogre для рендера использует DirectX, который лично я считаю технологией: а) не нужной б) медленно умирающей
Qt3D это средство для создания трехмерных презентаций
Это вы со студией их, наверное, путаете. Сейчас Qt активно продвигает свой модуль для работы с 3d графикой. Описание.
Ogre
После того, как основатель и бессменный лидер проекта Steve Streeting ушел по состоянию здоровья, движок очень затормозил. Вроде бы сейчас его тоже пилят, но как-то все медленно, половина вики не работает, а большое русское комьюнити просто развалилось. Жаль, я в свое время активно использовал этот движок и тоже делал на нем различные симуляции, и он был отличным.
OSG гибче, не зря создатели OpenMW мигрировали с него с Ogre.
Я как-то тоже решил для пробы (один небольшой проект) взять OSG, и тоже могу сказать, что работать с ним приятнее и стабильнее, чем с Огром. Работает именно так, как ожидаешь, что не скажешь о последних версия Огра.
Ну и OSG тоже до сих пор пишет автор движка, уже очень много лет.
В Windows Ogre для рендера использует DirectX
В Ogre3D используются OpenGL и DirectX 9/11, рендер можно выбрать.
Сейчас Qt активно продвигает свой модуль для работы с 3d графикой
Возможно я что-то упустил. С какой версии Qt появилась эта возможность? Мне стыдно, что я упустил этот момент, так как, по крайней мере у нас в универе я выступаю в роли евангелиста Qt)
Это вы со студией их, наверное, путаете.
Да, Вы правы, я спутал это с Qt3D Studio.
Что ж… спасибо за наводку, буду изучать и следить
Ой не сразу...! Два года я водил команду как Моисей по пустыне в поисках удобной технологииМного лет назад, работая в другой конторе, которая пилит деньги на оборонных заказах, я выбрал в качестве языка С++ и рендер Ogre3d. На этой связке выпустил 3-и тренажёра для военных.
Потом разругался и работал год тут (у них там полностью свои разработки).
Уже на должности тех. директора в СимРэйле, начиная с 2011 года, мы делали тренажёр Ласточки, для обучения локомотивных бригад.
Язык программирования я сменил на С# (он проще/компилируется быстрее/ошибок меньше), а рендер был выбран снова Ogre3d (с оберткой для C# mogre) и это была ошибка.
Ogre3d это только рэндер и практически полное отсутствие вменяемых инструментов для пользователей и если на первой моей работе такой выбор прокатил, то тут были другие масштабы.
Даже примитивная операция конвертации модельки из макса в движок представляла из себя боль и страдания.
В конечном итоге силами 3 программистов были написаны: редактор пути, редактор графических интерфейсов (для HMI), визуальный редактор и ещё куча всего для работы тренажёра.
Наличие такого объёма кода и поддержки всего этого сильно выматывали. Первыми начали сливаться левел дизайнеры и надо было решать эту проблему…
В один прекрасный день акционеры притащили ещё один заказ и для МЧС, нужно было сварганить интерактивный тренажёр для детей, а там есть главный герой, скрипты, анимации, звуковое сопровождение и т.д.
От художника! прозвучала мысль, что нужно делать его на Unity. Сказано-сделано. В результате мы сделали его настолько быстро и просто, что было решено отказаться от своих редакторов и полностью перейти в Unity3D.
Потом был Сапсан, МТК-1, LNG и т.д, а в прошлом году я уволился.
Оговорюсь, что неограниченная протяженность в принципе недостижима
Ой, а StarCitizen-то не знает...
Sign up to leave a comment.
Трехмерная визуализация в тренажерах подвижного состава на базе движка OpenSceneGraph