Академический Документы
Профессиональный Документы
Культура Документы
OGRE 3D
gonzalo_tirado@alu.uma.es
Resumen
OGRE 3D es un motor de gráficos 3D de código abierto. Es flexible y orientado a objetos, además de ser 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 píxel 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.
Palabras clave
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).
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:
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 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:
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.
¿Por qué Ogre3D?
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.
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 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
Texturizado
Iluminación
Shaders
Animación
Mallas
Curvas y superficies
− Splines
− Caminos Bezier bicuadrados para superficies curvas
Efectos especiales
Física
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.
Pacific Storm
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.
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.
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.
Figura 7: Ankh
The Blob
Project Football
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.
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
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-
40C0EC4F68E5&displaylang=en
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:
AdditionalDependencies="kernel32.lib"
por
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;
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:
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
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.
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.
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
Crear un nuevo proyecto C++ y ahí seleccionar Makefile -> "Hello World C++".
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".
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.
Trasteando un poco
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.
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.
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
Figura 14: 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:
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.
− 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.
Figura 15: 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.
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.
Referencias bibliográficas
(Cortizo, 2007) J.C. Cortizo Pérez: Motores 3D, Asignatura Motores del Master de la
Universidad Europea de Madrid, http://www.esi.uem.es/jccortizo/motores/motores3d.pdf ,
2007.
(Cortizo, 2007) J.C. Cortizo Pérez: Teoría de motores, Asignatura Motores del Master de la
Universidad Europea de Madrid, http://www.esi.uem.es/jccortizo/motores/teoria1.pdf ,
2007.
(DevMaster, 2005) DevMaster: Ogre3D engine details, incluye un listado de engines muy
completo, http://www.devmaster.net/engines/engine_details.php?id=2 , 2005.
(Gamasutra, 2007) Gamasutra: Q&A: Steve Streeting On Open Source 3D Engine OGRE 3D,
entrevista a Steve Streeting, lider del proyecto de OGRE, http://www.gamasutra.com/php-
bin/news_index.php?story=14581 , 2007
(Guppyworks, 2007) Guppyworks: HCA : The Ugly Prince Duckling, juego realizado con
OGRE3D , http://www.guppyworks.com/hca_tupd.htm , 2007.
(Ikaro Games, 2007) Ikaro Games: Blog de desarrollo, estudio encargado del juego en
desarrollo Project Football, http://www.ikarogames.com/blog/ , 2007.
(Ikaro Games, 2007) Ikaro Games: Crear un Proyecto de Eclipse en Linux con Ogre y CEGUI,
http://www.ikarogames.com/blog/archives/3-Crear-un-proyecto-de-Eclipse-en-Linux-con-
Ogre-y-CEGUI.html , 2007.
(Incredible Sims, 2007) Incredible Sims: Web corporativa, compañía creadora del toolkit de
simulación , http://incrediblesims.com/ , 2007.
(JetDogs, 2007) JetDogs Studios: Web corporativa, compañía creadora del juego The Legend of
Beowulf, http://www.jetdogs.com/ , 2007.
(Junker, 2006) G. Junker: Q&A: Pro OGRE 3D Programming, referencia básica para la
programación con OGRE, Editorial Apress, 2006
(Lesta Studio, 2007) Lesta Studio: Web corporativa, compañía creadora del juego Pacific Storm,
http://www.lesta.ru , 2007.
(MSDN, 2007) Microsoft: Using Visual C++ 2005 Express Edition with the MS Platform SDK,
http://msdn2.microsoft.com/en-us/express/aa700755.aspx , 2007.
(OGRE3D, 2007) Ogre3D.org: OGRE Gallery, http://www.ogre3d.org/ 2007.
(OGRE wiki, 2007) OGRE wiki community: Assembling a toolset, extensiones de terceras
partes, http://www.ogre3d.org/wiki/index.php/AssemblingAToolset , 2007.
(OGRE wiki, 2007) OGRE wiki community: Installing the Ogre SDK,
http://www.ogre3d.org/wiki/index.php/Installing_An_SDK , 2007.
(OGRE wiki, 2007) OGRE wiki community: OGRE tutorials, tutoriales de distintos nivieles de
dificultad, http://www.ogre3d.org/wiki/index.php/Ogre_Tutorials , 2007.
(Santirso, 2007) M. Santirso González: Quiero ser como Will Wright, Capítulo 2,
http://www.redroomsoftware.com/tirsoweb/wp-content/uploads/other/QSCWW-
Capitulo_2.pdf , 2007.
(Wikipedia, 2007) Wikipedia: List of game engines, lista en inglés muy completa de motores de
juego, http://en.wikipedia.org/wiki/List_of_game_engines , 2007.