Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menu

Mensajes - marcianus

#1
Cita de: tamat en 17 de Septiembre de 2009, 04:19:38 PM
Solo me aseguraba

gracias por tu ayuda y paciencia.


Con el tiempo uno se hace mayor y las cosas cuestan mas  ::).
#2
Cita de: tamat en 17 de Septiembre de 2009, 10:29:22 AM
Vuelves a cometer un error.

Cambiar la Z sí que altera lo que vemos, solo hay un caso donde no sucede así, y es si trabajamos con una proyeccion ortografica y nuestro front está alineado con el eje Z del mundo

Sobre la negrita, no me refiero a cambiar el valor de Z absoluto (respecto al eje Z del mundo). Entiendo lo que dices, es lo mismo que quiero decir yo.  Y si yo utilizo un sistema de coordenadas "centrado" en la camara (con su coordenada z en direccion "de lo que se ve") se cumple tambien

Cita de: tamat en 17 de Septiembre de 2009, 10:29:22 AM
Incluso aunque la camara estuviera alineada con el eje Z, si estamos en perspectiva solo sucedería lo que comentas si el vertice que movemos está justo en el centro, si esta en otro lado entonces la proyeccion haría que se alejase o acercase al centro, un poco en la linea del clasico salvapantallas de estrellas que viajan hacia ti.

Me referia a ese caso en particular, obviamente.

#3
Cita de: tamat en 16 de Septiembre de 2009, 12:59:51 PM
A ver, la piramide cortada (o frustrum) es el area del mundo que queda dentro de la zona visible. Obviamente viene definido por las matrices de proyeccion (esta define la forma de la piramide) y por la Modelview (esta define donde está la piramide), pero no tiene sentido hablar de tener la piramide en un sitio y mirar a otro, es absurdo, la piramide ES lo que ves.

Ok, estaba malinterpretando un ejemplo. Esto es lo que entiendo ahora (mis disculpas por haceros perder el tiempo y dadme de collejas si la vuelgo a cagar):

znear y  zfar que determinan la "base" y "tapa" de la piramide truncada o frustrum son planos perpendiculares a la linea de vision (el vector  z unitario del el espacio de coordenadas centrado en la camara). Vamos, que son valores relativos, solo despues de:

glMatrixMode( GL_PROJECTION_MATRIX )
glLoadIdentity()
glPerspective(ap,ar,znear,zfar)

znear y zfar coinciden en valor con laz z absolutas del sistema de coordenadas universal.

Cambiar la z del punto al que miramos no provoca cambios en lo proyectado porque "seguimos mirando en la misma direccion" (z unitario del sistema de coordenadas definido por la camara y el propio sistema de coordenadas de la misma no cambian). Pero si movemos el origen de la camara aunque solo sea en z si que cambia la proyeccion (nos alejamos o acercamos, segun el cambio de z).


Si por error estoy en el modo de GL_PROJECTION_MATRIX
e invoco glLookAt(),
los resultados seran impredecibles porque la matriz de glLookAt() en lugar de multiplicar a la matriz actual de modelado, hara alguna "guarreria" con la matriz actual de proyeccion.


De nuevo disculpas por parecer tan lerdo.
#4
Cita de: tamat en 15 de Septiembre de 2009, 12:59:28 PM
No existe un modo glPerspectiva o glOrtho, estas funciones lo unico que hacen es cargar la matriz que quieras en la matriz activa.

Por eso es importante que cuando uses las funciones de GL para cámara (glOrtho, glLookat, glPerspective, etc) recuerda que afectan a la matriz activa, que puede ser la MODELVIEW o la PROJECTION. No cambian automaticamente de matriz.

Recuerda que la PROJECTION es la que determina temas de proyeccion de 3D a 2D, así que tiene que estar activa antes de usar glOrtho o glPerspective.

La MODELVIEW es la de posicionar la cámara y tiene que estar activa antes de hacer glLookAt o cualquier glTranslate, glRotate o glScale.

Un error habitual es dejar activada la PROJECTION al settear la camara y luego extrañarse que el translate no funcione correctamente.

Y por último, recuerda que las funciones que modifican las matrices son acumulativas, es decir, no settean el valor en la matriz de opengl, lo multiplican, así que asegurate de hacer un glLoadIdentity antes.

Yo por lo general hago:

glMatrixMode( GL_PROJECTION_MATRIX )
glLoadIdentity()
glOrtho(0, WINDOW_WIDTH, 0, WINDOW_HEIGHT,-1,1)  //aunque a veces invierto la Y

glMatrixMode( GL_MODELVIEW_MATRIX )
glLoadIdentity()

//si estuvieramos en Perspective aquí iria el glLookAt

Por lo demas creo que vas bastante bien.

Vale, muchas gracias me has aclarado bastante los conceptos. glLookAt() "trabaja" con MODELVIEW y simplemente se emplea para situar la camara en el espacio (es preferible mover la camara que todos los objetos de una escena).

En el modo de proyeccion glOrtho, entiendo que SIEMPRE se proyecta ortogonalmente sobre el plano znear  los objetos que esten dentro del volumen definido por los parametros correspondientes.

En el modo glPerspective siempre se proyecta sobre el plano znear todos los objetos dentro del volumen que crea la piramide truncada definida por los parametros correspondientes a la llamada a dicha funcion glPerspective SIEMPRE Y CUANDO (simplificandolo mucho) la camara "apunte" desde un punto fuera de dicha piramide a un punto del interior de la misma.

Vamos, que eligiendo este modo de proyeccion, no vasta con tener los objetos dentro de la zona de interes, sino que ademas "hay que mirarlos", no?.

Me han ayudado tambien unos ejemplos de Nate Robbins donde tocando parametros ves automaticamente lo que pasa.
Solo una duda, en estos ejemplos, el sistema de coordenadas es de mano derecha (las coordenadas negativas de z se "alejan" de la pantalla de proyeccion pero en un ejemplo sencillo con 4 cubos de colores me encuentro que el sistema de proyeccion es de mano izquierda (que es lo que he leido que es por defecto). Hay algun tipo de parametro global que haga que se pueda elegir un tipo u otro?
#5
Programación gráfica / Re: glut.h y windows.h a la vez.
14 de Septiembre de 2009, 01:39:15 PM
Cita de: yorch en 14 de Septiembre de 2009, 01:25:09 PM
Hola, yo que ahora no estoy currando a ver si te puedo ayudar :P

Hace tiempo que no toco OpenGL pero creo recordar que el error en VS de la redefinición de exit() al incluir glut.h se arreglaba cambiando el orden de "includes". Prueba a ponerlo al final de todos los #include que tengas.

Saludos :)



Muchisimas gracias. Era eso (tenia el include de glut antes que el de windows).
#6
Cita de: [EX3] en 14 de Septiembre de 2009, 12:50:04 PM
Si el asunto no es que sean conceptos sencillos si no que ahora mismo es horario de trabajo y mas de uno (me deberia incluir  :..) estamos ocupados en nuestros respectivos trabajos :D

Salu2...

Mis disculpas, por tanto :)
#7
Programación gráfica / glut.h y windows.h a la vez.
14 de Septiembre de 2009, 12:36:33 PM
Estoy haciendo mis pruebas con Visual Studio Express. Me encuentro en un tutorial que necesito emplear la libreria windows.h (para utilizar la funcion Sleep(), pero cuando la añado como cabecera, me encuentro que "choca" con  GL/glut.h, ya que al compilar, me da error de redefinicion del metodo exit().  ???

Hay alguna manera sencilla de solventar o "rodear" esta "pequeña dificultad"?

Utilizo Sleep()  de windows.h porque el tutorial que sigo es de UNIX  y el metodo empleado aqui, usleep() no me lo reconoce el compilador de Visual Studio (me soprende porque usleep() pertenece a la libreria POSIX). Quizas es que me dejo algun otro fichero de cabecera por incluir?

Me pasa lo mismo utilizando los metodos siguientes:

srandom() y random()

aunque estos me importan menos (se han de emplear para inicializacion de variables y poniendo valores fijos en lugar de random de momento me sirve).

gracias y saludos
#8
Cita de: [EX3] en 14 de Septiembre de 2009, 12:27:44 PM
Cita de: marcianus en 14 de Septiembre de 2009, 12:00:43 PM
Mas disculpas por si he preguntado demasiadas tonterias dado que nadie responde  :-[
No seas impaciente, hombre, que no te van a responder en una mañana :P

Salu2...

Ya me lo imagino, pero como creo que son conceptos exageradamente basicos, la gente los tendria ya por la mano (o quizas, por eso, como los tienen tan asumidos, ....... :D)
#9
Mas disculpas por si he preguntado demasiadas tonterias dado que nadie responde  :-[
#10
Programación gráfica / Primerizo con OpenGL, dudas de concepto
14 de Septiembre de 2009, 10:45:18 AM
Antes que nada saludos a todos. Este es mi primer mensaje (a pesar de llevar ya un tiempecito leyendo por aqui) y como no podia ser, es para consultar algunas dudas conceptuales sobre mis primeros "pasitos" en OpenGL

1. El modo de proyeccion de OpenGL es un sistema de proyeccion de mano derecha, por defecto con el plano x,y en la pantalla y las coordenadas z positivas hacia el observador y las coordenadas negativas "alejandose" del mismo.
¿ Correcto?

2. Uso del modo de proyeccion Ortogonal, GLOrtho.

Entiendo que en este modo de proyeccion solo se visualizan los objetos que quedan dentro del volumen de proyeccion determinado por el cubo construido a partir de los parametros pasados a dicho metodo.

Por ejemplo, supongamos el siguiente modo de proyeccion, con x1=x1=z1>0 :

glOrtho(-x1,x1,-y1,y1,-z1,z1).

El plano de visualizacion sobre el que se proyectan los objetos es el plano z = z1, mirando dicho plano desde "fuera" del cubo, en direccion de las z's negativas (la cara anterior del cubo)

¿Correcto?

Es importante el orden de los vertices "delimitadores" del volumen porque cambian el plano de proyeccion. ¿Correcto?

Porque si empleo:

glOrtho(-x1,x1,-y1,y1,z1,-z1).


EDITO: se supone que glOrtho "funciona asi":

glOrtho( left, right, bottom, top, zNear, zFar )

Jugando con un fichero de ejemplo, me sale que en este modo de proyeccion, el sistema de coordenadas es "DE MANO IZQUIERDA"  ??? ??? (viendo las imagenes en el plano de proyeccion siempre desde el lado negativo de z).

-----------------------------------------------------------------------------------------------------------------------------------------------------
1.a Con este modo de proyeccion no tiene sentido emplear gluLookAt (aunque lo invoquemos, "no hace nada"
o
1.b La llamada en cualquier momento a gluLookAt "hace pasar" de manera automatica al modo gluPerspective()?

2. Uso de gluPerspective y gluLookAt

Si invocamos el modo de proyeccion en perspectiva, automaticamente se utiliza por defecto los siguiente valores de gluLookAt

gluLookAt(0,0,0,0,0,-1,0,1,0) ("mirando" hacia las z's negativas)


Es decir, el punto de vista desde el origen del sistema de coordenadas universal mirando en la direccion de las z negativas y con la camara "vertical".  (vector Up es ortogonal al vector "que mira").¿Correcto?.

o

gluLookAt(0,0,0,0,0,1,0,1,0) ("mirando" hacia las z's positivas)


Si "levanto" un poco la camara y la traslado a un  observador que este en (0,0,5)  y mirando al origen de coordenadas, manteniendo el vector Up (0,1,0):

gluLookAt (0,5,5,0,0,0,0,1,0)

las dudas son sobre "donde apunta" el vector Up. ¿Sus coordendas 0,1,0 son respecto al sistema de coordenadas universal?. En este caso el vector "que mira" y el vector Up no son ortogonales pero si delimitan un plano vertical. Asi que entiendo que el vector Up simplemente se "emplea" para "rotar la camara" sobre su propio "punto de mira". ¿Correcto?


Disculpas por el ladrillazo pero necesito tener muy claros estos conceptos para "seguir adelante".

saludos






Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.