Camara En Opengl

[marcode]

 si sabes el punto donde está la cámara, y el punto al que quieres mirar, no necesitas nada más para usar gluLookAt, el vector up por lo general será 0,1,0.

[angelfmarcos]

 Fallaba al ponerme en la posicion (20, 0, 0) y mirar hacia el centro. giraba sobre el eje Y para orientarme hacia el centro y eso lo hacia bien, pero luego el girar sobre el eje Z o X daba el mismo resultado, girando siempre sobre el mismo eje.

El código que estoy usando es

Código [Seleccionar] Expand


Quaternion ra, rb, rc, r;
Matrix m;
ra.EulerToQuat (ang_a, 0, 0);
rb.EulerToQuat (0, ang_b, 0);
rc.EulerToQuat (0, 0, ang_c);
r = r * rc;
r = r * rb;
r = r * ra;
r.GetMatrix (m);
float m_vals[16];
m.GetValues (m_vals);
glMultMatrixf (m_vals);
glTranslatef (-pos_x, -pos_y, -pos_z);


donde ang_a, ang_b y ang_c son la orientacion de la camara.


El problema de localizar asi el objeto es que necesito en todo momento saber los ángulo de orientación de la cámara. Además debo o acercarme para que se muestre completo en pantalla. Tambíen pensaba hacer la localización por densidad de puntos y no por el centro del objeto (pero bueno, eso para otra version xD)

[tamat]

 Creo que sigues sin comprender el concepto de rotación tridimensional.

Te equivocas al seguir guardando los tres angulos por separado en floats y luego hacer tres rotaciones hasta tener la rotacion deseada, no es esa la idea.

Un quaternion es ya de por sí una rotación que contempla los tres ejes y por lo tanto es ese el unico dato que tienes que guardar, ese y nada más. Si luego durante el transcurso de tu aplicación quieres alterar esa rotación (por ejemplo el usuario quiere rotar haciendo roll sobre su propio eje Z) pues construyes el quaternion que rota en Z y lo multiplicas por el quaternion de la rotación de tu camara que ya tienes, el resultado será la rotación de la camara una vez aplicada la rotación.

Lo que tu haces es simplemente usar los quaterniones para aplicar tres rotaciones por separado, exactamente lo mismo que si haces tres glRotates, solo que ahora en lugar de hacerlo a traves del API lo haces a traves de tu codigo. No has ganado nada aunque en algunos contextos pueda parecerte que si.

Una rotación 3D tiene que contener la información necesaria para pasar de un sistema a otro sistema de coordenadas en el que solo hay un cambio de orientación. No necesitas las famosas tres variables porque estas modelan algo que el quaternion ya tiene (y para colmo no lo hacen del todo bien).

El sistema debería ser:
- Mi camara tiene un quaternion que me indica como se ha de rotar todo el sistema.
- Si en algun momento mi camara cambia de rotación le aplico unicamente esa rotación a mi camara, ninguna más. Normalmente cualquier acción del usuario se puede resolver con una unica rotación, obviamente puedes aplicar muchas sucesivas pero eso sería si realmente se han producido varias acciones que impliquen rotaciones en diferentes ejes.
- No puedo tener directamente el angulo de pitch, roll o yaw porque estos valores son conceptos de percepción personal sobre las rotaciones, pero puedo aplicar trigonometria basica para obtener esos angulos si se el vector FRONT o el vector UP, que los puedo sacar facilmente de mi quaternion.

Estas pecando en lo mismo que pequé yo en su momento y que me llevó a perder un mes de desarrollo de mi juego de naves espaciales.

Lo que me llevó a ver la luz fué que me di cuenta de que es imposible guardar la rotación como tres angulos ya que no es lo mismo rotar 90 grados en Z y luego 90 en Y que rotar 90 en Y y luego 90 en Z. El resultado cambia.

[angelfmarcos]

 Tambien lo había hecho asi. Y la navegación iba perfectamente, pero luego no sabía obtener la orientacion ni posicionar la camara con una orientacion concreta como punto de partida.

La aplicacion que estoy desarrollando es un editor de escenarios en el que vamos añadiendo primitivas, etc.. bastante sencillote, pero una de las cosas que debe poder hacer es manejar la camara mediante la posicion y la orientacion, para poder guardarlo en un fichero y recuperarlo posteriormente.

Estoy pensando que si en lugar de estos 3 valores guardo el x,y,z,w del quaternion podria volver a restaurar la camara sin problemas ¿es correcto?

[tamat]

 Es correcto, sino mal contenedor de rotaciones sería.

Cualquier operacion que quieras para camaras seguro que la encuentras con quaterniones, yo de hecho para serte sincero no se como funcionan internamente los quaterniones, me limité a buscar una implementación y los metodos que no tenía los saqué tambien de internet.

[killrazor]

 A ver, por partes. Es ineficiente por que todo el trabajo lo mandamos a la tarjeta mientras que con cuaterniones o camaras basadas en Euler la matriz la obtenemos directamente de un calculo hecho por el procesador, mucho mas eficiente y rapido. El quaternion hay que comprenderlo para saberle sacar el juguillo. La idea es que en general "volamos" con la camara asi que al final usamos los angulos tipicos de un avion (headin, pitch y roll). Eso implica los movimientos de los tres ejes. Con las camaras basadas en angulos Euler puedes tener un problema de gimbal lock y eso me hizo definitivamente decidirme por los quaterniones, pero eso es otra historia. Ademas es mas eficiente por que solo calculas una vez la matriz. Realmente juntar varias rotaciones es tan facil como multiplicar vectores. Eso lo hace un metodo muy potente, y lo unico que mandamos a la targeta es la matriz de rotacion.

Con cuaterniones lo unico que has de hacer para posicionar la camara es decidir donde miras, y el vector de la direccion a la que quieres mirar. Asi que no es dificil....

[ethernet]

A ver, por partes. Es ineficiente por que todo el trabajo lo mandamos a la tarjeta mientras que con cuaterniones o camaras basadas en Euler la matriz la obtenemos directamente de un calculo hecho por el procesador, mucho mas eficiente y rapido.

Umh? gluLookAt se calcula en CPU al igual que si tu lo haces con quaternion. Siguiendo tu política es mejor que calculemos las rotaciones, la iluminación, el blend e incluso los shaders en la CPU que es más rápida y eficiente. En cualquiera caso lee lo que te ha dicho tamat.

Nadie ha dicho que los quaternions sean fáciles o difíciles, pero para un desarrollo normal con gluLookAt es muchísimo más que suficiente. Nada impide usar quaternion junto con gluLookAt en cualquier caso.

[senior wapo]

 Me da pereza buscar overengineering en wikipedia.

Si estás haciendo un editor 3D para poner entidades, lo normal no es que te muevas como en una nave espacial. Un control tipo FPS en la vista 3D es lo más común, que es la manera en que los mortales de a pie nos orientamos. ¿ Seguro que con eso no te vale ?

Con un par de operaciones de seno y coseno puedes orientar la cámara guardando sólo en ángulo de deriva (yaw) y el de cabeceo (pitch). Eso te da los vectores lookat, up y right a la hora de dibujar.

Tanto tiempo gastado en complicarse con super cámaras y al final le faltará el sistema de Undo (deshacer) :P

Edit: Si trabajas simplemente con ángulos, te basta restarle a la posición del objeto observado la de la cámara para obtener el vector lookat (normaliza...). Con un par de arcotangentes sacas los ángulos (que además te sirven para calcular los vectores up y right con sin() y cos() ).

[angelfmarcos]

 Es un control ActiveX que sirve tanto para el editor de escenarios como para poder visualizar escenas y navegar en ellas.

[josette]

Yo obtuve un codigo extraido de www.gametutorials.com en el apartado opengl pero tambien tengo algunos problemas. Alguien puede validar si esta clase funciona o si se puede adapar a lo que en este 'topic' se comenta?