Cuando empecé a estudiar el mundo de las tres dimensiones y todo lo que lo envuelve, me convencí de que si tenía que hacer algo, lo tenía que internar hacer realmente bien. El nivel de los Engines era demasiado alto como para introducir un simple mostrador de polígonos con más o menos velocidad. Necesitaba crear algo que realmente rompiera un poco con todo lo que había en ese momento y pudiera ofrecer algo nuevo a este mundo tan competitivo.

Bien, después de nueve meses de estudio, de aprender matemáticas desde cero, de un gasto importante en libros y en teléfono, creo que tengo un Engine que por lo menos rellena un hueco que hasta ahora estaba vacío.

Para entender bien el proceso que seguí para crear el Engine ( que aún no tiene nombre), voy a explicar brevemente lo que hay hasta ahora, o lo que pienso que hay, puesto que quizás alguien haya visto alguna cosa que yo no haya podido observar.

Los Engines actuales se basan en partir el espacio de manera que fácilmente el ordenador pueda eliminar un gran número de polígonos que no son visibles por la cámara. Esto que quizás parezca muy sencillo, es tremendamente difícil. Y no lo es porque no se sepan técnicas para hacerlo, que sí existen y están presentes en todos los modeladores 3D, sino que debe hacerse en tiempo real, es decir, a 30 imágenes por segundo como mínimo.

Un Engine se diferencia de otro fundamentalmente en la forma que tiene de dividir el espacio. Hasta ahora, el mundo se creaba con estructuras sencillas, es decir "paredes" simples que ayudaban mucho al ordenador a la hora de hacer los cálculos. Pero por desgracia esto implicaba objetos geométricamente sencillos y que no tuvieran una gran cantidad de polígonos. De hecho, si observamos los juegos que contienen estos Engines, veremos que la gran mayoría de estructuras son simples y llanos planos.

Otro Engine totalmente distinto es el que utiliza el juego Tomb Raider. Este Engine está basado en cubos de manera que fácilmente calcula si se ve o no se ve un cubo. Por desgracia tiene el mismo problema que el sistema anterior. ( ¡Atención, no estoy seguro de cómo funciona el Engine del Tomb, pero creo que es así, pero quizás me equivoque!)

Así que el final tenemos un grafista con unos conocimientos enormes sobre un programa de modelado al estilo 3DStudio Max o LightWave utilizando estructuras simples para crear los mundos.

Bien, pues yo partí desde aquí. Tengo que crear un Engine que permita a los grafistas hacer lo que quieran.

Y después de nueve meses, tengo algo bastante visible, por lo menos lo más difícil ya está hecho y funciona, que es la partición del espacio.

Bueno, en realidad el Engine no está basado en polígonos, sino en objetos. Esto parece una tontería pero es muy importante. Imaginemos el siguiente caso:

Este castillo ha sido creado por un amigo mio muy metido en esto de los videojuegos y que ha creado ya verdaderas obras maestras.

Bien, pues a lo que íbamos. Este castillo está formado de objetos. Las torres son objetos, las murallas también. Pues si yo en algún momento veo un trozo de torre, lo más normal es que vea los trozos que me faltan. Entonces para qué partir la torre en cientos de polígonos y comprobar si se ven, cuando la mayor parte de veces que se tiene que ver la veo enterita.

Esto implica una gran ventaja: la torre puede ser un objeto muy complejo. Si veo alguna parte de la torre, sé que tengo que dibujar el objeto ( en realidad no se dibuja todo, se hacen muchos cálculos previos para saber qué es lo que se ve de un objeto. Para hacerte una idea, las tablas ocupan ahora mismo 9MB!)

Bueno, esto también implica un poco de responsabilidad para el grafista. Mira este ejemplo:

Aquí ten un poco de imaginación y piensa que los círculos azules son estatuas muy detalladas.

Si colocamos las estatuas a esta distancia, podremos tener una super-estatua por habitación y nunca veremos las dos, con lo que el número de imágenes por segundo aumenta.

Pero en el caso de la derecha, en algún momento podremos ver las dos estatuas, con lo que la velocidad del juegos se vería disminuida. Este caso no es que sea incorrecto, simplemente el grafista podría haber pensado que si la coloca como en el caso de la izquierda, no se dibujarían nunca las dos, y así se ganaría mucho en velocidad. Pero repito que el segundo caso se admite perfectamente y el Engine lo tratará de la forma que encuentre más conveniente.

Bueno, los objetos pueden ser como quieras y pueden tener el número de polígonos que hagan falta, pero no nos engañemos, a mayor número de polígonos mayores cálculos y más lentitud. De todas formas utilizando el truco de las habitaciones podríamos soportar un número muy elevado de polígonos sin perder velocidad, claro que al final todo depende de muchas cosas.

Pero lo que no soportaría, y no deseo en absoluto, es que se utilicen objetos planos. Por favor, ya que he tardado tanto en desarrollar el Engine y he dotado a los grafistas de la posibilidad de usar objetos orgánicos, utilizad este potencial. Aquí os muestro un ejemplo de un objeto que podría funcionar perfectamente con el Engine:

Este objeto NO está optimizado, y se deberían SIEMPRE eliminar los polígonos que no sirven para nada. Pero da una idea de lo que se debería hacer: objetos rugosos, orgánicos, con vida!.

Ahora podríamos formular una buena pregunta:

Pero si cerramos una de esas puertas y la habitación no se debe ver completamente, lo mejor es que dividamos el objeto en tres objetos. Siempre depende del tipo de juego que queramos hacer y dónde queremos situar este objeto.

Otra cosa muy importante a tener en cuenta es el tamaño del objeto. Para que os hagais una idea, si nosotros dibujaramos en MAX un cubo de 1 unidad por 1 unidad y colocáramos la cámara a una unidad de distancia, esto es lo que veríamos:

No hagas caso de la sombra, son pruebas. Aquí lo que importa es el tamaño. De todas maneras sé que al principio los grafistas se emocionan y empiezan a hacer virguerías que luego hay que retocar. Lo mejor es empezar con alguna cosa pequeña, mandármela y yo la estudio y os explico el porqué debería de hacerse de una manera o de otra.

Bien, en principio esta beta del Engine revisión 0.000000000000000001 no soporta transparencias, pero si alguien me manda algo con transparencias, mejor porque así puedo programarlo.

Las texturas tienen que ser BMP de 256x256 como máximo y tienen que ser cuadradas potencias de 2, es decir: 2,4,8,16,32,64,128,256 y el nº de colores sería muy conveniente que fuera de 256, aunque admite sin complejos 24 bits, pero la memoria después se queja un poco!

Si quieres hacer animación, utiliza texturas del mismo tamaño y númeralas, por ejemplo: fuego1.bmp, fuego2.bmp fuego3.bmp y utiliza fuego.bmp (sin numerar) en el programa de modelado.

No te emociones con los parámetros de los materiales porque por ahora no se soportan, pero si crees que debería soportar alguna característica comunícamelo e intentaré programarlo.

Cuidado con el número de texturas utilizado. Piensa que las tarjetas tienen como mínimo 4 MB de RAM de vídeo, y si el juego va destinado a este rango de tarjetas, no podremos utilizar muchas texturas.

Bien, si sabes lo que son los Vertex Colors, perfecto, porque el programa los soporta. Si no es así, mejor te lo explico cuando me mandes alguna escena con luces.

En conjunto te diré que el Engine soporta las luces y las sombras, por lo que deberías colocar focos de luz para que la escena tenga más o menos dramatismo. También activa las sombras, puesto que el Engine también las reconoce.

Puedes utilizar luces de colores sin problemas.

Bueno, ya sabéis que un Engine si física es como un arco iris sin azul!( qué chor...!!) Ahora en serio. Este engine tiene todas las características idóneas para tener la física más perfecta del mundo de los videojuegos. Ahora mismo la colisión es PERFECTA con cualquier objeto, sean torres especiales, donuts o cualquier cosa. Y no tarda mucho en calcularse, aunque posiblemente es un apartado que todavía puede mejorarse muchísimo. Imagínate una esfera que cae rodando por una superficie inclinada. Alucinante, pero muy corriente hoy en día. Ahora imagínate esa misma esfera rodando por un plano inclinado llenos de abolladuras. ¡Mucho más alucinante verdad! Pues esto es posible con este Engine. Pero aún estoy estudiando la forma de implementarlo de una manera sencilla con la escena. Así que por ahora de física no hay que preocuparse, es cosa mía.

El Engine es para los grafistas, así que si tenéis alguna idea, decídmela, quizás pueda hacer realidad vuestros sueños.

No soporta animación todavía pero lo soportará.

Si estás utilizando el MAX, colapsa todos los objetos y asígnales vertex colors.

Yo también!! No, ahora en serio, lo vereis cuando tenga algo realmente impresionante, al estilo Quake III. Así que también tendréis que aportar vuestro grano de arena, porque aunque ahora tengo una demo, no está el objeto optimizado para el Engine, ni puede verse en todo su potencial.

Yo soy el que más ganas tiene de que la gente vea el Engine y diga:¡lo quiero para mi juego!. Pero llevo muchos años en esto y creo que es mejor impactar de golpe que no ir dando Betas y Betas.

Qué tengo que mandarte.

Bueno, pues la escena en formato MAX 2.0 ó 2.5 y las texturas en un mismo directorio. Piensa que para generar el mapa, el programa que recorta los objetos en polígonos y los divide en el espacio puede tardar SEMANAS en calcularlo todo. ( Hombre que creías, ¿que esto estaba chupado? Para que tu puedas dibujar lo que quieras en el MAX, YO tengo que currar mucho y ¡el ordenador muchísimo más!).

Así que al principio mándame poca cosa, unas tres habitación o algo así. Yo la estudiaré y te diré si hay que hacer algún retoque o no para optimizar el Engine.

Mándame el mensaje a mi dirección y enseguida que pueda lo probaré y te diré cosas.

Pues Javier Maura.