OpenGL Collision Detection

Question

В настоящее время я работаю над созданием своей первой игры FPS с использованием JOGL. (Привязки Java для OpenGL).

До сих пор я мог генерировать «мир» (серия кубов) и модель игрока. У меня есть обнаружение столкновения между игроком и кубиками, отлично работающими.

Теперь я пытаюсь добавить в оружие. Я правильно рисую модели оружия и загружаю их на модель игрока. Первый пистолет, который я пытаюсь реализовать, - это лазерная пушка, которая стреляет и мгновенно лазера прямой видимости на все, на что вы нацеливаетесь. Прежде чем я буду работать над реализацией моделей противника, я хотел бы получить обнаружение столкновения между лазером и стенами.

В настоящее время мой лазер нарисован рядом маленьких кубиков один за другим. Первый куб рисуется в конце игрового пистолета, затем он непрерывно отталкивается оттуда. Идея заключалась в том, чтобы продолжать рисовать кубы лазера, пока не обнаружилось столкновение с чем-то, а именно кубиками в мире.

Я знаю расположение кубов в мире. Проблема в том, что я должен вызвать glMatrixPush для рисования моей модели персонажа. Лазер затем рисуется в этом обзоре. Это означает, что я потерял свою прежнюю систему координат - так что я рисую мир в одной системе, затем лазер в другой. Внутри этой матрицы проигрывателя я несколько раз звоню glRotate и glTranslate, чтобы синхронизировать все с тем, как поворачивается камера. Затем лазер строится путем перевода по оси z этой новой системы.

Моя проблема заключается в том, что через все эти преобразования я больше не знаю, где мой лазер существует в системе координат карты, в первую очередь из-за поворотов, связанных с камерой.

Кто-нибудь знает способ - или есть идеи, как решить эту проблему? Я считаю, что мне нужен способ конвертировать новые координаты лазера в старые координаты карты, но я не уверен, как идти о том, чтобы уничтожить все преобразования, которые были с ним сделаны. Также могут быть некоторые функции, предоставляемые OpenGL для решения таких проблем, о которых я просто не знаю.

Answer 1

Точка, которая была сделана в первом ответе, заключается в том, что вы никогда не должны зависеть от матрицы, чтобы позиционировать объект в первую очередь. Вы должны следить за положением и вращением лазера, прежде чем вы даже подумаете о его рисовании. Затем вы используете команды перевода и вращения, чтобы поместить их там, где вы знаете, что это должно быть.

Вы пытаетесь сделать что-то в обратном направлении, и да, это означает, что вам придется выполнять математическую математику, и OpenGL не отслеживает это, потому что матрица ModelView является ТОЛЬКО, что OpenGL сохраняет отслеживать позиции объекта. OpenGL не имеет понятия «пространство мира» или «пространство камеры». Существует только матрица, на которую умножается все входные данные. Это элегантно просто ... но в некоторых случаях я предпочитаю, чтобы DirectX имел отдельную матрицу представлений и модельную матрицу.

Итак, если вы не знаете, где находится объект без математической математики, то я бы рассмотрел фундаментальную проблему проектирования. Если вам нет нужно, чтобы узнать положение объекта, а затем преобразовать матрицу в содержимое вашего сердца, но если вам это нужно, начните с позиции.

(довольно много, что говорит первый ответ, просто по-другому ...)

Answer 2

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

glPushMatrix(viewMatrix); 
glPushMatrix(playerMatrix); 
DrawPlayer(); 
glPopMatrix(); 
glPushMatrix(laserMatrix); 
DrawLaser(); 
glPopMatrix(); 
glPopMatrix(); 

Кроме того, убедитесь, что вы не смешивать логику преобразования рендеринга с игровой логикой. Вы всегда должны хранить позицию мира в пространстве, чтобы иметь возможность проверять пересечения, независимо от текущего стека матрицы OpenGL.

Помните, что будьте осторожны с пространственными отношениями родителя/ребенка. На практике они не так уж часты. Для получения дополнительной информации, google о проблемах графов сцены.