2010-09-04 2 views
0

Comme je l'ai compris, il est recommandé d'utiliser glTranslate/glototate en faveur de glutLootAt. Je ne vais pas chercher les raisons au-delà du mode de calcul évident HW vs SW, mais juste aller avec la vague. Cependant, cela me donne des maux de tête car je ne sais pas exactement comment arrêter efficacement la caméra de percer les murs. Je ne suis intéressé que par les intersections de plans de points, pas par les AABB ou quoi que ce soit d'autre. Donc, en utilisant glTranslates et glRotates signifie que le point de vue reste immobile (à (0,0,0) pour plus de simplicité) pendant que le monde tourne autour d'elle. Cela signifie pour moi que pour vérifier tous les points d'intersection, je dois maintenant recalculer les coordonnées des sommets du monde (ce qui n'était pas nécessaire avec l'approche glutLookAt) pour chaque mouvement de caméra. Comme il n'est pas possible d'obtenir les nouvelles coordonnées nécessaires à partir du GPU-land, elles doivent être calculées manuellement dans la CPU. Pour chaque mouvement de caméra ... :(collision ponctuelle sans les fonctions glutLookAt *

Il semble qu'il y ait la nécessité de maintenir les rotations actuelles de côté chacune des 3 axises et même pour les traductions Il n'y a pas mise à l'échelle utilisée dans mon programme Mes questions:..

1 - est le raisonnement ci-dessus imparfait Comment 2 -?. sinon, il doit y avoir un moyen d'éviter ces recalculs la façon dont je le vois (et en regardant http://www.glprogramming.com/red/appendixf.html) dont il a besoin multiplication d'une matrice pour les traductions et un autre pour la rotation (seulement en dehors de l'axe Y nécessaire) Cependant, devoir calculer autant d'additions/multiplications et surtout le sinus/cosinus sera certainement tuer FPS Il y aura des milliers ou même des dizaines de milliers de sommets ute sur. Chaque image ... toutes les maths ... Après avoir calculé les nouvelles coordonnées du monde, les choses semblent très faciles - voyez s'il y a un avion qui a changé son signe 'd' (de l'équation des plans ax + par + cz + d = 0). Si c'est le cas, utilisez une approche de produits croisés légers pour tester si le point est à l'intérieur de l'espace à l'intérieur de chaque triangle «en mouvement» de ce plan.

Merci

modifier: Je l'ai trouvé à propos glGet et je pense qu'il est le chemin à parcourir, mais je ne sais pas comment utiliser correctement:

// Retains the current modelview matrix 
//glPushMatrix(); 
glGetFloatv(GL_MODELVIEW_MATRIX, m_vt16CurrentMatrixVerts); 
//glPopMatrix(); 

m_vt16CurrentMatrixVerts est un flotteur [16] qui est rempli avec 0.f ou 8.67453e-13 ou quelque chose de similaire. Où suis-je en train de baiser?

+0

C'est gluLookAt, pas glutLookAt, et je ne sais pas ce que vous voulez dire à propos de HW vs SW, tous les calculs de matrice OpenGL sont effectués sur le CPU. – mk12

Répondre

2

gluLookAt est une fonction très pratique sans aucune pénalité de performance. Il n'y a aucune raison de ne pas l'utiliser, et, surtout, aucune considération "HW vs SW" à ce sujet. Comme Mk12 l'a indiqué, glRotatef est également fait sur le CPU. La partie GPU est: gl_Position = ProjectionMatrix x ViewMatrix x ModelMatrix x VertexPosition.

« en utilisant glTranslates et glRotates signifie que le point de vue reste toujours » -> même chose pour gluLookAt

« à (0,0,0) pour la simplicité » -> pas pour la simplicité, il est un fait. Cependant, ceci (0,0,0) est dans le système de coordonnées de la caméra. Cela a du sens: par rapport à l'appareil photo, l'appareil photo est à l'origine ...

Maintenant, si vous voulez empêcher l'appareil photo de traverser les murs, la méthode habituelle consiste à tracer un rayon depuis l'appareil photo. Je soupçonne que c'est de cela que vous parlez («pour vérifier les points d'intersection»). Mais il n'y a pas besoin de faire cela dans l'espace de la caméra. Vous pouvez le faire dans l'espace du monde. Voici une comparaison:

  • rayons Tracing dans l'espace de la caméra: ray commence toujours par (0,0,0) et va à (0,0, -1).Traçage de l'espace du monde: le rayon commence à partir de la position de la caméra (dans l'espace du monde) et va jusqu'à (eyeCenter - eyePos). normaliser(). La géométrie doit être transformée de l'espace du modèle à l'espace du monde. Notez qu'il n'y a pas de troisième option (Rayons de traçage dans l'espace Modèle) qui éviterait de transformer la géométrie de l'espace Modèle en Espace Monde. Tout d'abord, le monde de votre jeu est probablement encore: la matrice du modèle est probablement toujours l'identité. Transformer sa géométrie du modèle à l'espace mondial équivaut à ne rien faire du tout.
  • Deuxièmement, pour tous les autres objets, vous pouvez prendre l'approche inverse. Au lieu de transformer toute la géométrie dans une direction, ne transformez que le rayon dans l'autre sens: prenez la matrice de votre modèle, inversez-la, et vous avez une matrice qui va de l'espace du monde à l'espace modèle. Multipliez l'origine et la direction de votre rayon par cette matrice: votre rayon est maintenant dans l'espace modèle. Intersection de la manière normale. Terminé.

Notez que tout ce que j'ai dit est des techniques standard. Pas de hacks ou d'autres choses bizarres, juste des maths :)

+0

errr, je pense que je vais devoir saisir cette réponse. Je serai de retour après le week-end – kellogs

Questions connexes