OGL 2D

[nsL]

Hola!!!

Hace lustros q no posteo por aqui (uni, curro y demas) y veo q hay muchas caras nuevas, lo cual es siempre bueno :)

He vuelto al redil, y con ganas de programar, y como siempre he vuelto al punto donde me he quedado hace 1-2 años. Utilizar OGL para 2D.

En el trabajo , gracias a dios, tengo la suerte de estar currando con openGL para hacer un panel informativo de llegadas de autobuses tal y cual (tranquilos q no os voy a contar mi vida xD). El caso es q era un proyecto ya empezado por otro chico y la base q ya la tenia él consistia en que cada imagen q pintaba en la pantalla, la pintaba como textura de un lado de un cubo, todo ello usando proyeccion perspectiva.

Yo siempre q habia intentado hacer algo en 2D con openGL lo habia hecho con proyeccion ortho. Pero vamos, para el caso da igual.

A lo q quiero llegar es q voy a ponerme a hacer cosillas a parte por mi cuenta en casa. Algun jueguecillo o tal,  y queria saber los fundamentos de usar 2D con openGL. Es decir:

¿Para manejar imagenes simplemente es crear QUADS con textura, y a pintar (a grosso modo) ? Lo cual seria simil a una SDL_Surface...
¿Cuanto es aconsejable cargar texturas mipmap, teniendo en cuenta que aunq dan mejor acabado, ocupan mas memoria?
¿Esta bien la idea de usar proyeccion ortho, o por el contrario la perspectiva da mas juego?
¿El tema de transparencias, basta con crear un QUAD con una textura q posea canal alpha y ya sera transparente tal poligono, o se ha de aplicar otro metodo?

Mi idea es crearme unas clases para crear "surfaces" (siempre fui de SDL xD) a modo de """"API"""" (notense las comillas) para crearme por encima algun jueguecillo.

No se si quedo mas o menos claro. De todas formas creo q me vereis mas a menudo por aqui con alguna dudilla sobre el tema ;)

Me alegro de volver a veros y gracias

Saludos!!

[senior wapo]

.
¿Para manejar imagenes simplemente es crear QUADS con textura, y a pintar (a grosso modo) ? Lo cual seria simil a una SDL_Surface...

Si.

¿Cuanto es aconsejable cargar texturas mipmap, teniendo en cuenta que aunq dan mejor acabado, ocupan mas memoria?

Eso lo valoras tú. Si tus imágenes serán a tamaño normal o aumentadas no necesitas mipmaps. Si pesa mas la calidad visual que el consumo de memoria usa mipmaps.

¿Esta bien la idea de usar proyeccion ortho, o por el contrario la perspectiva da mas juego?

Tanto da uno que otro, al fin y al cabo son matrices de proyección.
Cuando quieras algo avanzado tendrás que hacerte tu la matriz a mano en ambos casos.

¿El tema de transparencias, basta con crear un QUAD con una textura q posea canal alpha y ya sera transparente tal poligono, o se ha de aplicar otro metodo?

Basta con que la textura tenga canal alfa y actives el blending. Mirate glEnable(GL_BLEND) y glBlendFunc()

[Lex]

...

[nsL]

Pero por ejemplo, ¿si pinto un poligono 100x100 con una textura 100x100, y luego si pinto otro poligono 200x200 con la misma textura de antes? ¿No afectara a la hora de la calidad el usar mipmaps? ¿o afecta solamente a la hora de renderizar mas cerca o lejos (Z), en vez del tamaño del poligono donde se pinte....?

Tengo algo de dudas sobre eso :D

Mas cosillas:

Estoy pensando usar GLUT para tener lo q haga multiplataforma. El problema es q he comprobado que el input de teclas va algo mal. Es decir, q si estas pulsando una tecla (avanzar por ejemplo) y pulsas la de girar,  gira pero deja de avanzar. Vamos, q no se pueden hacer combinaciones para q por ejemplo vaya en diagonal el muñeco. Usais alguna libreria para input cuando usais GLUT?

Saludos!!

[_Grey]

Pero por ejemplo, ¿si pinto un poligono 100x100 con una textura 100x100, y luego si pinto otro poligono 200x200 con la misma textura de antes? ¿No afectara a la hora de la calidad el usar mipmaps? ¿o afecta solamente a la hora de renderizar mas cerca o lejos (Z), en vez del tamaño del poligono donde se pinte....?

Si haces efectos de "Zoom" como el dices, puedes aprovechar los mipmaping. No importa la Z, la grafica mira si ha de "estirar" la textura, y coge el nivel de mipmaping que mejor le venga.

Al margen de lo que algun entendido pueda decir de tu otra consulta sobre GLUT, si finalmente optas por codigo Windows, puedes conocer el estado del teclado con una sola llamada a GetKeyboardState(); con lo que dependera de las soluciones nativas a este respecto de los otros sistemas si es algo facil o no, pero desde windows poco codigo habrias de cambiar.

Saludos.

[senior wapo]

Anda otro de Stratos en las Rozas... Respecto al tema, si vas a hacer un juego con proyección ortográfica, usar mipmaps creo yo que es tirar la memoria a la basura, porque aunque pongas un polígono en la coordenada Z -3000 se va a ver igual que en la 0.

No es así. Dicho de forma sencilla, el mipmaping no se aplica por distancia sino por la relación tamaño de pixel a texel.

Si pintas un quad que ocupa 64x64 pixels en pantalla usando una textura de 128x128 texels usaras el siguiente nivel de mipmap, no la imagen principal de la textura.


Mipmapping se usa para filtros de redución de tamaño. Para aumentar se tira de interpolaciones (filtro bilineal normalmente).

Otro uso del mipmap es forzar usar un mipmap de nivel inferior al que le corresponde a un poligono con la intención de hacer que salga la imagen borrosa por el filtro bilineal del zoom.
Pintas exactamente el mismo quad con las mismas coordenadas de textura pero fuerzas a la tarjeta a usar el siguiente nivel de mipmap en cada fotograma: obtienes un efecto de enborronamiento progresivo. O en sentido contrario, un efecto de enfocar una imagen si empiezas con el nivel de mipmap mas bajo (1X1) y vas subiéndolo.

Si haces eso mismo pero desactivando filtro bilineal y poniendo nearest (truncamiento), lo que obtienes son efectos de pixelización.

[Lex]

...

[marcode]

No estoy de acuerdo en eso último, no tiene nada que ver el filtrado con el mipmaping.

[senior wapo]

No estoy de acuerdo en eso último, no tiene nada que ver el filtrado con el mipmaping.

No comprendo que intentas decir sobre lo que he puesto.

[Loover]

Otro detalle.

Para poder poner en pantalla imágenes de cualquier tamaño (incluidas aquellas mayores que el máximo de textura permitido por el usuario) deberías cortar cada imagen en bloques y dibujar estos juntos (y que se vean afectados todos ellos como un grupo por las traslaciones, rotaciones y escalados). Esto es por lo menos lo que hago yo en LooverLib, así puedes dibujar por ejemplo una imagen de 12x1 o de 123432x234323. En el segundo caso lógicamente se cortara en muchos bloques. En LooverLib el tamaño de bloque se calcula automáticamente (teniendo en cuenta el máximo de textura permitido y las dimensiones de la imagen) o bien se deja a elección del usuario (para hacer un scroll).

Y no, no se notan los cortes entre bloques absolutamente nada, ni tras las rotaciones o escalados.

[marcode]

No estoy de acuerdo en eso último, no tiene nada que ver el filtrado con el mipmaping.

No comprendo que intentas decir sobre lo que he puesto.

No me extraña, con el mensajito tan escueto que he puesto...

Quería decir que puede haber filtrado sin mipmaping y viceversa. Vamos.. que no es necesario el mipmap para que queden suavizadas las texturas reducidas.

Perdona por no haberme aclarado.

[marcode]

creo que interpreté mal esta frase:

Mipmapping se usa para filtros de redución de tamaño. Para aumentar se tira de interpolaciones (filtro bilineal normalmente).

Y a la duda de nsL de la memoria que ocupan los mipmaps, aproximadamente un tercio del tamaño de la textura.