16
Programación gráfica / Re:Error al compilar objeto de shader
« en: 10 de Diciembre de 2015, 07:38:37 pm »
glShaderSource lo que hace es reemplazar el código en un objeto ya creado, pero antes tienes que crearlo con glCreateShader
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.
17
Proyectos / Re:Busco grafista para juego android
« en: 09 de Enero de 2014, 10:33:23 pm »
bueno, ya no es necesario, ya encontré a alguien al poner la solicitud en colaboradores.
pero ahora, ¿cómo la puedo quitar?.
pero ahora, ¿cómo la puedo quitar?.
18
Proyectos / Re:Busco grafista para juego android
« en: 06 de Enero de 2014, 01:56:02 am »
ah gracias, voy a mirar en esa sección y en los otros foros.
19
Proyectos / Busco grafista para juego android
« en: 03 de Enero de 2014, 07:54:58 pm »
Busco compañero grafista para hacer un videojuego para la plataforma Android 
_
Se empezaría casi desde cero, pero ya tengo la idea, el motor propio, y un editor de físicas. Tenía pensado hacerlo yo entero pero voy lento con los gráficos y pierdo un montón de tiempo que debería estar programando. La idea es acabar en poco tiempo, un par de meses, al menos una fase beta. El juego será una especie de tipo "plataformas" pero con física.
Los gráficos no deben ser muy complicados, tipo Angry birds, con fondos sencillos y sprites simpáticos, y en general no requerirá de animaciones complicadas, así que no tiene mucha dificultad creo. La persona que busco no hace falta que sea un gran experto ni un artista, con alguien que sepa diseñar cosas sencillas pero vistosas es suficiente. Yo uso Inkscape porque creo que es lo que más se adapta para hacer esos gráficos simples (sin que vayan cargados de detalles de pixels).
Lo que si pido es que hay una cierta dedicación y disponibilidad, yo trabajo a media jornada y voy a dedicar mucho tiempo, así que pido también que se involucre. Abstenerse oportunistas. Porque si es alguien que tiene pensado despacharme con cuatro gráficos rápidos en sus huecos libres después de mandarle 10 correos porque no me contesta, que se olvide, perderá el poco tiempo que dedique cuando me canse de él y me hará perder el tiempo a mí. Prefiero incluso que sea alguien que esté empezando, que crea que tiene talento para esto, y que tenga ilusión por aprender, mejorar, e involucrarse a tope, y llegado el caso que quiera crear conmigo una pequeña compañía de juegos.
Del tema de los beneficios prefiero comentarlo por privado porque la forma de pago que tengo pensada para este juego es un poco peculiar y requiere explicarlo, aunque lo que sí es seguro es que si los hay serán totalmente a repartir mitad y mitad, sin paliativos.
Si hay alguien interesado que me mande un MP y lo hablamos.
Saludos a todos.
_Se empezaría casi desde cero, pero ya tengo la idea, el motor propio, y un editor de físicas. Tenía pensado hacerlo yo entero pero voy lento con los gráficos y pierdo un montón de tiempo que debería estar programando. La idea es acabar en poco tiempo, un par de meses, al menos una fase beta. El juego será una especie de tipo "plataformas" pero con física.
Los gráficos no deben ser muy complicados, tipo Angry birds, con fondos sencillos y sprites simpáticos, y en general no requerirá de animaciones complicadas, así que no tiene mucha dificultad creo. La persona que busco no hace falta que sea un gran experto ni un artista, con alguien que sepa diseñar cosas sencillas pero vistosas es suficiente. Yo uso Inkscape porque creo que es lo que más se adapta para hacer esos gráficos simples (sin que vayan cargados de detalles de pixels).
Lo que si pido es que hay una cierta dedicación y disponibilidad, yo trabajo a media jornada y voy a dedicar mucho tiempo, así que pido también que se involucre. Abstenerse oportunistas. Porque si es alguien que tiene pensado despacharme con cuatro gráficos rápidos en sus huecos libres después de mandarle 10 correos porque no me contesta, que se olvide, perderá el poco tiempo que dedique cuando me canse de él y me hará perder el tiempo a mí. Prefiero incluso que sea alguien que esté empezando, que crea que tiene talento para esto, y que tenga ilusión por aprender, mejorar, e involucrarse a tope, y llegado el caso que quiera crear conmigo una pequeña compañía de juegos.
Del tema de los beneficios prefiero comentarlo por privado porque la forma de pago que tengo pensada para este juego es un poco peculiar y requiere explicarlo, aunque lo que sí es seguro es que si los hay serán totalmente a repartir mitad y mitad, sin paliativos.
Si hay alguien interesado que me mande un MP y lo hablamos.
Saludos a todos.
20
General Programadores / Re:Problema con vectores y movimiento
« en: 14 de Marzo de 2013, 01:02:57 am »
yo creo que es perfectamente asumible, ¿cuantos objetos piensas mover?
Bueno, si coges una función que multiplique matrices, desenrollas sus bucles y omites las multiplicaciones por 0, seguro que se gana algo, pero en principio no me complicaría la vida con esto, y usaría glLoadMatrix y glMultMatrix, o mejor una librería auxiliar o una clase para operar con matrices.
Luego también de esta manera se pueden enlazar las multiplicaciones de matrices para mantener una jerarquía, es decir, un brazo con respecto a un cuerpo tendrá siempre una posición concreta 10,5,0 por ejemplo (a menos que se desmembre), si a la hora de dibujar coges la multiplicación de modelview por el cuerpo y la multiplicas por la posición del brazo, obtienes la posición absoluta del brazo en el espacio, si la multiplicas por la matriz de la pierna obtienes la de la pierna, no es necesario mover todas las extremidades o partes de un mismo objeto conjuntamente con el cuerpo en cada movimiento, por lo que se ahorran muchas operaciones, y por supuesto las puedes rotar libremente porque al enlazar multiplicaciones siempre se mantendrán unidas al cuerpo.
Para mantener todo esto lo mejor es crear una clase que contenga como principal dato una matriz, y las funciones avanzar, rotar, orientar, obtener posición, etc. y que se puedan asignar objetos hijos de la misma clase. que puedas obtener su matriz local y su matriz global (teniendo en cuenta a los padres), como digo basta multiplicar,
matriz global de la mano = matriz cuerpo * matriz brazo * matriz local
matriz para dibujar segun el punto de vista = modelview *matriz global
Esa clase la asignas a los personajes de la escena o haces clases heradadas y ya está. En mi opiniòn es mejor hacer clases heredadas, y así tener por ejemplo esa clase, y luego otra heredada que contenga un modelo 3D, sus respectivos bounding box para calcular colisiones, luego otra para personajes animados, etc. De este modo podrás usar la clase que te convenga según para lo que se use.
Bueno, si coges una función que multiplique matrices, desenrollas sus bucles y omites las multiplicaciones por 0, seguro que se gana algo, pero en principio no me complicaría la vida con esto, y usaría glLoadMatrix y glMultMatrix, o mejor una librería auxiliar o una clase para operar con matrices.
Luego también de esta manera se pueden enlazar las multiplicaciones de matrices para mantener una jerarquía, es decir, un brazo con respecto a un cuerpo tendrá siempre una posición concreta 10,5,0 por ejemplo (a menos que se desmembre), si a la hora de dibujar coges la multiplicación de modelview por el cuerpo y la multiplicas por la posición del brazo, obtienes la posición absoluta del brazo en el espacio, si la multiplicas por la matriz de la pierna obtienes la de la pierna, no es necesario mover todas las extremidades o partes de un mismo objeto conjuntamente con el cuerpo en cada movimiento, por lo que se ahorran muchas operaciones, y por supuesto las puedes rotar libremente porque al enlazar multiplicaciones siempre se mantendrán unidas al cuerpo.
Para mantener todo esto lo mejor es crear una clase que contenga como principal dato una matriz, y las funciones avanzar, rotar, orientar, obtener posición, etc. y que se puedan asignar objetos hijos de la misma clase. que puedas obtener su matriz local y su matriz global (teniendo en cuenta a los padres), como digo basta multiplicar,
matriz global de la mano = matriz cuerpo * matriz brazo * matriz local
matriz para dibujar segun el punto de vista = modelview *matriz global
Esa clase la asignas a los personajes de la escena o haces clases heradadas y ya está. En mi opiniòn es mejor hacer clases heredadas, y así tener por ejemplo esa clase, y luego otra heredada que contenga un modelo 3D, sus respectivos bounding box para calcular colisiones, luego otra para personajes animados, etc. De este modo podrás usar la clase que te convenga según para lo que se use.
21
General Programadores / Re:Problema con vectores y movimiento
« en: 13 de Marzo de 2013, 05:45:46 pm »
si no esto equivocado la solución correcta es multiplicar la matriz de la posición del objeto por una matriz de traslación, por ejemplo para avanzar 10 unidades hacia delante sería esta.
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,10,1 (aqui están x, y , z y se pone 10 en la z, que es hacia delante).
El tema es que tienes que asociar una matriz a cada objeto, entonces hacer las operaciones sobre dicha matriz. Cada operación que hagas la modificará y con ella la orientación, posición, e incluso escala del objeto si quieres.
Después para dibujarlo basta con multiplicar la matriz modelview por la matriz del objeto y listo.
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,10,1 (aqui están x, y , z y se pone 10 en la z, que es hacia delante).
El tema es que tienes que asociar una matriz a cada objeto, entonces hacer las operaciones sobre dicha matriz. Cada operación que hagas la modificará y con ella la orientación, posición, e incluso escala del objeto si quieres.
Después para dibujarlo basta con multiplicar la matriz modelview por la matriz del objeto y listo.
22
Programación gráfica / Re:De direct3d9 a OpenGL
« en: 13 de Marzo de 2013, 01:13:23 pm »
Bien, puedes empezar sin shaders, pero evitaría el tema de iluminación y texturas (y cualquier otro tipo de efecto como niebla o lo que sea), porque puedes perfectamente pasarte a OGL usando unos cubos coloreados como modelos. Puedes encontrarlos hechos en la red con glBegin y glEnd.
Así a bote pronto la secuencia de aprendizaje/transición sería.
- Iniciar el entorno opengl: ventana, inputs, viewport, etc.
- Dibujar en pantalla algo: crear la proyeccion ortogonal, limpiar buffer de pantalla, dibujar un rectangulo, intercambiar buffer.
- Renderizar un cubo en 3D: y aprender lo relacionado con proyeccion en perspectiva, zbuffer, face culling, modo wire, etc.
- Crear la cámara, desplazarte por el entorno, varial el FOV, el rango, aprender las operaciones con matrices...
Y la verdad es que a partir de aquí todo lo demás se puede considerar como efectos adicionales, es decir, cómo se va a pintar lo que ya tienes, aquí empezaría ya con los shaders como si fuera la segunda parte.
No tiene mucho misterio, se crea un nuevo programa, se crean y se compilan un objeto para vertex shader que están en formato de texto, otro para el fragment shader y se asignan al programa, se enlazan y ya se puede usar el shader activandolo y desactivandolo.
Para empezar por ejemplo, busca un shader en la red para luz difusa, y cargalo (los dos archivos, el vertex y el fragment), activa el programa antes de renderizar el cubo, deberás ver el cubo iluminado.
A partir de aquí empezaría con los vertex buffers objects (VBO), pasar de dibujar el cubo de pruebas con glBegin/glEnd a hacerlo con VBO. Esto se podría hacer antes de empezar con los shaders, pero la forma que tiene de hacerse está deprecatada, y como da lo mismo empezar con los shaders antes que con los VBO, es mejor ese orden. Luego puedes intentar texturizarlo.
Realmente a partir de aquí todo serán shaders y buffers objects, que los hay de muchos tipos, EBO, PBO, FBO, UBO...., aunque no todos son necesarios, los buffers se encargan de gestionar la memoria de vídeo para que sea lo más veloz posible, y los shader de cómo se pinta lo que hay en la memoria.
La mejor literatura está en el superbible http://ldc.usb.ve/~vtheok/cursos/ci4321/pdfs/02.pdf
y como referencia concreta y directa de cómo hacer tal cosa este documento
http://github.prideout.net/modern-opengl-prezo/
Así a bote pronto la secuencia de aprendizaje/transición sería.
- Iniciar el entorno opengl: ventana, inputs, viewport, etc.
- Dibujar en pantalla algo: crear la proyeccion ortogonal, limpiar buffer de pantalla, dibujar un rectangulo, intercambiar buffer.
- Renderizar un cubo en 3D: y aprender lo relacionado con proyeccion en perspectiva, zbuffer, face culling, modo wire, etc.
- Crear la cámara, desplazarte por el entorno, varial el FOV, el rango, aprender las operaciones con matrices...
Y la verdad es que a partir de aquí todo lo demás se puede considerar como efectos adicionales, es decir, cómo se va a pintar lo que ya tienes, aquí empezaría ya con los shaders como si fuera la segunda parte.
No tiene mucho misterio, se crea un nuevo programa, se crean y se compilan un objeto para vertex shader que están en formato de texto, otro para el fragment shader y se asignan al programa, se enlazan y ya se puede usar el shader activandolo y desactivandolo.
Para empezar por ejemplo, busca un shader en la red para luz difusa, y cargalo (los dos archivos, el vertex y el fragment), activa el programa antes de renderizar el cubo, deberás ver el cubo iluminado.
A partir de aquí empezaría con los vertex buffers objects (VBO), pasar de dibujar el cubo de pruebas con glBegin/glEnd a hacerlo con VBO. Esto se podría hacer antes de empezar con los shaders, pero la forma que tiene de hacerse está deprecatada, y como da lo mismo empezar con los shaders antes que con los VBO, es mejor ese orden. Luego puedes intentar texturizarlo.
Realmente a partir de aquí todo serán shaders y buffers objects, que los hay de muchos tipos, EBO, PBO, FBO, UBO...., aunque no todos son necesarios, los buffers se encargan de gestionar la memoria de vídeo para que sea lo más veloz posible, y los shader de cómo se pinta lo que hay en la memoria.
La mejor literatura está en el superbible http://ldc.usb.ve/~vtheok/cursos/ci4321/pdfs/02.pdf
y como referencia concreta y directa de cómo hacer tal cosa este documento
http://github.prideout.net/modern-opengl-prezo/
23
Programación gráfica / Duda Opengl
« en: 20 de Enero de 2006, 02:53:56 pm »Cita de: "Marci"
RaySe supone que la información de los vértices la envías en glInterLeavedArrays y en glDrawElements envías además los índices.Código: [Seleccionar]glDrawArrays(GL_TRIANGLES, 0, 36);
glDrawElements(GL_TRIANGLES, 36, GL_UNSIGNED_INT, index);
A mi me parece que le estamos enviando a la GPU la misma información con las dos funciones. Solo varía el origen de los datos, no?
Si los vértices no están indexados no tiene sentido dibujar con glDrawElements.
En el caso del cubo de ejemplo anterior si se dibuja indexado se han de mandar 8 vertices pero si no lo está hay que enviarlos todos con los que haya que formar todos los triángulos, aunque estén repetidos.
24
Programación gráfica / Duda Opengl
« en: 18 de Enero de 2006, 05:49:11 pm »Cita de: "misscelan"
Primera pregunta. Si mando la malla entera a un glDrawArrays o glDrawElements y los saco con GL_TRIANGLE_STRIP esos mismos procedimientos se encargarían de crear los triángulos uniendo los vértices más cercanos o va creando las líneas según le llegan los vértices y me dejará un pupurrí de triángulos.
Se van creando los triángulos de una manerá lógica según están en la lista o le llegan.
aquí se ven las 3 formas de dibujar, strip, fan y normal.
http://bhbn.free.fr/etudes/rsc/OpenGL.doc.html-wv-2.png' target='_blank'>http://bhbn.free.fr/etudes/rsc/OpenGL.doc....c.html-wv-2.png
Citar
En el caso de mandarlos con GL_TRIANGLE_STRIP el proc mismo se encargaría de no usar los vértices duplicados?.
El procedimiento hará lo que tu le digas de acuerdo a las normas que tiene cada forma de dibujar, lo normal es que salga un churro si no sabes exactamente lo que estás haciendo.
Citar
En el caso de no poder usar GL_TRIANGLE_STRIP desde el punto de vista de la rapidez cual creeis que sería más rápido.
El método de reorganizar los vértices que os dije al principio del post o dejar que lo organice él y pasárselos con glDrawElements.
según cada caso es mejor una forma u otra, pero la tarjeta no te va a organizar nada, que yo sepa.
Por ejemplo un cubo con caras con su propia textura y normales, dibujar triangulos sin indexar.
Para una esfera donde todos comparten textura y normales mejor indexado.
Para un cono o una sombrilla, o un círculo plano, con FAN
Para un terreno que comparte normales, textura y posición, lo más rápido sería indexado y con STRIP, dibujando en tiras cada fila o columna.
Pero siempre tienes que tener en cuenta que la posición de cada vertice en la lista es lo que la tarjeta gráfica tiene en cuenta a la hora de dibujar los triángulos. Quitar o añadir uno sería un desastre al menos para los que le preceden.
25
Programación gráfica / Duda Opengl
« en: 18 de Enero de 2006, 05:17:25 pm »Cita de: "Marci"
porque son 8 los vértices que tiene el cubo.CitarIndexado solo calcularía los 8 vertices de cada esquina
No entiendo porque solo 8 :huh:
a la tarjeta le llegan los 8 vértices, y un índice por cada vértice que hay que apuntar para dibujar todos los triángulos, el caso del cubo 48.
Esos 8 vértices son transformados para que queden proyectados en la pantalla.
Durante la rasterización se dibujan los triángulos mediante los índices que apuntan a cada vértice, si son 8, del 0 al 7.
0,1,2....0,3,4.....4,6,5....,1,6,7... (por ejemplo)
si tu le pasas esos 48 vértices duplicados en cada triángulo, la tarjeta transforma los 48 vértices. Como están dibujados mediante GL_TRIANGLES dibujaría cada triángulo usando la serie de vértices 0,1,2....3,4,5....6,7,8....9,10,11, etc. Esto si ha de hacerse con cientos de miles, la ganancia puede ser enorme indexandolos.
Hay que tener en cuenta que aunque tengan la misma posición no tienen porque estar duplicados ya que cada uno puede tener sus propias normales, o coordenadas de textura, por lo que muchas veces no quedará más remedio que mandar los 48, a no ser que hayan inventado algo ya para solucionar esto.
Entonces, por lo general y si yo no estoy errado, si los vértices comparten el mismo vértice incluido la normal y la coordenada de textura mejor indexarlo, si no, mejor no hacerlo.
Edit: me he hecho la picha un lío ahora y antes con los vértices del cubo, no son 48 si no 36 , 6 caras x 2 triángulos x 3 vértices.
26
Programación gráfica / Duda Opengl
« en: 18 de Enero de 2006, 03:52:57 pm »
Puede ser mucha velocidad, sobre todo si hay vertices compartidos.
Por ejemplo un cubo sin indexar formado por 6 caras, o sea.. 12 triangulos, la tarjeta calcularía 4x12 = 48 vértices o en el mejor de los casos 24 si son rectangulos.
Indexado solo calcularía los 8 vertices de cada esquina, por lo que en teoría debería ser mucho más rapido, al menos en lo que a la transformación de cada vértice se refiere.
Pero a veces puede ser mejor no usarlos, por ejemplo para hacer tiras de triángulos con GL_TRIANGLE_STRIP o GL_TRIANGLE_FAN, ya que así ni se duplican los vértices, ni se tienen que leer los índices, se va leyendo secuencialmente cada vértice y es lo más rápido.
Por ejemplo un cubo sin indexar formado por 6 caras, o sea.. 12 triangulos, la tarjeta calcularía 4x12 = 48 vértices o en el mejor de los casos 24 si son rectangulos.
Indexado solo calcularía los 8 vertices de cada esquina, por lo que en teoría debería ser mucho más rapido, al menos en lo que a la transformación de cada vértice se refiere.
Pero a veces puede ser mejor no usarlos, por ejemplo para hacer tiras de triángulos con GL_TRIANGLE_STRIP o GL_TRIANGLE_FAN, ya que así ni se duplican los vértices, ni se tienen que leer los índices, se va leyendo secuencialmente cada vértice y es lo más rápido.
27
Programación gráfica / Duda Opengl
« en: 18 de Enero de 2006, 02:36:48 pm »Citar
¿Existe algún comando parecido a glDrawArrays al que le pueda pasar el array de vertices y el de los indices y el se encargue de mandarlo todo de golpe?
si, glDrawElements
28
Programación gráfica / Transparencias En Textura Png Con Opengl
« en: 04 de Enero de 2006, 04:13:12 pm »
vale, no hagas ni caso del otro ejemplo que me equivoqué.
glBlendFunc( GL_ONE, GL_ONE );
esta sería la función güena.
Sencillamente se suman el color de la textura con el color del fondo, aunque se pueden encontrar otras combinaciones para que quede más guapo.
Saludos y a divertirse. (ole)
glBlendFunc( GL_ONE, GL_ONE );
esta sería la función güena.
Sencillamente se suman el color de la textura con el color del fondo, aunque se pueden encontrar otras combinaciones para que quede más guapo.
Saludos y a divertirse. (ole)
29
Programación gráfica / Transparencias En Textura Png Con Opengl
« en: 04 de Enero de 2006, 04:00:24 pm »
Ten en cuenta que lo que te he dicho del test alpha no siempre es conveniente usarlo, el problema que tiene es que como dibuja o no el pixel, pueden aparecer los bordes dentados, y en ciertas texturas como http://216.231.48.101/~impulse/misc2/flare.jpg' target='_blank'>esta se vería desastrosamente.
Si te das cuenta debería tener un color alpha progresivo, para que quedase una mezcla consistente. Bueno, pues hay otra forma de hacer transparencias con el blend sin necesidad de usar canal alpha, aprovechando que el fondo de la textura es negro usando esta combinación.
ColorFinal = (ColorOrigen * ColorDestino) + (ColorDestino * 1)
Esto supone que en donde la textura tenga color negro se dibujará con el color de destino, donde tenga color blanco se pintará de blanco y en las zonas intermedias grises se mezclará perfectamente, esta es la función:
glBlendFunc( GL_DST_COLOR, GL_ONE );
El color origen se multiplica por el primer parámetro (destino), el color de destino por el segundo (uno) y se suman los dos resultados, esa es la formula que he puesto.
Prueba a dibujar la textura del enlace, activando este tipo de mezcla para que veas como queda, doy por hecho que tienes el DepthBuffer desactivado.
despues prueba a hacer más combinaciones cambiando los parametros de glBlendFunc y mira lo que sale, así entenderás mejor su funcionamiento.
Si te das cuenta debería tener un color alpha progresivo, para que quedase una mezcla consistente. Bueno, pues hay otra forma de hacer transparencias con el blend sin necesidad de usar canal alpha, aprovechando que el fondo de la textura es negro usando esta combinación.
ColorFinal = (ColorOrigen * ColorDestino) + (ColorDestino * 1)
Esto supone que en donde la textura tenga color negro se dibujará con el color de destino, donde tenga color blanco se pintará de blanco y en las zonas intermedias grises se mezclará perfectamente, esta es la función:
glBlendFunc( GL_DST_COLOR, GL_ONE );
El color origen se multiplica por el primer parámetro (destino), el color de destino por el segundo (uno) y se suman los dos resultados, esa es la formula que he puesto.
Prueba a dibujar la textura del enlace, activando este tipo de mezcla para que veas como queda, doy por hecho que tienes el DepthBuffer desactivado.
despues prueba a hacer más combinaciones cambiando los parametros de glBlendFunc y mira lo que sale, así entenderás mejor su funcionamiento.
30
Programación gráfica / Transparencias En Textura Png Con Opengl
« en: 04 de Enero de 2006, 01:55:09 pm »
Me temo que la respuesta se me va a alargar, a ver...
Tienes que imaginar que el buffer de profundidad es una superficie exactamente igual que la del buffer de color donde dibujas, donde se graban unas marcas que se corresponden con cada pixel, cada vez que se dibujan.
Estas marca puede tener un valor de 0 a n, donde n esta determinado por el número de bits del Buffer de profundidad, cuanto mayor es n mayor resolución tiene el buffer y por lo tanto más preciso es a la hora de ordenar los póligonos que dibujes.
Un DepthBuffer de un solo bit actuaría casi igual que una hoja tras un calco, cada vez que pintas algo verías que ha dejado una marca osea un 1, y cada vez que borras con clear y le pasas el flag de GL_DEPTH_BUFFER_BIT borra el buffer y lo deja libre de marcas a 0.
Si tu dibujas un sprite y está activado el Blend, la tarjeta gráfica hace una operación matemática indicada en glBlendFunc para determinar el color final de todos y cada uno de los pixels del sprite que son dibujados, por lo tanto en tu programa hace esto con todos los pixels (lo explicaré un poco más claro que antes):
ColorDibujado = ColorOrigen * ColorAlphaOrigen + ColorDestino * Inverso(ColorAlphaOrigen)
Donde el color de origen es el color que va se va a dibujar, ahí se incluye a la textura o a cualquier otro tipo de mezcla que se haga con él, de luz, sombra, niebla, mezcla con otro color, con otra textura, etc. Es decir, es el color que se ha elegido para pintar, en tu caso solo el color de la textura, por lo tanto el color de la cara sería verde con el componente alpha a 1 (al máximo) y este sería el color final.
ColorDibujado = Verde * 1 + Azul * 0
Efectivamente el pixel de la cara se pinta verde.
Ahora en la parte negra donde alpha está a 0 el color final sería:
ColorDibujado = Negro * 0 + Azul * 1
Y lo pinta de color azul (del color del fondo), si detrás hubiera una casa lo pintaría del color de la casa, por lo que siempre te parecerá que no lo dibuja, pero en realidad si lo ha dibujado, por lo que también se ha hecho una marca en el DepthBuffer.
Si pudieramos ver el DephtBuffer como si fuera la hoja tras el calco, veriamos que no tiene la forma circular de la cara, si no la forma de un cuadrado igual al tamaño de la textura, ya que se ha dibujado siempre sobre él, por lo tanto toda la zona rectangular de la textura vale 1 y el resto limpio vale 0.
Ahora se procede a dibujar una textura encima, y como está establecido con glDepthFunc(GL_LESS) que solo se dibuje cuando la marca dibujada sea menor que la marca actual, solo se dibujará donde la marca sea 0, ya que la marca que quiere dibujar la siguiente textura vale 1 igual que la anterior, (no es menor).
Es decir, la segunda textura que pones encima, dibuja en todos los sitios excepto en el cuadrado donde dibujaste la primera textura, por lo tanto, el color azul permanece intacto, y por eso te da la sensación de que no ha tenido efecto la transparencia.
Entonces de momento quita el buffer de profundidad para no complicarte con él, en un futuro lo puedes usar para ordenar sprites sin preocuparte del orden en el que los dibujes, o para hacer otros efectos como el que sin querer has estado haciendo, (una ventanita donde no se permite dibujar).
En cuanto a lo del alpha blending tu lo estas usando para hacer el típico efecto de transparencia de bordes, pero en realidad lo que has activado es una mezcla peculiar con el color alpha para que de la sensación de que no se dibuje.
Si echas un vistazo a los parámetros de http://www.mevis.de/opengl/glBlendFunc.html' target='_blank'>glBlendFunc verás que puedes hacer un monton de combinaciones, para hacer mezclas que parezcan reflejos, vidrio, sombras, o mezclas perfectas de brillos, fantasmas y todo lo que se te ocurra.
Para hacer la clásica transparencia a modo de color "Croma Key" que se usa en el cine o con el hombre del tiempo, creo que es mejor usar el test alfa, activalo con glEnable(GL_ALPHA_TEST); y defínelo con glAlphaFunc(GL_NOTEQUAL, 0);
Esto al contrario del Blend lo que hace es que comparar el color que se va a pintar con su color componente alpha y lo dibuja, o no, dependiendo de la función de comparación. Debería ser más rapido que el blend ya que además de ahorrar con las multiplicaciones de la mezcla, se ahorra en que los pixels que fallan el test no se dibujan.
Espero haberte aclarado muchas cosas, a lo primero es un poco lioso el OpenGL pero cuando cuando lo caces podrás hacer cualquier cosa facilmente sin mucha dificultad y que tampoco tiene mucho misterio.
Un saludo.
Andá!!!, si ya es la hora de comer (uoh)
Tienes que imaginar que el buffer de profundidad es una superficie exactamente igual que la del buffer de color donde dibujas, donde se graban unas marcas que se corresponden con cada pixel, cada vez que se dibujan.
Estas marca puede tener un valor de 0 a n, donde n esta determinado por el número de bits del Buffer de profundidad, cuanto mayor es n mayor resolución tiene el buffer y por lo tanto más preciso es a la hora de ordenar los póligonos que dibujes.
Un DepthBuffer de un solo bit actuaría casi igual que una hoja tras un calco, cada vez que pintas algo verías que ha dejado una marca osea un 1, y cada vez que borras con clear y le pasas el flag de GL_DEPTH_BUFFER_BIT borra el buffer y lo deja libre de marcas a 0.
Si tu dibujas un sprite y está activado el Blend, la tarjeta gráfica hace una operación matemática indicada en glBlendFunc para determinar el color final de todos y cada uno de los pixels del sprite que son dibujados, por lo tanto en tu programa hace esto con todos los pixels (lo explicaré un poco más claro que antes):
ColorDibujado = ColorOrigen * ColorAlphaOrigen + ColorDestino * Inverso(ColorAlphaOrigen)
Donde el color de origen es el color que va se va a dibujar, ahí se incluye a la textura o a cualquier otro tipo de mezcla que se haga con él, de luz, sombra, niebla, mezcla con otro color, con otra textura, etc. Es decir, es el color que se ha elegido para pintar, en tu caso solo el color de la textura, por lo tanto el color de la cara sería verde con el componente alpha a 1 (al máximo) y este sería el color final.
ColorDibujado = Verde * 1 + Azul * 0
Efectivamente el pixel de la cara se pinta verde.
Ahora en la parte negra donde alpha está a 0 el color final sería:
ColorDibujado = Negro * 0 + Azul * 1
Y lo pinta de color azul (del color del fondo), si detrás hubiera una casa lo pintaría del color de la casa, por lo que siempre te parecerá que no lo dibuja, pero en realidad si lo ha dibujado, por lo que también se ha hecho una marca en el DepthBuffer.
Si pudieramos ver el DephtBuffer como si fuera la hoja tras el calco, veriamos que no tiene la forma circular de la cara, si no la forma de un cuadrado igual al tamaño de la textura, ya que se ha dibujado siempre sobre él, por lo tanto toda la zona rectangular de la textura vale 1 y el resto limpio vale 0.
Ahora se procede a dibujar una textura encima, y como está establecido con glDepthFunc(GL_LESS) que solo se dibuje cuando la marca dibujada sea menor que la marca actual, solo se dibujará donde la marca sea 0, ya que la marca que quiere dibujar la siguiente textura vale 1 igual que la anterior, (no es menor).
Es decir, la segunda textura que pones encima, dibuja en todos los sitios excepto en el cuadrado donde dibujaste la primera textura, por lo tanto, el color azul permanece intacto, y por eso te da la sensación de que no ha tenido efecto la transparencia.
Entonces de momento quita el buffer de profundidad para no complicarte con él, en un futuro lo puedes usar para ordenar sprites sin preocuparte del orden en el que los dibujes, o para hacer otros efectos como el que sin querer has estado haciendo, (una ventanita donde no se permite dibujar).
En cuanto a lo del alpha blending tu lo estas usando para hacer el típico efecto de transparencia de bordes, pero en realidad lo que has activado es una mezcla peculiar con el color alpha para que de la sensación de que no se dibuje.
Si echas un vistazo a los parámetros de http://www.mevis.de/opengl/glBlendFunc.html' target='_blank'>glBlendFunc verás que puedes hacer un monton de combinaciones, para hacer mezclas que parezcan reflejos, vidrio, sombras, o mezclas perfectas de brillos, fantasmas y todo lo que se te ocurra.
Para hacer la clásica transparencia a modo de color "Croma Key" que se usa en el cine o con el hombre del tiempo, creo que es mejor usar el test alfa, activalo con glEnable(GL_ALPHA_TEST); y defínelo con glAlphaFunc(GL_NOTEQUAL, 0);
Esto al contrario del Blend lo que hace es que comparar el color que se va a pintar con su color componente alpha y lo dibuja, o no, dependiendo de la función de comparación. Debería ser más rapido que el blend ya que además de ahorrar con las multiplicaciones de la mezcla, se ahorra en que los pixels que fallan el test no se dibujan.
Espero haberte aclarado muchas cosas, a lo primero es un poco lioso el OpenGL pero cuando cuando lo caces podrás hacer cualquier cosa facilmente sin mucha dificultad y que tampoco tiene mucho misterio.
Un saludo.
Andá!!!, si ya es la hora de comer (uoh)