miércoles, 13 de febrero de 2008
domingo, 3 de febrero de 2008
Ahora sé por qué llorais
Los ciborgs no sienten dolor. Yo sí. No vuelvas a hacer eso. Escúchame y atiende. El Terminator está ahí fuera. No se puede razonar con él, es un exterminador. No siente lastima, ni remordimiento, ni miedo y no se detendrá ante nada, jamás, hasta que estés muerta.
Continuar leyendo...
Tu hijo me dió un mensaje para ti, me lo hizo memorizar. Gracias Sarah por tu valor en los años oscuros. No puedo ayudarte en lo que pronto te espera, solo sé que el futuro no está establecido. Debes ser más fuerte de lo que te imaginas ser. Debes sobrevivir o yo no existiré. Es todo.
- No acabará nunca, ¿verdad? Estoy temblando. Vaya leyenda, ¿eh? Debes estar decepcionado.
- No, no lo estoy.
- Kyle, las mujeres de tu tiempo, ¿cómo son?
- Luchadoras.
- No me refiero a eso. ¿Había alguien en especial?
- ¿Alguien?
- Una chica, ya sabes.
- No... nunca
- ¿Nunca? Lo siento. Cuanto lo siento. Te debe doler.
- Se puede controlar el dolor. Se puede desconectar.
- ¿Y no sientes nada?
- John Connor me dió una fotografía tuya. Entonces no supe por qué. Era muy vieja, rota, descolorida. Eras joven como ahora, pero parecías un poco triste. Siempre me pregunté lo que estarías pensando. Memoricé cada rasgo, cada curva. Atravesé el tiempo por ti Sarah. Te quiero. Desde siempre.
- No lo lograremos, ¿verdad? Me refiero a la gente.
- Está en vuestra naturaleza destruiros mutuamente.
Observando a John con la máquina, de repente lo vi claro. El Terminator jamás se detendría, jamás le abandonaría y jamás le haría daño, ni le gritaría o se emborracharía y le pegaría, ni diría que estaba demasiado ocupado para pasar un rato con él. Siempre estaría allí y moriría para protegerle. De todos los posibles padres que vinieron y se fueron año tras año, aquella cosa, aquella máquina, era el único que daba la talla. En un mundo enloquecido, era la opción más sensata.
- Se acabó.
- No, aun hay otro chip, y también debe ser destruido. Ten, yo no puedo autoterminarme. Debes bajarme hasta la caldera.
- No, no , ¡NO!
- Lo siento John, lo siento.
- No, todo irá bien, quédate con nosotros, todo irá bien.
- Tengo que irme.
- No, no lo hagas, por favor no te vayas.
- Debo marcharme John.
- ¡No! No, espera, espera, no tienes por qué hacerlo.
- Lo sé.
- No, no lo hagas, no te vayas.
- He de terminar aquí.
- Te ordeno que no te vayas, ¡te ordeno que no te vayas! ¡Te lo ordeno!
- Ahora sé por qué lloráis, pero es algo que yo nunca podré hacer.
viernes, 1 de febrero de 2008
Tan sometido
Hay que estudiar algo con porvenir,
hay que buscar algo para escapar.
Una carrera con salida
de las miserias de la vida.
Febrero está aquí, eso significa que muchos especimenes pseudo-estudiantes, entre los que yo me incluyo, nos refugiamos en cavernosos refugios para alimentar nuestras hambrientas quijoteras ávidas de conocimiento. Parece una noble causa, pero ni mucho menos. Detrás de este afán de sabiduría se esconde una triste realidad. Casi todo el que estudia una carrera lo hace para obtener el preciado título. Sí, ese que nos convertirá en diplomado/licenciado/ingeniero en… y del que podremos fardar en nuestra vida curricular. Porque de eso se trata, o así se lo toma cualquier estudiante de los denominados genéricos, cada asignatura se considera como un obstáculo que se interpone entre el estudiante y su vil título, cuando la verdadera recompensa debería ser la experiencia y sabiduría adquirida en el camino.
Continuar leyendo...
El mercado laboral pronto va a necesitar
gente con preparación, más competitividad.
No pensar ni criticar, sumisión, adaptación.
Y llaman universidades a criaderos de mutantes.
Y en eso nos convertimos, progenie mutante. Adaptados por y para la sociedad productiva. Somos maquinaria del denso tejido industrial. No se tiene en cuenta quienes ni cómo somos, el título es nuestra carta de presentación, o al menos suele ser así, que generalizar es de ineptos.
Hace unas semanas, creo que fue la noche del advenimiento anual de JC, andaba con P y A discutiendo que quien sería más digno de halagos: un lobo de mar, curtido en mil batallas y conocedor de medio mundo, o un ilustré erudito que tiene en su poder cuantiosas cantidades de conocimientos adquiridos de las mejores bibliotecas. Este último es también conocido como rata de biblioteca, sin que el símil con el roedor menosprecie su candidatura. Pues, en un principio, y supongo que debido a nuestras distintas personalidades, A se decantó por el lobo de mar y P y yo por el erudito.
lobo vs rataAnalizando fríamente las dos opciones a barajar, se pueden encontrar argumentos para apoyar a los dos candidatos. Porque de qué sirve saber de la vida sin experimentarla, y por otro lado, sin apoyarte en lo que otros ya han aprendido volverás a caer en sus mismos errores. Parece que la discusión puede sintetizarse de la siguiente forma: qué es más valioso, descubrir mediante la experiencia o mediante el aprendizaje teórico. Un equilibrio parece lo más sensato. Cada persona debe balancear teoría y practica hasta encontrar el punto donde se encuentra más confortado. Siguiendo con la discusión, A me mostró argumentos para me rindiera a su evidencia y diera mi apoyo al lobo de mar. Fueron bastante convincentes, pero, aun así sigo buscando mi equilibrio.
Cumple y estate calladito y ganarás tu dinerito.
Hoy la mafia empresarial decidió tu bienestar
Un esclavo de nivel preso de un ordenador.
Tu corazón es sometido para el sistema productivo.
Pues si, es difícil salir del engranaje social preestablecido. Tú y yo, como todo hijo de vecino, sabemos que acabaremos terminando nuestros estudios, encontrando trabajo, comprándonos el coche y pagando la hipoteca. Porque es lo que no ha tocado vivir. Pero, tanto estudiar, tanto estudiar… no sirve de nada si no disfrutas de la vida. Leí hace tiempo, no recuerdo dónde, que se debía pensar cada mañana al levantarse si te gusta lo que tienes que hacer ese día, si es que sí, vas bien. Si no es así pero no puedes evitarlo, te jodes ese día. Si pasa mucho tiempo y sigue sin gustarte lo que tienes que hacer: ¡QUÉ SE JODAN OTROS!
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:
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:
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:
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
Librerías y wrappers
Exportadores
Aquí concluye la introducción a OGRE 3D. Espero con mucho entusiasmo que el lector haya encontrado interesante su contenido.
Efecto Old MovieContinuar 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 ShadowsLas 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 SkyBoxEs 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 VisionExtensiones 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’:
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.
OGRE Render WindowContinuar 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 WindowIntegració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
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 StormFirstAid 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 SimHCA : 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 DucklingLegend 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 DragonAnkh: 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 EgipciaThe 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 BlobProject 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 FootballThe 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 ToolkitThe 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
Renderizado
Gestión de escena
Texturizado
Iluminación
Sombras
Shaders
Animación
Mallas
Curvas y superficies
Efectos especiales
Scripting
Física
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
Suscribirse a:
Entradas (Atom)
