Sistema De Camaras

[[Over]]

 Hola.

Me gustaria saber si tienen webs o tutoriales donde explique como hacer un sistema de camaras avanzado para cualquier API.

He visto que la gente lo hace de una manera u otra, hay quien usa matrices, otros vectores y luego el gluLookAt (el que uso yo),etc... Pero quisiera ver la mayor cantidad de sistemas posible para decantarme por el mejor que haya.

Quizas influye para el tipo de necesidad que tengas con la camara. Pero es por curiosidad.

PD: Me gustaria que ufese un sistema abstracto del API, auqnue luego al final se aplique a un API concreto, pero que todo el proceso de calculos de rotacion y demas sea abstracto.


Gracias.

[Astat]

 Para mi sin duda el mejor es el OpenProducer, sistema multiplataforma para el manejo de camaras.

Hechale un ojo en su web: http://www.andesengineering.com/Producer/

Un saludo

[JL10]

"] Hola.

Me gustaria saber si tienen webs o tutoriales donde explique como hacer un sistema de camaras avanzado para cualquier API.

He visto que la gente lo hace de una manera u otra, hay quien usa matrices, otros vectores y luego el gluLookAt (el que uso yo),etc... Pero quisiera ver la mayor cantidad de sistemas posible para decantarme por el mejor que haya.

Quizas influye para el tipo de necesidad que tengas con la camara. Pero es por curiosidad.

PD: Me gustaria que ufese un sistema abstracto del API, auqnue luego al final se aplique a un API concreto, pero que todo el proceso de calculos de rotacion y demas sea abstracto.


Gracias.

Hasta dónde has llegado con respecto a este tema. ¿Me puedes dar tu experiencia?. (Ahora, en esta fecha, tengo esta misma inquietud que la que tuviste tú hace tiempo) (gracias)

[Marci]

La mayor parte de las APIs al final lo que hacen es trabajar con matrices para crear la proyeccion, escalado, rotacion... y una camara no hace mas que automatizar varias operaciones sobre estas matrices. Para crear el sistema de camara independiente de la API no tendrias mas que leer las matrices de dicha API y pasarselos a tu sistema de camara, realizar las operaciones que quieras con estas matrices y despues volverselas a pasar a la API para que dibuje los resultados

[JL10]

Es que me dá la impresión, (estoy empezando en el tema por lo que a lo mejor estoy muy equivocado), que un sistema de cámara es más fácil de implementar que controlar los movimientos que usar un sistema de cuaterniones, que implica mucho más cálculo y complicación.

Ya sé que depende de lo que se pretenda. Voy a poner un caso habitual: la cámara que pueda estar dentro de un vehículo en movimiento como un avión acrobático. (Hago la matización de acrobático, pues quiero usar todos los grados de libertad). Creo que para esta caso es más fácil usar la función "xxxLookAt", pues facilita posición, punto de mira y orientación.

¿Qué opináis?

[JL10]

.....realizar las operaciones que quieras con estas matrices y despues volverselas a pasar a la API para que dibuje los resultados

Entonces recomiendas esta práctica. ¿Es más eficiente hacer lo de esta manera?. ¿Puede que haya menos operaciones intermedias?. Creo que permite más flexibilidad pues siempre puedes hacer alguna transformación particular. ¿es cierto?

[marcode]

Se puede hacer cargando la matriz inversa del objeto donde estará el foco de la cámara en la matriz MODELVIEW antes de renderizar la escena, en el caso de OpenGL con glLoadMatrixf.

El objeto puede ser un ojo, el parachoques de un coche, o lo que sea. También se pueden crear cualquier cámara que haga un seguimiento o algún tipo de movimiento especial o concreto, programandolo independientemente, ya sea una cámara voladora, situada en un casco, o en el cogote de alguien, todos se crean y se comportan como un objeto más, algunos serán invisibles, otros no.

Puedes hacer una clase básica Cámara que a su vez derive en más objetos, por ejemplo una cámara de vigilancia programable para que haga un giro de 90º hacia izquierda y derecha cada cierto tiempo, una que persiga a lo Tomb raider,  o puedes hacer una cámara de cine con sus raíles, su grúa, etc.

Al final la matriz de visualización será la inversa de la matriz objetivo multiplicada previamente por sus parientes asociados, que en el caso de la cámara de cine serían un soporte que permita girarla sobre su eje z, sobre una base para girarla hacia arriba y a los lados, sobre una grúa con un brazo capaz de alargarse, encogerse, subir, bajar..., sobre una base que gira en el eje de las Y, sobre unas ruedas que se desplazan hacia los lados...

De esta forma la cámara prácticamente solo es una función que define la matriz MODELVIEW a partir de la matriz de un objeto real o imaginario independiente del API.

[Marci]

Entonces recomiendas esta práctica. ¿Es más eficiente hacer lo de esta manera?. ¿Puede que haya menos operaciones intermedias?. Creo que permite más flexibilidad pues siempre puedes hacer alguna transformación particular. ¿es cierto?

Hacerla independiente de la API al final se reduce a tomar los datos de la API, procesarlos y volverselos a pasar a la API. Estos datos los puedes procesar usando matrices o quaternions y con ambos vas a conseguir el mismo resultado (rotar la camara 3D), de hecho se puede convertir una matriz en un quaternion y viceversa. Usar matrices resulta mas intuitivo pero no tiene porque ser mas rapido

[Diferencial]

Buenas aqui te dejo un link para el manejo de camaras, es el que siempre he visto yo en cuanto a sistemas camaras. (Lo he visto en varios sitios) El manejo es con vectores.

http://www.morrowland.com/apron/tut_d3d.php

Asi podras aprovechar opengl o directx.

[JL10]

...usando matrices o quaternions y con ambos vas a conseguir el mismo resultado (rotar la camara 3D), de hecho se puede convertir una matriz en un quaternion y viceversa. Usar matrices resulta mas intuitivo pero no tiene porque ser mas rapido

Probaré los dos planteamientos: con matrices y con cuaterniones. Pero si uso matrices[4x4], ¿no tendré el problema del "gimbal lock" que solventa el método de los cuaterniones?.

[Marci]

Pero si uso matrices[4x4], ¿no tendré el problema del "gimbal lock" que solventa el método de los cuaterniones?.

Yo por ahora no he tenido que pegarme con el "gimbal lock" trabajando con matrices, asi que no te puede decir mucho :( . De todas maneras puedes mirar en http://es.wikipedia.org/wiki/Rotación

[Elvis Enmanuel]

http://www.gamedev.net/reference/articles/article1199.asp

ains

[JL10]

Pero si uso matrices[4x4], ¿no tendré el problema del "gimbal lock" que solventa el método de los cuaterniones?.

Yo por ahora no he tenido que pegarme con el "gimbal lock" trabajando con matrices, asi que no te puede decir mucho :( . De todas maneras puedes mirar en http://es.wikipedia.org/wiki/Rotación

Marci, muchas gracias..... por la web-site, es muy esclarecedora

Si se usa matrices de rotaciones sobre ejes locales no se puede producir el efecto del "gimbal lock". Como el sistema de cámara no quería hacer mediante ejes de referencia ya tengo la seguridad de no padecer este efecto.