You are on page 1of 25

REALIZACIÓN DE UN MOTOR DE RENDER PARA DISPOSITIVOS MÓVILES BASADO EN IRRLICHT

Autor: Javier Meseguer de Paz
Dirigido por: Antonio Berlanga de Jesús

Plan de la presentación

  


  

Introducción Estado del arte Definición del proyecto Implementación Resultados Trabajo Futuro Resumen Demostración

color = rojo visualizar Motor de render Sistema operativo API gráfica .3ds” escena cubo.Introducción  ¿Qué es un motor de render?  Componente software encargado de generar y visualizar información gráfica  Abstrae los mecanismos de creación de gráficos Descripción de la cubo = cargar modelo “cubo.

Introducción  Razones para usar un motor de render  Es reutilizable  Varias aplicaciones pueden compartir motor  Ejemplo: El Unreal Engine 3 es usado por 79 juegos  Abstrae la comunicación con el API gráfica de ésta al resto de la aplicación  Independiza  Facilita  Como el mantenimiento de la aplicación siempre que se separa el modelo de la vista .

hay varios proyectos en marcha en esta misma Universidad que se beneficiarían de un motor de render para móviles .Introducción  Motivación del proyecto  Las capacidades gráficas de los teléfonos móviles van en aumento  Ya hay móviles con GPU   No hay un motor de render para móviles gratuito equiparable a los existentes para PC Y sería muy interesante tenerlos para:     Juegos Visualización de mundos virtuales Explorar nuevas interfaces Otras aplicaciones que puedan usar 3D  De hecho.

Estado del arte  Motores de render para móviles  Comerciales  Casi todos son propietarios  El más famoso es: IdeaWorks 3D AirPlay  Gratuitos  HeroCraft HiTech MobileDragon  GLQuake / Quake II for Symbian OS .

Estado del arte  HeroCraft   HiTech MobileDragon por:  Descartado El aspecto de las demos No haber podido ser ejecutado en el dispositivo .

Estado del arte  GLQuake/Quake II Engine for Symbian OS  Descartado por:    Obsoleto en general Difícil de usar y modificar No es de propósito general (especializado en FPS)  Por esto. decidimos crear nuestro propio motor de render  Partiendo de un motor gráfico de código abierto para PC .

Estado del arte  Esto implica que teníamos que decidir:  Qué API gráfica usar  Qué motor de render de código abierto para PC migrar  A qué plataforma / sistema operativo  Usando qué dispositivo como referencia  Para tomar una decisión informada. estudiamos el estado del arte de todas estas tecnologías  ¡Especialmente la plataforma objetivo y el motor de render de PC! .

Estado del arte  La decisión de la plataforma afecta a todo lo demás  No hay vuelta atrás  No todas las opciones son posibles. Hay que comprobar que: Sea posible desarrollar gratuitamente para la plataforma  Sea posible ejecutar un motor gráfico sin tener que certificarlo   Dentro de las opciones posibles. hay que valorar Qué lenguajes de programación hay disponibles  Facilidades a la migración desde otras plataformas  Madurez de la plataforma  Popularidad de la plataforma  .

Ha habido dos intentos de migración de Irrlicht   Intentos de migración    mIrrlicht Irrlicht-em . pero más complejo Irrlicht es más sencillo.Estado del arte   También especialmente importante qué motor migrar Hay muchos motores de render de código abierto para PC  No obstante. destacan OGRE 3D e Irrlicht   OGRE 3D es más avanzado. pero más rápido y simple   Tiene menos líneas de código dependiente del API No tiene dependencias externas OGRE 3D fue migrado a Windows Mobile hace mucho.

tiene aceleración gráfica.Definición del proyecto  Planteamiento formal  Migrar Irrlicht 1.1 a S60. y teníamos disponibilidad de uno Es la plataforma usada por el N95 Hay disponible un capa POSIX y una STL (OpenC/C++)  ¿Por qué S60?    Esto implica que el API gráfica a usar es OpenGL ES 1. tomando como dispositivo objeto el Nokia N95 8Gb   ¿Por qué Irrlicht?  Es más simple ¿Por qué el Nokia N95 8Gb?  Es muy potente.x .4.

Definición del proyecto  Requisitos  Conseguir una versión funcional  Mantener la compatibilidad con la versión oficial y el resto de sistemas operativos  Fuera de ámbito  Implementar nuevas técnicas  Que funcione en otros dispositivos  Incluyendo el emulador  Arreglar bugs .

Identificar las partes dependientes del API gráfica y la plataforma   2.x Crear el device para S60 . API gráfica: Driver Plataforma: Device Crear el driver de OpenGL ES 1. 3.Implementación 1.

Implementación – Driver OGLES  Driver de OpenGL ES 1.x  Partimos del driver de OpenGL  Algunas diferencias pudieron salvarse:  Carencia  de primitivas de modos de rasterización de soporte para los formatos de color de No hay quads ni polígonos No hay GL_LINES ni GL_POINTS  Carencia   Carencia Irrlicht  Otras .

. Reflexión especular dependiente del punto de vista  Carencia   Carencia  de generación automática de coordenadas de texturas Se usa para simular reflexiones ..Implementación – Driver OGLES  Otras  no: de shaders  Carencia  Carencia  Usado para técnicas avanzadas como el bump-mapping de ciertos modos de envoltura de ciertos modos de iluminación Prácticamente no se usa.

Implementación – Device S60  Peculiaridades de la programación Symbian  Hay tres compiladores WINSCW – genera x86 para el emulador  GCC-E – genera ARM. de pago y el más completo   El API de Symbian está basado en Frameworks Afortunadamente no es obligatorio usarlos  No obstante. eso está menos documentado   Symbian es resultado de una evolución  Hay que documentarse mediante ejemplos. gratuito y limitado  ARM RVCT – genera ARM optimizado. porque los nombres de las cosas ya no corresponden con lo que son .

hay que hacer algunos cambios  Algunos debidos a que el compilador es de Symbian C++ y no ANSI C++  Ejemplo: Problemas con definiciones en los headers  Otros debidos al cambio de compilador Cómo compactar las estructuras Las convenciones de llamada  Ejemplo:  Otros debidos al cambio de plataforma  Ejemplo: .Implementación – Device S60  Antes de crear el device.

Implementación – Device S60   Finalmente podemos crear el device Tiene que poder hacer lo siguiente:  Gestionar  Gracias el sistema de ficheros a OpenC++ se puede usar POSIX para ello.  Crear la ventana  Obtener el modo de video  Dormir la aplicación .

Implementación – Device S60  Manejar eventos  Relacionados  con las ventanas  Entrada de datos del usuario Es muy distinta en PC y en el N95  Falta de teclado QWERTY  Cuando se requiere inmediatez: modo normal  Cuando se requieren todas las letras: modo multitapping  Falta de ratón  Se emula con el teclado .

. Veamos los resultados.Resultados Y con eso terminamos la implementación.

Resultados  Balance de características  Hemos perdido (en orden de importancia)     Shaders (y por tanto normal mapping) Reflejos Reflexión especular dependiente de la vista Modos de envoltura de texturas Soporte para múltiples formatos de fichero Soporte para 2D Un buen sistema de partículas Una GUI Detección de colisiones básica Gestión de escena …  Pero conservamos        .

x Añadir nuevas características  Bump-mapping.4.x Añadir soporte para otras plataformas Añadir soporte para otros dispositivos … . luces direccionales. bloom.5   Optimizar el driver de OpenGL ES 1. refracción…     Añadir soporte para OpenGL ES 2.Trabajo futuro  Actualizar la versión de Irrlicht a la última  En lo que cambiábamos la versión 1.1 ha salido la 1.

Resumen Hay muchas mejores posibles aún .

Resumen   Queríamos un motor de render para móviles gratuito No encontramos ninguno de calidad Decidimos portar uno de PC a una plataforma móvil  Concretamente Irrlicht a S60   Para ello hubo que crear Un driver de OpenGL ES  Un device para S60   Logramos un motor para móviles que conserva casi todas las características del Irrlicht original .