Мне то нет никакого смысла его продавать. Я в эпле не работаю, и только рад, когда мне заказывают что-то без 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 — это комплексный физический объект. И он объективно сложнее.
Навмеш может забрать зоны, которые недоступны должны быть. Поэтому нужно размечать. И в зависимости от геометрии уровня, их не всегда можно отсечь тупо по дистанции телепортации.
На тему инвентаря, видимо у вас нет сохранения инвентаря. Так как если оно есть, то предмет должен храниться в виде идентификатора и параметров. Поэтому данные отделяются от кода. Вы же не можете сохранить весь мир целиком и его состояние. Поэтому инвентарь и делается абстракцией, которую легко сериализовать.
У меня сетап 1080 TI, i7-8700к, 32 гига оперативы корсаровской и 2тб ssd, вайв, окулус го. Работать то в этом плане очень удобно, но собирал я его довольно долго. И главное, всё познаётся в сравнении. VR проектов я за это время разного масштаба сделал в районе 10. И прикол именно в том, что сейчас у меня много проектов с бекендом, неиронками, OpenCV на бекенде и их разрабатывать именно удобнее.
Нет в целом ничего невозможного, вопрос в том какая работа именно комфортная. А дальше уже что больше нравится. Когда можно целиком всё покрыть тестами, даже в CI&CD систему их впилить — это в разы удобнее. Нежели когда нужно каждый раз прогонять руками, так как задача слишком комплексная для тестирования.
По поводу видеокарты. 1050TI соглашусь. На 650 свет печься на более менее вменяемой сцене будет вечность. Я пытался работать на 950М, это адекватной работой трудно назвать. Но в целом может быть и можно.
По поводу инвентаря. Да это всё равно придётся делать, если идти по адекватному солиду. Так как данные должны быть отделены от визуализации и состояния по хорошему. Если нужна гибкость. Так что тут я не соглашусь. Даже в аликс если брать, разные состояния разных объектов. То же радио в самом начале с вытаскивающейся антенной — это гемор. И там много таких вещей. Грамотное ограничение телепортации — это не навмеш настроить, там нужно ещё руками размечать. Можно придумать простой кейс. Но сопоставимый по количеству функционала просто в 3д будет проще в разы. Так как там проще вводить ограничения, которые необходимы.
Оборудование заказчика обладает одной проблемой. Нужно постоянно учиться, тестировать новое и так далее, чтобы выдавать качество. Если оборудование лежит чётко на проект, то после проекта экспериментировать уже не с чем. Поэтому я просто с первых контрактов купил всё оборудование и до сих пор докупаю всякое.
И я не вижу ничего плохого в том, чтобы в комментариях исправлялись неточности, которые появились в ходе изучения, либо неправильных материалов, либо неправильного восприятия материала. Это и мне, и аудитории полезно.
Про то, в чём я себя чувствую неуверенно, я и не собираюсь углубляться. Но учитывая сколько задач мы решаем шейдерами почти каждый день, есть много вещей которые можно делать чисто на уровне практики. Почему-то те, кто во всём разбираются, пишут сразу статьи про какой-то космос. А не практические статьи для новичков, которым тоже надо учиться, как даже банальный dissolve просто написать (хз, что придумать даже проще). Можете посмотреть мою серию по математике. Мои статьи — это в большинстве своём простая практика с примерами. Так как это основное, что нужно новичкам. А не «как сделать физичную верёвку с помощью FEM». Или любой другой сложной математической модели, где нужно знать диффуры достаточно хорошо, чтобы вкурить, что происходит. Я только за, чтобы люди делились экспертизой и исправляли неточности источников, так как я сам опираюсь на какие-то. Но почему-то большинство специалистов этого не делает :)
На тему уже написано. Каждый пишет своим языком, и каждый вопринимает информацию по своему. Я пока встречаю больше страха шейдеров, чем «да это просто нужно прочитать X, Y, Z» с точки зрения найма сотдрудников.
декартовым
Про координаты я говорил именно про картезианские. Так как решал такую задачу, когда мне нужно было морфировать вертексы плейна, чтобы получить картографическую проекцию. Собственно я пробовал разные способы.
Зависит от графического апи и оборудования. Забудем про как минимум три случая (и это тоже зависит от графического апи, так как на OpenGL ES 2.0 всё прям грустно), когда стоимость — это просто условие. То что выше, это условное упрощение, чуть лучше чем «выполняются обе ветки ифа», на мой взгляд. tangentvector.wordpress.com/2013/04/12/a-digression-on-divergence
То как оно себя конкретно поведёт и упростится на этапе компиляции — зависит от компилятора и графического апи. Новый волновой фронт понятное дело не создастся во время исполнения, а это всё будет решено на этапе компиляции. Но это доп. исполнение и доп. копия данных. Может в этом я конечно ошибаюсь, так как я опираюсь на то, что я изучал. Если можете объяснить на пальцах по простому, как оно работает в комментарии, было бы круто.
Условная игра в этом плане в разы приятнее разработки 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 — это комплексный физический объект. И он объективно сложнее.
На тему инвентаря, видимо у вас нет сохранения инвентаря. Так как если оно есть, то предмет должен храниться в виде идентификатора и параметров. Поэтому данные отделяются от кода. Вы же не можете сохранить весь мир целиком и его состояние. Поэтому инвентарь и делается абстракцией, которую легко сериализовать.
У меня сетап 1080 TI, i7-8700к, 32 гига оперативы корсаровской и 2тб ssd, вайв, окулус го. Работать то в этом плане очень удобно, но собирал я его довольно долго. И главное, всё познаётся в сравнении. VR проектов я за это время разного масштаба сделал в районе 10. И прикол именно в том, что сейчас у меня много проектов с бекендом, неиронками, OpenCV на бекенде и их разрабатывать именно удобнее.
Нет в целом ничего невозможного, вопрос в том какая работа именно комфортная. А дальше уже что больше нравится. Когда можно целиком всё покрыть тестами, даже в CI&CD систему их впилить — это в разы удобнее. Нежели когда нужно каждый раз прогонять руками, так как задача слишком комплексная для тестирования.
По поводу инвентаря. Да это всё равно придётся делать, если идти по адекватному солиду. Так как данные должны быть отделены от визуализации и состояния по хорошему. Если нужна гибкость. Так что тут я не соглашусь. Даже в аликс если брать, разные состояния разных объектов. То же радио в самом начале с вытаскивающейся антенной — это гемор. И там много таких вещей. Грамотное ограничение телепортации — это не навмеш настроить, там нужно ещё руками размечать. Можно придумать простой кейс. Но сопоставимый по количеству функционала просто в 3д будет проще в разы. Так как там проще вводить ограничения, которые необходимы.
Оборудование заказчика обладает одной проблемой. Нужно постоянно учиться, тестировать новое и так далее, чтобы выдавать качество. Если оборудование лежит чётко на проект, то после проекта экспериментировать уже не с чем. Поэтому я просто с первых контрактов купил всё оборудование и до сих пор докупаю всякое.
Не волновой фронт, а то как поведёт себя if. Но может хватит выпендриваться, и объясните на пальцах, если знаете объяснение лучше? :)
Про то, в чём я себя чувствую неуверенно, я и не собираюсь углубляться. Но учитывая сколько задач мы решаем шейдерами почти каждый день, есть много вещей которые можно делать чисто на уровне практики. Почему-то те, кто во всём разбираются, пишут сразу статьи про какой-то космос. А не практические статьи для новичков, которым тоже надо учиться, как даже банальный dissolve просто написать (хз, что придумать даже проще). Можете посмотреть мою серию по математике. Мои статьи — это в большинстве своём простая практика с примерами. Так как это основное, что нужно новичкам. А не «как сделать физичную верёвку с помощью FEM». Или любой другой сложной математической модели, где нужно знать диффуры достаточно хорошо, чтобы вкурить, что происходит. Я только за, чтобы люди делились экспертизой и исправляли неточности источников, так как я сам опираюсь на какие-то. Но почему-то большинство специалистов этого не делает :)
На тему уже написано. Каждый пишет своим языком, и каждый вопринимает информацию по своему. Я пока встречаю больше страха шейдеров, чем «да это просто нужно прочитать X, Y, Z» с точки зрения найма сотдрудников.
Про координаты я говорил именно про картезианские. Так как решал такую задачу, когда мне нужно было морфировать вертексы плейна, чтобы получить картографическую проекцию. Собственно я пробовал разные способы.
То как оно себя конкретно поведёт и упростится на этапе компиляции — зависит от компилятора и графического апи. Новый волновой фронт понятное дело не создастся во время исполнения, а это всё будет решено на этапе компиляции. Но это доп. исполнение и доп. копия данных. Может в этом я конечно ошибаюсь, так как я опираюсь на то, что я изучал. Если можете объяснить на пальцах по простому, как оно работает в комментарии, было бы круто.