#aframe #argon
#aframe #argon
Вопрос:
Я хотел бы создать программу рисования GPS в Argon и A-Frame, которая рисует линии на основе движений людей.
Линии могут быть нарисованы в A-Frame, например, с помощью компонента meshline, который использует декартовы точки:
<a-entity meshline="lineWidth: 20; path: -2 -1 0, 0 -2 0</a-entity>
Если бы я должен был сделать это с помощью устройства GPS, я бы взял координаты GPS и сопоставил их непосредственно с чем-то вроде Google maps. Есть ли у Argon какие-либо аналогичные функции, чтобы я мог использовать координаты GPS непосредственно в качестве пути, например:
<a-entity meshline="lineWidth: 20; path: 37.32299 -122.04185 0, 37.32298 -122.03224</a-entity>
Поскольку можно указать точку LLA для системы отсчета, я полагаю, что одним из способов сделать это было бы представить центральную точку LLA как «0, 0, 0», а затем использовать функцию для сопоставления домена LLA с декартовым диапазоном.
Однако было бы предпочтительнее использовать географические координаты напрямую. Возможно ли это в Argon?
Ответ №1:
Чтобы понять ответ, вам нужно сначала понять различные системы отсчета, используемые Argon.
Во-первых, Argon использует cesiumjs.org это геопространственные математические библиотеки и объекты, так что все «местоположения» в Argon должны быть либо выражены геопространственно, ЛИБО относиться к геопространственному объекту. Они имеют корни в центре земли, в том, что Цезий называет FIXED
координатами, но также известны как координаты ECEF или ECF. В этой системе координаты указаны в метрах, вверх / вниз проходят через полюса, восток / запад проходят через меридиан (я полагаю). Любая точка на поверхности земли представлена довольно большими числами.
Эта система координат хороша тем, что мы можем точно представить что-либо на земле или вблизи нее, используя ее. Cesium также поддерживает INERTIAL
координаты, которые используются для представления объектов на околоземной орбите, и может преобразовываться между двумя кадрами.
Но это неудобно при выполнении AR по нескольким причинам:
- числа, используемые для представления положения наблюдателя и объектов рядом с ними, довольно велики, даже если они находятся очень близко, что может привести к проблемам с математической точностью, особенно в системе 3D-графики.
- Координаты, о которых мы «думаем» , когда думаем об окружающем нас мире , имеют основание как «плоское» и указывают «вверх» … ну, вставай. Итак, в 3D-графике объект над другим объектом обычно имеет те же значения X и Z, но имеет значение Y, которое больше. В координатах ECEF все числа меняются, потому что то, что мы воспринимаем как «вверх», на самом деле является вектором от центра земли через нас, и только «вверх», если мы находимся на северном (или южном, в зависимости от вашего / -) полюса. Большинство библиотек 3D-графики, которые вы, возможно, захотите использовать (например, библиотеки физики, например), предполагают мир, в котором земля представляет собой одну плоскость (обычно плоскость XZ), а Y — вверх (некоторые аэронавтические и другие инженерные приложения используют Z как up и имеют XY в качестве основания, но проблемато же самое).
Argon решает эту проблему, как и многие геопространственные системы дополненной реальности, создавая локальную систему координат для использования графикой и приложением. На самом деле для этого есть три варианта:
- Выберите какое-нибудь произвольное (но фиксированное) локальное место в качестве источника. В некоторых системах, которые созданы для работы в одном месте, это жестко запрограммировано. Другие позволяют приложению устанавливать его. Мы не делаем этого, потому что это побудило бы приложения идти по легкому пути и работать только в одном месте (мы видели это в прошлом).
- Установите локальное место для камеры. Это имеет то преимущество, что математика является наиболее «точной», потому что все точки выражены относительно камеры. Но это вызывает две проблемы. Во-первых, камера имеет тенденцию непрерывно перемещаться (даже если только из-за шума датчика) в приложениях дополненной реальности. Во-вторых, многие библиотеки (опять же, как библиотеки физики) предполагают, что источник системы стабилен и находится на земле, а камера / пользователь перемещается по нему. Эти проблемы можно обойти, но они утомительны для разработчиков приложений.
- Установите начало координат локальных координат в произвольное местоположение рядом с пользователем, и если пользователь переместится далеко от него, повторите центрирование автоматически. Преимущество этого в том, что программе не обязательно много делать, чтобы справиться с этим, и она хорошо сочетается с библиотеками 3D-графики. Недостатком является то, что локальные координаты произвольны и могут отличаться при каждом запуске программы. Однако разработчику приложения, возможно, придется обратить внимание на то, когда источник повторно центрируется.
Аргон использует open 3. Когда приложение запускается, мы создаем новую локальную систему координат в местоположении пользователя, в плоскости, касательной к земле. Если пользователь перемещается далеко от этого местоположения, мы обновляем источник и отправляем событие в приложение (в настоящее время мы повторно центрируем, если вы находитесь в 5 км от источника). Во многих простых приложениях, где только несколько кадров или ссылок выражаются в геопространственных координатах (а остальные данные приложения выражаются относительно известных геопространственных местоположений), преобразование из геопространственного в локальное может выполняться только в каждом кадре, что позволяет разработчику приложения игнорировать проблему повторного входа. Программист может свободно использовать либо ENU (восток-север-вверх), либо EUS (восток-юг-юг) в качестве своей системы координат; мы склонны использовать EUS, потому что это похоже на то, что использует большинство систем 3D-графики (Y — вверх, Z указывает на юг, а X — на восток).
Одна из причин, по которой мы выбрали этот подход, заключается в том, что в прошлом мы обнаружили, что если бы у нас были предсказуемые локальные координаты, разработчики приложений хранили бы данные с использованием этих координат, даже если это не очень хорошая идея (ваши данные теперь привязаны к некоторой относительно произвольной системе координат, зависящей от конкретного приложения, и теперь будут использоваться толькоработайте в этом месте).
Итак, теперь к вашему вопросу. Ваша проблема в том, что вы хотите использовать геопространственные (координаты цезия, которые использует argon) координаты в AFrame. Короткий ответ: вы не можете использовать их напрямую, поскольку AFrame построен с учетом локальной системы координат 3D-графики. Пакет argon-aframe связывает aframe с argon, позволяя вам указывать referenceframe
компоненты, которые позиционируют a-объект в геопространственном местоположении argon / cesium, и позаботиться обо всех внутренних преобразованиях для вас.
При написании этого кода предполагалось, что авторы затем создадут свой контент, используя локальные 3D-графические координаты, и прикрепят эти фрагменты графики к объектам a, которые были расположены в мире с referenceframe
помощью ‘s .
Чтобы отдельные координаты в AFrame соответствовали геопространственным местам, вам нужно будет управлять этим самостоятельно, возможно, путем создания компонента, который сделает это за вас, или (если данные известны в начале) путем их предварительного преобразования.
Вот что я бы сделал.
Предполагая, что у вас есть список геопространственных координат (выраженных как LLA), я бы преобразовал каждую из них в локальные координаты (сначала преобразовав из LLA в ФИКСИРОВАННЫЕ ECEF-координаты Cesium и создав объект Cesium, а затем вызвав Argon context.getEntityPose()
для этого объекта (который вернет его локальные координаты). Я бы выбрал одно геопространственное местоположение в наборе (возможно, первое?), А Затем вычел его локальные координаты из каждого из них, чтобы все они были выражены в локальных координатах относительно этого известного геопространственного местоположения.
Затем я бы создал объект AFrame, прикрепленный к referenceframe этого уникального геопространственного объекта, и создал бы ваш графический контент внутри него, используя локальные координаты, которые выражены относительно него. Например, допустим, геопространственное местоположение LongLat = "-84.398881 33.778463"
и вы сохранили эти точки (локальные координаты относительно LongLat
) userPath
, вы могли бы сделать что-то вроде этого:
<ar-scene>
<ar-geopose id="GT" lla=" -84.398881 33.778463" userotation="false">
<a-entity meshline="lineWidth: 20; path: userPath; color: #E20049"></a-entity>
</ar-geopose>
</ar-scene>
Комментарии:
1. Кстати, если бы я собирался реализовать это прямо сейчас, я думаю, я бы создал компонент с именем «llapath», который принимает два параметра: путь к LLAS и имя компонента (текст, например, «meshline»). Он преобразует свой список LLA в список локальных координат относительно текущего начала координат, а затем устанавливает свойство «path» именованного компонента. Конечно, нужно было бы обработать некоторые «детали»: если над ним в иерархии есть опорный фрейм или действительно какие-либо узлы над ним в иерархии, ему нужно будет соответствующим образом преобразовать точки на пути (уродливо!).).
2. Или, возможно, поскольку это так просто, я бы просто взял код для meshline и обновил его, чтобы создать «llameshline». Если вы хотите быть супер простым, просто заставьте его находиться в верхней части сцены, чтобы вам не нужно было беспокоиться о вложенных преобразованиях.
3. Спасибо! На самом деле мы немного обсуждали это сегодня. Я думаю, поскольку в конечном итоге у меня будет много строк, и их не нужно визуализировать в реальном времени, я мог бы сначала выполнить преобразование на стороне сервера и использовать компонент шаблонов для перебора их и отправки.
4. На самом деле, может быть, и нет. Я забыл ar-referenceframe.js предназначен для работы в Интернете. Само по себе это не нарушает условия сделки, но, безусловно, усложняет. Я буду держать вас в курсе.
5. Извините за этот комментарий, но не могли бы вы помочь мне с тем, как я могу реализовать компонент <ar-geopose> .