3D-системы используются для визуализации инженерных решений (типа обучения операторов АЭС, мониторинга там же), в нефтегазовой геологоразведке (туда идут самые дорогие иммерсионные системы), для демонстрации различных товаров (от кастомных дизайнов салонов автомобилей до типа укладки товара в грузовиках), для обучения ремонтников (можно разобрать двигатель Боинга), в медицине для обучения, а также для отработки эвакуаций и ЧС на разных ответственных объектах.
Главная проблема подготовки контента — это то, что на рынке много компаний, которые говорят «Мы умеем это делать», но не имеют своего железа по факту. Без двухнедельного тестирования, без чёткого понимания ограничений железа и просто знания особенных грабель — это не «умеем и можем», а «хотим, но не получится».
Почему рынок взорвался
Виноваты Оккулусы и другие подобные дешевые системы отображения 3D-контента. Они дают хороший эффект присутствия, но совершенно не подходят для вышеописанных инженерных и технических нужд, потому что работать больше 10-15 минут уже больно глазам и голове. Ну и детализация пока, увы, недостаточная — пиксели перед лицом хорошо заметны. Зато — дёшево, и даже очень дёшево. Отсюда идеи многих компаний сделать на этом решения в духе «круто и инновация». Да, это инновация, но в большинстве случаев это не круто. Круто — это кластер у вас в подвале.
У нас в 3D-школу регулярно обращаются и заказчики, и их подрядчики. Регулярно для обучения своих специалистов, часто для прямых заказов, иногда — чтобы мы сделали хоть что-то за оставшиеся две недели из двух месяцев разработки. Спасаем проекты.
Расскажу о типовых граблях таких «спасаемых» и вообще о том, что чаще всего встречается на рынке.
Грабли
— Самые первые детские грабли — это изначально выбор такого ПО визуализации (подешевле), которое работает с каким-то своим форматом. Звучит немного странно, но поддержка разных CAD-ов — это основа того, что контент будет показываться нормально. Именно за это мы очень любим Eon — он «из коробки» перемалывают всё, от 3ds, FBX и OBJ до форматов STL, IGES, SolidWorks и Inventor. Почему это важно? Потому что рано или поздно вам принесут модель из Компаса, 3D Max, что-нибудь Сименсовое и так далее. У нас за пару лет через центр прошли тысячи людей, и они приносили примерно два десятка разных форматов из самых странных источников. Конвертировалось всё без проблем.
— Вторая часть — это выбор железа под конкретную задачу. Как правило, самые частые — это тренинг, обучение, презентация. Есть системы, которые дешевы, но не подходят под ту или иную задачу. Например, у нас есть 3D-стол, которой классно делает архитектуру и механизмы. Зато с ним очень проблематично обучать заглядывать в турбины. А вот в 3D-кубе можно подвесить турбину в воздухе перед пользователем, чтобы он её обходил, засовывал голову внутрь, почти что облизывал лопасть и т.п. Столы для таких задач не приспособлены. Или вот для презентации нужен хороший вау-эффект (это часто касается музеев и продавцов VIP-штук) — есть голографическая система, которая демонстрирует парящий в воздухе объект. В темноте. Опыт работы и настройки позволяет правильно порекомендовать и подобрать конкретную систему. Естественно, когда у компании нет всего спектра вариантов, делается на том, что персонал знает или что выгоднее продавать. Результат не всегда оптимальный.
— Очень много грабель собирается на стадии сбора техзадания. Пожалуй, это самый сложный этап. Нужно понять за заказчика, что за контент ему нужен, как он его будет использоваться и под какие системы. Нужно четко оговаривать все детали. Бывает, что заказчик ставит задачу делать под одну систему, через месяца два смотрит предварительный прогон и произносит: «Слушайте, что-то не впечатляет, давайте под голографический проектор сделаем». Переделать можно, но это время. Ещё на этапе переговоров нужно внимательно слушать и изучать все аспекты.
— На той же стадии выявления техтребований важно понять алгоритм и сториборд. В идеале — опять же, сначала всё нарисовать хоть на салфетках и по шагам пройти тот же тренинг с преподавателем. Почему это важно? Ну, например, это снимает вопросы, как правильно создавать модель. Вот взять клавиатуру: можно создать как одну сплошную модель, если она будет использоваться как тупой лёгкий предмет в симуляторе ЧС и эвакуации. Можно делать как совокупность клавиш, если планируется на них нажимать. А можно делать внутренности, если они предполагаются для учебного разбора. Какие объекты, какая детализация, какое управление — всё это нужно понимать ещё «на берегу».
Мультипликаторы прикалываются
— Потом оптимизация. Как правило, это частая проблема тех, у кого недостаточно профессиональные специалисты. Например, для нефтеперерабатывающих станций большая часть рендера идёт в реальном времени, и нужно детализировать только важные объекты. Те же библиотечные трубы отлично выглядят вблизи, на них даже щербинки видно. Но это не нужно — каждый лишний полигон на трубе будет замедлять процесс. А вот, наоборот, запорная арматура — она нужна отлично детализированной. И сразу нужно думать про то, что при дальнейшей модернизации контента архитектура не вызвала тормозов. Часто проект сдаётся «впритык» к возможностям системы, а потом через месяц начинает лагать, потому что заказчик добавил модели нового оборудования. В общем — можно бездумно замоделить в хайполе, а можно подойти с умом.
Вот гном с бутылкой. Бутылку не видно. А полигонов в ней больше, чем в целом гноме.
— Финальная часть оптимизации обычно как в ремонте — «зачем стены выравнивать, на отделке обоями поправят». Бывает сразу известно, что проект под телефоны в том числе — но об оптимизации задумываются только в самом конце.
— Важен подход к моделлингу. Нужно сразу знать, как будет работать интерактив, что будет выгружаться в программную среду, как объекты будут взаимодействовать, что точно будет происходить. Это нужно уметь сразу документировать, иначе потом ждёт море сюрпризов.
— Вторая точка, где больше всего проблем — это интерфейсы и взаимодействие девайсами-управлялками. В плане совместимости относительно спокойно — Eon сам поддерживает массу манипуляторов от джойстиков и перчаток до кинектов и 3D-мышей, драйверы есть подо все. Не нужно ничего писать самому. Там же много готовых модулей типа меню в воздухе, разных систем взаимодействия с пользователем. Есть типовые модули вроде «взрыв-схемы», позволяющие легко и просто разбирать объект. Много драйверов к готовым 3D-системам. Мы берем любой куб и прямо в среде указываем, что это туда. И все настройки камер, углов и так далее уже оптимальны. В другой среде приходилось бы тратить больше времени.
— Важна точность 3D-управлении. Есть драйвер, он описывает работу с девайсом. Но нужно думать и за пользователя. Чтобы попытка взять объект не превращалась в пиксельхантинг, нужно автоприцеливание. Часто требуется модуль магнита, позволяющий размещать детали объекта на каком-то расстоянии, чтобы они «со щелчком» сходились и собирались. Понимание удобства интерфейса для конечной системы очень влияет на уровень погружения, поэтому отмахиваться от этого (как часто делают на enterprise-софте для инженеров) просто нельзя.
«Мышь»
«Геймпад»
— Касаемо железа очень много нюансов по типам 3D — вертикальная раскладка, горизонтальная, синхронизация, чередование. В зависимости от системы это может означать падение разрешения вдвое. Для себя мы пришли к выводу, что имеет смысл использовать только 120 Гц (квадробуфер или Full3D) сохраняет разрешение. Наверное, вы видели в домашних 3D-телевизорах этот эффект размазывания из-за чередования строк.
— Сами регулярно наступали на грабли с правильным подбором очков — для разной аудитории нужны разные модели. Например, есть три основных технологии сейчас — это синхронизация по DLP-чипу проектора (DLP-очки подойдут к любому проектору), по инфракрасному и по радиосигналу. Радиоинтерфейс дорогой, но эффективный. ИК — вполне функционален. DLP дешев и сердит. А еще важно учитывать падение яркости из-за активных очков до 70%.
— Ещё одно звено — компьютеры для рендера. Они должны быть с правильной видеокартой. Не все выдают квадробуфер, не все выдают систему мозаик для разных экранов. Опять же, Eon работает с системой мозаик nVidea — много экранов объединяются в один панорамный. А это требует определённого железа. Неправильный ноутбук для рендера на выезде или неправильная видеокарта — фигня на выходе.
— Передатчики-приемники должны поддерживать 120 Гц — если факторы не учитывать, сигнал вполне себе не дойдет. Не все умеют передавать 4К 120 Гц чисто по физике. Пока у нас работает без косяков Extron, другие — не срослись на 100% качественно. Cигнал отправляется по оптике или витой паре. Качество соединения имеет значение: если та же оптика немного неверно воткнута — в момент максимальной нагрузки экран может начать мерцать, что часто списывают на недостатки ПО, а не физические свойства канала. Конечно, есть традиционные проблемы, когда спецификация на устройство показывает одно, а в реальной жизни всё выглядит несколько иначе. Был, например, кабель, который при малейшем изгибе выходил за заявленные параметры. Часто заказчики покупают новый ноутбук для демонстраций, а потом сталкиваются с тем, что к нему же нужно добирать усилитель. Мы используем бустеры с внешним питанием для таких случаев, если что-то показывается на чужом оборудовании. Есть ещё нюансы, не зная которых, можно очень долго запускать презентацию.
— Много сложностей при перевозке — важно очень аккуратно собирать и разбирать. Если монтировать неаккуратно, конструкция разбалтывается. У нас по молодости падал проектор, разбивался — во время монтажа на точке привесили для тестов, а затянуть забыли. Один раз приехали — не заработал ИК-излучатель за 100 баксов. И его ни у кого нет в Москве, возится только под заказ за два месяца. В результате основали свой склад запчастей.
— В 3D много составляющих, которые могут убить весь эффект. Если очки не заряжены или кабель не пропускает 3D, все остальные компоненты за тонны долларов — это уже не важно. Много точек отказа. У нас, например, был случай, когда один человек — назовём его Полковником — пристально смотрел на модель изделия, а потом сказал: «Что-то мутная она». Мы 10 минут выясняли, пока не поняли, что у него отвалился радиоинтерфейс к очкам. Сменили «рамку» — дальше пошло нормально. Поэтому хорошая практика — жёстко отслеживать наработку ламп, всегда даже после пятисекундного использования заряжать очки, проверять эмиттеры. В демо-центре включаем систему за час до презентаций всегда, есть даже специальный человек для этого. За час до конца рабочего дня этот же специальный человек ставит все на зарядку, проверяет железо, меняет компоненты.
Речь о таких очках.
— Ну и традиционные проблемы разработки — стиль кода, общая архитектура, комментарии — всё это привычно, но всё равно актуально.
Как-то вот так. Если интересно больше про 3D-центр, то вот экскурсия. Ну и вот моя почта, если у вас есть вопрос, который не подходит для комментариев — PPochtennov@croc.ru.
Автор: PPochtennov
