miércoles, 23 de enero de 2008

OGRE (V): Trasteando un poco

Para finalizar esta introdución, se profundizará en el manejador de escena y algunas características curiosas. Se mostrará algo de lo que OGRE puede ofrecer. Éste suministra una serie de demos técnicas en las que se puede observar la calidad de los gráficos que es capaz de manejar. Además, existen muchas extensiones que añaden funcionalidad a la librería, de cuyo total se enumerarán las más importantes.

Efecto Old Movie

Continuar leyendo...
Estructura del manejador de escena

El objetivo en un motor de renderizado es proveer una manera fácil y rápida de dibujar la escena en pantalla, ahorrándose así muchos de los engorrosos pasos de configuración de una API de más bajo nivel como puede ser DirectX u OpenGL. Gracias a la estructura de OGRE, esto resulta bastante sencillo. Para comenzar, se pueden distinguir tres elementos básicos: las Entitys, los SceneNodes y los SceneManagers.

Las Entitys o entidades representan todos los objetos que pueden dibujarse en la escena. Se puede pensar en una entidad como cualquier cosa que es representada por una malla 3D. Un robot sería una entidad, un pez sería una entidad, el terreno sobre el que se mueven los personajes también sería una gran entidad. Sin embargo, otros objetos, como las cámaras o las luces, no son entidades. También cabría mencionar que la orientación y la posición no son propiedades propias de las entidades. Esto significa que no se puede poner directamente una entidad en una escena. En lugar de ello, hay que adjuntar la entidad a otra estructura llamada SceneNode, la cual contiene toda la información sobre la ubicación y orientación de la entidad.

Como ya se ha mencionado, los SceneNodes realizan un seguimiento de la ubicación y orientación de todos los objetos que se le atribuyen. Al crear una entidad, no es añadida a la escena hasta que no se le adjunta a un SceneNode. Su función es ser un contenedor de entidades además de otros objetos como cámaras o luces. Además, se pueden crear jerarquías de nodos, es decir, los SceneNodes pueden ser padres de otros SceneNodes. Cabe mencionar que las posiciones de los SceneNodes son relativas a las de sus padres. De esta forma, si un nodo llamado NodoB, que tiene la posición (3,0,0) y su padre, llamado NodoA, que es el nodo raíz y, que, por lo tanto, tiene sus coordenadas en escala absoluta, tiene la posición (2,0,0), la ubicación absoluta del NodoB será la (5,0,0).

Por último, los SceneManagers son los encargados de seguirle la pista a todos los objetos que se dibujan por pantalla. Pueden verse también como los encargados de todo lo que tenga que ver con el dibujo de la escena. Los SceneManagers poseen el nodo raíz de la jerarquía de SceneNodes, de forma que, a partir de él, se puede llegar a cualquier Entity de la escena. Además, los SceneManagers se encargan también del dibujo del terreno, por lo que en él se pueden especificar las características del mundo que se dibujará. Por ejemplo, si se va a realizar un juego de interiores, el SceneManager para ellos es distino que si se trata de uno de exteriores. De hecho, es posible utilizar varios manejadores de escena para un mismo proyecto.

Una cámara es un objeto especial que funciona de forma parecida a un SceneNode. Una cámara tiene funciones como setPosition, yaw, roll y pitch y se puede adjuntar a cualquier SceneNode. Al igual que cualquiera de estos últimos, la posición de una cámara es relativa a la de sus padres. Para todos los movimientos y rotaciones se puede considerar, básicamente, una cámara como si de un SceneNode se tratara. Una de las características propias de las cámaras es que sólo se puede utilizar una cámara a la vez. Es decir, no se puede crear una cámara para ver una parte de la escena, una segunda cámara para ver otra parte y, a continuación, permitir o inhabilitar las cámaras sobre la base de la escena que queremos mostrar. La forma de conseguir esta funcionalidad es crear SceneNodes que actúen como "titulares de la cámara". Estos SceneNodes se colocan en el lugar y momento en el que queremos colocar la cámara. Cuando sea el momento de cambiar la cámara, simplemente le asignamos un determinado SceneNode sin necesidad de hacer nada más.

Cuando se comienza a hacer frente al uso de múltiples cámaras aparece el concepto de Viewport. Esta clase es muy útil en estas situaciones. Para ello, es importante entender cómo OGRE decide qué cámara va a usar cuando se renderiza la escena. Puede darse el caso que varios SceneManagers estén corriendo al mismo tiempo. También es posible dividir la pantalla en varias áreas y tener cámaras para cada una de las zonas de la pantalla (un ejemplo bastante ilustrativo puede ser una partida para 2 jugadores en un juego de consola). Para entender cómo OGRE realiza una escena, basta considerar estos tres constructores: la cámara, el SceneManager, y la RenderWindow. La RenderWindow es la ventana en la que todo se muestra. El objeto SceneManager crea las cámaras para ver la escena. Ahora, se debe decir a la RenderWindow que cámaras debe mostrar en la pantalla y en qué porción de la ventana debe renderizarlas. El área donde se le dice a la RenderWindow que debe mostrar la cámara es el Viewport. En la mayoría de los usos típicos de OGRE, por lo general, será necesaria una sola Cámara, y, por tanto, sólo se dispondrá de un Viewport.

El uso de las sombras en OGRE es relativamente simple. Actualmente se soportan tres tipos:
  • Modulative Texture Shadows. Es la técnica más liviana en el uso de hardware, pero, por consiguiente, menos vistosa. Se realiza un casting de render a textura de sombras que, posteriormente, se aplica a la escena.
  • Modulative Stencil Shadows. Esta técnica renderiza todas las sombras voluménicas como una modoulación después de que todos los objetos no transparentes se hayan renderizado. No es tan liviano como la técnica anterior y tampoco es tan exacta, pero queda mucho más vistosa.
  • Additive Stencil Shadows. Esta técnica renderiza para cada luz las sombras que luego se añaden a la escena. Resulta muy costoso para la tarjeta gráfica porque, para cada luz, deberá realizar un paso adicional de renderizado.

OGRE no soporta sombras por shaders de forma nativa. Si se requieren este tipo de sombras habrá que incluir los programas programas propios de vértices y fragmentos. Hay que recordar que OGRE soportaba tanto Cg, como HLSL y GLSL

Additive Stencil Shadows

Las luces, al igual que las sombras, resultan fáciles de implementar. La clase Luces tienen una amplia gama de propiedades que describen cómo se ve la luz. Dos de las más importantes son el color difuso y el especular. OGRE proporciona tres tipos de iluminación:
  • Punto de luz. Se emite la luz en todas las direcciones.
  • Spotlight. Funciona exactamente igual que una linterna. Se proporciona la posición en la que la luz se enciende y la dirección en la que se quiere iluminar. También se puede modificar el ángulo de la luz y la intensidad del círculo de luz.
  • Direccional. Simula una luz direccional en la lejanía que se proyecta en toda la escena hacia una misma dirección.

En algunos casos, se pueden combinar varias técnicas. Digamos que se quiere simular la luz de la luna. Se podría establecer una única luz ambiental para la escena, pero esto no es del todo realista, puesto que, la luna no ilumina todo por igual (tampoco lo hace el sol). Una forma más eficaz de hacerlo sería fijando una luz direccional y un punto de luz en la dirección que la luna sería más brillante.

Para manejar terreno. La clase SceneManager define el metodo setWorldGeometry que se usa para cargar los archivos de terreno. Estos archivos consisten en represtaciones de mapas de alturas o heightmap para dibujar un terreno con relieves. La textura se le añade con la función WorldTexture también definida en la misma clase.

Para mostrar cielos OGRE ofrece tres diferentes técnicas:
  • SkyBoxes. Consiste en rodear la escena con una caja mostrando un cielo por todas partes, usado, por ejemplo, en juegos de naves en el espacio.
  • SkyDomes. Se trata de media esfera que muestra un cielo más natural pero sólo en la parte superior, ideal para exteriores con terreno.
  • SkyPlanes. Se sitúa en la parte superior un plano de la escena que muestra el cielo. Funciona bien en juegos en los que no se ve el horizonte. Además, interactúa muy bien con efectos de niebla.


Uso del SkyBox


Es posible combinar la niebla con cualquiera de las diferentes técnicas de mostrar cielos, aunque pueden surgir algunos problemas al intentar usarla junto con un SkyBox o un SkyDome. Existen tres tipos distintos de niebla que difieren en su densidad.

Con esto concluimos un primer y muy básico esbozo de los componentes principales en la gestión de la escena. Quedan en el tintero innumerables aspectos gráficos que no se han tratado como pueden ser las animaciones, las quaterniones, los efectos de partículas y los shaders, los cuales, para un primer acercamiento, podrían parecer demasiado ambiciosos. Se deja en manos del lector indagar en profundidad en los entresijos de estos temas más avanzados. Tanto el soporte oficial como el proporcionado por la comunidad es innumerable y existe una gran cantidad de material para todos aquéllos que aun tengan curiosidad.

Efecto Heat Vision


Extensiones para OGRE

Existen muchas herramientas, librerías, wrappers y exportadores para acondicionar OGRE a nuestras necesidades. Esto contribuye a que podamos tener un marco de trabajo lo más personalizado posible y adaptado a la aplicación que se quiera implementar, en lugar de adaptar nuestra aplicación a las funcionalidades que limite nuestro motor. Todas estas ayudas han sido desarrolladas por terceras partes y muchas siguen también la filosofía de código abierto. Algunas de las más representativas son:

Herramientas
  • Visual C++
  • Code::blocks
  • Eclipse
  • Gcc
  • TortoiseCVS
  • OGRE Studio
  • Mesh Viewer
  • OGRE Particle Editor

Librerías y wrappers
  • OgreAL
  • OgreODE
  • OgreNewt
  • OgreBullet
  • CEGUI
  • OgreDotNet
  • MOGRE
  • Ogre4j
  • Phyton-OGRE

Exportadores
  • SoftImage XSI
  • Maya
  • 3D Studio Max
  • Blender
  • Wings 3D
  • Cinema 4D


Aquí concluye la introducción a OGRE 3D. Espero con mucho entusiasmo que el lector haya encontrado interesante su contenido.



jueves, 17 de enero de 2008

OGRE (IV): ¿Cómo empezar?

Cómo se ha comentado, OGRE da mucho juego, ya que permite la integración con OpenGL y DirectX. Además, se pueden desarrollar aplicaciones tanto para Windows como para Linux y MacOS X. Por ello, se presentan varios tutoriales sobre cómo integrar OGRE con entornos de desarrollo como Visual Studio o Eclipse en distintas plataformas.

OGRE Render Window

Continuar leyendo...
Integración con Visual C++ Express 2005 en Windows XP

Paso 1: Instalar Visual C++ Express 2005

Para instalarlo el primer paso es descargar el programa. Se puede hacer desde aquí:

http://www.microsoft.com/spanish/msdn/vstudio/express/default.mspx

Aunque Visual C++ 2005 en su versión Express es gratuito su uso, se debe registrar la copia de forma gratuita si se quiere seguir usándola pasados 30 días. Además es necesario actualizarlo con el Service Pack 1 (VS80sp1-KB926748-X86-INTL.exe) que se puede descargar desde aquí:

http://www.microsoft.com/downloads/details.aspx?FamilyId=
7B0B0339-613A-46E6-AB4D-080D4D4A8C4E&displaylang=es


Paso 2: Instalar Microsoft Platform SDK.

El siguiente paso es instalar el Microsoft Platform SDK, que es el kit de desarrollo de aplicaciones para Windows. Se puede descargar desde aquí:

http://www.microsoft.com/downloads/details.aspx?FamilyId=
A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en


Paso 3: Actualizar los directorios de Visual C++

Se pueden encontrar las listas de directorios de Visual C++ siguiendo la siguiente ruta de menús: Herramientas -> Opciones -> Proyectos y soluciones -> Directorios de VC++. Allí se debe añadir los siguientes:

Archivos ejecutables: C:\Archivos de programa\Microsoft Platform SDK\Bin
Archivos de inclusión: C:\Archivos de programa\Microsoft Platform SDK\Include
Archivos de inclusión: C:\Archivos de programa\Microsoft Platform SDK\Include\mfc
Archivos de biblioteca: C:\Archivos de programa\Microsoft Platform SDK\Lib

Paso 4: Actualizar el fichero ‘corewin_express.vsprops’

Hay que editar el fichero corewin_express.vsprops. Éste se encuentra en C:\Archivos de programa\Microsoft Visual Studio 8\VC\VCProjectDefaults. En el fichero se debe sustituir la siguiente cadena de texto

AdditionalDependencies="kernel32.lib"

por

AdditionalDependencies="kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib"

Paso 5: Habilitar el asistente de creación de aplicaciones

En Visual C++ Express, el asistente de aplicaciones Windows Win32 está deshabilitado. Para habilitarlo se necesita editar el archivo ‘AppSettings.htm’:

C:\Archivos de programa\Microsoft Visual Studio 8\VC\VCWizards\AppWiz\Generic\Application\html\3082\


Con el editor de texto se debe comentar las líneas de la 441 a la 444, poniendo // al principio de las estas:

// WIN_APP.disabled = true;
// WIN_APP_LABEL.disabled = true;

// DLL_APP.disabled = true;

// DLL_APP_LABEL.disabled = true;

Paso 6: Instalar el Directx SDK

Para instalarlo primero hay que descárgaselo de la siguiente dirección:

http://www.microsoft.com/downloads/details.aspx?FamilyId=
4B78A58A-E672-4B83-A28E-72B5E93BD60A&displaylang=en


Los directorios del Directx SDK deben estar en lo alto de las listas de librería e inclusión respectivamente, sino, podrían producirse errores durante la compilación. Al tener instalado ya Visual Studio esto debería hacerse automáticamente, pero no está de más comprobarlo:

Archivos de biblioteca: C:\Archivos de programa\Microsoft DirectX SDK\Lib\x86
Archivos de inclusión: C:\Archivos de programa\Microsoft DirectX SDK\Include

Paso 7: Instalar el OGRE SDK

Para instalarlo basta con descargar el OGRE SDK preparado para Visual C 2005

http://downloads.sourceforge.net/ogre/OgreSDKSetup1.4.5_VC80.exe

Paso 8: Instalar el Asistente de creación de aplicaciones OGRE

Se necesita descargar el siguiente archivo y descomprimir su contenido:

http://downloads.sourceforge.net/ogreconglo/ogresdkwizard80_Eihort_v1_4_2.zip

Para instalarlo sólo hay que hacer doble clic sobre el archivo ‘VC8_Express_Setup’, se ejecutará el script y saldrá un mensaje que confirmará que se ha instalado sin problemas.

Paso 9: Comprobar la correcta integración

Para comprobar que todo está correcto basta con utilizar el asistente que se acaba de instalar. En Visual C++, Archivo -> Nuevo -> Proyecto -> OGRE SDK Aplication se crea un nuevo proyecto de prueba y se compila. Al ejecutarse aparecerá una ventana con opciones de configuración. Tras elegir las que se consideren oportunas aparecerá una ventana con la cabeza de un ogro renderizada. Este hecho indica que la instalación ha sido exitosa.

OGRE Engine Rendering Setup Window

OGRE Render Window


Integración con Eclipse 1.3.0 en Ubuntu 7.10

En este tutorial se utilizará EasyEclipse C++ 1.3.0 y la versión estable de OGRE 1.4.3. Posteriormente se explicará como configurar un proyecto Eclipse en Linux, incluyendo las librerías OGRE y CEGUI para la creación de una aplicación básica de OGRE. Existe la posibilidad de compilar el código fuente de las librerías, pero, como las últimas versiones se encuentran ya empaquetadas para Ubuntu, se hará uso de ellas

Paso 1: Instalar CEGUI

Instalar primero CEGUI 0.5.0, mediante el paquete libcegui-mk2-dev y sus dependencias.

Paso 2: Instalar OGRE

Instalar OGRE 1.4.3 mediante el paquete libogre-dev y sus dependencias.

Paso 3: Instalar EasyEclipse C++

Descargar EasyEclipse C++ 1.3.0. Descomprimirlo y ejecutarlo.

Paso 4: Crear un nuevo proyecto de Eclipse

Crear un nuevo proyecto C++ y ahí seleccionar Makefile -> "Hello World C++".

Paso 5: Seleccionar generación de Makesfiles automáticamente

Una vez creado el nuevo proyecto, pulsar con el botón derecho del ratón sobre el nombre del proyecto y seleccionar "Properties". En el menú C/C++ Build marcar "Generate Makefiles automatically".

Paso 6: Actualizar los directorios

En el submenú Settings, seleccionar la pestaña "Tool settings".

En GCC C++ Compiler: En el apartado Directories añadir las rutas "/usr/include/CEGUI", "/usr/include/OGRE" y "/usr/include/OGRE/GLX". En Miscellaneous, en la casilla flags hay que poner "-c -fmessage-length=0 -fexceptions -fident".

En GCC C++ Linker: En Libraries hay que añadir "CEGUIBase", "OgreMain" y "CEGUIOgreRenderer".

Con esto se tiene configurado el entorno Eclipse para desarrollar aplicaciones con OGRE y CEGUI. Hay que tener en cuenta que OGRE necesita encontrar en el directorio donde se ejecuta la aplicación los ficheros de configuración "resources.cfg" y "plugins.cfg". Para más información sobre estos ficheros y problemas en la instalación se puede consultar la wiki oficial de OGRE.


viernes, 11 de enero de 2008

OGRE (III): ¿Qué se puede hacer?

Lo común es que OGRE sea usado para crear juegos, pero éste no es su único fin, pues, deliberadamente, está diseñado para proveer sólo una solución a las necesidades gráficas. Es por esto, por lo que puede ser usado en infinidad de proyectos que requieran de necesidades gráficas avanzadas. Aquí se muestran algunas aplicaciones desarrolladas con OGRE, entre las que, además de videojuegos, se incluye software educacional e infantil, junto con algunos juegos serios y demostraciones técnicas.


Continuar leyendo...

Pacific Storm

Desarrollador: Lesta Studio
Web: http://www.lesta.ru/
Licencia: Comercial
Género: Estrategia (Histórico), Tiempo real
Sinopsis: Pacific Storm mezcla estrategia en tiempo real, wargame y simulación, en un título que te permitirá controlar tanto al bando estadounidense como al japonés. Cuenta con una parte estratégica orientada a la gestión de recursos como petróleo, hierro, níquel o dinero, así como una parte de batalla en la que dirigirás tus unidades de cruceros, portaaviones, destructores, submarinos, lanchas torpederas, barcos de carga, cazas, bombarderos, aviones de reconocimiento, cañones antiaéreos y muchas mas. Las unidades disponen de sistema de experiencia que les permite mejorar de batalla en batalla.

Pacific Storm

FirstAid Sim

Desarrollador: Guppyworks
Web: http://www.guppyworks.com/
Licencia: Desconocida
Género: Juego serio. Simulación. Educación
Sinopsis: El juego es un simulador de primeros auxilios que permite al usuario aprender a priorizar los primeros auxilios de las víctimas en accidentes de tráfico. El jugador controla a una persona que acaba de llegar a un incidente de tráfico y tiene que intentar reanimar a las víctimas. El juego tiene como público objetivo a los jóvenes que tienen carné de conducir.

FirstAid Sim

HCA : The Ugly Prince Duckling

Desarrollador: Guppyworks
Web: http://www.guppyworks.com/
Licencia: Comercial
Género: Aventura gráfica. Acción. Infantil
Sinopsis: Aventura gráfica en 3ª persona que tiene lugar en Copenhague, durante la Edad de Oro, en torno a 1820. Se controla a Hans Christian Andersen a sus 14 años de edad que llega a Copenhague para perseguir su sueño de entrar en el Teatro Real y de convertirse en un famoso actor. El juego es una combinación de una búsqueda tradicional basada en aventuras, algunos mini-juegos de acción y una interacción con las personas que viven en la ciudad.

HCA: The Ugly Prince Duckling

Legend of the Dragon

Desarrollador: Freak Frog Entertainment
Web: Desconocida
Licencia: Comercial
Género: Acción. Lucha
Sinopsis: Este juego desarrollado en España, está basado en la conocida serie de televisión del mismo nombre. The Legend of the Dragon es un juego de lucha y ambiente oriental, que permite elegir entre tres héroes diferentes: Ang, Ling y Beingal. La acción se desarrolla a lo largo de 9 misiones diferentes y otorga a los jugadores un sistema de combate que mezcla artes marciales con poderes especiales.

Legend of the Dragon

Ankh: Una Aventura Egipcia

Desarrollador: Deck13
Web: http://www.deck13.com/
Licencia: Comercial
Género: Aventura Gráfica. Comedia
Sinopsis: Es un juego de aventuras realmente notable en cuanto a diseño de personajes, ambientación e historia. En esta aventura tomaremos el control de un joven egipcio llamado Assil, quien, tras robar la llave de la Gran Pirámide para organizar una fiesta para sus amigos, cae víctima de una maldición mortal.

Ankh: Una Aventura Egipcia

The Blob

Desarrollador: Universidad de Utrecht
Web: http://www.uu.nl
Licencia: Desconocida
Género: Plataformas
Sinopsis: The Blob es un proyecto increíble llevado a cabo por estudiantes de la escuela de arte y la universidad de Utrecht. El juego ha sido realizado durante 4 meses por un equipo de 9 personas. El resultado es un juego tridimensional en el que el jugador controla una bola de pintura a través de la ciudad. La bola puede absorber color, tragarse NPC's para aumentar así de tamaño y cambiar su color. Con la pintura, el jugador puede proceder a pintar toda la ciudad. Casi todo se puede pintar: los edificios, los árboles, los automóviles, entre otros objetos. El principal objetivo del juego es pintar los edificios más representativos.

The Blob

Project Football

Desarrollador: Ikaro Games
Web: http://www.ikarogames.com/
Licencia: Libre. GPL
Género: Simulador deportivo
Sinopsis: Se trata de un juego todavía en desarrollo por el grupo de reciente creación Ikaro Games. Es un mánager de fútbol multiplataforma que se centrará, principalmente, en los distintos aspectos de un entrenador de fútbol, como son las alineaciones, tácticas y fichajes; y la simulación de partidos en dos dimensiones.

Project Football

The Incredible Sims Toolkit

Desarrollador: Incredible Sims team
Web: http://incrediblesims.com/
Licencia: Comercial
Género: Juegos serios. Simulador. Demostraciones técnicas
Sinopsis: The Incredible Sims Toolkit permite simular con realismo los entornos, procesos y flujos de trabajo de la vida profesional. El kit de herramientas permite realizar aplicaciones que sirvan para capacitar al personal de una empresa utilizando técnicas de videojuego. Está desarrollado en C # y utiliza Mogre (API en C # de OGRE) para la representación 3D.

Incredible Sims Toolkit

The Legend of Beowulf

Desarrollador: JetDogs Studios
Web: http://www.jetdogs.com/
Licencia: Desconocida
Género: Aventura gráfica. Comedia
Sinopsis: En esta aventura encarnarás al personaje de leyenda Beowulf. En ella tendrás que enfrentarte al glorioso reto de salvar la gran sala de los Héroes del malvado Grendel. En el camino, el jugador se enfrentará a numerosos retos, entre los que destacan sus divertidos rompecabezas, algunos de un humor bastante retorcido.

The Legend of Beowulf



OGRE (II): ¿Por qué OGRE?

OGRE (Object Oriented Graphics Engine) es un motor de gráficos en tres dimensiones multiplataforma. ¿Qué ventajas tiene que sea multiplataforma? Pues que no hay problema para quienes quieran crear aplicaciones para Windows, Linux o Mac. Esto es posible gracias a que está construido de forma que no se compromete con una API en particular, puesto que el motor soporta tanto el uso de DX9 como de OpenGL. Además, la principal ventaja de OGRE sobre otros engines 3D es que es un proyecto open source bajo licencia LGPL. Esto significa que su uso es gratuito y apenas existen exigencias para su uso.

Desde el principio, OGRE fue diseñado bajo la filosofía de orientación a objetos, por lo que su interfaz es clara, intuitiva y fácil de usar. Esto significa que con OGRE podemos hacer juegos o cualquier tipo de aplicación que requieran gráficos tridimensionales que tengan poco que envidiar a los realizados por la mayoría de los motores del mercado.

Continuar leyendo...

Algo que hay que recordar es que OGRE no es un motor diseñado sólo con los juegos en mente, es un motor de gráficos 3D general. Por este motivo, éste no trae soporte nativo para sonido ni física. Esto no supone un problema, ya que, gracias a la enorme comunidad existente en internet, existen módulos especialmente diseñados que le permiten añadir estas funcionalidades.

¿Cuándo y por qué se inició el proyecto? OGRE se inició a principios de 2001 como un spin-off de un proyecto personal de Steve Streeting en el que estaba trabajando. Se trataba de un wrapper que envolvía a Direct3D (versión 5 o 6) de manera que su código fuente no se viera afectado por la fealdad de aquella versión de D3D.

Existen varios principios fundamentales por los cuales se inició el proyecto y que aún hoy son válidos. En primer lugar, y, por encima de todo, fue el deseo de hacer un renderizado en tiempo real que fuera potente e intuitivo. En aquel momento había una gran cantidad de motores que fueron diseñados completamente en torno a una característica técnica, un tipo de formato o de juego concreto. Así, que sintieron la necesidad de crear algo distinto.

Se buscaba una lista de funcionalidades básicas que pudiera soportar plugins para especializarse, es decir, simplemente unos patrones de uso para el manejo de unas estructuras y planteamientos concretos. Además, se buscaba que las prestaciones fueran en tiempo real con unas opciones de guía básicas. Desde entonces, no se ha tratado de asumir ninguna otra función con el fin de asegurarse llegar a una audiencia lo más amplia posible.

Una razón por la que OGRE no está enfocado exclusivamente al mundo de los videojuegos es que no todo el que necesita un motor 3D quiere hacer juegos. Se puede utilizar OGRE también para hacer aplicaciones de simulación, corporativas o de investigación. En segundo lugar, es que, incluso dentro de la industria de los juegos, los requisitos pueden variar ampliamente. Por ejemplo, un MMORPG necesitará una biblioteca de red muy diferente a la de un FPS, y un simulador de vuelo necesitará funciones de colisión y de física muy diferentes a la de un juego de lucha. Si OGRE incluyera todas estas características, forzaría la imposición de una serie de restricciones a seguir, restándole así la flexibilidad de uso que lo caracteriza.

Muchos experimentados desarrolladores de juegos han expresado su aprobación en este sentido porque no incluye limitaciones. Puede ser desalentador para usuarios iniciados que sólo quieren construir otro FPS, pero, para estas personas, hay un número creciente de marcos de trabajo utilizando OGRE en combinación con otras bibliotecas. Es importante darse cuenta de que, estando OGRE siempre separado, se garantiza la flexibilidad suficientemente como para ser incorporado en alguno de estos marcos.

¿Por qué debería considerarse el uso de OGRE en lugar de otros motores 3D? Muchos de ellos, aunque técnicamente son impresionantes, la falta de cohesión y de un diseño adecuado en la documentación les impide que puedan ser utilizados de forma eficaz. La gran mayoría tiene una larga lista de características, pero dan la sensación de ser un montón de demostraciones técnicas reunidas sin una clara visión de trabajar juntas. Además, la mayoría de los motores están diseñados para un determinado estilo de juego.

OGRE es diferente. Prioriza el diseño frente a la acumulación de características. Todas las características se han considerado a fondo y se incluyen en el diseño general de la forma más elegante posible y siempre plenamente documentadas. Así, se consigue que todos los elementos del motor formen parte siempre de un conjunto coherente. Por consiguiente, la calidad es antepuesta a la cantidad. Como la cantidad se puede añadir con el paso del tiempo, se sigue la filosofía de ir poco a poco, pero con la seguridad de un trabajo bien hecho. Por ello, el núcleo del equipo de desarrollo se mantiene deliberadamente pequeño y todos sus miembros son veteranos ingenieros de software con muchos años de experiencia en el mundo real. Pero esto no impide que las actualizaciones de la comunidad sean bienvenidas, si bien, se someten a un estricto control de calidad y cohesión con la filosofía de OGRE antes de ser aceptadas.

OGRE no presupone qué tipo de juego o demo se va a realizar. Por ello, utiliza una jerarquía de clases flexible que permite diseñar complementos para especializar la organización de la escena, criterio adoptado para que se pueda realizar la escena a nuestro gusto. ¿Se desea renderizar rápido los niveles de interiores? Bien, pues utilizamos el plugin BSP/PVS de manejo de escena que ya está escrito. ¿Se quiere un paisaje al aire libre? Una vez más, podemos utilizar otro plugin de manejo de escena. El resto del motor seguirá funcionando exáctamente como antes.

Pero, ¿es OGRE realmente libre? Su código fuente está disponible bajo la GNU Lesser General Public License (LGPL), que, básicamente, significa que puede utilizarse sin problemas siempre y cuando el código sea liberado si se hace algún cambio en el núcleo o si se distribuye. El código de la nueva aplicación o los nuevos complementos que sean creados no tienen que ser liberados, sino que se deja a elección del usuario.

Existe mucha información sobre los principios por los que se ha desarrollado OGRE. Para obtener una visión rápida del diseño la mejor manera es echarle un vistazo a los manuales de usuario. La API es la documentación de referencia, que puedes consultar online. Pero, sin duda, la mejor manera de conocer OGRE es usarlo. Alguna de sus características técnicas son:

Características generales
  • Diseño orientado a objetos. Interfaz simple y fácil de usar, diseñada para que requiera poco esfuerzo el renderizado de escenas en tres dimensiones
  • Arquitectura basada en plugins muy flexible que permite extender las funcionalidades del motor
  • Sistema de Carga/Respaldo. Soporte de zip/pk3 para archivar
  • Diseño limpio y bien documentado de las clases del motor
  • Independiente de la API gráfica, se puede utilizar OpenGL o DirectX


Renderizado
  • Material LOD
  • Soporta la gama completa de operaciones de función fija como multitextura y multipass blending, coordinación de generación de texturas
  • Soporte para múltiples técnicas de materiales
  • Objetos transparentes gestionados automáticamente
  • Sistema de fuentes con fuentes TrueType y texturas precreadas
  • Sistema de GUI 2D con botones, listas, cajas de edición, barras de desplazamiento, etc. (Usando CEGUI)


Gestión de escena
  • Altamente personalizable. Flexible gestión de escena no vinculada a ningún tipo de escena. Se puede usar las clases predefinidas si encajan bien o crearse subclases propias para obtener un control total sobre la organización de la escena
  • Grafo de escena jerarquico
  • BSP, Octrees, Occlusion Culling, LOD


Texturizado
  • Básico, multi-texturizado, bumpmapping, mipmapping, texturas volumétricas y proyectadas
  • Texturizado proyectivo automático entre vínculos con texturas unitarias a instancias Frustum
  • Puede registrar textura de fuentes externas
  • Soporta PNG, JPEG, TGA, BMP y DDS como archivos de imagen


Iluminación
  • Por vértice, por pixel, Lightmapping
  • Puede tener un número ilimitado de luces en la escena
  • Soporte a través de programas de vértices y de fragmentos


Sombras
  • Shadow mapping, shadow volume
  • Técnicas soportadas: modulative stencil, additive stencil, modulative projective
  • Múltiples esténciles para optimizaciones de sombras, incluyendo programas de vertices de extrusión, luz y sombras inteligentes, integración con la malla LOD, métodos zpass y zfail, esténciles de doble cara y saturación de recorte de región
  • Textura sombras que se desvanecen a larga distancia


Shaders
  • Vertex y pixel shaders de alto nivel
  • Soporta programas de vértices y de fragmentos de bajo nivel escritos en ensamblador, y programas de alto nivel en Cg, HLSL, y GLSL


Animación
  • Cinemática inversa, animación esquelética, animación de mezcla
  • Animación del esqueleto, incluyendo la mezcla de múltiples animaciones y de peso variable de skinning de huesos


Mallas
  • Cargado de malla, skinning, progresivo
  • Aceleración de skinning por hardware
  • Flexibilidad en los formatos de malla de datos aceptados
  • Exportadores para muchas herramientas de modelado incluidas Milkshape3D, 3D Studio Max, Maya, Blender y Wings3D


Curvas y superficies
  • Splines
  • Caminos Bezier bicuadrados para superficies curvas


Efectos especiales
  • Cartografía de medio ambiente, billboarding, sistema de partículas, motion blur, cielo, agua, niebla
  • Sistemas de partículas, incluyendo emisores fácilmente extensibles y affectors (personalizable mediante plugins). Los sistemas pueden ser definidos mediante scripts para un ajuste fácil
  • Soporte para skyboxes, skyplanes y skydomes, muy fáciles de usar


Scripting
  • El lenguaje de script permite mantener los materiales fuera del código
  • Scripts de renderizado multipaso


Física
  • Física básica, detección de colisiónes, cuerpos rígidos
  • Controladores que permiten organizar fácilmente los valores entre los objetos derivados
  • Incluye bindings para múltiples sistemas de colisión/física de terceras partes, como ODE o Newton



lunes, 7 de enero de 2008

OGRE (I): Introducción

Un motor hace referencia a una serie de rutinas de programación que permiten el diseño, la creación y la representación del juego. La analogía con el motor de un automóvil es bastante ilustrativa: el motor debajo del capó no es visible, pero le da la funcionalidad al automóvil que es la de transportar. La misma analogía permite explicar algunos de los aspectos que, generalmente, maneja un motor de juegos, en el que las texturas y los modelos 3D serían la carrocería, pintura e interiores.

Del mismo modo en que carrocería, pintura y exteriores no andan sin un motor, el arte y los guiones del juego no funcionan sin un motor de juegos. Un motor de juegos es el núcleo software de un videojuego o de una aplicación interactiva con gráficos en tiempo real. Éste provee las tecnologías necesarias, simplifica el desarrollo y, en algunos casos, permite el desarrollo para distintas plataformas (Mac/Linux/Windows/Consolas).

Esquema típico de un motor de juegos

Continuar leyendo...

Existen muchas librerías que proporcionan las funciones básicas de un motor de juegos, como DirectX, OpenGL, Java3D, SDL, Newton, entre otros. Las librerías gráficas como OpenGL y DirectX usan los drivers de las tarjetas gráficas, de forma que constituyen la interfaz entre la aplicación software (juego) y el adaptador gráfico hardware. Aúnan funciones para dibujar objetos 2D/3D y los motores gráficos se suelen sustentar en ellas. Una librería gráfica, a partir de modelos en 3D, consiguen obtener un espacio bidimensional, pero un motor de juegos hace más cosas, como iluminación, anti-aliasing o mezcla de texturas. Existen varias razones por la que el uso de motores de juego es importante. Algunas de ellas son:

  • Facilita el desarrollo
  • Abre nuevas oportunidades de negocio, como es la venta de las licencias de los motores para la realización de otros juegos
  • Abstracción de la plataforma. Si un Motor corre en varias plataformas, nuestro juego también
  • Separación de Motor/Contenidos, lo cual permite tener varios grupos de trabajo en paralelo
  • Beneficios a terceros, ya que los avances en el motor pueden beneficiar a varios juegos
  • Permite enfatizar en la parte artística, ya que, al tener mayor grado de abstracción, se tiene menor carga de trabajo en programación
  • Mayor modularidad y reaprovechamiento

Los motores de juego surgen en la década de los 90 tras el éxito de Doom y Quake. Juegos como Quake 3 y Unreal ya se diseñaron separando motor y contenidos ¿Qué ilustra el éxito de estos juegos? Por un lado, una mayor rapidez del mundo de los videojuegos. Desarrollar motores agiliza el desarrollo de juegos y permite sacar secuelas más fácilmente para mantener el mercado “caliente”. Además, el licenciar posteriormente los motores permite obtener unos beneficios extras muy suculentos.

La arquitectura de un motor de juegos debe proporcionar mucha abstracción. Con que las librerías utilizadas estén portadas a todos los SO, permitimos que nuestro motor o juego funcione en todas las arquitecturas necesarias. Un parámetro que se debe tener muy en cuenta al elegir un motor de juegos es su portabilidad y en qué librerías se basa. Los motores de juego suelen tener una estructura como la que sigue:

Esquema típico de un motor de juegos

El motor gráfico o de render es el que proporciona funciones de renderizado 2D, 3D y de sprites. Se suele apoyar en librerías/APIs gráficas como OpenGL o DirectX. Define una capa de abstracción entre el HW/SO y el juego en sí. Además, se encarga de la visibilidad (BSP y buffers), el mapeado, el antialiasing, la gestión de mallas 3D, entre otras cosas.

El grafo de escena es una parte muy importante de un motor de juegos. Ésta es una estructura de datos muy utilizada en editores gráficos basados en vectores y en videojuegos. Se encarga de ordenar la representación lógica y, también a veces, espacial de una escena gráfica. Cada nodo puede tener muchos hijos, pero, un nodo sólo suele tener un padre. El efecto de algo sobre un padre es visible por todos sus hijos. Así, una operación sobre un grupo se propaga hacia todos sus nodos hijo. Esto permite manejar (escalar/mover/rotar/etc.) grupos de objetos como si fueran uno solo. En los juegos, cada nodo suele representar un objeto en la escena.

Ejemplo de representación de varios objetos en grafo de escena

El motor de físicas es software que simula modelos de física utilizando variables del tipo velocidad, masa, etc. Su objetivo es simular y predecir los efectos bajo diversas situaciones de lo que ocurre en la vida real o en un mundo de fantasía. En los juegos se utilizan cada vez más, sobre todo en los de carreras donde factores como la fuerza centrífuga o derrapajes necesitan de ecuaciones físicas para aportar realismo.

El detector de colisiones es un algoritmo empleado para detectar cuándo dos o más objetos colisionan. Se suelen realizar mediante el cálculo de la intersección de volúmenes simples (Bounding Volumes). Se pueden utilizar distintos volúmenes para envolver el objeto y así detectar mejor las colisiones, como cubos o esferas. Se puede tomar como un componente independiente, aunque tiene mucho que ver con el grafo de escena y el motor de físicas.

El motor de inteligencia artificial es el encargado de dotar a ciertos elementos del juego un comportamiento pseudointeligente. Por regla general, lo que se aplica en los juegos son técnicas muy simples de inteligencia artificial como máquinas de estados o algoritmos de búsquedas. Sin embargo, cada vez más se utilizan nuevas técnicas para conseguir una inteligencia más “realista” como redes neuronales o algoritmos genéticos.

El motor de sonido es el encargado de reproducir la banda sonora del juego y los efectos de sonido, como disparos o explosiones, en sincronía con la acción del juego.

La gestión de redes está alcanzando una progresiva mayor importancia. Hoy por hoy, casi todos los juegos tienen una componente de red. Existen juegos exclusivamente online, de los cuales, la mayoría ofrece partidas multijugador a través de red. Es importante tener un componente que aglutine todas las utilidades de red, de forma que, el hecho de que se juegue de una forma u otra sea, en cierta medida, “transparente” para el desarrollador del juego.

Todas las partes que componen un motor de juegos tienen su importancia, pero lo más básico e imprescindible de un motor de juegos es el motor gráfico. Aunque el Grafo de Escena es también una pieza vital, el resto de componentes son más prescindibles y no aparecen en todos los motores, y cuando lo hacen, aparecen como plugins. La elección del motor de un motor u otro es algo fundamental, sobre todo si necesitamos alguno de estos componentes. Un ejemplo de motor de juegos básico es OGRE 3D, que, básicamente, aglutina únicamente funciones de tratamiento gráfico y deja a elección del usuario las otras componentes. La comunidad de OGRE es la que ofrece multitud de librerías para complementarlo y añadirle funcionalidad, las cuales se integran a la perfección con dicho motor. Pero OGRE 3D no es único, pues existen infinidad de motores. Éstos se suelen clasificar por su licencia de uso:

Los motores comerciales suelen tener la ventaja de proporcionar soporte y mayor número de herramientas de desarrollo adicionales. No obstante, coste de licencia puede suponer un gran inconveniente, puesto que suele ser mayor cuantas mejores prestaciones ofrezca el motor. Algunos de los distintos motores comerciales pueden ser:

  • Torque Game Engine
  • 3D Game Studio
  • Blitz3D
  • Reality Engine
  • Deep Creator
  • Cipher

Los aquí mostrados son los que se pueden llamar “asequibles”. Me refiero con ello a los que tienen licencias de bajo coste. Ninguno de estos se han utilizado para los últimos títulos AAA, pero son utilizados frecuentemente por pequeños estudios y grupos amateurs de desarrollo.

Los motores de código libre en cambio presentan la ventaja de que no tienen ningún coste, junto a que el usuario tiene la libertad de poder modificarlos si así lo necesita. Por el contrario, tienen la desventaja de que no hay soporte técnico “oficial”, aunque la comunidad suele ayudar, y puede sufrir en determinadas ocasiones falta de herramientas que ayuden al desarrollo. Además, hay que tener en cuenta que muchos de estos motores están regidos por unas licencias de uso limitadas y pueden surgir inconvenientes si el juego que se va desarrollar presenta fines comerciales. Algunos de los motores open source más populares son:

  • OGRE
  • Crystal Space
  • Irrlicht
  • jME
  • Reality Factory
  • RealmForge GDK

Como hemos visto OGRE 3D no es el único motor, e, igualmente, lo mismo no es el que más conviene, ya que cada uno de ellos ofrece diferentes funcionalidades y licencias de uso. Antes de aventurarse con un proyecto es conveniente analizar con profundidad cual es el que más se ajusta a nuestras necesidades, ya que una buena elección puede evitar numerosos quebraderos de cabeza.



Introducción a OGRE

OGRE 3D es un motor de gráficos en tres dimensiones de código abierto. Es flexible y orientado a objetos. Además, éste es portable a múltiples entornos, como Windows, MacOS X o Linux. Ha sido diseñado con la idea de hacer más sencillo el desarrollo de juegos 3D. Explota al máximo las posibilidades de las tarjetas gráficas, ya que brinda soporte para vertex y pixel shaders, como HLSL (DirectX), GLSL (OpenGL) y Cg (DirectX/OpenGL). El motor está muy extendido y es muy valorado por la comunidad de código abierto. Con él se han desarrollado muchos juegos, algunos de ellos con carácter comercial.

Por sugerencia stratera, he decidido recopilar aquí los artículos/tutoriales que estoy redactando sobre OGRE. Este post además servirá de índice para dichos artículos y lo iré actualizando conforme los vaya publicando. Sin más preámbulos:


Última actualización: 23/1/2008

jueves, 3 de enero de 2008

¿Conoces la solución?