Revolution Engine

Se agradece el ofrecimiento, pero la verdad es que ayer terminé la versión 0.2, con transparencias y todo

Ahora lo colgaré todo en mi blog, es que antes no he tenido tiempo.

technik.. yo no he sido capaz de ponerle ninguna textura al cubo... En concreto he transformado una imagen cualquiera a un .png mediante el paint de windows (si! tela de profesional!), pero no me sale nada en el cubo. Solo obtengo patrones de lineas.

¿Hay alguna restricción en cuanto al tamaño en pixeles del png?

A eso te puedo contestar yo: Si que la hay, tanto el ancho como el alto de las texturas de Wii SIEMPRE deben ser múltiplos de 4.

technik: ¿Has probado a poner muchos cubos a ver hasta donde aguanta la consola?

oyzzo, lo de las transparencias cre que lo voy a hacer mejor con GX_DECAL, me resulta mas comoda esa ecuacion. De todas formas no la he implementado aun simplemente por falta de tiempo. esta tarde me pondre a ello. Dado que las PNGU me proveen del canal alpha no es nada complicado adaptar als transparencias a GX. Lo que pasa es que en vez de utilizar modulate, utilizare decal porsi quiero que el objeto en si no sea totalmente trasparente con una textura encima, sino que el color de fondo tenga trasnparencia parcial, independientemente de la trasnparencia de la textura. Modulate lo veo mas para uno de los TEVstages superiores, a los que les tengo preparadas funciones que pueden ser interesantes. De todas formas gracias por interesarte
Moki, la restriccion de tamaños es como te dice frontier, por el tema del acceso en memoria tengo entendido.
frontier, si quieres hago ahora una demo con un monton de cubos, a ver jeje.

Pues estaría bien ver esa demo jejeje.

Por cierto technik, he enlazado el blog del revolution engine desde el mío, espero que no te importe.

pon un multiplicador de cubos y un contador xDD a ver cuando revienta =P


frontier, si hay transparencias con grrlib, lo he estado repasando y si pones el color a 0f5c o algo asi se hace transparente =3

pho: Ummm, no sabía nada. Me imagíno que será un color especial que define GRRLIB y que omite pintar cuando pasa la imágen de su búfer interno al búfer de video. Gracias por la info.

Creo que es el truco de konta al que te referias xDD, porque es lo que se me habia ocurrido hacer al ver su soruce y al ir a modificar he visto que ya estaba xDDD

Podrías postear el source para que veamos como va

Vuestros deseos son ordenes
Ya hay colgada una demo con un monton de cubos y su correspondiente source. No he hecho nada mas chulo porque el cargador de 3Ds me esta dando problemas con las DisplayLists, sino os habria puesto un modelo repetido muchas veces. A ver si lo soluciono pronto porque pensandolo un poco creo que es de lo poco que me queda pra liberar el engine en su primera version. Creo que le metere eso, algo superficial de 2D y luego solo me queda pulir algunas funciones que van algo bruscas, pero creo que puedo decir que el Revolution Engine esta cerca

Ahí va un "semiofftopic":
technik, te sugiero que linkees el blog del proyecto en tu ficha de datos de usuario. He caído en la cuenta ahora que he querido visitarlo y se me ha hecho necesario moverme varias páginas hacia atrás en el hilo.

El Revolution Engine cada vez más cerca... Cosas como ésta son las que de verdad me hacen no arrepentirme de haberle hecho un hueco a la wii en el salón; que bien pinta la scene y que bien que le va a venir este motor.

Chapó.

La demo de MuchosCubos no se puede bajar desde blogger....

EDIT: No hay manera.... pongo el plasma.png en la SD, asegurandome de que la textura tenga dimensiones de multiplos de 4 pixels, pero nada. En concreto la textura que estoy intentando cargar es esta:

No importa cuantas veces cambie el tamaño, siempre me sale el mismo cubo con lineas...

No me he parado a comprobarlo, pero casi seguro que el problema está en que la imágen es paletizada. Abrela con el paint de windows y guardala como png con otro nombre. Eso debería convertirla a RGB auténtico y hacer que se muestre correctamente en la demo.

Ahora mismo PNGU no carga imágenes paletizadas, aunque al menos permite identificarlas. Mi idea era no dar soporte a este tipo de imágenes porque están obsoletas y daría mucho trabajo implementarlas en la librería. Ahora ya no estoy tan seguro porque he visto que hay mucho software de tratamiento de imágenes que aún las usa...

Hola, queria informaros que en el source de la ultima demo de unos de los programadores del GRRlib, hay una nueva version de las librerias en las que puedes indicarle el tipo de opacidad que quieres al presentar una imagen
void GRRLIB_DrawImg(int xpos, int ypos, int width, int high, const u16 data[], float rad_ang, float rapport, int alpha )
donde alpha = a la opacidad.

La demo la podeis encontrar aqui:
http://www.wiibrew.org/wiki/Homebrew_apps/ExistenzE

Tambien otra nueva libreria de sonido llamada Sndlib_beta1.0, que se trata de una libreria de sonido para la wii, que es una pasada. Claro esto no tiene que ver mucho con el tema del engine, pero en uno de los ejemplos de la libreria, mientras suena una musica de fondo, se muestran en pantalla 900 cubos girando, junto con 900 secciones de 'suelo' y una iluminacion compuesta por tres fuentes de luz 'Spot' , eso ya interesa mas no? igual a alguien le interesa.

La libreria la podeis encontrar aqui:
http://www.entuwii.net/foro/viewtopic.php?f=6&t=24


Venga saludos.

A ver, intento responder a todo
realbrucest Listo, ya esta el enlace como mi pagina personal.
Moki_X Ya he arreglado el enlace de la demo de muchoscubos. Con respecto a lo de la imagen, si quereis subo la que uso yo para evitar errores, pero debe funcionar con cualquier imagen no paletizada (de colores no indexados). De hecho la que yo uso era paletizada pero lo arregle con el photoshop (imagen->modo->RGB, o algo asi).
Kontakatilu El sonido tambien es interesante, no vamos a tener todos los juegos sin sonido verdad? no molaria.

Mientras tanto sigo con las displaylists. 1 saludo a todos

EDIT: Yo pongo las imagnes en la raiz de la SD, pero quiza tenga relacion con que uso el tcp loader del canal hombrew en vez de meter el programa en apps/

Moki_X escribió:La demo de MuchosCubos no se puede bajar desde blogger....

EDIT: No hay manera.... pongo el plasma.png en la SD, asegurandome de que la textura tenga dimensiones de multiplos de 4 pixels, pero nada.

No importa cuantas veces cambie el tamaño, siempre me sale el mismo cubo con lineas...

Acabo de probar la imagen que has puesto y a mi me funciona correctamente.... Pon la imagen con el nombre de plasma.png en la carpeta donde tengas el elf (asi es como me ha funcionado a mi)

kikex-box escribió:
Acabo de probar la imagen que has puesto y a mi me funciona correctamente.... Pon la imagen con el nombre de plasma.png en la carpeta donde tengas el elf (asi es como me ha funcionado a mi)

OK. estaba poniendo plasma.png en la raíz de la SD, por eso no me chutaba...

He probado la demo de MuchosCubos. La textura la carga correctamente, pero salta un code dump al pulsar home para volver al menú del HBC.

PD.: Releed la última frase que he escrito... ¿a que parece un idioma distinto? xD

EDIT: mira http://btemplates.com/ a ver si encuentras alguna plantilla un poco más vistosa para el blog... que esa que tienes puesta hace llorar los ojos

Kontakatilu escribió:void GRRLIB_DrawImg(int xpos, int ypos, int width, int high, const u16 data[], float rad_ang, float rapport, int alpha )
donde alpha = a la opacidad.

Te Quiero *_* xDDDDDDd

muy buena la demo technik =33

technik de que formas cargas las texturas? ocupas GRRLIB o directamente por GX.
te envie un mp revisalo

Carnage, me ha gustado mucho ese port del tutorial de opengl, yo hice esos mismos tutoriales en su dia
¿Lo has hecho usando tinyGL? Yo el tema de las texturas lo hago cargando las imagenes con pngu y de ahi directamente las proceso con GX. Y para el 2D tampoco voy a usar GRRLib (demasiado lento) voy a hacerlo directamente sobre el modulo de video de la wii

Technik:
No las portie directamente a GX, hay varias cosas interesantes que se pueden hacer, estoy tratando de hacer las tut de carga de modelos y bsp, perdona si las respuestas estan medias desfasadas, pero es el tema del horario aca en Chile

Has probado a hacer algo de texturas? La verdad es que GX viene muy bien preparada para las texturas (menos cierto detalle rgb5a3 verdad frontier? jeje) y se pueden ahcer muchas cosas si usas las pngu. Esta muy bien que trabajes sobre GX directamente, Es mucho mas rapido, pero como son ports de OpenGL pense que usabas TinyGL.
EDIT: Con respecto a los cargadores de modelos, yo estoy haciendo uno para las pruebas ahora mismo, pero estoy pensando que voy a definir mis propios formatos de archivo para el motor grafico, porque sino hay cierta informacion sobrante que se carga sin necesidad, y ademas muchos formatos no son open source y hay informacion que no es facil rescatarla, y luego se pierde tiempo en las onversiones...nose, muchas cosas. Ve contandome tus avances, si quieres ayudar con el engine, siempre hay sitio para mas programadores jeje.

technik, hechale un vistazo al formato Wavefront .obj. Es muuy compacto y muuy simple, y ademas lo soportan todos los programas de modelado 3D que conozco. Tengo hecho el parser y funciona perfecto, Carga los datos en memoria dinamica bien y todo... solo me falta solucionar el problemilla ese que hace que se cuelgue GX_DrawDone.

technik escribió:Has probado a hacer algo de texturas? La verdad es que GX viene muy bien preparada para las texturas (menos cierto detalle rgb5a3 verdad frontier? jeje) y se pueden ahcer muchas cosas si usas las pngu. Esta muy bien que trabajes sobre GX directamente, Es mucho mas rapido, pero como son ports de OpenGL pense que usabas TinyGL.
EDIT: Con respecto a los cargadores de modelos, yo estoy haciendo uno para las pruebas ahora mismo, pero estoy pensando que voy a definir mis propios formatos de archivo para el motor grafico, porque sino hay cierta informacion sobrante que se carga sin necesidad, y ademas muchos formatos no son open source y hay informacion que no es facil rescatarla, y luego se pierde tiempo en las onversiones...nose, muchas cosas. Ve contandome tus avances, si quieres ayudar con el engine, siempre hay sitio para mas programadores jeje.

Si de hecho estoy probando con el tema de texturas en tga (estoy bastante acostumbrado a ese formato por todo el asunto de Quake). No has pensado en el formato md3?, es open y hay bastante documentación al tanto. Si por su puesto que deseo ayudar con el engine, gracias.

Como usas tga? hay alguna libreria por ahi o te la has hecho tu? porque la Wii no usa internamente cualquier formato.

technik escribió:Como usas tga? hay alguna libreria por ahi o te la has hecho tu? porque la Wii no usa internamente cualquier formato.

No la estoy haciendo yo, te acuerdas de las tutoriales, la 4 de tex mapping, viene completo la carga de tga, mejor que como se hace en quake, luego le aplicas lo raro de rgb5a3 y listo

Bueno, al fin funciona mi cargador de modelos 3D en formato wavefront obj. Aun se le tiene que dedicar un par de ratos para que funcione bién, pero el trabajo mas duro ya está hecho
En el leeme.txt explico un poco lo que hace y lo que le falta por hacer

Os dejo también algunos modelos que he usado yo para probarlo, el menor tiene menos de 5 caras y el mayor tiene mil caras.
Ahi va:
http://www.mediafire.com/?2u2tdtviyyp

Oyzzo, ya que lo has publicado en el hilo del Revolution engine, entiendo que me permitirias usarlo/integrarlo en este o alguna aplicacion del mismo?

oyzzo escribió:Bueno, al fin funciona mi cargador de modelos 3D en formato wavefront obj. Aun se le tiene que dedicar un par de ratos para que funcione bién, pero el trabajo mas duro ya está hecho
En el leeme.txt explico un poco lo que hace y lo que le falta por hacer

Muy bueno! Pero con el modelo del coche se vuelve loco , por lo menos a mí me salen triángulos aleatoriamente por el exterior.

technik: cuando lo termine lo puedes incluir en el engine. yo solo lo usare para los juegos k haga

lo de los triangulos locos es por las normales k aun no las carga. esta noche me pongo con ello

perdonad que me meta donde no me llaman, pero creo que lo mejor para todos seria que formarais un grupo con los programadores que esteis en el engine.
asi podriais asignaros una parte cada uno y depurando conjuntamente.
es solo una opinion pero seguid asi que al final saldra algo grande y en los juegos en los que programe usando vuestro motor saldra lo primero el logo y sus creadores en los creditos

HEHEHEHE! esa risa es debida a que tengo rulando la iluminación ya una demo muy simple con cubos. Voy a terminar de hacer que el cargador de modelos cargue las normales, así puedo aplicar iluminación a los modelos ^^

amdiaz: aunque yo no esté en el engine cedo mi codigo gustosamente a technik para que lo use.

Gracias a todos por el trabajo que os estáis dando para que otros podamos hacer juegos decentes en Wii. Este engine va a ser muy útil y todo es gracias a vosotros.

Bueno, pues ayer conseguí cargar las coordenadas uv de las texturas y las normales del modelo. El problema es que siguen habiendo algunos triangulos locos. Si alguien se ve con animos de hecharme una mano(technik?) para ver porque hay algun punto de algun triangulo que se dibuja mal... es lo ultimo que falta para que se carguen perfectos los modelos.

oyzzo, por supuesto que me ofrzco a ayudarte. Ahora mismo estoy demasiado liado para hacer modificaciones gordas en el engine pero si que tengo tiempo para echarte una mano en lo que pueda.

Ok, pues le voy a añadir que dibuje el wireframe de los modelos para que se vea mejor las diferentes caras y te paso el codigo con los modelos que uso de prueba. Yo para crear modelos y retocarlos uso wings3D que es libre, sencillo y rula en cualquier lado. Los modelos tienen que estar formados por triangulos, tener coordenadas de texturas (aunque no tengan textura) y el .obj debe terminar con una linea vacia.
Yo lo que hago es:
creo un modelo o lo modifico con wings.
para crear coordenadas de texturas selecciono el modelo y le doy a create uv del menu (boton derecho). Selecciono edges, le doy a mark edges tu cut, continue y listo.
le doy a exportar wavefront obj activando tesellation: triangles para que lo exporte como caras triangulares.
Abro el modelo con vim(notepad o lo k sea) voy al final y le pongo un enter.

Eso es todo. Si quieres modificar un modelo de los que te paso no necesitan todo eso, solo modificar lo que quieras y exportar.
Los controles son: crucetas cambia el eje de rotación, (A) hace que rote en los 3 ejes y (B) activa/desactiva el wireframe. Home sale.

EDIT: Lo tienes en MP
EDIT2: si quieres algun modelo pidemelo por mp y te lo envio en un momento.

EDIT3:
Dejo un video para los que lo quieran ver:
http://es.youtube.com/watch?v=w1OyKLKcjms

EDIT4:
BUENAS NOTICIAS! el cargador de modelos .obj ya va perfecto He solucionado el maldito bug que causaba las caras locas xD (me ha costado 3 dias con sus respectivas noches) pero antes de poner una demo voy a acabar de añadirle la textura.

Oyzzo, me encanta tu cargador de modelos
Lo voy a añadir al engine desde el primer momento (siempre que te parezca bien, por supuesto). Es mas, me ha recordado que por ahora no os he dicho como desarrollar cosas mas compatibles con el engine. No pasa nada, mas vale tarde que nunca. Por esto he puesto en el blog del engine una entrada con tooooda la informacion que usa internamente el engine para trabajar con modelos 3D.
He tenido que hacer un par de sacrificios en cuanto a sofisticacion para que os sea mas sencillo comenzar. En futuras versiones el formato se hara mas complejo, optimizado y eficiente, pero por ahora esta bien asi. Esta todo detallado para que no tengais problemas creando funciones, pero si no entendeis algo o teneis algun problema con ello solo teneis que postear vuestras dudas aqui
Ademas de esto, dentro de 2 o 3 dias sacare una version limitada del engine para desarrolladores. En realidad no se si la publicare, pero os avisare cuando este lista para que me la podais pedir por MP los interesados. Esta version no traera casi ninguna funcion del engine, sino lo justo para que funcione el nuevo sistema de modelos y podais hacer vuestras propias pruebas. Esta medida es para evitar inestabilidades y problemas que no tengan que ver con vuestras funciones. Id contando por aqui todo lo que hagais con esto. Algunas cosas que se pueden hacer son funciones de creacion de Primitives (Adjuntare un ejemplo comentado) o cargadores de modelos 100% compatibles. En el caso del cargador de oyzzo, ni que decir tiene que no le voy a pedir al pobre que encima lo porte, con el trabajo que se ha pegado, si me pasa el source yo lo adaptare al formato (Seguramente el cambio no sea muy grande dado que parte de la simplificacion que hice iba encaminada precisamente a facilitar la compatibilidad con tu cargador.

technik, me parece estupendo que lo incluyas en el engine, de hecho por eso lo he ido posteando aquí y informandote de como iva el trabajo.
Lo de la estructura de modelos del engine, es muy parecido al que he usado pero agrupado en una estructura, así que dudo que llegue ni a 10 lineas de codigo el adaptarlo Te he enviado los sources por mp, si encuentras algun problema adaptandolo coméntamelo.

Ahora estoy haciendo pruebas con la iluminación, con un minimotor de partículas (simple pero resultón ) y quiero mirarme tb algo de física.

Para los que no quieran / puedan probar la demo k he colgado del visor aquí va un vídeo:
http://es.youtube.com/watch?v=sRBwG6FneLs

oyzzo escribió:Para los que no quieran / puedan probar la demo k he colgado del visor aquí va un vídeo:
http://es.youtube.com/watch?v=sRBwG6FneLs

Estupendo.

Supongo que podrá cargar desde FAT varios modelos cada frame, ¿no?

ANTONIOND escribió:

oyzzo escribió:Para los que no quieran / puedan probar la demo k he colgado del visor aquí va un vídeo:
http://es.youtube.com/watch?v=sRBwG6FneLs

Estupendo.

Supongo que podrá cargar desde FAT varios modelos cada frame, ¿no?

What?

frontier escribió:

ANTONIOND escribió:

oyzzo escribió:Para los que no quieran / puedan probar la demo k he colgado del visor aquí va un vídeo:
http://es.youtube.com/watch?v=sRBwG6FneLs

Estupendo.

Supongo que podrá cargar desde FAT varios modelos cada frame, ¿no?

What?

A ver... imagínate un juego con muchos modelos y texturas, tantos que es mejor no cargarlos en la RAM todos desde el principio. Tendrías que irlos cargando según los vas a usar, y para eso se tendría que poder cargar el modelo desde FAT, convertirlo al formato del engine y mostrarlo. Estoy preguntando si se puede hacer eso.

Ya te respondo yo. Que no cargues todo el juego desde el principio no quiere decir que tengas que cargar un monton de modelos por frame, simplemente tendras que administrar los tiempos de carga adelantandote a las necesidades del juego. Eso o mostrar la tipica pantallita de "cargando..." jaja

¿Con la velocidad del lector SD? NI DE COÑA.

De todas formas tienes espacio de sobra, en 80 MB caben muchos modelos y texturas. Además, ten en cuenta que sólo tendrás que cargar a la vez los contenidos de una fase.

technik escribió:Ya te respondo yo. Que no cargues todo el juego desde el principio no quiere decir que tengas que cargar un monton de modelos por frame, simplemente tendras que administrar los tiempos de carga adelantandote a las necesidades del juego. Eso o mostrar la tipica pantallita de "cargando..." jaja

Ok, jeje. Es que estoy programando un juego ahora en DS y la VRAM deja mucho que desear. Por si fuera poco, las libnds no tienen un sistema dinámico de administrar texturas, asi que no me puedo permitir el lujo de ir cargando todas indiscriminadamente, ya que para borrar una las tengo que borrar todas (o programar mi propio sistema para administrarlas, pero me da pereza, jeje). Voy cargándolas de FAT a la vez que los modelos, justo cuando los necesito (por lo menos una parte, y a veces cargo modelos sin texturas nuevas). Como no me va del todo mal en la DS (si, la carga de texturas es leeenta, pero la de display lists no) supongo que en la Wii irá mucho mejor. Acostumbrado a lo malo cualquier cosa sienta bien, no sabía que la Wii tiene 80 MB de RAM.

PD: Aun así, la velocidad de lectura de la SD es lenta y a veces me toca lo de "cargando..." .

ANTONIOND: La respuesta a tu pregunta es si, se pueden cargar modelos y texturas desde la SD cuando quieras, pero se puede hacer de mejor manera que cargar cada frame. Se Tienen que repartir los tiempos de carga. No vas a cargar al principio del juego todos los modelos... Cargas los que necesites y vas cargando según se necesiten y descargando los que no se vayan a mostrar. Por ejemplo si en un juego estas en una sala, puedes cargar los modelos de esa sala y los de las salas contiguas por ejemplo, y al pasar a una sala contigua se cargan los de las salas contiguas a esa y se liberan los demas. Así no aprecias retardos en las cargas ni tienes que poner loading, y solo tienes los modelos que se ven o los que se pueden ver a corto plazo.
Es solo una idea, pero dependiendo del juego se puede hacer de muchas maneras, eso ya depende de quien programe el juego

oyzzo escribió:ANTONIOND: La respuesta a tu pregunta es si, se pueden cargar modelos y texturas desde la SD cuando quieras, pero se puede hacer de mejor manera que cargar cada frame. Se Tienen que repartir los tiempos de carga. No vas a cargar al principio del juego todos los modelos... Cargas los que necesites y vas cargando según se necesiten y descargando los que no se vayan a mostrar. Por ejemplo si en un juego estas en una sala, puedes cargar los modelos de esa sala y los de las salas contiguas por ejemplo, y al pasar a una sala contigua se cargan los de las salas contiguas a esa y se liberan los demas. Así no aprecias retardos en las cargas ni tienes que poner loading, y solo tienes los modelos que se ven o los que se pueden ver a corto plazo.
Es solo una idea, pero dependiendo del juego se puede hacer de muchas maneras, eso ya depende de quien programe el juego

Ok, precísamente yo hago eso. Cargo los modelos iniciales cuando inicio la sala, y luego voy cargando unos pocos modelos o texturas según los necesito.

He estado mirando cierto documento ancestral y se me ha ocurrido una idea. Podríamos hacer una herramienta para guardar modelos en un formato propio. Almacenaríamos por un lado varios arrays (vértices, normales, etc...), por otro una display list ya compilada con los índices a esos arrays y por último los datos de las texturas utilizadas. Para las texturas podríamos hacerlo de dos formas: Guardar la textura ya convertida dentro del mismo archivo o guardar sólo una referencia a una imágen externa y convertirla en tiempo de carga.

Este formato de archivo, tal y como lo he planteado, sólo podría guardar modelos estáticos, puesto que usa display lists. Para modelos dinámicos tendríamos que usar otra cosa o bien almacenar los distintos frames de animación como modelos estáticos independientes (aunque podrían compartir las texturas y los arrays de vértices, normales, etc). Creo que para cargar y mostrar los escenarios sería muy útil, y muy muy rápido.

Si a technik y a los demás os parece buena idea me puedeo poner manos a la obra...

Lo del formato propio lo comente un par de paginas mas a tras jeje, parece que hemos tenido la misma idea. Lo que pasa es que me gustaria aprovechar y meter mucha mas informacion en el formato, no solo la informacion de display. La informacion de animacion no es incompatible con las display lists, solo es mas complejo, creo recordar. Y para los escenarios yo no usaria lo mismo que para los modelo. Para empezar en caso de terreno y otros escenarios de exterior hay formas mucho mas eficientes de almacenamiento que arrays de vertices, y en caso de interior habria que hacer un precompilado con un arbol BSP para acelerar el renderizado. Si te interesa el tema te puedo contar por MP como tenia pensado hacer el formato de modelos

Claro que me interesa el tema, espero tu MP.

Estoy de acuerdo con que no se debería tratar el escenario igual que los modelos dinámicos, y no he dicho lo contrario. El motivo principal de hacer esta distinción es que son cosas distintas, cada una con sus particularidades.

En cuanto a compatibilizar display lists y geometría dinámica... Nanai. No se puede y nunca se ha podido. Si quieres variar la geometría tienes que recompilar la display list, y eso te llevaría más tiempo que mandar los datos "a mano". Hace años trabajé con OGL, cuando aún no existían los vertex shaders, y la situación era la misma. Ten en cuenta que usamos display lists sólo porque es lo más rápido que permite la GPU de Wii, en el mundo exterior hace tiempo que quedaron obsoletas por esta y otras razones.

También estoy de acuerdo en que hay formas más óptimas de mover un escenario, pero todas ellas se aprovechan de alguna particularidad de ese escenario. Los terrains no permiten geometría cóncava y los BSP sólo dan buenos resultados cuando los polígonos son grandes. Por eso, para casos generales, lo más rápido es un array de vértices y una display list (a ser posible formada por triangle-strips en lugar de caras sueltas).

Por eso pienso que deberíamos tener un formato para el caso de escenario general, es decir, estático y sin "truquitos raros". Eso no quita para que haya otros formatos a disposición del usuario, tanto para modelos dinámicos como para casos especiales de escenario.

Esto marcha! me muerdo las uñas por no saber programar en opengl y poderos echar una manita, tantos avances y yo sin poder hacer nada de esto. Os dejo un video de mi ultimo trabajo que sacaré dentro de poco y asi no me siento tan mal, espero que no os moleste.

http://es.youtube.com/watch?v=dbASa-wLyY8

P.D.: Si os acordais de ciertos documentos sobre 3d, que sepais que tambien hay algunos sobre 2D, lo digo por si hacen falta...

Saludos...