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

<< OGRE (I): Introducción - Índice - OGRE (III): ¿Qué se puede hacer? >>