Archivo: January, 2008

« Anteriores
Siguientes »

Problemas con la codificación de archivos

[ Blog: yEnS - plusdeporte (blog) ]
2008:01:28 01:22:55

Pues parece que finalmente no se cumplirán los plazos de presentación de la web. El principal problema ha sido el cambio de codificación de los archivos del proyecto de ANSI (Windows) a UTF-8 UNIX… Caracteres “basura” e “invisibles” nos han traído por la calle de la amargura pero gracias a textmate (Mac OS X) la codificación de los archivos se ha cambiado sin mayores problemas… Nota mental: a partir de ahora trabajar sólo en Linux/Mac y nos olvidaremos de futuros problemas de codificación…

En fin, sentimos las molestias causadas a quién haya leído la anterior entrada si realmente estaba interesado en ver la web a lo largo de esta semana… muy pronto nuevas (y esperemos buenas) noticias.

Un saludo!

Report semanal de Kukoo Kitchen

[ Blog: Josepho - Blog personal de Josepho ]
2008:01:26 14:16:00

visualizeus en la tele!

[ Blog: Kr0n - beer2beer ]
2008:01:25 20:53:47

¡Sus cinco primeros minutos de fama, señores!

Resulta que el equipo de Cámara Abierta 2.0 tropezó con el proyecto y les gustó lo suficiente como para currarse este reportaje tan chulo que se han currado.

(el video, tras el salto!)

Cámara Abierta 2.0 es un nuevo espacio de La 2 que como ellos mismos definen es “el primer programa de Televisión en España dedicado a Internet como plataforma de información, creación y comunicación“. Y la verdad es que no soy un punto de vista muy imparcial que digamos, pero viendo lo bien que les ha quedado el reportaje sobre el visualizeus, sencillo, clarito, buen montaje y mejor música… pues buen hacer tienen, si señor.

Muchas gracias al equipo de Cámara Abierta por fijarse en visualizeus ;)

Compártelo

We’re Off To See The Wizard

[ Blog: Hans - El rincón de Topo & Pollo ]
2008:01:25 13:03:00
(Follow the Yellow Brick Road)

Follow the Yellow Brick Road. Follow the Yellow Brick Road.
Follow, follow, follow, follow,
Follow the Yellow Brick Road.
Follow the Yellow Brick, Follow the Yellow Brick,
Follow the Yellow Brick Road.

We're off to see the Wizard, The Wonderful Wizard of Oz.
You'll find he is a whiz of a Wiz! If ever a Wiz! there was.
If ever oh ever a Wiz! there was The Wizard of Oz is one becoz,
Becoz, becoz, becoz, becoz, becoz.
Becoz of the wonderful things he does.



"We're Off to See the Wizard (Follow the Yellow Brick Road)"

Ya somos de DOID

[ Blog: JDHorux - SymbiaIT Games ]
2008:01:24 13:25:00
SymbiaIT Games ya pertenece a DOID como empresa asociada. Iremos informando de los eventos en los que participemos y todas las iniciativas de dicha asociación.

Demoreel 2008

[ Blog: zwiTTeR - dfrriz - Ilustración, arte y videojuegos... ]
2008:01:23 21:59:00

OGRE (V): Trasteando un poco

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

Efecto Old Movie

Continuar leyendo...
Estructura del manejador de escena

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

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

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

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

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

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

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

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

Additive Stencil Shadows

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

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

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

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


Uso del SkyBox


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

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

Efecto Heat Vision


Extensiones para OGRE

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

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

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

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


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



Nuevas capturas de The Happy Race 2008

[ Blog: Hans - El rincón de Topo & Pollo ]
2008:01:23 10:41:00
Del desierto :D

Photobucket

Photobucket

La Industria del Videojuego en España. ¿Un Futuro Pixelado?

[ Blog: JDHorux - SymbiaIT Games ]
2008:01:22 12:35:00
En las Jornades POW UAB, se realizó una interesantísima mesa redonda sobre el presente y el futuro del videojuego en España.

Han subido un video que se puede ver aquí.

Doid

[ Blog: JDHorux - SymbiaIT Games ]
2008:01:22 12:01:00
SymbiaIT Games socia de DOID (Asociación de Desarrolladores de Ocio Interactivo Digital).

DOID es una asociación sin ánimo de lucro, creada con el objetivo de promover tanto la industria como la cultura del videojuego y otras formas similares de entretenimiento digital a través de todo tipo de actividades, a la vez que se favorece el encuentro entre las distintas partes interesadas.



Empresas DE GRAN IMPORTANCIA en el sector del videojuego en España ya forman parte de la misma:

Abylight (Barcelona)
Devilish Games (Villena, Alacant)
EnjoyUp (Hospitalet del Llobregat, Barcelona)
Evolution Dreams Studio (Barcelona)
Exelweiss (València)
Kailab (Barcelona)
Novarama (Barcelona)
OPQA Studios (Madrid)
UC Games (Vigo)
Grupo ZED (Madrid)
Unkasoft (Salamanca)
Revistronic (Madrid)
Mayhem Studio (Madrid)
Péndulo Studios (Madrid)

Además, hay otras asociaciones importantes en el sector:

DeSEA
StRAtOS
« Anteriores
Siguientes »