2013-04-15 2 views
2

Итак, я пытаюсь изучить OpenGL 2.0 на Android, я действительно играл в OpenGL 1 на iOS и очень наслаждался этим.Android: OpenGL 2.0 камера первого лица

Мой простой вопрос о камере и создания 3D среды, в которой вы можете передвигаться (Первый человек)

Должен ли я использовать

Matrix.setLookAtM(mViewMatrix, 0, eyeX, eyeY, eyeZ, lookX, lookY, lookZ, upX, upY, upZ); 

управлять камерой и где я нахожусь в мир (обновлено onDrawFrame), или установив, что на onSurfaceCreated (один раз) и с помощью

Matrix.setIdentityM(mViewMatrix, 0); 
Matrix.translateM(mViewMatrix, 0, mMoveY, 0.0f, mMoveX); 
Matrix.rotateM(mViewMatrix, 0, mDeltaY, 1.0f, 0.0f, 0.0f); 
Matrix.rotateM(mViewMatrix, 0, mDeltaX, 0.0f, 1.0f, 0.0f); 

вместо который чувствует, как я вращающаяся мир вокруг меня.

Я видел примеры, когда они делают либо, на OpenGL 1 я использовал для использования GLLookAt

+1

Используйте тот, который дает правильные результаты, очевидно. Оба могут использоваться, поскольку 'setLookAt' является просто более высокой абстракцией над переводами и вращениями. –

+0

Используйте тот, который лучше всего подходит вам и вашему прецеденту. В OpenGL все, что вы делаете, вращает мир вокруг вас, в действительности нет камеры (и тем более в ES 2, где в любом случае вы полностью контролируете трансформацию в шейдерах). В конце 'setLookAt' не делает ничего, кроме вычисления вращения и перевода * * мира *, таким же образом, как и в случае вызовов' translate' и 'rotate', это просто лучше (или более высокий уровень) для определенных случаев использования. Если у вас уже есть значения 'mMove' и' mDelta', второй метод кажется более простым. –

+0

Просьба объяснить мне, как выглядит то же самое, что вызвать кучу перевода и поворот вызовов методов? Часть перевода действительно не такая большая работа, но вращение должно выполнять операции sin/cos для создания матрицы вращения, а затем умножить 2 матрицы. LookAt, с другой стороны, непосредственно вставляет 3 базовых вектора и перевод в матрицу.Основными векторами являются: крест по оси X (вперед, вверх), ось Y вверх, ось Z вперед = глазное яблоко. Каждый из них представлен столбцом соответственно. Хотя я согласен, если результат тот же, используйте то, что подходит вам лучше всего. –

ответ

1

Любой из этих двух методов является штраф, так как вы можете получить те же результаты. Общая разница заключается в том, как вы хотите сохранить состояние своих объектов. Для трехмерной среды я всегда использовал бы 3 вектора для определения состояния объекта (position, forward, up) и использования модифицированной версии lookAt и modelMatrix, которая может поместить объект с теми же параметрами, что и lookAt. Поверхность этого подхода заключается в том, что вы можете напрямую размещать параметры в зависимости от другого объекта, например: управляемая ракета следит за вами и всегда поворачивается к вам без матера, где вы находитесь и как вы двигаетесь. Тогда его вектор вперед равен taregetPosition-missilePosition (обычно нормированный). С другой стороны, если вам нужно вычислить углы, у вас есть довольно некоторая работа, непосредственно asin, acos и несколько операторов if для каждого из двух углов. Далее, например, просто перемещайтесь по комнате, идите вперед: если вы используете базовые векторы, то position = position+forward*speedFactor, а с углами вам снова нужно вычислить, с каким способом вы сталкиваетесь, а затем сделать то же самое ... (существует довольно много ситуаций, когда полезен)

Но есть и недостатки. Вы должны иметь свою собственную систему для перемещения и поворота этих векторов. Например, если вы хотите сказать, Повернитесь налево на 45 градусов, это будет выглядеть примерно так:

forward = (forward+cross(up,forward)*tan(45)).normalized 

и это работает только для угла в интервале (-90, 90). При повороте становится совершенно одинаковым, но вам нужно также скорректировать вектор вверх.

Поэтому, чтобы обернуть его, ЕСЛИ вы создадите все методы для работы с базовыми векторами (вращение, посмотрите, модельная матрица ...), они являются реальным методом экономии труда. Но это просто зависит от проекта, который вы пишете, чтобы решить, что использовать.

+0

Я думаю, что я понимаю, что вы говорите, идя со вторым методом, у меня есть поворот в градусах из коробки, однако мне нужно проработать мою позицию (X, Y, Z) в пространстве. Есть ли у вас какие-либо идеи о том, как я буду это делать? – Burf2000

+0

Что именно вы подразумеваете под этим? –

+0

Итак, если вы используете rotateM, то вы знаете вращение игроков, как вы его установили, однако вы не знаете, где это место в пространстве, потому что вы используете translateM и rotateM вместе. Например, поверните на 45 градусов, а затем двигайтесь вперед на 1 шаг, как бы вы знали свои x, y, z pos – Burf2000

Смежные вопросы