Buenas noches, gente de Stratos.
Hace poco me he decicido embarcar hacia el desarrollo de un pequeño motor 3D por software, para la consola portatil libre llamada GP2X. (Para mas información sobre ella,
http://www.gpx2.com ).
Comprendo los fundamentos de las tranformaciones geometricas 3D (¿Quien no ha hecho el tipico cubo rotando?) y, aunque ya tengo unos cuantos aspectos del motor finalizados (Matemáticas en punto fijo usando ASM de ARM, Vectores, Matrices, Polígonos (Flat, Gouraud y Texturizados, aunque nada de corrección de perspectiva y alguna chorrada más) se me ha planteado un serio problema al concebir el funcionamiento a la hora de renderizar.
El problema es el siguiente: Si manejo la escena mediante nodos de objetos, que a su vez se enlazan a mallas y texturas en listas de recursos, ¿cómo podría llegar a determinar el orden de dibujo de los polígonos de todos los objetos para que no se superpongan entre ellos, sin utilizar un zbuffer?
He pensado seriamente en implementarlo o no, pero aunque los resultados sean excelentes, puede causar un mal rendimiento. Entonces, ¿que deberia hacer? ¿Debería volcar todas las caras de todos los objetos en un array gigantesco pero limitado y ordenarlos por Z? ¿O conoceis algun metodo mejor?
Muchas gracias :)
Hola, leo de tanto en tanto el foro de gp32spain, quiza vengas de alli, si bien no participo, me intereso la GP32 y me interesa la proxima.
Digo esto por que no se si seras de esos que estan con el clon de wipeout o intentando algo para la GPX2, algunos piden un port de OpenGL.
-----
Lo primero es contarte que en librerias como OpenGL y Direct3D los poligonos de renderizan en el orden que les llega, normalmente se encarga el Zbuffer de que todo salga bien, si se trata de poligonos con transparencias no queda mas remedio que ordenarlos y dejarlos para el final.
Como tu no quieres usar Zbuffer, vale, cosas de rendimiento, no te queda mas remedio que ordenar.
Quiza sea un array muy grande, pero no te queda otra que ordenar, y para eso tendras que tener un gran array de poligonos de todos los objetos.
Quiza pienses en la posibilidad de ordenar a nivel de objetos, para que el array de poligonos general sea menor, pero con un objeto tan grande como el decorado dara problemas, no vale la pena complicarse.
Ya que estamos, deja que te recomiendo el libro
"Tricks of the 3D Game Programming Gurus-Advanced 3D Graphics and Rasterization", esta muy bien, pero lo mas interesante para este caso, es que todo es a nivel de soft.
Saludos.
En las noticias de la GPX2 pone que estan desarrollando estas cositas:
1. Game SDK with GCC 4.x
2. Genesis/Megadrive/MegaCD
3. Sound core, Doom porting, SNES
4. Neo-Geo
5. Quake engine porting, 3D work
6. NES, SMS, MSX, GBC, GB
7. Others: Utility development for ARM
8. 3D graphic library, 3D engine and examples
9. Naruto 3D porting, New 3D racing game(like wipeout), Gunbound clone
10. MAME, PSX, Dos Box(PC emulator with MS-DOS)
11. Build SDL/Lib C cross compiling toolchain, VBA32(GBA emulater)
These programs are being developed now, more information will be given in mid October
Como mola, que fabricas una consola, tienes a la gente trabajando en software para ella y luego anuncias como tuyo el software que hacen otros :P
Ya te digo XD
Pero bueno, habra que ver que tal esta la GP2X (genial)
Yo estoy esperando con MUCHA curiosidad esta nueva consola :)
Muchas gracias Grey, le hecharé el guante al libro este en cuanto pueda :)
Un z-buffer por software puede ser mucho más rapido que la comprobación de distancia de cada objeto, principalmente porque el consumo de tiempo crece de forma lineal, si ordenas los objetos por distancias tienes que comprobar todos los objetos con todos por lo que crece de forma exponencial a medida que vas añadiendo y si vas a comprobar una lista enorme al final te puede ir lentísimo.
Además el ordenar por objetos no funciona muy bien, la comprobación deberá realizarse con todos los polígonos, y aun así seguirá sin ser correcto porque cada polígono tiene al menos tres vertices que hay que tener en cuenta para que no se solapen unos con otros, por lo que se debe de realizar un monton de comprobaciones para que no tenga fallos.
Wolfestein 3D funcionaba perfectamente en un 80286 sin coprocesador matemático ni na, quizás puedes encontrar cosas en su código fuente para ver como lo hicieron.
http://site.n.ml.org/info/_msdos-games/
Por lo que se lee aqui, para la GP32 ya han logrado portar el Quake, el Duke Nukem y ademas estan probando un motor 3D
- Duke Nukem 3D para Gp32!
- Quake portado para GP2X !!
- WipeOut para Gp32 !! , Engine 3D v-0.1 (ArChEr está trabajando en un engine 3D para Gp32. También esta haciendo un juego basandose en el.)
http://www.gp32games.com/
El que va de puta madre en la gp32 es el doom, con todas las musicas, graficos y sonidos del original :D
Tambien se comenta por ahi que la gp2x es capaz de hacer cosas como el Quake 2... A ver si es verdad (genial)
El Wolfstein 3D tiraba rayos para determinar visibilidad ... eso no creo que sirva ...
El ordenamiento de poligonos es nLogn con n = 10K -> O(n) = 100K maximo con una resolucion de 640x480 tenes 300k de comprobaciones mínimo por frame lo cual es como para querer escaparle ...
Si tenes material estatico como un mapa, un sistema como el BSP te vendria al pelo ... ordena los poligonos de atras a adelante en forma lineal, aparte que te divide el espacio en partes convexas con lo que te da lo posibilidad de PVS ...
Ahora si no cuentas con un mapa muy grande y el queso esta en la cantidad de modelos ... tienes varios sistemas, pero aun así no podras escapar del zbuffer para modelos detallados ...
Las tecnicas que yo utilizaba cuando hacia render por software ( o que iba a implementar ):
* Arbol BSP ( de cabeza ) y PVS, 80 % de rendimiento lo sacaras aquí
* S-Buffers o S-Heap ( sirve para poligonos grandes ). Son listas/heaps de lineas de rasterización, se precalculan y al final se rasteriza ..., para que tengas una idea:
struct Span { int x1, x2, z1,z2, idSuperficieDelMapa; };
* IZ-Buffer. Un z-buffer que guarda el 1/Z.
* LightMaps para precalculo de luces estaticas en superficies estaticas.
Don Carmak usaba algunas mas pero no estoy seguro ahora, igual con esas tenes para rato ... y mejorará un monton cualquier render por software ...
Fiero es el mas indicado para hablar del tema pues es él el que anda en el tema del render por software ...
Saludos.
La GP es lo mas cercano que existe a una portatil de marca blanca.
Me pido la version a GP2X del motor c# :P
Cita de: "seryu"una portatil de marca blanca.
¿Qué es?
Si piensas usar rasterización por software entonces no te queda más remedio que hacer un motor especifico para el tipo de juego en lugar de uno genérico.
En los quakes se dibujaba primero el mundo mediante S-buffers horizontales (escribiendo en Z y sin comprobar Z porque el BSP ya te los da ordenados y los poligonos estaban cortados para no cruzarse entre si). A continuacion se dibujaban los objetos (MD1-2) con test de Z. Luego se dibujaban los poligonos transparentes (con test de Z). Los poligonos de cada objeto no se ordenaban.
En Doom 1-2 se dibujaban los poligonos de las paredes sin Zbuffer, columna a columna, manteniendo una lista de bordes por columna que permitia reconstruir los spans horizontales de suelos/techos de dicho sector (nodo BSP +/-). Los poligonos te los daba ordenados el BSP. Dibujas nodo a nodo del BSP y pones cada columna de pixeles de cada sprite en dicho sector en una lista y recortas contra los bordes dibujados del sector actual. Luego dibujas los demas sectores más alejados según el BSP y al final del bucle cuandp ya está todo el escenario vuelcas todas las tiras de sprites de atrás a adelante.
Hay muchas optimizaciones de los algoritmos que dependerán del tipo de motor que pretendas usar en tu juego, y en render por software es crucial emplearlas, asi que nada de engines genéricos si no quieres hacer algo limitado en plan demoscene.
EDITADO: El algoritmo del wolfenstein lo dejo fuera asumiendo que la consola puede mover DOOM o Quake por soft, si no es asi, pregunta.
CitarQUOTE (seryu @ 03/10/05, 18:00 )
una portatil de marca blanca.
¿Qué es?
Que no sea de marca.
Hmmmm, es la primera vez que oigo hablar de esa consola, pero por lo poco que he visto tiene una pinta brutal! :blink:
No me he enterado de nada, como está el tema? Dónde y quien la vende? Por cuanta pasta? La resolución de vídeo me parece buenísima, y la idea de que la gente pueda hacer sus juegos o lo que quiera libremente también. :huh:
Hace unos 4 o 5 años salió la GP32, que es una consola Koreana. Pero hasta hace un año no se comercializó aquí en España, y llegó a manos de Virgin, por 190 €.
Ahora, la compañia que hizo la GP32 se ha dividido en dos, Gamepark y Gamepark Holdings. Gamepark ha decidido lanzar una consola potente (la XGP, al estilo de la PSP, se dice que quieren portar el quake 3 para esta) pero cerrada, y Gamepark Holdings ha decidido lanzar la GP2X (Que es la que he puesto los specs antes) que será completamente libre, y apoyará a la scene.
La GP2X saldrá este mes, por 168€ y la podras reservar desde www.hardcore-gamer.net , que son los distribuidores oficiales aquí en españa.
:)
Hace unos meses cuando conocí este nuevo "juguete" estuve a punto de comprarla, pero al saber que va a salir un modelo igual pero mejor decidí esperar... así que veremos que tal :)