Ну смотря о чём речь. Если прям Image Target Tracking, без детекции через OpenCV чего-то вроде QR кода и т.п. — нет, так как в целом практические либы устраивают по своим параметрам. А если аналоги простых методов, то тут маркером смотря что считать. Если брать определение реперной точки (с пафосным названием фидуциальный маркер), то на OpenCV можно много под что написать конкретный классификатор. Некое обобщённое решение делать не пробовал. Но скажем, чтобы в качестве маркера выступала лента из последовательности цветов — конечно.
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Пробовал. Мне не понравился. Правильная работа с якорями + меканим мне нравится больше. Анимации проще редактировать, чем code_first подход. Особенно в комплексных эффектах. Но возможно дело в специфике проектов.
Так как NGINX — это по сути готовый упрощённый бекенд не требующий особых навыков. Я не говорю про правильную конфигурацию на прод сервер. В статье речь о хотя бы «запустить на конфигурации по умолчанию». Так же можно запустить тот же апач или IIS.
Просто хотя бы для задачи. В игре есть иконки, иконки не хочется хранить в билде или в бандлах, так как их очень много и они часто меняются. Нужен SpriteLodader, который будет уметь грузить её по урлу, а во время загрузки отображать в интерфейсе загрузку.
Собственно чтобы не просить бекендеров завести тебе нужные файлы и бек такой и т.п. Можно в одну строку в командной строке развернуть инстанс nginx, закинуть файлы, да протестить.
Блендер же это инструмент, который требует навыков сложнее одной консольной команды, чтобы хотя бы им уметь делать базовые вещи.
Blender не относится к экспертизе разработчика. Его можно знать, и чем больше знаешь — тем лучше вообще. Но это 3д моделлерский софт для 3д моделлеров. И в классическом продакшене юнити разработчики не обязаны уметь им пользоваться в целом. Так же как и фотошопом, иллюстратором, фигмой, скетчем и т.п. Или из 3д софта майей с максом)
Это не инструмент для разработки) Хотя иногда править нормали за моделлерами быстрее самому)
Мне то нет никакого смысла его продавать. Я в эпле не работаю, и только рад, когда мне заказывают что-то без AR/VR или трекинга. Так как бороться с шумами, объяснять что этот маркер — херня и не будет работать, и тестировать всё это дело — ну такое. Типа опыт позволяет, но в разы проще и интереснее пишутся другие вещи. Типа шейдеров или любой другой вещи, которая тестируема в движке и работает стабильно.
Условная игра в этом плане в разы приятнее разработки AR/VR, или какой-нить сервис по процессингу чего-то в облаке на питоне (даже в случае крупного проекта, где надо много всего учитывать и как бы знать, что такое архитектура в отличии от среднего фриланс заказа, или же как строится адекватный пайплайн, как прикручивается CI&CD и так далее). Так как там свои нюансы и приколы. И иногда закапываешься с какой-нить просадкой или фигней надолго. Но в целом это в разы приятнее, чем ползать по локации заказчика и каллибровать датчики.
Просто после 15 проектов связанных с AR/VR — плавал знаю. И это не стартапы, а просто заказная разработка под конкретную задачу. Просто главное честно говорить и обсуждать все нюансы трекинга. И понимать задача решаема или нет. На свой SLAM можно тоже сжечь тонну бабла, и прийти к выводу, что процессор и датчики в телефонах — хрень. Но если в задаче хватает точности и функционала аркита, то как бы зачем?
Просто есть набор «влажных фантазий». А есть то, что реально можно сделать на текущем уровне качества. Не забивая на проблемы трекинга, а досканально их понимая и делая решение в контексте этих проблем.
И линейка нормально не работает и в идеальных условиях. У аркита можно рассчитывать на точность +-5 см где-то, что очень плохо для линейки. Которая ещё и накапливается по мере того, как пользователь отходит от «точки привязки».
Согласен. Основной вопрос какая точность нужна. Дело в том, что вы берёте в данном случае — где она не работает. А есть кейсы, где она работает, так как условия хорошие. Но это безусловно не кейс, о котором все мечтают — типа навигации по торговому центру, так как там пол блестит и досвидания. И свой SLAM на датчиках телефона — это вообще никак не решит. Там проблема чисто в наборе датчиков среднего мобильника и мощности процессора.
Но скажем на производстве, где есть возможность раскидать свой трекинг и приклеить к телефону свой датчик (ну либо засунуть его в красивый чехол, не суть как его крепить) — это вполне реально. Особенно если нужна точность в пределах +- 5 см.
Аркит едет через каждые 50 метров, и у него много проблем. Но если есть точки рекалибровки, и нужно просто выводить плашки от отпределённой точки интереса, то там тоже всё прекрасно работает. Вопрос в конкретике задачи.
Да я не пытаюсь продать, я рассказываю скорее что есть из моего опыта. Помимо ToF или SLAM, который важен только для инсайд-аут трекинга — есть ещё системы типа вайкон и оптитрек, если нужна высокая точность. Для трекинга рук есть магнитный трекинг, который используется в медицине, так как там тяжко с прямой видимостью, когда руки в человеке. С низкой точностью и большими расстояниями — есть ультразвук и марвелмайнд. Так что SLAM и ToF, или же лидары, это лишь верхушка айсберга.
Просто позицию довольно хорошо научились получать, так что это не так интересно. Если же мы говорим про оцифровку мира, то просто зависит от того, кто чем занимается. Я работаю с трекингом и разрабатываю под него софт, а не разрабатываю yet another slam.
Последнее я даже разрабатывал в рамках работы одной компании. И даже было на выставках по недвижимости всякой. Там есть очень много нюансов.
С мебелью в квартире AR логичнее, что собственно и сделала икея.
А примерка одежды — технологии пока не доросли, там очень много технических проблем, из-за чего даже примерка часов и колец — это технически сложно. Но вообще есть такие штуки. play.google.com/store/apps/details?id=tattoo.inkhunter&hl=en_US для тату. Для часов или типа того на память не вспомню.
Но вот примерить платье — это сложно. Помимо того, что оцифровка платья качественная с ригом стоит дорого, так ещё нужно получить скелет пользователя. Можно попробовать таким, но это не мобилка, а десктоп github.com/CMU-Perceptual-Computing-Lab/openpose
А так, то что большой часть проектов убил usdz — это довольно неплохо. Так как да, проект уровня «мы показываем 3д модельку в AR» без причины и обоснования — это грустно.
Но скажем из забавных штук можно глянуть Porsсhe Car Visualizer, кейс от икеи и artefact собственно. Если говорить про маркерный AR или трекинг.
Так то есть ещё огромный пласт типа дипфейков, масок и прочего. И AR в данном контексте применяется достаточно часто. Хотя тут правильнее сказать технологии компьютерного зрения, но они часто идут рука об руку с AR.
Ну есть много вещей посложнее. Разные системы трекинга. Но если речь про b2c — да не спорю, я до сих пор не вижу применения пользовательского особого, кроме игр. Ходят мечты об удалённом рабочем месте и т.п. В целом может можно придумать что-то прикольное для лёгкого фитнеса (иначе потом надоест лечить прыщи из-за маски, да и в целом перегрев лица это не так приятно) Я могу в тот же битсейбер играть минут 40-50. Дольше это уже нереально. Но вот, что ещё пользователю там делать — совершенно непонятно. А главное зачем. Образование, и вопрос фокуса внимания, но у широкого пользователя это не будет мотиватором к покупке. Пока в любом случае некомфортно.
Но если брать корпоративное обучение, b2b кейсы и так далее, есть много применимых историй, в которых эффективность оправдана. А неудобства и т.п. незначительны.
А если речь про AR — там вопрос не совсем в знании API. Основная фишка в знании AR — это знание UX. Да, безусловно, есть куча кейсов, где можно применять достаточно прикольно. Навигация, экскурсии, мне например очень нравится артефакт из Российских, чтобы узнавать интересные детали про картины и искусство. Но в целом многие считают мобильный AR костылём, а хорошие b2c AR очки пока не пришли на рынок.
Что в AR, что в VR если мы говорим про разрабов. Я бы считал технически самым важным понимание принципов рендера (так как ресурсов дано не так много), разных техник оптимизации и математики хотя бы на уровне линала, чтобы делать что-то интересное и полезное. Скажем навигация по своей сути сводится к технологии трекинга + умению преобразовывать одну систему координат в другую. И если уж линейный перенос позиции ни у кого слава богу вопросов не вызывает. То вот допустим при восстановлении позиции по маркеру правильно применить матрицу поворота — то с этим возникают трудности.
Да, вполне живы. Много компаний, которые занимаются разными AR/VR проектами. Из неигровых можно вспомнить vr-professionals.comvrconcept.net и много кого ещё. В РФ в целом много кто этим занимается, по моему последнему исследованию небольшому в районе 100-150 живых компаний в разных частях индустрии.
А да, ещё общая боль — это степень оптимизации. На текущем уровне компом сделать красиво под десктоп — херня вопрос. А вот если мы подходим к VR ресурсов у нас в разы меньше. По этой причине я не раз писал кастомные шейдеры заточенные конкретно под VR в которых у нас кастомный алгоритм для отражений, как отображать лайтмапы и прочее. Думая о том, что про мультипасс лучше забыть, и писать всё сингл пасс стиле.
Большой процесс — это в основном невозможность покрыть систему автотестами нормально, поэтому усложняется процедура ревью и так далее. То есть, как можно грамотно строить стандартный процесс разработки. У нас есть софт (игра, не игра не так важно) Есть команда разработки. Допустим она больше 5-7 человек (иначе это всё не имеет смысла). Люди разного уровня. Что мы хотим от софта? Чтобы его просто было обновлять, чтобы он не ломался от каждого чиха, не тормозил и в целом легко доставлять его пользователям, так же как и обновления. Мы для этого берём кубер (если есть бек), тимсити и прочие прелести жизни. Зачем нам нужно покрытие автотестами? Чтобы когда разработка делает очередной пуш и отправляет всё в CI&CD систему, мы сразу отсекали те коммиты, которые не проходят тесты и говорили «это в мастер вливать нельзя». Что позволяет нам получать не забагованную херню, где постоянно что-то вылезает, а стабильные сборки. Дальше всё зависит от прокрытия и прочего. Это возможно не во всех играх делать хорошо, но в VR с этим в разы хуже.
А теперь пройдёмся по маленькому процессу. У нас 1-3 разработчика, так что CI&CD система не особо то и нужна, так как вряд ли проект будет супер комплексным. Как у нас выглядит итерация тестирования механики?
Дизайн
Мы создали новую интерфейсную панель, сверстали, посмотрели прям в движке в разных разрешениях и знаем, как она будет отображаться на разных устройствах. Если же мы не знаем дизайн правила по размеру шрифтов и элементов. Берём figma и открываем прототип, и прокликиваем на телефоне без всяких сборок. Чисто из figma.
Что же у нас будет в VR? По хорошему, для качества — сборка в билд, открыть панель и посмотреть. Как она смотрится в окружении, на каком расстоянии её включать в зависимости от того, с какого расстояния читаются скрипты, а на каком мы переходим к minify view. Так же не рябят ли контуры, кнопки и прочее на нашем целевом устройстве.
Механики
Все, даже физические механики в обычных играх это достаточно ограниченное число векторов скорости и скаляров. Потому что управляем мы всем с помощью дискретных сигналов. Поэтому это можно тестировать даже не проходя игру, но пройти уровень можно и движке. При этом не вставая со стула и т.п.
Казалось бы мелочь, бытовая вещь. Но замерь сколько времени тратится на то, чтобы тоже самое сделать в VR. А с компа это сделать нельзя с симуляцией, так как нереально сделать адекватную симуляцию из-за слишком большого числа решений.
И в VR очень много физических механик. Ещё надо учитывать что вообще у пользователей разный рост, разная длинна рук и анатомические параметры. По этой причине то, что тебе удобно в шлеме, другому человеку будет неудобно. Скажем ты баскетболист два метра, а играет девочка 1.5 метра ростом. Она тупо увидит всё иначе. И может не дотянуться, если ты поместил что-то на верх на расстояния вытянутой руки. При разработке hl2 — тебе даже думать про это не надо. А в аликсе думаю это выверено.
И можно продолжать очень долго и написать отдельную статью по нормальному UX в VR. Я видел одну неплохую на хабре, но там мало внимания посвящено тому, что анатомия у человека разная. Есть комфортные наклоны шеи, есть некомфортные и так далее.
То есть мы можем конечно взять контекст, что средний VR проект в геймдеве даже за прототип не прокатит по своей комплексности и количеству функционала. Так как у VR и бюджеты не те, и сроки обычно.
Но если брать примеры одного масштаба — они проще без VR. И это обусловлено даже простым тезисом. Инпутом. Инпут в играх — это сигналы клавиш по сути, в мобилках тоже обычно всё ограничено кнопками.
Инпут в 6DoF VR — это 3 точки, которые могут вести себя произвольно + сигналы. И нужно их обрабатывать. То есть спектр возможных случаев в разы больше.
Плюс в обычных играх можно ограничивать игрока, как тебе хочется. В VR так нельзя, потому что будет укачивать или дизориентировать пользователя или ещё что-то произойдёт.
Ну, а отдельный новый процесс — тестируем шрифты на читаемость и графику на то, как она рябит на расстояниях — отдельный сорт удовольствия)
То есть суть в том, что я может не совсем верно донёс мысль статьи. Нет вообще ничего невозможного. Но как человек, который был и в мобильном геймдеве, и в энтерпрайсе, и бекенд на .Net писал. Есть то, что объективно проще и удобнее. Энтерпрайс в целом в разы проще геймдева. Геймдев на самом деле проще VR. При решении многих задач.
Вопрос именно в сравнении. А дальше либо нравится, либо не нравится)
Да нет, не по разному. Очень зависит. Да и в VR зависит, если в инвентаре может быть 50 предметов, там будет тоже самое. Это уже ваша конкретная задача может быть так решена.
Проблема не в механизме фиксированных джоинтов. Это детский сад даже руками писать. Проблема в том, что есть комплексный объект с разными контекстными зонами нажатия. Чтобы через него не проходили другие объекты, чтобы физика на нём грамотно работала.
В случае 3д — это коробка с доступными сигналами. А в случае VR — это комплексный физический объект. И он объективно сложнее.
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Просто хотя бы для задачи. В игре есть иконки, иконки не хочется хранить в билде или в бандлах, так как их очень много и они часто меняются. Нужен SpriteLodader, который будет уметь грузить её по урлу, а во время загрузки отображать в интерфейсе загрузку.
Собственно чтобы не просить бекендеров завести тебе нужные файлы и бек такой и т.п. Можно в одну строку в командной строке развернуть инстанс nginx, закинуть файлы, да протестить.
Блендер же это инструмент, который требует навыков сложнее одной консольной команды, чтобы хотя бы им уметь делать базовые вещи.
Blender не относится к экспертизе разработчика. Его можно знать, и чем больше знаешь — тем лучше вообще. Но это 3д моделлерский софт для 3д моделлеров. И в классическом продакшене юнити разработчики не обязаны уметь им пользоваться в целом. Так же как и фотошопом, иллюстратором, фигмой, скетчем и т.п. Или из 3д софта майей с максом)
Это не инструмент для разработки) Хотя иногда править нормали за моделлерами быстрее самому)
Условная игра в этом плане в разы приятнее разработки AR/VR, или какой-нить сервис по процессингу чего-то в облаке на питоне (даже в случае крупного проекта, где надо много всего учитывать и как бы знать, что такое архитектура в отличии от среднего фриланс заказа, или же как строится адекватный пайплайн, как прикручивается CI&CD и так далее). Так как там свои нюансы и приколы. И иногда закапываешься с какой-нить просадкой или фигней надолго. Но в целом это в разы приятнее, чем ползать по локации заказчика и каллибровать датчики.
Просто после 15 проектов связанных с AR/VR — плавал знаю. И это не стартапы, а просто заказная разработка под конкретную задачу. Просто главное честно говорить и обсуждать все нюансы трекинга. И понимать задача решаема или нет. На свой SLAM можно тоже сжечь тонну бабла, и прийти к выводу, что процессор и датчики в телефонах — хрень. Но если в задаче хватает точности и функционала аркита, то как бы зачем?
И линейка нормально не работает и в идеальных условиях. У аркита можно рассчитывать на точность +-5 см где-то, что очень плохо для линейки. Которая ещё и накапливается по мере того, как пользователь отходит от «точки привязки».
Но скажем на производстве, где есть возможность раскидать свой трекинг и приклеить к телефону свой датчик (ну либо засунуть его в красивый чехол, не суть как его крепить) — это вполне реально. Особенно если нужна точность в пределах +- 5 см.
Аркит едет через каждые 50 метров, и у него много проблем. Но если есть точки рекалибровки, и нужно просто выводить плашки от отпределённой точки интереса, то там тоже всё прекрасно работает. Вопрос в конкретике задачи.
Просто позицию довольно хорошо научились получать, так что это не так интересно. Если же мы говорим про оцифровку мира, то просто зависит от того, кто чем занимается. Я работаю с трекингом и разрабатываю под него софт, а не разрабатываю yet another slam.
А юзкейсов есть довольно много, просто не в b2c.
С мебелью в квартире AR логичнее, что собственно и сделала икея.
А примерка одежды — технологии пока не доросли, там очень много технических проблем, из-за чего даже примерка часов и колец — это технически сложно. Но вообще есть такие штуки. play.google.com/store/apps/details?id=tattoo.inkhunter&hl=en_US для тату. Для часов или типа того на память не вспомню.
Но вот примерить платье — это сложно. Помимо того, что оцифровка платья качественная с ригом стоит дорого, так ещё нужно получить скелет пользователя. Можно попробовать таким, но это не мобилка, а десктоп github.com/CMU-Perceptual-Computing-Lab/openpose
Но скажем из забавных штук можно глянуть Porsсhe Car Visualizer, кейс от икеи и artefact собственно. Если говорить про маркерный AR или трекинг.
Так то есть ещё огромный пласт типа дипфейков, масок и прочего. И AR в данном контексте применяется достаточно часто. Хотя тут правильнее сказать технологии компьютерного зрения, но они часто идут рука об руку с AR.
Но если брать корпоративное обучение, b2b кейсы и так далее, есть много применимых историй, в которых эффективность оправдана. А неудобства и т.п. незначительны.
А если речь про AR — там вопрос не совсем в знании API. Основная фишка в знании AR — это знание UX. Да, безусловно, есть куча кейсов, где можно применять достаточно прикольно. Навигация, экскурсии, мне например очень нравится артефакт из Российских, чтобы узнавать интересные детали про картины и искусство. Но в целом многие считают мобильный AR костылём, а хорошие b2c AR очки пока не пришли на рынок.
Что в AR, что в VR если мы говорим про разрабов. Я бы считал технически самым важным понимание принципов рендера (так как ресурсов дано не так много), разных техник оптимизации и математики хотя бы на уровне линала, чтобы делать что-то интересное и полезное. Скажем навигация по своей сути сводится к технологии трекинга + умению преобразовывать одну систему координат в другую. И если уж линейный перенос позиции ни у кого слава богу вопросов не вызывает. То вот допустим при восстановлении позиции по маркеру правильно применить матрицу поворота — то с этим возникают трудности.
Большой процесс — это в основном невозможность покрыть систему автотестами нормально, поэтому усложняется процедура ревью и так далее. То есть, как можно грамотно строить стандартный процесс разработки. У нас есть софт (игра, не игра не так важно) Есть команда разработки. Допустим она больше 5-7 человек (иначе это всё не имеет смысла). Люди разного уровня. Что мы хотим от софта? Чтобы его просто было обновлять, чтобы он не ломался от каждого чиха, не тормозил и в целом легко доставлять его пользователям, так же как и обновления. Мы для этого берём кубер (если есть бек), тимсити и прочие прелести жизни. Зачем нам нужно покрытие автотестами? Чтобы когда разработка делает очередной пуш и отправляет всё в CI&CD систему, мы сразу отсекали те коммиты, которые не проходят тесты и говорили «это в мастер вливать нельзя». Что позволяет нам получать не забагованную херню, где постоянно что-то вылезает, а стабильные сборки. Дальше всё зависит от прокрытия и прочего. Это возможно не во всех играх делать хорошо, но в VR с этим в разы хуже.
А теперь пройдёмся по маленькому процессу. У нас 1-3 разработчика, так что CI&CD система не особо то и нужна, так как вряд ли проект будет супер комплексным. Как у нас выглядит итерация тестирования механики?
Дизайн
Мы создали новую интерфейсную панель, сверстали, посмотрели прям в движке в разных разрешениях и знаем, как она будет отображаться на разных устройствах. Если же мы не знаем дизайн правила по размеру шрифтов и элементов. Берём figma и открываем прототип, и прокликиваем на телефоне без всяких сборок. Чисто из figma.
Что же у нас будет в VR? По хорошему, для качества — сборка в билд, открыть панель и посмотреть. Как она смотрится в окружении, на каком расстоянии её включать в зависимости от того, с какого расстояния читаются скрипты, а на каком мы переходим к minify view. Так же не рябят ли контуры, кнопки и прочее на нашем целевом устройстве.
Механики
Все, даже физические механики в обычных играх это достаточно ограниченное число векторов скорости и скаляров. Потому что управляем мы всем с помощью дискретных сигналов. Поэтому это можно тестировать даже не проходя игру, но пройти уровень можно и движке. При этом не вставая со стула и т.п.
Казалось бы мелочь, бытовая вещь. Но замерь сколько времени тратится на то, чтобы тоже самое сделать в VR. А с компа это сделать нельзя с симуляцией, так как нереально сделать адекватную симуляцию из-за слишком большого числа решений.
И в VR очень много физических механик. Ещё надо учитывать что вообще у пользователей разный рост, разная длинна рук и анатомические параметры. По этой причине то, что тебе удобно в шлеме, другому человеку будет неудобно. Скажем ты баскетболист два метра, а играет девочка 1.5 метра ростом. Она тупо увидит всё иначе. И может не дотянуться, если ты поместил что-то на верх на расстояния вытянутой руки. При разработке hl2 — тебе даже думать про это не надо. А в аликсе думаю это выверено.
И можно продолжать очень долго и написать отдельную статью по нормальному UX в VR. Я видел одну неплохую на хабре, но там мало внимания посвящено тому, что анатомия у человека разная. Есть комфортные наклоны шеи, есть некомфортные и так далее.
Но если брать примеры одного масштаба — они проще без VR. И это обусловлено даже простым тезисом. Инпутом. Инпут в играх — это сигналы клавиш по сути, в мобилках тоже обычно всё ограничено кнопками.
Инпут в 6DoF VR — это 3 точки, которые могут вести себя произвольно + сигналы. И нужно их обрабатывать. То есть спектр возможных случаев в разы больше.
Плюс в обычных играх можно ограничивать игрока, как тебе хочется. В VR так нельзя, потому что будет укачивать или дизориентировать пользователя или ещё что-то произойдёт.
Ну, а отдельный новый процесс — тестируем шрифты на читаемость и графику на то, как она рябит на расстояниях — отдельный сорт удовольствия)
Вопрос именно в сравнении. А дальше либо нравится, либо не нравится)
В случае 3д — это коробка с доступными сигналами. А в случае VR — это комплексный физический объект. И он объективно сложнее.