UNIVERSIDAD PONTIFICIA COMILLAS · el movimiento del esqueleto automáticamente afectará las...
-
Upload
truongxuyen -
Category
Documents
-
view
213 -
download
0
Transcript of UNIVERSIDAD PONTIFICIA COMILLAS · el movimiento del esqueleto automáticamente afectará las...
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
DISEÑO Y DESARROLLO DE UN SISTEMAS DE PARTÍCULAS PARA ANIMACIÓN
POR ORDENADOR
AUTOR: MANUEL MARTÍNEZ HERRERA
MADRID, Febrero de 2007
Autorizada la entrega del proyecto del alumno:
Dº. Manuel Martínez Herrera
EL DIRECTOR DEL PROYECTO
D. Mauro López Arias
Fdo: ________________ Fecha: 20/02/07
Vº Bº del Coordinador de Proyectos
D. Miguel Ángel Sanz Bobi
Fdo: ________________ Fecha: 20/02/07
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
DISEÑO Y DESARROLLO DE UN SISTEMAS DE PARTÍCULAS PARA ANIMACIÓN
POR ORDENADOR
AUTOR: MANUEL MARTÍNEZ HERRERA
MADRID, Febrero de 2007
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
I
DEDICATORIA A los que no confiaban en mí.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
II
AGRADECIMIENTOS A las personas que, en mayor o menor medida, han ayudado en el desarrollo de este
proyecto, especialmente a Mauro, por su paciencia y confianza a veces inmerecidas.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
III
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS PARA
ANIMACIÓN POR ORDENADOR
RESUMEN
En los últimos años, las herramientas dedicadas a la generación de gráficos
por ordenador y al modelado 3D han conseguido ocupar un papel muy
importante dentro del mundo de las aplicaciones informáticas. La principal causa
de este crecimiento se encuentra en la industria del entretenimiento electrónico,
especialmente en los videojuegos y en las películas de animación por ordenador.
Sin embargo, la aplicación de esta tecnología va mucho más allá, abarcando los
más diversos campos, encontrándose en soluciones de carácter científico‐técnico,
simuladores, generación de escenarios, etc.
Los sistemas de partículas ocupan un papel fundamental dentro de este
tipo de aplicaciones, especialmente en las referentes a juegos y animación por
ordenador, hacia las que este proyecto está dirigido. Con ellos se pueden
representar efectos gráficos que pretenden simular fenómenos naturales como
explosiones, corrientes de agua, fuego... suponiendo unas leyes físicas del entorno
para alcanzar el máximo grado de realismo posible.
Al tratarse, por lo tanto, de una tecnología relativamente reciente, muchas
empresas desarrolladoras encuentran problemas a la hora de buscar en el mercado
una herramienta que les permita generar estos sistemas de partículas y, más aún,
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
IV
que les permita integrarlos de forma transparente con el resto de sus aplicaciones
gráficas.
Debido, entonces, a la escasa oferta de este tipo de soluciones, la tendencia
actual en la industria es desarrollar cada empresa su sistema de partículas propio,
lo que conlleva una inversión de recursos como tiempo y dinero para conseguir a
veces algo poco reutilizable y que, en algunos casos, puede suponer una limitación
o barrera de entrada para las empresas novicias en el sector.
Lo que este proyecto pretende es realizar una herramienta gráfica que
permita a los desarrolladores de las compañías de videojuegos y de animación por
ordenador generar sistemas de partículas complejos, de una forma rápida,
independiente del marco de trabajo, y utilizando las tecnologías más actuales
(OpenGL, DirectX). Para conseguirlo, será fundamental aplicar el concepto de
modularidad, que es lo que va a permitir que los diferentes paquetes integrantes
de la aplicación sean independientes entre sí, posibilitando esto satisfacer las
necesidades más específicas de los clientes mediante una serie de pequeños
cambios en algunos módulos determinados. Con esto se conseguirá entrar en un
mercado en plena etapa de crecimiento, atendiendo a una demanda hasta ahora
insatisfecha y garantizando, por lo tanto, él éxito de la aplicación.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
V
ABSTRACT
In the last years, computer tools aimed to create graphics and to 3D
modelling are playing a relevant role in computer applications world. We can find
the main reason for this growth in the electronic entertainment industry,
especially in videogames and computer‐animated films. Nevertheless, the
application of this technology goes further more, covering a wide range of fields,
finding scientific‐ technologic solutions, simulators, creation of sets, etc.
For this kind of applications particle systems are basic, mainly in those
referred to games and computer animation, the ones this project is aimed to. With
them graphic effects can be represented simulating natural phenomena like
explosions, running water, fire… supposing environmental laws of physics to
create effects as real as possible.
By being, then, a relatively recent technology, many development
companies find problems when they are searching in the market a tool to create
these particle systems and, what is more, to be able to integrate them in a clear
way with their other graphic applications.
So, due to the shortage of offers made of these kinds of solutions,
nowadays, the tendency is to develop for each company its own particle systems,
what entails a investment of resources, time and money to obtain, sometimes, a
product that is unlikely to be re‐used and that, in certain cases, can be a handicap
or a barrier for companies beginning in the sector.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
VI
So, the purpose of this project is to create a graphic tool to allow video
games and computer animation companies’ developers to generate complex
particle systems, in a quick way, apart from frame work and using the most up‐
dated technologies (OpenGL, DirectX). To achieve this, it will be basic to apply the
concept of modularity. This will be what it is going to allow the different packages
of this application to be independent, helping so to satisfy the most specific
necessities of clients by certain little changes made in certain modules.
To accede to a currently growing market will be possible with this
application, paying attention to a demand not satisfied up today and
guaranteeing, therefore, its success.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
VII
Índice
I. INTRODUCCIÓN: ENTORNO DEL PROBLEMA ................................................. 1
Situación de las aplicaciones gráficas ..........................................................................1
Gráficos 3D por ordenador............................................................................................3
Los sistemas de partículas .............................................................................................6
Motivación del proyecto ................................................................................................8
II. OBJETIVO DEL PROYECTO ................................................................................... 10
II. ANÁLISIS DE REQUISITOS ................................................................................... 12
Introducción...................................................................................................................12
Documento de Conceptos del Sistema ......................................................................13
Lista de requisitos .........................................................................................................15
Modelo lógico del sistema ...........................................................................................21
III. ESTUDIO DE ARQUITECTURA ..........................................................................35
Introducción...................................................................................................................35
Selección de la arquitectura.........................................................................................36
Especificación gráfica ...................................................................................................41
Lenguaje de programación..........................................................................................44
Sistema operativo..........................................................................................................48
IV. DISEÑO DEL SISTEMA..........................................................................................50
Introducción...................................................................................................................50
El Sistema de Partículas ...............................................................................................51
Visión general de la aplicación ...................................................................................64
El paquete EngineDemo ..............................................................................................68
Entrada de datos: El interfaz de usuario ...................................................................74
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
VIII
V. USO DE LA APLICACIÓN.......................................................................................79
VII. PLANIFICACIÓN Y PRESUPUESTO ..................................................... 85
ANEXOS ............................................................................................................................ 97
Anexo A: Acerca de OpenGL ......................................................................................... 97
Anexo B: Comparación entre OpenGL y Direct X. ..................................................101
Anexo C: Relación de clases......................................................................................... 107
Anexo D: El fichero de emisores. ................................................................................109
Bibliografía. .................................................................................................................... 111
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
1
I. INTRODUCCIÓN
Situación actual de las aplicaciones gráficas
En el mundo de la informática las aplicaciones gráficas tienen cada vez
una mayor importancia. Son necesarias tanto para solucionar problemas
técnicos, como de ocio y entretenimiento.
En el primer grupo de aplicaciones pueden incluirse las diferentes
aplicaciones CAD/CAM, en las que es necesaria una gran precisión y
exactitud, y deben proporcionar también gran cantidad de operaciones de
modificación de los modelos (secciones, intersecciones, taladros…).
El segundo grupo está formado por las aplicaciones en las que se prima
la calidad visual. Hoy en día estas soluciones son las que utilizan las
tecnologías más avanzadas en lo que a gráficos se refiere. Dentro de este
conjunto puede hacerse una nueva división:
• Aplicaciones batch: Mejores resultados pero con un alto tiempo
de ejecución.
• Aplicaciones en tiempo real: Buscan el equilibrio entre la calidad
y la tasa de refresco de la pantalla. Son también conocidas como
motores gráficos.
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Este proyecto está diseñado para la representación de sistemas de
partículas, y debe ser incluido dentro de las aplicaciones en tiempo real del
grupo de ocio y entretenimiento.
2
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Gráficos 3D por ordenador
El término gráficos 3D por ordenador (3D computer graphics) se refiere a
trabajos de arte gráfico que fueron creados con ayuda de ordenadores y
programas especiales 3D. En general, el término puede referirse también al
proceso de crear dichos gráficos, o al campo de estudio de técnicas y tecnología
relacionadas con los gráficos 3D.
Un gráfico 3D difiere de uno 2D principalmente por la forma en que ha sido
generado. Este tipo de gráficos se origina mediante un proceso de cálculos
matemáticos sobre entidades geométricas tridimensionales producidas en un
ordenador, y cuyo propósito es conseguir una proyección visual en dos
dimensiones para ser mostrada en una pantalla o impresa en papel.
El proceso de creación de gráficos 3D por computadora puede ser dividido
en estas tres fases básicas [8]:
• Modelado
• Composición de la escena
• Rénder (creación de la imagen final)
Modelado
La etapa de modelado consiste en ir dando forma a objetos individuales que
luego serán usados en la escena. Los procesos de modelado pueden incluir la
3
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
edición de la superficie del objeto o las propiedades del material (por ejemplo,
color, luminosidad, difusión, características de reflexión, transparencia u
opacidad, o el índice de refracción), agregar texturas, mapas de relieve y otras
características.
El proceso de modelado puede incluir algunas actividades relacionadas con
la preparación del modelo 3D para su posterior animación. A los objetos se les
puede asignar un esqueleto, una estructura central con la capacidad de afectar la
forma y movimientos de ese objeto. Esto ayuda al proceso de animación, en el cual
el movimiento del esqueleto automáticamente afectará las porciones
correspondientes del modelo.
Composición de la escena
Esta etapa involucra la distribución de objetos, luces, cámaras y otras
entidades en una escena que será utilizada para producir una imagen estática o
una animación. Si se utiliza para animación, esta fase, en general, hace uso de una
técnica llamada keyframing, que facilita la creación de movimientos complicados en
la escena. Con la ayuda de la técnica de keyframing, en lugar de tener que corregir
la posición de un objeto, su rotación o tamaño en cada cuadro de la animación,
solo se necesita marcar algunos cuadros clave (keyframes). Los cuadros entre
keyframes son generados automáticamente, lo que se conoce como “Interpolación”.
La iluminación es un aspecto importante de la composición de la escena.
Como en la realidad, la iluminación es un factor importante que contribuye al
resultado estético y a la calidad visual del trabajo terminado. Por eso, puede ser un
arte difícil de dominar. Los efectos de iluminación pueden contribuir en gran
4
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
medida al humor y la respuesta emocional generada por la escena, algo que es
bien conocido por fotógrafos y técnicos de iluminación teatral.
Renderizado
Se llama rénder al proceso final de generar la imagen 3D o animación a
partir de la escena creada. Esto puede ser comparado a tomar una foto o en el caso
de la animación, a filmar una escena de la vida real. Generalmente se buscan
imágenes de calidad fotorrealista, y para este fin se han desarrollado muchos
métodos especiales. Las técnicas van desde las más sencillas, como el rénder de
alambre (wireframe rendering), pasando por el rénder basado en polígonos, hasta
las técnicas más modernas como el Scanline Rendering, el Raytracing, o el Mapeado
de fotones.
El software del rénder puede simular efectos cinematográficos que son, en
realidad, un producto de las imperfecciones mecánicas de la fotografía física, pero
como el ojo humano está acostumbrado a su presencia, la simulación de dichos
efectos aporta un elemento de realismo a la escena. Se han desarrollado técnicas
con el propósito de simular otros efectos de origen natural, como la interacción de
la luz con la atmósfera o el humo. Ejemplos de estas técnicas incluyen los sistemas
de partículas, que pueden simular lluvia, humo o fuego, y las cáusticas para
simular el efecto de la luz al atravesar superficies refractantes.
El proceso de renderizado necesita una gran capacidad de cálculo, pues
requiere simular gran cantidad de procesos físicos complejos. La capacidad de
cálculo se ha incrementado rápidamente a través de los años, permitiendo un
grado superior de realismo en el renderizado y por los tanto en los resultados.
5
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Los sistemas de partículas
El término “sistema de partículas” se refiere a la técnica usada en la
animación por ordenador para simular fenómenos concretos que serían muy
complicados de reproducir con las técnicas convencionales de renderizado. Un
ejemplo de los efectos comúnmente realizados por los sistemas de partículas
serían explosiones, fuego, humo, corrientes de agua, nieve, chispas, niebla,
nubes…
Aunque en la mayoría de los casos los sistemas de partículas son
implementados en entornos gráficos tridimensionales, los sistemas de partículas
bidimensionales pueden ser también usados bajo ciertas circunstancias.
Normalmente, la posición de un sistema de partículas en un espacio 3D está
controlada por lo que se conoce como “emisor”. Principalmente, el emisor se
caracteriza por una serie de parámetros que serán aplicados a las partículas
emitidas por éste y que definirán su comportamiento. Los parámetros de
comportamiento de las partículas pueden incluir el ratio de generación de las
mismas (es decir, cuantas partículas se tienen que generar por unidad de tiempo),
la velocidad de desplazamiento, el tiempo de vida, color o el tamaño.
Ocasionalmente, lo que se hace es inicializar estos parámetros alrededor de un
valor centra con una variación aleatoria contenida dentro de un rango.
De forma periódica, el sistema de partículas realiza una vuelta de
actualización que consta de dos fases principales:
6
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Fase de simulación. Durante esta fase se crearán las nuevas partículas
necesarias en función del ratio de generación y el tiempo
transcurrido desde la última vuelta. Se comprueba el tiempo de vida
de las partículas ya existentes, se eliminan aquellas que hayan
excedido el tiempo de vida máximo, y se aplican al resto de
partículas los modificadores especificados para el emisor y que
definirán el efecto que se pretende conseguir.
• Fase de rendering. Una vez que se haya completado la fase anterior
cada partícula es dibujada normalmente en forma de píxel o de
textura.
A continuación se muestran una serie de efectos conseguidos mediante
sistemas de partículas:
7
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Motivación del proyecto
La industria de la animación por ordenador ha disfrutado durante los
últimos años de un auge que le ha permitido expandir sus fronteras más allá del
mundo del cine o del entretenimiento electrónico (videojuegos).
Este crecimiento se ha debido en parte a que, en la actualidad, y gracias
a las aplicaciones en tiempo real, la capacidad del hardware está creciendo a
un ritmo mucho más elevado, permitiéndonos realizar gran cantidad de
efectos en el hardware de nuestra tarjeta gráfica, dejando al procesador
principal libre para realizar otras tareas. Esto es algo fácilmente comprobable,
solo es necesario observar la frecuencia con la que los fabricantes lanzan al
mercado sus nuevas tarjetas gráficas, superando con creces la potencia del
anterior modelo. El crecimiento es tan rápido que hace que la ley de Moore se
quede desfasada.
Gracias a este hardware se pueden aplicar, en tiempo real, efectos que
hace algunos unos años estaban solo al alcance de las estaciones gráficas más
potentes. Es decir, el avance de la tecnología ha hecho que la animación por
ordenador y el grafismo 3D sea algo mucho más “portable”.
Se trata sin duda de un campo con una gran proyección de futuro y cuyo
crecimiento está fuertemente ligado al avance de las tecnologías de la información.
Este proyecto representa, por lo tanto, una oportunidad única para conocer
el funcionamiento de este tipo de aplicaciones, proporcionando una base útil de
cara a la industria del entretenimiento basada en la animación por ordenador.
8
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Por otro lado, y debido a su naturaleza, la herramienta que se va a realizar
se aleja de los trabajos y prácticas realizados durante el periodo de formación
universitaria, suponiendo el acercamiento a una metodología y unas herramientas
de trabajo desconocidas hasta el momento y que permitirán al alumno ampliar sus
conocimientos y conocer nuevos campos de aplicación de la informática.
Por último, hay que valorar el atractivo que ofrece la posibilidad de
desarrollar una aplicación que tenga una utilidad real, y que, una vez finalizada,
pueda ser implantada y funcione correctamente dentro de escenarios creados
como entornos gráficos tridimensionales.
9
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
II. OBJETIVO DEL PROYECTO
Se pretende crear una aplicación que permita definir y simular sistemas de
partículas en entornos gráficos tridimensionales a partir de una serie de
características específicas introducidas por un diseñador de un interfaz gráfico.
Según estas características, las partículas se comportarán de una forma una otra,
variando así su movimiento en la pantalla, aspecto físico, periodo de vida… De
esta forma que se podrán obtener diversos sistemas de partículas con una misma
aplicación para generar efectos visuales.
Para conseguir este objetivo principal es necesario alcanzar una serie de
objetivos menores tales como:
• Desarrollar una aplicación que permita generar sistemas de partículas
complejos, que soporte emisores con diferentes formas (esferas, cubos…), y
simular comportamientos reales (colisiones, caídas).
• Crear un formato de archivos para salvar todos los parámetros de un
sistema, de forma que una vez creado este sistema sea reutilizable.
• Modularidad, la herramienta será modular, estando compuesta por tres
módulos principales:
o Un sistema de renderizado para pintar los objetos y partículas, así
como el entorno gráfico.
o Un módulo base (para acceso a ficheros, funciones matemáticas…).
10
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
o El sistema de partículas en sí, encargado de calcular posiciones,
tamaños (haciendo uso del módulo base), y llamar al módulo de
renderizado.
De esta forma se podrán realizar cambios en un módulo cualquiera sin que
los demás se vean afectados.
• Portabilidad, aunque la aplicación se haga bajo OpenGL, será fácilmente
portable a otras APIs de programación gráfica (como Direct X), ya que
todas las operaciones de dibujado se harán en el módulo de renderizado.
De esta forma, sustituyendo éste por uno compatible (que use el mismo
interfaz) se podrá portar la aplicación.
• La herramienta funcionará en tiempo real, es decir, cualquier modificación
de un parámetro se verá reflejada de manera inmediata en la simulación.
• El interfaz gráfico permitirá navegar entre los diferentes emisores que
existan y modificar sus propiedades, a la vez que añadir o eliminar
elementos.
• Se mostrarán estadísticas sobre los tiempos empleados en los cálculos,
fotogramas por segundo o número de partículas de cada sistema.
11
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
III. ANÁLISIS DE REQUISITOS
Introducción
El objetivo de esta fase o etapa es trazar los condicionantes de la aplicación,
definiendo necesidades, problemas y requisitos del usuario, para expresarlo
mediante los modelos de procesos y datos. Para ello se completarán tres puntos
esenciales [1]:
• Documento de Conceptos del Sistema.
• Lista de requisitos.
• Modelo lógico del sistema.
12
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Documento de Conceptos del Sistema
El documento de Conceptos del Sistema especifica de forma resumida parte
de la información recogida durante las entrevistas realizadas con el cliente.
PROYECTO
SISTEMA DE PARTÍCULAS
DOCUMENTO DE
CONCEPTOS DEL SISTEMA
FECHA:
MAYO 2006
1. OBJETIVOS DEL SISTEMA
El principal objetivo del sistema es facilitar la labor de los programadores y
diseñadores gráficos de la empresa cliente, permitiendo acelerar el desarrollo de
aplicaciones 3D que requieran efectos elaborados con sistemas de partículas.
2. ALCANCE DEL SISTEMA
La construcción del sistema abarcará las funciones que se determinan a
continuación:
• Generación de sistemas de partículas en tiempo real.
• Interacción de dichos sistemas con escenarios gráficos 3D.
• Creación y manipulación de archivos para almacenamiento de la
información asociada a cada sistema.
3. TIPOLOGÍA DE USUARIOS
Los usuarios de este sistema serán principalmente desarrolladores gráficos, tanto
diseñadores como programadores. Estarán, por lo tanto, familiarizados con los
principales conceptos relacionados con la animación por ordenador, y puede que
hayan trabajo con las principales APIS gráficas como OpenGL o Direct X, lo que
facilitará el entendimiento y el manejo de la aplicación.
4. RESTRICCIONES
• Todas las librerías gráficas y software usadas para su desarrollo deben
13
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
hacerse bajo la especificación OpenGL, aunque se deben poder migrar a
otras especificaciones. Consultar anexo A para más información sobre esta
especificación.
• Se dispondrá de un presupuesto de 12.000 euros.
• El plazo para el desarrollo del proyecto no debe sobrepasar los seis meses
de duración.
5. ANTECEDENTES
Hasta el momento, la mayor parte de las herramientas para la generación de
sistemas de partículas son propias de las compañías desarrolladoras, de manera
que no existe un modelo común o un patrón a seguir a la hora de diseñar una
aplicación de este tipo. Se deberán cumplir las necesidades del cliente pero
dejando cierta flexibilidad para futuras adaptaciones en otros entornos o
empresas.
14
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Lista de requisitos
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: De diseño IDENTIFICADOR: REQ‐01
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS: REQ‐04
TÍTULO: Abstracción del sistema de pintado
DESCRIPCIÓN:
Dentro de la aplicación, juega un papel fundamental el código de pintado, ya que
éste es el que se encarga de generar los efectos y mostrarlos por pantalla. Esta
parte del código debe estar aislada en el menor número de puntos para facilitar la
portabilidad. En otras palabras, debe ofrecer un interfaz lo más sencillo posible
para que el módulo de renderizado pueda ser modificado de forma independiente
al resto del sistema.
Este requisito está fuertemente relacionado con la modularidad del sistema,
concepto también muy importante y que se verá más adelante.
BENEFICIOS:
Este requisito permitirá independizar el resto de la aplicación del paquete de
renderizado, de forma que si en algún momento se decide cambiar la
especificación (pasar de OpenGL a Direct X, por ejemplo) las dificultades sean las
menos posibles. También ayudará a hacer la aplicación más independiente de la
plataforma.
15
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: Funcional IDENTIFICADOR: REQ‐02
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS: REQ‐03
TÍTULO: Interfaz gráfico
DESCRIPCIÓN:
La aplicación debe contar con un interfaz gráfico que facilite al desarrollador la
interacción con la misma. Este interfaz debe ser lo menos complejo posible y
permitir acceder a todas las funcionalidades de la utilidad. Así mismo, debe
mostrar toda la información de lo que se está ejecutando en cada instante, es
decir, a través del interfaz el usuario debe poder ver los emisores que se
están ejecutando en un momento dado, su características, etc.
BENEFICIOS:
Atendiendo al fin último de la aplicación, el interfaz gráfico no sería una parte
estrictamente necesaria. Esto es debido a que la función principal del sistema es
colocar emisores de partículas en un punto concreto de un escenario 3D, lo cual se
hace mediante modificaciones en el código fuente. Sin embargo, es interesante que
el usuario pueda interaccionar con la aplicación de una forma visual, más
intuitiva, que ayude a la comprensión del funcionamiento de ésta y que no
requiera compilar el programa cada vez que se cambien los parámetros de
entrada.
El interfaz, por lo tanto, ayudará a hacer uso del sistema de una forma más amena,
abstrayendo al desarrollador de las complejas operaciones internas.
16
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: Funcional IDENTIFICADOR: REQ‐03
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS: REQ‐02
TÍTULO: Ejecución en tiempo real
DESCRIPCIÓN:
El sistema debe mostrar los resultados de las operaciones introducidas a través del
interfaz de usuario en tiempo real. Es decir, no serán necesarios procesos de
compilación y “linkado” siempre que se quiera crear o destruir nuevos emisores, o
modificar los parámetros de los ya existentes viendo como afectan a los efectos
realizados en fase de dibujado.
BENEFICIOS:
Esto permitirá al usuario ver como los efectos generados por los emisores van
variando según se modifiquen los parámetros de entrada de los mismos. Esto se
considera una parte importante de la aplicación ya que el desarrollador puede
probar varios efectos antes de decidirse por una configuración final, sin tener que
estar definiendo variables en el código que simulen la información de entrada, y
teniendo que compilar la aplicación para apreciar los cambios. Esto permitirá
ahorrar tiempo a la hora de diseñar efectos, y hará que el uso de la aplicación sea
menos complicado.
17
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: de diseño IDENTIFICADOR: REQ‐04
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS: REQ‐01
TÍTULO: Modularidad
DESCRIPCIÓN:
El objetivo de este requisito es doble:
• Por un lado, conseguir que, salvo los interfaces de comunicación, los
diferentes paquetes que forman la aplicación sean independientes entre sí.
• Por otra parte, esta división de paquetes de trabajo debe permitir una
reutilización de estos componentes y de las funcionalidades de cada uno de
ellos.
BENEFICIOS:
Debido al tipo de aplicación ante la que se está trabajando, la independencia entre
los diferentes componentes de ésta es algo fundamental, ya que con el paso del
tiempo nos permitirá realizar modificaciones sobre cada uno de estos paquetes de
trabajo sin que el resto de ellos se vean afectados.
Estas modificaciones pueden venir condicionadas por cambios en la tecnología,
nuevas necesidades del cliente, ampliación de la funcionalidad del sistema, etc.
Como ya se ha mencionado anteriormente, merece especial atención la
independencia del módulo de renderizado, ya que nos permitirá migrar entre
diversas especificaciones gráficas haciendo unos cambios mínimos.
La modularidad permitirá también la reutilización de componentes y métodos.
Por poner un ejemplo, si se tiene un método “aplicar modificador” que se puede
aplicar tanto sobre emisores de partículas como sobre emisores de emisores, esto
dará lugar a que con muy pocas clases se puedan crear una gran variedad de
efectos.
18
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: de rendimiento IDENTIFICADOR: REQ‐05
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS:
TÍTULO: Velocidad en frames por segundo.
DESCRIPCIÓN:
La sensación de velocidad y fluidez con que se mueven los emisores y las
partículas por la pantalla del usuario o por en entorno gráfico 3D ésta
estrechamente ligada a la cantidad de frames que se emiten por segundo.
La aplicación debe ser capaz de correr sin ningún tipo de problemas a una
velocidad mínima de 25 frames por segundo (25fps).
BENEFICIOS:
Si se tiene, por ejemplo, un emisor emitiendo partículas a un frame por segundo
(1fps) apenas habría sensación de movimiento por parte de las partículas, ya que
pasarían de una posición en pantalla a otra de una forma muy brusca, sin
apreciarse un desplazamiento continuo intermedio.
A 10fps, entre la posición inicial y la final, en un segundo, el sistema pinta en
pantalla diez veces la partícula de una forma distribuida entre ambas
coordenadas, de manera que se aprecia la trayectoria y el movimiento seguido por
la partícula dando una mayor sensación de fluidez.
19
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Alta
TIPO DE REQUISITO: operativo IDENTIFICADOR: REQ‐06
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS:
TÍTULO: Fichero de emisores
DESCRIPCIÓN:
Es necesario definir un formato de fichero para que los emisores editados por los
usuarios se puedan guardar en disco, de forma que puedan volver a ser
reutilizados.
BENEFICIOS:
Cada vez que un usuario edite un emisor, es decir, configure el efecto que se
genera por medio de la introducción de los parámetros de entrada de los
inicializadores y modificadores, debe tener la posibilidad de guardar esta
configuración en disco.
Esto permitirá al usuario volver a cargar el emisor en otra ejecución posterior.
PROYECTO: Sistema de partículas JEFE PROYECTO: Manuel Martínez Herrera
FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Media
TIPO DE REQUISITO: de rendimiento IDENTIFICADOR: REQ‐07
FUENTE: Entrevista con el cliente REQ. RELACIONANDOS:
TÍTULO: Acceso a memoria
DESCRIPCIÓN:
Debido al uso excesivo que las aplicaciones gráficas 3D hacen de la memoria del
sistema se deben minimizar los accesos a ésta.
BENEFICIOS:
Esto se conseguirá declarando listas de emisores y de partículas con una tamaño
predeterminado para evitar pedir memoria siempre que se cree un objeto.
20
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Modelo lógico del sistema
Nivel 0: Diagrama de contexto
1
Sistemade Partí culas
EntornoGráf ico 3D
Programador Efectos
Orden emisor
Parámet ros
Orden renderizado
Proceso 1. SISTEMA DE PARTÍCULAS
Descripción En este diagrama se muestra el primer nivel del modelo de
procesos, donde se representan las entidades externas al sistema
y los flujos principales de entradas y salidas.
En su relación con el exterior, el sistema de partículas recibe del
usuario, en este caso el programador, la siguiente información:
• La orden de emisor, que podrá consistir en crear un
nuevo emisor, cargar uno guardado en disco, o guardar
un emisor que se acaba de crear.
• La orden de renderizado, que indicará al sistema de
partículas si debe arrancar, pausar o detener la ejecución
de un emisor.
• Los parámetros con los valores para inicializar las
partículas y aplicar los inicializadores y modificadores.
21
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Con esta información, el sistema generará y dibujará los efectos
que serán pasados al entorno gráfico tridimensional para ser
mostrados por pantalla.
22
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Nivel 1: Diagrama conceptual
1.1
CrearEmisor
1.2
Aplicarinic ializadores
1.3
Aplicarmodif icadores
1.4
Renderizado
Fichero emisores
1.5
CargarEmisor
1.6
Guardaremisor
Fichero emisores
Buf f er emisiónParámet rosmodif icadores
Emisorinic ializado
Orden em sior
Emisor
Parámet rosinic ializadores
Emisorparam et rizado
Orden em isor
Parámet ros
Emisorparam et rizado
Orden renderizado
Orden em isor
Efectos
Orden em isión
Efectos
Proceso 1.1 Crear Emisor
Descripción Este proceso recibe del usuario la orden de crear un nuevo
emisor. Se creará un elemento de este tipo, asignándole un
nombre que introducirá el usuario. Se comprobará que no hay
otro emisor con el mismo nombre.
Como salida el proceso genera un objeto tipo emisor sobre el
que se aplicarán las operaciones de inicialización, modificación
y renderización.
23
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Proceso 1.2 Aplicar inicializadores
Descripción Este proceso recibe como entradas el emisor generado por el
proceso P‐1.1 y los parámetros inicializadores introducidos por
el usuario, o bien un emisor guardado en archivo con los
parámetros correspondientes para su inicialización.
Con esta información se inicializa el emisor, asignando un
valor inicial necesario a las partículas, como serían el tiempo de
vida, tamaño, color, posición, velocidad… que determinarán
parte del comportamiento del emisor.
Como salida, el proceso genera el emisor inicializado.
Proceso 1. 3 Aplicar modificadores
Descripción Este proceso recibe el emisor ya inicializado y los parámetros
correspondientes a los modificadores.
En cada vuelta del sistema el proceso aplica sobre las partículas
del emisor los modificadores que éste tenga asignados
cambiando los atributos de estas. Se encarga de la creación de
nuevas partículas y de la eliminación de aquéllas cuyo tiempo
de vida se haya sobrepasado.
Como salida, el proceso genera el buffer que contiene las
nuevas partículas que el módulo de renderización tiene que
dibujar.
Proceso 1.4 Renderizado
Descripción El proceso de renderizado es el que se encarga de dibujar las
partículas. Como entrada recibe el buffer de partículas sobre las
cuales aplicará las funciones de pintado.
24
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
También le llegan las órdenes de emisión que introduce el
usuario. Hay tres tipos de órdenes de emisión:
• Arrancar emisor. Se comienza a dibujar en pantalla.
• Pausar emisor. El emisor deja de emitir partículas pero
las que ya ha emitido siguen con su ciclo de vida.
• Para emisor. Se para el emisor y se destruyen todas las
partículas emitidas por éste.
La salida generada por el proceso contiene el efecto gráfico que
genera el emisor y que se mostrará por pantalla, bien de forma
aislada, bien dentro de un entorno gráfico tridimensional.
Proceso 1.5 Cargar emisor
Descripción Este proceso recibe del usuario la orden de leer un emisor
concreto del almacén “Fichero de emisores”. Cada emisor del
fichero contiene los parámetros necesarios para la aplicación de
los inicializadores y los modificadores.
El proceso genera así un emisor parametrizado que se envía al
proceso P‐1.2 para que sea inicializado, o bien ejecutará un
archivo que pinte el efecto en pantalla directamente.
Proceso 1.5 Guardar emisor
Descripción En cualquier momento durante la ejecución de la aplicación el
usuario puede seleccionar un emisor y elegir guardarlo en
disco para poder volver a cargarlo en otro momento que
vuelva a ejecutar la aplicación. El proceso guarda los
parámetros asignados a los inicializadores y a los
modificadores.
Recibe del usuario la orden de guardar así como estos
25
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
parámetros, y genera un archivo parametrizado que será
guardado en el almacén “Fichero de emisores”.
Almacén Fichero de emisores
Descripción En este almacén se guardan los emisores creados anteriormente
por el usuario junto con los parámetros de inicialización y
modificación de estos.
Es accedido por el proceso P‐1.5 para leer y por el P‐1.6 para
escribir.
26
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Nivel 2: Explotación de los procesos del diagrama conceptual
P‐1.1 Crear Emisor
1.1.1
CrearEmisor
1.1.2
Aplicartipo
Crear EmisorEmisor Genérico
Emisor emisores
Emisor partículas
Proceso 1.1.1 Crear emisor
Descripción El sistema recibe del usuario la orden de crear un nuevo
emisor. Se crea un nuevo objeto de este tipo y se pasa al
proceso P.1.1.2 para asignarle el tipo.
Proceso 1.1.2 Aplicar tipo
Descripción Este proceso recibe un nuevo emisor y se encarga de aplicarle
un tipo según la orden introducida por el usuario. A partir de
este momento el emisor ya será tratado como un emisor de
partículas o como un emisor de emisores.
27
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
P‐1.2 Aplicar inicializadores
1.2.1Aplicarinic ializador partículas
1.2.2Aplicarinic ializador emisor
Emisor emisores
Emisor partículas
Emisor partículas
Parámet rosinic ializadores
Parámet rosinic ializadores
Emisor partículasinic ializado
Emisor emisoresinic ializado
Proceso 1.2.1 Aplicar inicializadores al emisor de partículas
Descripción Este proceso recibe como entradas el emisor de partículas
creado en el proceso P‐1.1 o el que le pasa el proceso P‐1.2.2, y
los parámetros de los inicializadores que introduce el usuario
por medio del interfaz gráfico.
También puede recibir un emisor parametrizado leído desde
fichero, es decir, la definición de un emisor junto con los
valores de sus inicializadores.
El proceso aplica entonces los distintos inicializadores
(velocidad, posición, caja…) sobre las partículas del
emisor y genera como salidas el emisor ya inicializado.
28
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Proceso 1.2.2 Aplicar inicializadores al emisor de emisores
Descripción Este proceso recibe un nuevo emisor de emisores y, de forma
recursiva, comienza a llamar al inicializador de emisores que
contiene hasta que llega a un emisor que en vez de lanzar
emisores lanza partículas. Entonces pasa este emisor al
inicializador de emisores de partículas.
Este proceso recibe como entrada también los parámetros
correspondientes a sus inicializadores, y genera como salida el
emisor de emisores inicializado.
P‐1.3 Aplicar modificadores
1.3.1Aplicarmodif icadores particulas
1.3.2Aplicarmodif icador emisores
1.3.3
Cont rolaremisión
Emisor partículasinic ializado
Emisor emisoresinic ializado
Emisor partículasinicializado Orden emisión
Buf f er emisión
Buf f er emisión
Nuev o estadoemisor
Proceso 1.3.1 Aplicar modificadores al emisor de partículas
Descripción Este proceso recibe como entradas el emisor de partículas
inicializado creado en el proceso P‐1.2.1 y los parámetros de los
modificadores introducidos por el usuario o leídos desde un
fichero por el proceso P‐1.5.
29
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El proceso aplica los distintos modificadores (velocidad,
posición, viento, color…) sobre las partículas del emisor,
comprueba el tiempo de vida de éstas, destruye las que lo
hayan consumido y genera nuevas partículas según la tasa de
creación y el tiempo transcurrido.
Como salida el proceso genera el buffer de pintado de
partículas que le llegará al renderer.
Proceso 1.3.2 Aplicar modificadores al emisor de emisores
Descripción A este proceso le llegan los emisores de emisores creados en el
proceso P‐1.2.2 y los parámetros de los modificadores
introducidos por el usuario o leídos desde un fichero por el
proceso P‐1.5.
El proceso llama recursivamente a los emisores que contiene el
emisor hasta llegar al emisor de partículas final que se envía al
proceso P‐1.3.1.
Como salida el proceso genera el buffer de pintado de emisores
que le llegará al renderer.
Proceso 1.3.3 Controlar emisión
Descripción El proceso “Controlar emisión” se encarga de recibir las
órdenes que el usuario manda al módulo de renderizado a
través del interfaz gráfico para controlar la ejecución del
programa. Según la orden, el proceso mandará a los
modificadores el nuevo estado del emisor, que puede ser
arrancado, en pausa o parado.
30
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
P‐1.4 Renderizado
1.4.1
Renderizarbuf fer
1.4.2Procesarorden usuario
Buf f er emisión Efecto
Señal controlbuf fer
Orden renderizado
Orden em isión
Proceso 1.4.1 Renderizar buffer
Descripción Es el proceso central de la aplicación. Se encarga de recibir el
buffer de emisión del proceso que aplica los modificadores y
realizar las funciones de pintado para generar el efecto que se
verá en la pantalla del usuario.
También recibe como entrada del proceso P‐1.4.2 la señal para
controlar el proceso de renderizado, que le indica cuando
arrancar o parar las operaciones de pintado.
Proceso 1.4.2 Procesar orden usuario
Descripción En cualquier momento de la ejecución el usuario puede pausar,
parar, y volver a arrancar el proceso de pintado. Este proceso
se encarga de recibir la orden que el usuario introduce a través
del interfaz gráfico para avisar al proceso de renderizado P‐
1.4.1 de las intenciones del usuario. También avisa al proceso
31
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
encargado de aplicar los modificadores sobre el estado del
emisor para que se comience o termine la actualización de los
parámetros de las partículas.
Esta funcionalidad se podría haber incluido dentro del proceso
de renderizado P‐1.4.1, sin embargo, para hacerlo más
transparente al resto del sistema y que de esta forma sea más
fácil una posible re‐programación se han intentando meter en
este proceso las menores funciones posibles.
P‐1.4 Cargar emisor
1.5.1
Leerf ichero
Fichero emisores
1.5.2
Comprobarf ichero
1.5.3
Ejcutaremisor
Orden cargarf ichero Fichero
Nombre ejecutable
Emisorparamet rizado
Efecto
Proceso 1.5.1 Leer fichero
Descripción Cuando el usuario escoge la acción “Cargar emisor” se emite
una orden que el proceso “Leer fichero” recibe, entonces lee del
Fichero de emisores el emisor seleccionado por el usuario y lo
pasa al proceso P‐1.5.2 “Comprobar fichero”.
32
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Proceso 1.5.2 Comprobar fichero
Descripción Este proceso recibe el fichero cargado en el paso anterior y
determina el tipo de fichero que es. Puede recibir dos tipos de
fichero:
• Un emisor junto con los parámetros de sus
inicializadores y modificadores que será sometido a
todo el proceso de renderizado.
• El nombre de un archivo ejecutable creado por
compilación y que se incluyen a modo de demostración
de la funcionalidad de la aplicación generando efectos
complejos.
Si se trata de un emisor parametrizado se pasa como salida al
proceso de aplicar inicializadores para que pase por el resto de
fases de la aplicación.
En el otro caso, se genera como salida el nombre del archivo
ejecutable que se pasará al proceso P‐1.5.3 “Ejecutar emisor”.
Proceso 1.5.3 Ejecutar emisor
Descripción Recibe el nombre del fichero a ejecutar. Mediante una
instrucción de consola de comandos ejecuta el fichero,
generando el efecto que será mostrado en la pantalla del
usuario.
1.6 Guardar emisor
33
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
1.6.1
Guardaremisor Fichero emisores
Parámet ros
Ficheroparamet rizado
Orden guardaremisor
Proceso 1.6.1 Guardar emisor
Descripción Un único subproceso que recibe del usuario la orden de
guardar un emisor y los parámetros de éste, que entre otra
información contiene el nombre del emisor y los valores que se
aplicarán a sus inicializadores y modificadores. Genera un
fichero parametrizado que se guarda en el fichero de emisores.
34
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
IV. ESTUDIO DE ARQUITECTURA
Introducción
El objetivo de esta fase es definir las posibles soluciones de arquitectura
técnica que satisfagan tanto los requisitos del cliente como las restricciones de
diseño. Para conseguirlo, se van a definir las posibles soluciones, se someterán a
un estudio de viabilidad y se elegirá la más adecuada para ser desarrollada e
implementada [1].
Se debe entonces indicar qué componentes básicos software y de
comunicaciones deben desarrollarse o adquirirse. Por lo tanto, habrá que
especificar recursos básicos como sistema operativo, lenguaje de programación y
herramientas de desarrollo, usando como principal parámetro de medida las
necesidades del sistema y las exigencias del cliente.
35
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Arquitectura
Conviene recordar el contexto general del sistema. Se trata de una
aplicación cuya función primordial es el proceso de datos basándose en una serie
de entradas y que, entre otras funciones adicionales, debe proporcionar un interfaz
de usuario que permita variar dichas entradas y poder ver los resultados de la
ejecución en tiempo real.
Ante esta situación, se plantean dos posibles soluciones: una de ellas,
basada en una arquitectura cliente‐servidor, y otra que consista en una aplicación
única que corra entera en la máquina del usuario. A continuación se estudiarán las
dos alternativas analizando cuál de ellas se adapta mejor a los requisitos del
usuario y de la aplicación.
Evaluación de la alternativa Cliente‐Servidor
Este tipo de arquitectura se basa en la distribución de la funcionalidad de la
aplicación, entre los clientes y los servidores. Proporciona las ventajas de la
arquitectura de aplicaciones basada en componentes, como serían:
• Función distribuida entre cliente y servidor.
• Reutilización de componentes.
• Funciones de negocio bien delimitadas.
• Multitarea, con la invocación de los servicios por parte del cliente de
forma síncrona o asíncrona.
36
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El cliente, genera una solicitud o transacción que es enviada al servidor a
través de la red. El servidor está constantemente atendiendo las solicitudes
entrantes de los clientes. Cada vez que recibe una petición la procesa, genera una
respuesta, y ébsta es enviada al cliente que se encargará de mostrarla por pantalla
o trabajar con ella según el tipo de aplicación.
Los sistemas de cliente‐servidor conllevan la distribución del software de la
aplicación, repartiéndolo entre ambas partes. Según como se haga esta
distribución se pueden presentar hasta cinco casos concretos, dependiendo de la
funcionalidad que incorpore el cliente:
• Presentación distribuida.
Presentación Aplicación Gestión datosPresentación
Cliente Servidor
• Presentación remota.
Presentación Aplicación Gestión datos
Cliente Servidor
37
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Función distribuida.
Presentación Aplicación Gestión datosAplicación
Cliente Servidor
• Función remota.
Presentación Gestión datosAplicación
Cliente Servidor
• Gestión de datos distribuida.
Presentación Gestión datosAplicación Gestión datos
Cliente Servidor
Debido a que la parte de renderizado, que es el dibujado del sistema de
partículas en pantalla, debe ejecutarse en el cliente y que el programa no realiza un
acceso a bases de datos (ya sea local o remoto), la alternativa que mejor encaja con
el diseño del sistema es la de función distribuida. Es decir, parte de la aplicación se
ejecutaría en el cliente, y parte en el servidor.
Sin embargo, hay una serie de razones por las que la arquitectura cliente‐
servidor no es la mejor para este tipo de aplicación.
• Este tipo de arquitectura se escoge para aquellas herramientas en las que
la máquina cliente, aparte del interfaz de usuario, ejecuta una pequeña
parte de la aplicación, dejando los procesos más costosos para el
servidor. Estos serían los llamados clientes ligeros.
En el caso del Sistema de Partículas, el cliente realiza de forma local las
operaciones de renderizado, que es la parte que más recursos consume
de la aplicación. Nos encontraríamos de esta forma ante una situación
38
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
extraña, con un servidor ligero, ejecutando un código sencillo que
apenas afectaría al rendimiento de los clientes en caso de ejecutarlo
ellos.
• Una arquitectura cliente servidor implicaría el uso de comunicación a
través de la red, estando así a merced de posibles caídas de la
comunicación, tráfico o localización del servidor, siendo necesario la
implantación de un protocolo para la recuperación de mensajes
perdidos.
• Sería necesario la programación de un pequeño middleware, para
cuestiones como formato y conversión de datos, recepción y envío de
paquetes… que sería necesario incorporar tanto al módulo de aplicación
del cliente como al del servidor.
• Requiere un programa servidor multihilo para atender las solicitudes de
los clientes.
• Por último, una posible caída del servidor dejaría a los clientes sin poder
ejecutar la aplicación. Por lo tanto habría que diseñar un sistema con
servidores de respaldo y que permitiera reconocer fallos en estos.
En resumen, es mucho más significativa la carga de trabajo que supone
desarrollar una arquitectura de este tipo en comparación con el rendimiento que
ofrecería la máquina cliente ejecutando la aplicación de forma completa.
39
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Aplicación completa en la máquina del usuario
Es el tipo de arquitectura más antigua y el más sencillo de implantar. La
herramienta se instala y se ejecuta de forma completa en la estación de trabajo del
cliente. Aún así, y para ajustarse a los requisitos del usuario, es necesario hacer
una separación entre el interfaz gráfico y el resto de la lógica de la aplicación.
Esto es necesario para conseguir la independencia entre los dos módulos,
de forma que el interfaz de usuario sea transparente a futuras modificaciones que
pueda haber en la manera de trabajar con los datos y viceversa. Es decir, si a lo
largo del ciclo de vida de la aplicación se producen cambios en los procesos que se
encargan de inicializar, modificar y dibujar los sistemas de partículas, estos no
deben afectar a las salidas o entradas que genera o espera recibir el interfaz.
Por lo tanto, se va a dividir la aplicación en dos niveles, uno de
presentación, encargado de la navegación con ventanas y el diálogo con el cliente,
y otro nivel de aplicación que realizará los cálculos atendiendo a las reglas de
negocio.
Nivel de presentación
Nivel de aplicación
40
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Especificación gráfica
Dentro del mundo de las APIs gráficas, hay dos especificaciones que
destacan sobre las demás: OpenGL y Direct X. Al ser especificaciones, se tratan de
documentos que definen un conjunto de funciones y su comportamiento exacto.
Antes de pasar al análisis de sus características para elegir la alternativa que mejor
se adapte al sistema, convendría aclarar en qué consiste un API gráfico.
Básicamente, evitando una explicación compleja, son unas librerías que nos
permiten comunicarnos con los elementos hardware de manera directa sin tener
que escribir complicados códigos para que estos los interpreten. De esta manera,
se evita una gran carga de programación a la hora de realizar aplicaciones gráficas
que generen o funcionen en escenarios 3D. En definitiva, son unas librerías que
sirven de intérprete entre el programa y los diferentes dispositivos de hardware
(placa de video, procesador, dispositivos de entra y salida, etc.).
41
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Tanto OpenGL como DirectX facilitan la programación y reducen sus
tiempos. Si el programador quisiera puede comunicarse directamente con el
Hardware pero, aparte de mayor tiempo de programación, sería necesario
programar código para cada placa específica que existe en el mercado. De esta
manera las empresas productoras de hardware realizan sus productos compatibles
con estas tecnologías.
Existen varias diferencias entre OpenGL y Direct X, pero la más importante
de ellas y que más afecta a este proyecto es que DirectX es una herramienta de
Microsoft y con funcionamiento exclusivo para Windows, y OpenGL puede ser
utilizado en una gran variedad de plataformas. Esto es algo determinante, ya que
trabajar bajo DirectX limitaría el uso de la aplicación que se está desarrollando a
plataformas Windows, perdiendo una gran cuota de mercado, especialmente en el
ámbito de las pequeñas empresas, que usan software libre para reducir costes en
licencias. OpenGL hace por lo tanto la aplicación mucho más portable, no
limitándose a funcionar únicamente bajo el sistema operativo de Microsoft [7].
OpenGL es una librería que permite desarrollar desde aplicaciones gráficas
modestas hasta potentes herramientas de visualización y generación de escenarios
3D. Direct X, por otra parte, está más enfocado hacia el desarrollo de aplicaciones
profesionales de gran envergadura, por lo que su uso se queda un poco grande
para una aplicación como este sistema de partículas.
Por lo tanto, OpenGL parece la opción más acertada. Pero, aun así, hay que
recordar que, según los requisitos del cliente, la aplicación que se está
desarrollando debe ser fácilmente portable entre estos tipos de tecnología, por lo
42
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
que, independientemente del API que se escoja, cambiar entre uno y otro debería
ser tan fácil como hacer unas pequeñas modificaciones en el módulo de
renderizado.
Para más información acerca de la comparativa entre OpenGL y Direct X se
puede consultar el Anexo B.
43
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Lenguaje de programación
Tradicionalmente, y hasta hace unos pocos años, las aplicaciones
informáticas se han desarrollado siguiendo el paradigma de la programación
estructurada. Sin embargo, esta forma de programar tenía el gran inconveniente
de que toda la aplicación estaba contenida en un único bloque de programa, que
cuando se hacía demasiado grande resultaba especialmente complicado su
manejo, mantenimiento y comprensión.
Ya que uno de los principales requisitos del cliente es la modularidad de la
aplicación para conseguir bloques independientes que permitan modificar partes
del sistema de forma transparente, el paradigma orientado a objetos es el que más
se ajusta atendiendo al tipo de aplicación que se está tratando. La orientación a
objetos proporciona una serie de conceptos tales como herencia, interfaz o
abstracción, que ayudan al desarrollo de software fácilmente escalable y con
facilidad de reutilización de componentes gracias a la encapsulación, eliminando
redundancias funcionales.
Al mismo tiempo, proporciona una independencia del entorno tecnológico,
posibilitando un acceso multientorno a las aplicaciones.
Dentro de los lenguajes de programación orientados a objetos, destacan
sobre el resto Java y C++. A continuación se hará un análisis de ambos para
determinar cuál es la mejor alternativa para el desarrollo de la aplicación.
44
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Actualmente, las librerías OpenGL encuentran adaptaciones tanto para Java
como para C++. Dado que el sistema de partículas basa su funcionamiento en el
proceso de datos, careciendo de acceso a base de datos o de comunicaciones en
red, hay que centrar el estudio de ambos lenguajes en su capacidad de proceso.
La principal diferencia entre Java y C++ se encuentra en el rendimiento.
Aunque ambos son lenguajes de alto nivel, la relación existente entre C++ y el C
clásico hacen que C++ sea un lenguaje más cercano al código máquina, por lo
tanto, más rápido a la hora de compilar y ejecutar.
Java es un lenguaje que no se compila en lenguaje maquina nativo, sino en
un código maquina intermedio que luego hay que interpretarlo. Además es un
lenguaje de muy alto nivel, con lo que un poco de código puede equivaler a
mucho código maquina intermedio. Mientras que con C o C++, observando en el
debugger cuánto código genera cada línea en C, aparecen unos pocos
nemotécnicos (comando ensamblador) por línea, incluso se da a veces en una
relación 1:1 (que seria la optima).
Ahora bien, también hay que señalar que hay distintos algoritmos, y que
estar en alto nivel puede permitir ver mejor el conjunto y saber dar una mejor
solución al problema. Así que Java podría permitir escribir algoritmos ligeramente
mejores que los de C++ en algún caso.
Por otro lado, el ejecutable de Java funciona en varias arquitecturas
diferentes. Tiene comprobaciones de seguridad estrictas y se puede controlar a
qué recursos acceden los componentes. Al tener gestión de memoria automática es
más difícil (aunque no imposible) cometer errores de pérdida de memoria por
olvido de liberación de los bloques no usados.
45
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Sin embargo, Java necesita una máquina virtual que consume tiempo de
proceso y que tarda mucho en arrancar. Esto en un servidor web no importa, pero
en una aplicación como la que se está desarrollando sí. Se puede distribuir de
forma que lleve incluida la máquina virtual y el bytecode en un sólo ejecutable,
pero ello lo hace dependiente de la plataforma [2].
Java utiliza cantidades ingentes de memoria. Algunas aplicaciones
necesitan un control preciso de la gestión de memoria, esto no es posible en Java.
Entre uno de los requisitos del cliente está el control de la memoria que usa la
aplicación. En C++ esto es fácil de hacer con los punteros y las funciones de
petición y liberación de memoria.
La recolección de basura automática (Garbage Collector) de Java no se
puede controlar, el comportamiento depende de la aplicación. Para aplicaciones
de cálculo intensivas como esta es ineficiente. No se puede usar para acceder a los
recursos a bajo nivel. Por motivos de seguridad y por estar mediatizado por la
máquina virtual no puede acceder a posiciones de memoria física concreta o a
registros del hardware, lo que lo hace inadecuado para muchas aplicaciones de
sistema.
Java no es apto para usarlo en aplicaciones de tiempo real duro debido a su
elevada latencia en cambios de contexto. Esto, tal vez, pudiera subsanarse con una
implementación especial de la máquina virtual, algo que escapa al alcance de este
proyecto.
46
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Por su parte, C++ también tiene una serie de inconvenientes. Es difícil, por
su extrema libertad, heredada de C. Es necesaria una gran disciplina para no
cometer errores que son difíciles de depurar. La escritura fuera de límites puede
originar comportamientos insospechados, y es necesario un control estricto de
memoria, cuya gestión debe de planificar el programador, y los errores en ese
tema suelen ser graves [3].
Por lo tanto, parece que lo más correcto es elegir C++ como lenguaje para el
desarrollo de la aplicación, por ofrecer un mayor rendimiento que Java y por
exigir un preciso control de la memoria (ambos requisitos exigidos por el cliente).
47
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El sistema operativo
OpenGL (Open Graphics Library) funciona bajo Windows, Linux y Mac OS.
Por lo tanto, la elección de un entorno u otro para el desarrollo de la aplicación no
limitará el funcionamiento de esta en otros sistemas operativos de cara a futuro.
Para el desarrollo del proyecto se hará uso de la librería GLU, acrónimo de
OpenGL Utility Library. Esta librería está compuesta por una serie de funciones de
dibujo de alto nivel que, a su vez, se basan en las rutinas primitivas de OpenGL.
Normalmente se distribuye con esta librería.
Las funciones de GLU se reconocen fácilmente, ya que todas comienzan con
el prefijo glu. Esto se verá más adelante en el apartado de diseño.
GLUT (OpenGL Utility Toolkit) es una sencilla API multiplataforma que
provee una reducida funcionalidad para el manejo de ventanas. Su utilidad
principal es permitir el desarrollo de aplicaciones con OpenGL sin demasiado
esfuerzo, dejando a un lado la complejidad de otros sistemas de ventanas, sin
dependencia del sistema operativo, lo que permite una fácil migración de una
plataforma a otra.
Teniendo en cuenta, entonces, la libertad que supone trabajar bajo las APIs
OpenGL y GLU para migrar la aplicación de un sistema operativo a otro, es
48
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
conveniente analizar las limitaciones que las diferentes tecnologías hardware
encuentran en las diferentes plataformas, comparando un sistema operativo
propietario como Windows XP contra una distribución de Linux.
Ya que Linux es un sistema con código abierto, es difícil encontrar drivers
para las diferentes tarjetas gráficas existentes en el mercado elaborados por los
propios fabricantes. De entre los dos grandes de las tarjetas aceleradoras: ATI y
nVidia hay grandes diferencias. Los drivers de nVidia son bastante buenos
mientras que ATI ha empezado a prestar atención a Linux más recientemente.
Durante el 2004, ATI anunció que había incrementado notablemente los recursos
dedicados al desarrollo de sus drivers bajo Linux. Esto se ha notado, por ejemplo,
en la importante mejora en el funcionamiento de videojuegos de última
generación bajo Linux que han experimentado los poseedores de tarjetas gráficas
ATI desde la salida del juego.
Aún así, Windows es la plataforma por defecto, ya que es la que usan las
principales empresas de desarrollo de este tipo de aplicaciones gráficas. No
obstante, el mundo de la animación por ordenador se está acercando, aunque muy
tímidamente hacia Linux.
Y aunque habrá que seguir de cerca esta evolución, para evitar problemas
de incompatibilidades con los dispositivos hardware, se va a elegir Windows XP
como sistema operativo para el desarrollo. Se han tenido en cuenta otros factores,
como el que se trate del sistema operativo más distribuido y el hecho de contar
con la herramienta de desarrollo más completa tanto a nivel profesional como a
nivel de programación doméstico: Microsoft Visual Studio.
49
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
V. DISEÑO DEL SISTEMA
Introducción
El proceso de diseño del sistema es mucho más costoso y creativo que el
análisis de requisitos o de arquitectura. Depende del entorno y de los factores que
le rodean. A partir de la plataforma tecnológica elegida se completarán requisitos
físicos del sistema, se diseñarán las entradas y salidas, y se hará una especificación
más detallada de los procesos.
En esta fase del proyecto lo que se persigue es transformar el modelo lógico
elaborado anteriormente en un modelo físico, sin perder la perspectiva de la
plataforma de hardware escogida en la fase del estudio de soluciones,
identificando los diferentes componentes software.
Se estudiarán primero las necesidades del sistema de partículas en sí, con
las clases necesarias para su correcto funcionamiento y los flujos de información
entre ellas. Posteriormente se hará un análisis del diseño de la aplicación
completa, que incluirá los módulos que servirán de soporte al sistema de
partículas. Finalmente se estudiará la entrada de datos en la aplicación a través del
interfaz gráfico.
50
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El sistema de partículas
El sistema de partículas compone el núcleo de la aplicación ya que, a parte
de contar con el módulo de renderizado, en él se encuentran las funciones
principales de la lógica de negocio, como son la creación de emisores, la aplicación
de los inicializadores y los modificadores o la gestión de memoria.
A continuación se estudiarán los diferentes subsistemas que componen el
módulo, las relaciones entre ellos, las funciones de cada uno y como se ha hecho
para sortear las dificultades que han surgido y poder cumplir los requisitos del
cliente. Se partirá desde un punto de vista global para posteriormente ir
profundizando en las tareas más específicas de cada clase.
El diagrama de clases queda así:
Inicializadores:• Posición• Partículas• Velocidad• Caja• Esfera
Modificadores:• Posición• Velocidad• Viento• Color
Renderers:• Point• Sprite
Emisor Base
Emisor de emisores
Emisor de partículas
Partículas
Pool de partículas
Pool de emisores
51
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
En el centro de la lógica de la aplicación se encuentra el emisor base. Se
trata de una clase padre que define una serie de métodos que marcarán el
comportamiento de los emisores de partículas y los emisores de emisores, que
heredan de ella. El emisor base, y por tanto el de partículas y el de emisores, hace
uso de los diferentes inicializadores, modificadores y renderers para generar los
efectos y dibujarlos por pantalla.
Los inicializadores, modificadores y renderers son clases que implementan
interfaces. El uso de interfaces permitirá definir comportamientos de clases, de
manera que pueden tener una serie de métodos comunes pero con una
funcionalidad diferente. Esto permitiría la modularidad y abstracción de la
aplicación requerida por el cliente, así como la reutilización de código evitando
redundancias.
Un perfecto ejemplo de esto se da en los inicializadores. Si se toma el
módulo de incializadores, en él existe una clase base interfaz (Initializer.h) a la
cuál implementan el resto de clases inicializadoras. De esta forma, el inicializador
de posición, el de velocidad, el de esfera… todos siguen el mismo patrón. Esto
facilita significativamente el desarrollo de la aplicación, ya que si en algún
momento se quiere añadir un nuevo inicializador se conoce de antemano las
funciones que este va a incorporar y su funcionamiento básico.
En el caso concreto del esta aplicación, el no usar interfaces hubiera
supuesto pensar y diseñar cada inicializador de forma separada, sin que hubiera
relación entre ellos, y también hacer cambios en las clases que accedieran a ellos ya
que cada uno tendría unas entradas y salidas diferentes. El uso de interfaces
permite entonces reutilizar código y realizar cambios en los paquetes de trabajo de
forma aislada y sin que el resto de la aplicación se viera afectada (transparencia).
52
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Los inicializadores, modificadores y renderers específicos son los que,
variando sus parámetros de entrada, se encargarán de generar diferentes efectos
cuando se apliquen a las partículas o emisores.
Tanto el emisor de partículas como el emisor de emisores hacen uso de un
pool de partículas. Esta clase, define como crear una lista de partículas y trabajar
sobre ella. Para conseguirlo, usa la clase Partícula, que no es más que una
estructura en la que se definirán los parámetros de la partícula (posición,
velocidad, color, tamaño…) y que son los que se encargarán de modificar los
modificadores para lograr los efectos.
Después de haber visto una descripción general del sistema se va a
proceder a realizar un análisis más específico de cada uno de sus componentes.
Inicializadores
Se encargan de aplicar una serie de propiedades a las partículas en el
momento en que estas son creadas. Constan de un método “Apply()” que
dependiendo del inicializador se comportará de una manera un otra.
Los inicializadores con los parámetros correspondientes son una de las
entradas de los emisores, junto con los modificadores. En el siguiente diagrama se
explica su funcionamiento:
53
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Inicializador Posicion‐Atributos
‐Pos(x1, y1, z1)‐Métodos
‐Apply(partícula){
Partícula.Pos = x1, y1, z1}
Inicializador Velocidad‐Atributos
‐Vel(x1, y1, z1)‐Métodos
‐Apply(partícula){
Partícula.Vel = x1, y1, z1}
Emisor
• Atribuos
• Pool de partículas
• Métodos
•Añadir Iniz(Pos, Vel)
•Aplicar Iniz()
Pool de partículas
Cada inicializador tiene sus atributos propios y su método Apply()
implementado de diferente forma. Sin embargo todos son accedidos de la misma
manera. En el ejemplo el emisor importa los inicializadores de velocidad y
posición y se los aplica a todas las partículas de un pool de partículas. Los
inicializadores incluidos en el proyecto son:
• Random (aleatorio). A la hora de crear un nuevo emisor es necesario
definir una serie de parámetros como la velocidad con que se generan
las partículas, el color de estas, su tiempo de vida, etc. Respecto a este
valor inicial se puede especificar un margen, tanto superior como
inferior, dentro del cual estos valores tomarán una desviación aleatoria
que ayudará a generar efectos más reales.
Por ejemplo, si se tiene una velocidad principal definida por el vector de
tres componentes (2, 1, 3) y un rango de variación definido por el vector
54
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
(0.5, 0, 1), las partículas serán generadas con una velocidad aleatoria
dentro del rango [(1.5, 1, 2) , (2.5, 1, 4)]. Si se quiere que todas las
partículas se generen con las misma velocidad determinada sin ningún
tipo de aleatoriedad sólo hay que definir el vector de rango como (0,0,0).
• Caja. Este inicializador genera partículas de forma aleatoria pero
siempre dentro de un cubo con volumen que va en función de los
parámetros.
• Esfera. Similar al anterior pero usando una esfera como límite para la
creación de partículas.
Como se ha dicho anteriormente, cada inicializador implementa un método
“Apply()” definido en el interfaz Initializer.h. Si se desease crear nuevos emisores
no habría más que definir un nuevo comportamiento del método según el efecto
que se pretendiese conseguir.
Modificadores
Los modificadores, aplicados a las partículas, se encargan de variar el
comportamiento de éstas, para así conseguir efectos determinados. Al igual que
los inicializadores, existe un interfaz Modiffier.h que implementan el resto de
modificadores para obtener así un comportamiento similar en todos ellos.
Los modificadores también sirven de entrada para los emisores. Su
funcionalidad es similar a la dos inicializadores salvo que estos se aplican sólo en
el momento en que se crean las partículas, mientras que los modificadores se
55
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
aplican en cada vuelta que da el sistema para refrescar los parámetros de las
partículas y volverlas a dibujar.
Modificador Posicion‐Atributos
‐Pos(x1, y1, z1)‐Métodos
‐Apply(partícula){
Partícula.Pos = x1, y1, z1}
Modificador Velocidad‐Atributos
‐Vel(x1, y1, z1)‐Métodos
‐Apply(partícula){
Partícula.Vel = x1, y1, z1}
Emisor
• Atribuos
• Pool de partículas
• Métodos
•Añadir Mod(Pos, Vel)
•Aplicar Mod()
Pool de partículas
Un aspecto importante a tener en cuenta es que los emisores para poder
aplicar los inicializadores y los modificadores necesitan importarlos y
almacenarlos en algún sitio. Para ello crean una lista (pool) para los inicializadores
y otra para los modificadores.
Se debe tener en cuenta aquí otro de los requisitos del usuario,
concretamente el referente a la gestión de memoria. C++ no tiene una gestión
dinámica de memoria controlada por el compilador. Cuando se crean o se
destruyen objetos, ya sean inicializadores, modificadores, partículas, emisores… es
necesario pedir memoria o liberarla según la acción que se esté tratando.
56
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Para evitar accesos continuos a memoria siempre que se quiera crear o
destruir un objeto lo que se hace es reservar espacio para un número determinado
de objetos que vendrá definido por el tamaño de una lista.
Por ejemplo, en el caso del emisor base, la instrucción
IInitializer* m_InitializerList[MAX_INITALIZERS];
reserva espacio en memoria para un pool de inicializadores con
MAX_INITIALIZERS elementos. De esta forma se acelera la ejecución del
programa y se controlan los elementos que hay que borrar cuando se elimine el
pool.
Los modificadores que se han añadido al proyecto son:
• De posición.
• De velocidad.
• De viento.
• Rampa de color.
Los dos primeros modificadores, de posición y de velocidad, se comportan
de la misma forma que los inicializadores del mismo tipo, salvo que se aplican
repetidas veces. El modificador de viento es similar al de velocidad.
Merece especial atención, sin embargo, el de rampa de color. Este
modificador se encarga de ir cambiando el color de las partículas que lanza un
emisor de forma gradual. El color viene definido por tres valores comprendidos
57
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
entre cero y uno, que se corresponden con la cantidad de rojo, de verde y de azul.
Es el formato RGB (red green blue). Por ejemplo, el color blanco sería (1,1,1).
Tanto los inicializadores como los modificadores funcionan en base a los
parámetros de entrada que introduce el usuario. No es necesario que se apliquen
todos ellos, de la misma forma que también se pueden aplicar varios del mismo
tipo con diferentes parámetros. Este sencillo diseño permitirá generar los efectos
más diversos en función de cómo usemos estas clases.
Renderers (dibujadores)
Son los encargados finales de dibujar los efectos en el entorno gráfico. La
independencia de este módulo es un requisito clave ya que es lo que permitirá
adaptar el proyecto a las diferentes APIs gráficas de forma transparente al resto de
la aplicación. Es decir, se podrá migrar de OpenGL a Direct X sin necesidad de
hacer cambios en ningún otro paquete de trabajo.
El sistema consta de dos tipos de renderers, el dibujador de píxeles y el
dibujador de texturas. Una textura no es más que una pequeña superficie con unas
características de color y tamaño determinadas.
Aunque el dibujador de puntos (PointRender.h y PoitnRenderer.cpp) no
permite definir tamaño o color de las partículas, ya se pueden apreciar en el las
instrucciones definidas por los APIs OpenGL y GLU:
glBegin(GL_POINTS);
while(count‐‐)
{
58
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
glVertex3f(pParticle‐>m_Pos.x, pParticle‐>m_Pos.y, pParticle‐>m_Pos.z);
pParticle++;
}
glEnd();
Este fragmento de código se encarga de recorrer un pool de partículas y
dibujarlas en pantalla en las posiciones x, y, z de cada partícula. La instrucción
glBegin indica que a continuación habrá una serie de instrucciones OpenGL,
mientras que con glEnd se indica el final de la sección. Entonces, si en algún
momento se quisiera pasar a Direct X no habría más que importar las librerías
correspondientes y cambiar estas instrucciones. Algo que no afectaría a ninguna
otra parte de la aplicación, cumpliendo así unos de los requisitos más importantes
de los impuestos por el cliente.
En el siguiente diagrama se puede observar la interacción de los renderers
(dibujadores) con los emisores:
Point Renderer• Métodos
•Draw()
Emisor• Atributos
• Renderer• Métodos
•Render(){ Renderer.Draw}
Sprite Renderer• Métodos
•Draw()Image Loader
Cada emisor crea un objeto de tipo de Renderer, que dependiendo de si
dibuja píxeles o texturas tendrá un método Draw() (dibujar) diferente. En el
59
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
método Render() del emisor se llama al Draw() del Renderer que tiene la clase
emisor como instancia, que se aplica a todo el pool de partículas del emisor.
El dibujador de texturas (SpriteRenderer.cpp y SpriteRenderer.h) se
comporta igual que el dibujador de puntos. Implementa un método “Draw()”
definido en el interfaz, sólo que en este caso es necesario definir el tamaño y el
color de las texturas. Estas son dos características básicas, ya que dependerán del
efecto que se quiera crear.
El dibujador de texturas usa la clase ImageLoader.cpp para la lectura de los
archivos que contienen las texturas. Esta clase a su vez llama a las clases File.h y
FileSys.h, contenidas en el módulo Base, uno de los módulos que dan soporte al
sistema de partículas y que se estudiarán con detalle en el siguiente apartado. Esta
clase sirve para poder acceder a los archivos de forma independiente a la
plataforma.
SpriteRenderer ImageLoader
Renderer
ModiffiersEmiters
Particle Sys
Base
File.h
FileSys.h
60
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Emisor Base
En el caso del emisor base, en lugar de tratarse de un interfaz como sucedía
con los inicializadores, emisores y renderers, se trata de una clase que define
métodos propios, que implementa sólo algunos de ellos, y de la que heredan el
emisor de partículas y el emisor de emisores para completarla con los métodos
que esta no implementa porque son específicos de cada uno de ellos.
El motivo por el que el emisor base no es un interfaz sino una clase normal
es el pool de emisores. Este puede contener tanto emisores de partículas como
emisores que a su vez emiten otros emisores. Sin embargo, en ocasiones necesita
acceder a los elementos de la lista de forma transparente, independientemente del
tipo que sean. Al heredar los dos del emisor base tienen el mismo interfaz de
acceso común, por lo que los métodos devolverán o recibirán como argumento
una instancia del emisor base, cosa que no podría hacerse si este fuera un interfaz.
El comportamiento del emisor base se ve reflejado en el siguiente diagrama:
Emisor Base• Variables
• Estado• Pool de partículas• Pool de modificadores• Pool de incializadores• Renderer• Tasa
• Métodos• Emisión• Aplicar incializadores• Aplicar modificadores• Render
Inicializadores
Modificadores
Renderers
Pool de partículasPartícula
61
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El emisor recibe como entradas los inicializadores y modificadores que se
vayan a usar (definidos por el usuario), así como la tasa de emisión, que es el
número de partículas que se van a generar por unidad de tiempo.
En cada vuelta del sistema el emisor, en el método Emisión(), genera las
nuevas partículas en base a la tasa y el tiempo transcurrido. A continuación, sobre
estas partículas recién creadas, aplica todos los inicializadores del pool.
Posteriormente recorre el pool de partículas comprobando aquellas que tiene que
ser eliminadas por haber excedido su tiempo de vida, realiza un aumento similar
al tiempo transcurrido desde la última vuelta sobre el tiempo de vida de las
partículas restantes, y aplica los modificadores.
Finalmente, aplica el método Render() sobre el pool de partículas
actualizado.
Emisor de emisores
El emisor de emisores tiene una estructura y comportamiento similar al emisor de
base. Usa un pool de emisores y un pool de partículas. Esto se debe a que cada elemento
del pool se emisores se corresponde con el elemento que está en la misma posición en el
pool de partículas. El objetivo de esto es tratar cada emisores como si de una partícula se
tratase, de manera que se puedan aplicar sobre él los inicializadores y modificadores
correspondientes.
Siempre que se crea un emisor se crea una partícula, y lo mismo sucede cuando se
destruyen. A la hora de hacer el update, se aplican todos los métodos sobre cada elemento
del pool de partículas, y se llaman de manera recursiva sobre el pool de emisores hasta
que se llegue a un emisor que emita partículas.
62
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Lo mismo sucede con el método Render(). Un emisor ejecuta su método Render()
sobre todos los elementos del pool de emisores que tiene declarado. Al mismo tiempo,
cada uno de estos emisores, si contienen más emisores, repetirán el mismo paso. Eso se
hará reiteradamente hasta que se llegue a un emisor de partículas, a las que se les aplicará
el Render() y serán dibujadas en pantalla.
63
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Visión general de la aplicación
El módulo que contiene el sistema de partículas, aunque contiene la mayor
parte de la lógica de la aplicación, necesita de la funcionalidad de otros módulos
para funcionar correctamente. Estos módulos son un módulo Base, otro de
operaciones Matemáticas, el EngineDemo que contiene el método main() de la
aplicación y el interfaz de usuario.
Sistema de
Partículas
Módulo Base
Módulo Math
EngineDemo Interfaz Usuario
Cada uno de estos módulos proporciona información de entrada al sistema
de partículas y utiliza la información que este genera como salidas.
Todos los módulos son independientes entre sí. La encapsulación que
proporcionan los lenguajes de programación orientados a objetos permiten que se
pueda cambiar el código de las clases de todos los paquetes sin que sea necesario
modificar el resto de la aplicación, solamente respetando las interfaces de
comunicación.
A continuación se el flujo de información entre los módulos del sistema.
64
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Inicializadores:• Posición• Partículas• Velocidad• Caja• Esfera
Modificadores:• Posición• Velocidad• Viento• Color
Renderers:• Point• Sprite
Emisor Base
Emisor de emisores
Emisor de partículas
Partículas
Pool de partículas
Pool de emisores
Base• Asserts• File Sys.• Types
Math• Matrix• Vector
EngineDemo• Engine• Socket Interfaz
Sistema de partículas
Como se ve en el diagrama, el único módulo que no depende de ningún
otro es el Base. El módulo base proporciona una serie de clases de ámbito general.
Todos los paquetes tienen dependencias con las librerías del módulo Base. Este
paquete tiene tres clases principales:
• MyAssert.h. Esta clase se utiliza para lanzar errores en tiempo de ejecución.
Los errores que se pretenden capturar con la instrucción “assert()” no se
pueden detectar durante el proceso de compilación, ya que se suelen basar
en la comprobación del contenido de determinadas variables. Se usan para
avisar sobre valores anómalos tomado. No interrumpen la ejecución del
programa, sólo avisan de que algo no está funcionando bien. Por ejemplo,
65
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
en el emisor de partículas (ParticleEmiter.cpp) hay un assert() en el método
Update():
SParticle * Particle = m_ParticleList.GetParticles();
assert(Particle != NULL);
La primera línea coge la primera partícula del pool de partículas, a partir de
la cual se comenzarán a aplicar los modificadores. El assert() comprueba
que la partícula no es “null”, es decir, que el pool de partículas contiene
algún elemento.
• FileSys.h. Estas librería sirve para abstraer el acceso a ficheros y hacerlo
independiente del entorno. Se usa, por ejemplo, para cargar las texturas que
usa la clase SpriteRenderer del sistema de partículas.
• Types.h. Define una serie de tipos de variables que son usadas a menudo en
el proyecto, especialmente en el paquete Math. Un ejemplo:
typedef unsigned short uint16;
typedef unsigned int uint32;
typedef unsigned __int64 uint64;
Son abreviaturas para ahorrar código.
El módulo Math define una serie de clases que implementan operaciones
matemáticas complejas con vectores y matrices. De esta forma, y teniendo en
cuenta la cantidad de veces que es necesario aplicar este tipo de operaciones para
calcular las posiciones y velocidades de las partículas, las clases sólo tienen que
importar esta librería (#include <math.h>). Se puede ver en el diagrama que son
66
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
muchas las clases que hacen uso de este módulo, esto se debe a que se está
trabajando en un entorno tridimensional, y parámetros como la velocidad, la
posición, o la posición relativa de las partículas respecto al emisor padre, se basan
en operaciones hechas con vectores de tres componentes y matrices de dimensión
4x4.
El módulo EngineDemo contiene el método main() de la aplicación que se
encarga de controlar la ejecución de los emisores. Tiene un socket UDP a través
del cual recibe las órdenes que el usuario introduce a través del interfaz.
Tanto el paquete EngineDemo como el Interfaz se estudiarán con mayor
nivel de detalle en próximos apartados.
Por lo tanto, si se deja a un lado el interfaz gráfico que forma parte de la
lógica de presentación, la lógica de la aplicación está compuesta por cuatro
paquetes principales. Cada paquete está compuesto por una serie de librerías
(archivos .h de c++) con sus correspondientes implementaciones. Así, además de
unas relaciones basadas en los flujos de información a través de las entradas y
salidas de los cuatro paquetes, lo que se da también es una serie de dependencias
entre clases.
Base FilesMath Files
Particle Sys
Engine Demo
67
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El paquete EngineDemo
Constituye uno de los módulos que dan soporte al sistema de partículas.
Concretamente, contiene la clase con el método main() que controla la ejecución de
la aplicación. Además, contiene un clase Socket que está escuchando de forma
permanente las órdenes que le llegan desde el interfaz introducidas por el usuario.
EngineDemo
EngineDemo.cpp• Main()
Thread Socket
Orden forma externa
Mensaje parseado
Sistema de Partículas
• Emisor
• Estado• Parámetros Inicializadores• Parámetros Modificadores
Resultados
El usuario, a través del interfaz, selecciona la operación que desea realizar
(arrancar emisor, parar, cargar nuevos parámetros…). Esta orden viaja a través de
un socket UDP que comunica la parte de presentación con el resto de la aplicación.
La clase que está escuchando por el socket recibe el datagrama y lo parsea, y pasa
la información de la operación a la clase EngineDemo.cpp. En está información se
encuentra la operación a realizar (arrancar, pausar o parar) sobre el emisor, que
68
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
básicamente consiste en cambiar su estado. También contiene los parámetros de
los inicializadores y los modificadores. Conociendo esto, el main() del
EngineDemo realiza las operaciones necesarias sobre los emisores, que en base a la
nueva información de entrada variarán el resultado mostrado por pantalla.
A continuación se van a estudiar estas dos clases con más detalle.
EngineDemo
Como se ha dicho antes, controla la ejecución de los emisores. Recibe como
entradas las órdenes que le llegan desde la clase que escucha la llegada de
datagramas UDP. En base a estas entradas, se encarga de crear los nuevos
emisores con los inicializadores y modificadores correspondientes. En el siguiente
fragmento de código se muestra como ejemplo la creación de un emisor de
emisores que emite texturas:
bool Init() { Declaración de emisor g_pEmitter = new CEmitersEmiter; g_pEmitter‐>Init(100.0f, 1000); Se crea un renderer de texturas
g_pRenderer = new CSpriteRenderer; g_pRenderer‐>Init(ʺData/glow.tgaʺ, CSpriteRenderer::BM_ADD);
Se crean los inicializadores y modificadores según la orden del usuario
g_pModiffier1 = new CUpdatePosModiffier; g_pModiffier1‐>Init(); g_pInitializer1 = new CRandomInitializer;
69
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
g_pInitializer1‐>Init();
Se asignan los inicializadote, modificadores y el renderer al emisor
g_pEmitter‐>AddGlobalModifier(g_pModiffier1); g_pEmitter‐>SetRenderer(g_pRenderer); g_pEmitter‐>AddInitializer(g_pInitializer1); return true; }
Una vez que se ha creado el emisor y se le han asignado los inicializadores
y los modificadores, la clase ejecuta una secuencia de instrucciones OpenGL de
forma periódica:
void Draw(void) { glClearColor(0.0f, 0.0f, 0.0f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glLoadIdentity(); gluLookAt( 10.0f, 10.0f, 10.0f , 0.0f, 0.0f, 0.0f, 0.0f, 1.0f , 0.0f ); glBegin(GL_POINTS); glColor3ub(255, 0, 0); glVertex3f(0.0f, 0.0f, 0.0f); glEnd(); g_pEmitter‐>Update(0.015f, CMatrix4x4f_Identity); g_pEmitter‐>Render(); glFlush(); glutSwapBuffers(); g_fAcum += 0.15f;
70
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
glutPostRedisplay();
}
Dentro de este método Draw() es importante destacar el momento en que se
llama al método Update() y Render() del emisor. Estos son los que se encargarán
de aplicar los modificadores a las partículas y dibujarlas en cada iteración del
sistema, creando así el efecto.
El EngineDemo permanece en este estado de ejecución hasta que le llega un
aviso del socket comunicándole que ha llegado una nueva instrucción desde el
interfaz.
Clase Socket, programación concurrente en C++
Cuando se diseñó el interfaz gráfico, se presentó el gran problema que
suponía la comunicación entre este y el resto de la aplicación. Esto se debía a que
el interfaz se iba a desarrollar en Java, mientras que el sistema de partículas y el
resto de módulos que componían la lógica de la aplicación se había programado
en C++.
Al principió se barajó la posibilidad de crear una zona de memoria
compartida en la que el interfaz escribiera las instrucciones metidas por el usuario
para que el EngineDemo las leyera. Esto afectaba muy significativamente al
rendimiento ya que requería que el EngineDemo estuviera constantemente
leyendo la zona de memoria compartida para ver si había habido algún cambio.
Además añadía el riesgo de que ambas partes accedieran al mismo tiempo a su
71
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
sección crítica, siendo necesario implantar un sistema de semáforos para evitar
accesos concurrentes.
Esto iba contra los requisitos del usuario ya que constantemente se están
haciendo accesos a disco, y era necesario empeñar parte de la memoria del sistema
para comparar si había diferencias entre el contenido del fichero entre un acceso y
el acceso anterior.
Lo ideal era poder avisar de una forma asíncrona al EngineDemo cada vez
que es usuario realizara un operación. Finalmente, se optó por la comunicación a
través de sockets UDP entre ambas partes, a través de un puerto conocido, de
forma que cuando el usuario realizará una acción se enviara un datagrama con su
contenido al sistema de partículas.
Sin embargo, aquí surgía un nuevo problema. El EngineDemo no podía
estar generando los efectos y escuchando por un puerto UDP al mismo tiempo.
Esto se debe a que en C++ la escucha a través de puertos UDP deja parada la
ejecución del programa hasta que llega algún datagrama.
La solución a esto se encontraba en la programación multihilo. Cuando
comienza la ejecución del EngineDemo, este arranca un hilo que escucha
constantemente la llegada de datagramas provenientes del interfaz gráfico.
Cuándo llega una orden del usuario, se formatea para que sea comprensible por el
EngineDemo y se le pasa. Este empieza entonces a generar los efectos, mientras
que el hilo continúa a la espera de la llegada de nuevos datagramas. Cuando esto
se produce, vuelve a avisar al EngineDemo de que ha llegado una nueva
instrucción. Se parará entonces la generación de efectos para examinar el
contenido de esta.
72
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
El ThreadSocket (así es como se llama la clase) realiza también una función
de parseado del mensaje que le llega desde el interfaz.
En el contenido del mensaje debe estar la acción que se quiere realizar, los
inicializadores y modificadores que se quieren aplicar, sus parámetros… Sin
embargo esta información viaja a través de la red como una cadena de bits a la que
es necesario dar un formato para que se pueda comprender la información que
contiene. EL ThreadSocket recibe este stream de bits y lo va seccionando,
reconociendo por el orden de estos a que tipo de información corresponden. Para
más información sobre el contenido del mensaje y su parseado se puede consultar
el Anexo D.
A continuación se muestra un ejemplo de la secuencia de ejecución de las
dos clases concurrentes.
Comenzar EngineDemo
Arrancar ThreadSocket
Comprobar acciónArrancar emisor
Parar emisorComprobar acciónArrancar emisor
Comenzar ThreadSocket
Esperar datagrama
Parsear datagrama
Esperar datagrama
Parsear datagrama
1001010
Nueva orden
1001010
Nueva orden
Arrancar hilo
73
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
La entrada de datos: el interfaz de usuario
Uno de los principales requisitos del cliente era poder manejar la aplicación
desde un interfaz gráfico, pudiendo ver los resultados de la ejecución en tiempo
real.
De acuerdo con el diseño de la arquitectura, el interfaz gráfico debe formar
parte del nivel de presentación, quedando aislada de la lógica de la aplicación y no
viéndose afectada por los cambios que se pudiera dar en esta.
Aunque el desarrollo del proyecto se ha realizado en C++, la programación
de interfaces gráficos con este lenguaje resultaba muy complicada, y usar un
editor gráfico generaba mucho código innecesario. Por lo tanto, se decidió usar
Java como lenguaje para el desarrollo de esta parte, ya que gracias a su librería
java.swing proporcionaba todo tipo de funciones y componentes gráficos
necesarios según las necesidades del proyecto.
El interfaz gráfico constituye el único medio de entrada de datos al sistema.
A través de él se introducirán los parámetros necesarios para los inicializadores y
los modificadores, así como las instrucciones a ejecutar sobre los emisores.
Proporcionará además una serie de funcionalidades adicionales que facilitarán el
uso de la aplicación, como la posibilidad de guardar emisores en disco para
posteriormente poder volver a cargarlos.
74
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
A continuación se muestra la interacción del interfaz con la aplicación.
Interfaz de usuario
Datagrama
Capa de presentaciónLógica de aplicación
ThreadSocket
EngineDemo.cpp
EngineDemo
Sistema de
Partículas
C++
Java
Acción usuario
El usuario, por medio de la ventana principal, introduce los datos
correspondientes al nuevo emisor que desee generar. Cuando realiza una acción
de arrancar, pausar, o parar emisor, estos datos se recogen y se encapsulan en un
datagrama, formateándolos de tal manera que sean comprensibles para el parser
del ThreadSocket.
Este formato de datos pretende buscar la transparencia entre la lógica de la
aplicación y el interfaz, de manera que el ThreadSocket sólo se preocupará de que
los datos que reciba estén en el formato adecuado, sin importarle cómo se han
generado. Lo mismo ocurre en el interfaz, sólo se preocupa de mandar los datos
según el formato especificado, independientemente de cómo se van a manipular
en el destino.
75
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Esto va a permitir poder variar la clase ThreadSocket o el interfaz de forma
independiente uno de otro, siempre que la entrada o salida de datos se haga de
acuerdo con la estructura del mensaje acordada.
Para comprender mejor el funcionamiento del interfaz gráfico, se van a
estudiar primero la entradas que genera para el sistema de partículas, y
posteriormente el conjunto de clases java que hacen que este funcionamiento sea
posible.
Entradas al sistema
Como se ha dicho, el interfaz supone el único medio de entrada de datos al
sistema. A través de él se debe proporcionar toda la información necesaria para el
correcto funcionamiento de este. El usuario debe introducir:
• Orden a ejecutar. Puede consistir en Arrancar, Pausar, o Para emisor.
Estas órdenes, una vez que hayan llegado al EngineDemo, son las que
indicarán al método “main()” el nuevo estado al que debe pasar el
emisor que se está ejecutando y, por lo tanto, si debe seguir ejecutándose
o no su método Render().
• Parámetros de los inicializadores. Comprende algunos parámetros
básicos para la inicialización del sistema. Algunos de estos son
necesarios, como la tasa de emisión o el tiempo de vida de las partículas,
mientras que otros pueden tomar valor por defecto si no se introducen
(como la posición del emisor). Esta información indica al EngineDemo
que inicializadores debe añadir al nuevo emisor. Se pueden añadir
76
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
varios del mismo tipo, mientras que otros son excluyentes entre sí (como
el inicializador de caja y el de esfera).
• Parámetros de los modificadores. Indican que modificadores va a tener
el nuevo emisor, y los argumentos con los que se van a aplicar estos.
Hay otras funciones que el usuario puede realizar por medio del interfaz,
pero que no afectan a la lógica de negocio, es decir, al sistema de partículas, sino
que ayudan a hacer la edición de emisores más rápida por medio del guardado de
las características de estos en disco para su posterior reutilización. Esto se verá con
mayor detalle en el apartado sobre Uso de la Aplicación.
Relación de clases del interfaz
En el diagrama se muestran las clases .java que han sido necesarias para el
desarrollo del interfaz.
DynamicTreeDemo
Leer FicheroEscribir Fichero
Emisor
Socket
Fichero emisores
Datagrama
Instrucciones usuario
77
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
La clase principal es DynamicTreeDemo. En ella se definen los
componentes gráficos (campos de texto, botones, etiquetas) que van a formar el
interfaz, y las acciones que pueden desencadenar cada uno de ellos. A esta clase
llegan las acciones del usuario que, tras una serie de modificaciones, se mandarán
a la clase Socket para que genere el datagrama que se envía al ThreadSocket del
EngineDemo, en la lógica de la aplicación.
DynamicTreeDemo hace uso también de dos clases para poder leer y
escribir en el fichero de emisores, donde se guardan las configuraciones de
emisores creados en ejecuciones anteriores, de manera que puedan volver a ser
cargados en memoria.
Finalmente, la clase Emisor se ha creado para poder trabajar con objetos de
este tipo, teniendo entre sus atributos los parámetros de los inicializadores y
modificadores, y hacer así que la aplicación funcione de la forma más parecida al
mundo real.
Es el contenido de los atributos de estos objetos de tipo Emisor los que se
parsearán para generar el datagrama de salida.
En el Anexo C se detalla una relación de todas las clases del sistema.
78
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
V. USO DE LA APLICACIÓN
En este apartado se pretende guiar al usuario sobre el uso de la aplicación a
través del interfaz gráfico. Se explicarán las entradas de datos, su formato, y las
posibles acciones sobre los emisores.
Aquí se muestra el aspecto de la ventana principal.
Para poder comenzar a trabajar con la aplicación es necesario tener un
emisor. Hay dos formas de añadir un emisor: crear uno nuevo o cargar uno
guardado en disco de una ejecución anterior.
79
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Para crear un nuevo emisor se debe pulsar sobre el botón “Crear emisor”.
Aparecerá una pequeña ventana de diálogo en la que habrá que introducir el
nombre del nuevo emisor. El nuevo emisor se añadirá al árbol de emisores del
sistema de partículas.
Se puede cargar también un emisor creado en una ejecución anterior. Para
hacerlo hay que desplegar la lista que muestra los emisores guardados en disco,
seleccionar uno, y pulsar el botón “Cargar emisor”.
El emisor se añadirá al árbol de emisores del sistema de partículas y se
rellenarán los campos con los valores que tenga asignados.
80
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Para empezar a generar un efecto producido por un emisor es necesario
rellenar los campos correspondientes a los parámetros de las partículas y los
inicializadores y modificadores de este. Antes de proseguir con la descripción del
interfaz se va a detallar el contenido y la función de cada uno de estos campos,
que suponen la entrada de datos al sistema, y cuyo entendimiento será necesario
para conocer el funcionamiento de la aplicación.
Parámetros generales
• Cantidad de partículas. Determina el tamaño máximo del pool de
partículas que usan el emisor de partículas y el emisor de emisores. Por
lo tanto, es el número máximo de partículas que puede generar un
emisor.
• Tasa. Indica el número de partículas por unidad de tiempo.
Inicializadores
• Velocidad. Fija la velocidad inicial con la que se generan las partículas.
Al tratarse en la aplicación como un vector el contenido debe constar de
tres números separados por comas.
• Variación Velocidad. Determina el rango dentro del cual puede variar la
velocidad de las partículas respecto a la velocidad inicial. Al tratarse en
la aplicación como un vector el contenido debe constar de tres números
separados por comas.
• Tiempo de vida. Define la duración de la partícula, es decir, el tiempo
que transcurre desde que se crea hasta que se destruye.
81
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Variación tiempo de vida. Limitan el rango dentro del cuál se moverá el
tiempo de vida de las partículas respecto al valor central (Tiempo de
vida) de forma aleatoria.
• Dimensión. Define el tamaño de las texturas.
• Variación dimensión. Determina cuánto puede variar la dimensión de
las texturas respecto al tamaño inicial cuando son generadas.
• Color. Especifica el color de las texturas. Va en formato RGB, por lo
tanto deberá ser un vector con tres elementos (red, blue, green)
contenidos entre cero y uno.
• Variación color. Limita como puede variar el color de las partículas al
inicializarse respecto al Color central.
• Inicializador de forma. Las partículas pueden generarse dentro de
esferas o cubos, de forma aleatoria dentro del volumen de estos. La
posición determina el centro geométrico de la figura, y el lado su
volumen (lado en caso de cubo, radio en caso de esfera). Para
determinar si se trata de un incializador de caja o de esfera se debe
seleccionar uno de los dos en la lista situada en la parte inferior de la
ventana.
Modificadores
De posición, de velocidad, o de viento. Se aplican a las partículas en cada
vuelta del sistema. Su formato es el de un vector de tres componentes (x, y, z).
82
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Cuando se hayan rellenado todos los campos necesarios para la
inicialización de los emisores se pueden empezar a generar los efectos. Hay tres
botones encargados de controlar la ejecución: “Arrancar emisor”, “Pausar emisor”
y “Parar emisor”.
“Arrancar emisor” transmite a la aplicación la orden de comenzar a generar
las partículas. “Pausar emisor” cambia el estado del emisor a “pausado”, de forma
que se dejan de emitir partículas, pero se siguen dibujando los cambios realizados
por los modificadores en las partículas ya creadas. “Parar emisor” termina la
generación de partículas y destruye todas las partículas que hay en pantalla.
Se va a explicar ahora la funcionalidad de los botones que facilitan el
manejo del interfaz gráfico pero que no están directamente relacionados con la
lógica del sistema de partículas.
• “Editar Emisor”. Crea un objeto tipo Emisor, que es el que se usa
para salvar las configuraciones de los emisores en disco para poder
cargarlas más tarde.
• “Borrar Campos”. Resetea los campos de texto destinados a los
parámetros de la partículas, inicializadores y modificadores, dejando
estos en blanco.
• “Arrancar demo”. Permite ejecutar emisores que están almacenados
en disco como archivos ejecutables, que sirven como ejemplo de las
posibilidades que ofrece el sistema de partículas.
83
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• “Guardar emisor”. Crea un fichero cuyo contenido es el emisor del
árbol que esté seleccionado junto con el valor que tiene asignado en
todos sus parámetros.
• “Eliminar emisor”. Elimina del árbol de emisores el nodo que esté
seleccionado.
• “Eliminar todos los emisores”. Borra todos los hijos del nodo raíz
“Sistema de partículas” del árbol.
84
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
VI. PLANIFICACIÓN Y PRESUPUESTO
Planificación
La planificación inicial apenas se ha visto alterada durante el desarrollo del
proyecto. Las variaciones surgidas han sido despreciables nunca superando
alteraciones de un día de retraso a la hora de finalizar o comenzar alguna etapa.
En el diagrama de Gantt se muestra el intercalado entre las etapas definidas
en un principio. Partiendo de las primeras entrevistas con el cliente y del análisis
de los requisitos en base a sus necesidades se hizo un primer diseño de la
aplicación y el estudio de la arquitectura, lo que llevó el primer mes de trabajo.
A partir de aquí se dedicaron dos semanas para la programación del
módulo Base y el módulo que contendrías las clases con las operaciones
matemáticas. Como uno dependía del otro no se pudieron desarrollar en paralelo.
Ya con las clases que necesita el sistema de partículas como apoyo para el
control de errores, los accesos a archivos y las operaciones con vectores y matrices,
se podía proceder al diseño de este. Es necesario, antes de pasar a programar los
emisores de partículas, desarrollar antes los inicializadores y los modificadores, ya
que condicionaran en parte el comportamiento de los emisores (son los emisores
los que llaman a estas clases, por lo tanto deben conocer su interfaz de
comunicación).
85
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Antes de hacer el emisor de partículas es necesario, también, hacer el pool
de partículas que manejará el emisor. Cuando el emisor de partículas esté listo se
puede comenzar a desarrollar los dibujadotes (renderers) para ver los primeros
efectos generados con píxeles.
De forma paralela a la programación del pool de emisores y el emisor de
emisores se puede ir programando el EngineDemo, que contiene el método main
del proyecto, para hacer las primeras pruebas.
Cuando la lógica de negocio esté lista, es necesario pasar al diseño y
programación del interfaz, y comprobar la comunicación entre ambas partes.
Semanas 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Entrevistas cliente
Análisis necesidades
Estudio arquitectura
Diseño aplicación
Diseño módulo base
AssertsSistema de ficheros
Diseño módulo matemático
Vectores
Matriz
Diseño Sistema Partículas
InicializadoresModificadores
Pool Partículas
Emisor de Partículas
DibujadoresPool Emisores
Emisor Emisores
Diseño EngineDemo
Engine Demo
Diseño Interfaz
Programación InterfazPruebas del sistema
Implantación
86
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
A continuación se describen las tareas especificadas en el diagrama de
Gantt:
• Entrevistas con el cliente. Constituyen el punto de partida de la aplicación.
Generan la información básica necesaria para comenzar el desarrollo.
• Análisis de necesidades. La necesidades se definen en función de la
información que llega como entrada proveniente de las entrevista con el
cliente. Especifican los objetivos y requisitos del proyecto.
• Estudio de arquitectura. Partiendo de la información generada por las
entrevistas con el cliente y el análisis de necesidades, y conociendo ya el
entorno del proyecto, se hace un análisis de la arquitectura, que servirá
para definir los componentes hardware y software necesarios que
condicionarán el resto del desarrollo.
• Diseño de la aplicación. Es la tarea más importante. Teniendo como entradas
la información de las entrevistas y el análisis de necesidades, se definirán
los distintos módulos componentes de la aplicación, su funcionalidad y sus
interrelaciones, estudiando siempre cumplir los objetivos y requisitos del
cliente.
• Diseño del módulo base. Una vez que se han establecido los paquetes
componentes de la aplicación se procede a diseñar el módulo base, que
ofrecerá soporte al resto de módulos. En esta etapa se estudian las
funciones básicas accedidas por el resto de clases.
• Asserts. Esta tarea se encarga de la comprobación de errores.
87
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Sistema de ficheros. Atendiendo a las necesidades de almacenamiento de
información especificadas por el cliente y en la etapa de diseño, en esta
tarea se desarrolla un sistema de acceso a ficheros independiente de la
plataforma en la que se ejecute el programa.
• Diseño del módulo matemático. En esta fase se estudian las funciones
matemáticas requeridas por las clases definidas en el diseño de la
aplicación.
• Vectores y matrices. Con la información generada por la etapa anterior se
implementan las funciones necesarias para poder operar con vectores y
matrices.
• Diseño del sistema de partículas. Se analizan los componentes necesarios para
la generación de partículas, su actualización, dibujado y, por consiguiente,
la ejecución de los efectos.
• Inicializadores y modificadores. Se programan en función del diseño del
sistema de partículas. Es necesario desarrollarlos antes que el resto de
componentes del módulo ya que lo usan el resto de clases.
• Pool de partículas. Se trata de definir y programar una clase que permita
crear arrays de partículas, eliminar e insertar elementos, y conocer el
número de partículas que contienen. La salida de esta fase es usada por el
emisor de partículas y el emisor de emisores, de manera que puedan
generar nuevas partículas y aplicar los inicializadores, modificadores y
renderers sobre todos los elementos del pool.
88
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Emisor de partículas. Una vez que se han diseñado e implementado los
inicializadores, modificadores y el pool de partículas, ya se puede
comenzar a programar los emisores, definiendo su comportamiento, y a la
espera del desarrollo de los renderers para conseguir los efectos gráficos.
• Dibujadores. Con la finalización de las etapas anteriores, la programación de
los renderers permitirá generar los primeros efectos gráficos. Esto servirá
como entrada para el desarrollo del emisor de emisores.
• Emisor de emisores. Con el emisor de partículas como esqueleto, en esta fase
se modificarán los métodos de este para conseguir emisores que a su vez
emitan más emisores.
• Diseño y programación EngineDemo. En esta etapa se desarrolla el método
“main” del proyecto que controla la ejecución. Se desarrolla en paralelo
junto con el emisor de emisores ya que con el emisor de partículas y los
dibujadores listos se puede comenzar a hacer funcionar la aplicación.
• Diseño y programación del interfaz de usuario. Se basa en los requisitos
definidos por el usuario sobre la necesidad de un interfaz gráfico. Es
necesario usar como entradas el interfaz de acceso al EngineDemo y las
entradas de datos al sistema.
• Pruebas del sistema. Cuando la aplicación esté cerca del 100% de su
funcionalidad se realizarán pruebas basadas en casos de uso y usabilidad
de la herramienta, así como pruebas de rendimiento y fiabilidad.
89
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Implantación. Cuando el proyecto esté finalizado se procederá a su
implantación en las máquinas del cliente, sometiéndose a una última fase
de pruebas por parte de este.
90
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Presupuesto
Para estimar el presupuesto total de la aplicación calcularemos el número
de horas total destinadas al desarrollo del proyecto y, ya que se trata de una
herramienta en la que el 90% de la horas se dedican a la programación,
multiplicaremos el número de horas resultante por el coste que supone una hora
de trabajo de un programador, que se ha estimado en 20 euros.
A esto se le sumarán unos costes adicionales provenientes del pago de
algunas licencias y equipos de trabajo.
A continuación se detallan las horas invertidas en cada etapa del trabajo.
Definición aplicación Horas Coste hora Total
Entrevistas con cliente 50 20 € 1.000 €
Requisitos/Necesidades 20 20 € 400 €
Estudio arquitectura 20 20 € 400 €
Diseño aplicación 30 20 € 600 €
TOTAL: 120 2.400 €
91
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Módulo Base Horas Coste hora Total
Diseño 5 20 € 100 €
Asserts 15 20 € 300 €
Sistema de ficheros 15 20 € 300 €
TOTAL: 35 700 €
Módulo Matemático Horas Coste hora Total
Diseño 10 20 € 200 €
Vector 2x2 7 20 € 140 €
Vector 3x3 5 20 € 100 €
Matriz 4x4 10 20 € 200 €
TOTAL: 32 640 €
92
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Engine Horas Coste hora Total
Diseño 10 20 € 200 €
EngineDemo 20 20 € 400 €
TOTAL: 30 600 €
Sistema de
Partículas Horas Coste hora Total
Diseño 25 20 € 500 €
Inicializadores 10 20 € 200 €
Modificadores 10 20 € 200 €
Dibujadores 5 20 € 100 €
Pool Partículas 5 20 € 100 €
Pool Emisores 10 20 € 200 €
Emisor Partículas 10 20 € 200 €
Emisor Emisores 15 20 € 300 €
TOTAL: 90 1.800 €
93
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Interfaz gráfico Horas Coste hora Total
Diseño 20 20 € 400 €
Programación 25 20 € 500 €
TOTAL: 45 900 €
Pruebas Horas Coste hora Total
Pruebas del sistema 15 20 € 300 €
Implantación 15 20 € 300 €
TOTAL: 30 600 €
94
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Otros costes Horas Coste hora Total
Licencia Microsoft
Office 300 €
Licencia Windows
XP 250 €
Portátil IBM
Thinkpad 1.500 €
Servicio ADSL 300 €
TOTAL: 2.350 €
TOTAL Horas Coste hora Total
Desarrollo
Definición
aplicación 120 20 € 2.400 €
Módulo Base 35 20 € 700 €
Módulo Matemático 32 20 € 640 €
Engine 30 20 € 600 €
Sistema de
Partículas 90 20 € 1.800 €
Interfaz gráfico 45 900 €
95
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Pruebas 30 20 € 600 €
Otros costes
Total otros costes 2.350 €
TOTAL: 370 9.990 €
En total, obtenemos 325 horas de trabajo. Si consideramos que se destinan
al proyecto 4 horas diarias, serían 20 horas por semana, y 80 horas por mes. Por lo
tanto, a duración estimada del proyecto es de unos cuatro meses y medio, con un
presupuesto cercano a los diez mil euros.
Se ajusta, entonces, al plazo de seis meses y al presupuesto de 12.000 euros
impuesto por el cliente.
96
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
ANEXOS
Anexo A: Acerca de OpenGL
OpenGL es una especificación estándar que define una API multilenguaje y
multiplataforma para escribir aplicaciones que produzcan gráficos 2D y 3D. Fue
desarrollada por Silicon Graphics a principios de los 90. Su nombre viene del
inglés Open Graphics Library, cuya traducción es biblioteca de gráficos abierta (libre)
[6].
OpenGL se utiliza en campos como CAD, realidad virtual, representación
científica y de información, simulación de vuelo o desarrollo de videojuegos, en el
que su principal competidor es Direct3D de Microsoft Windows.
Especificación
A grandes rasgos, OpenGL es una especificación, es decir, un documento
que describe un conjunto de funciones y su comportamiento exacto. A partir de
ella, los fabricantes de hardware crean implementaciones (bibliotecas de funciones
creadas para enlazar con las funciones de la especificación OpenGL, utilizando
aceleración hardware cuando sea posible). Dichos fabricantes tienen que superar
pruebas específicas que les permitan calificar su implementación como una
implementación de OpenGL.
97
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Existen implementaciones eficientes de OpenGL suministradas por
fabricantes para Mac OS, Microsoft Windows, Linux... Existen también varias
implementaciones software que permiten que OpenGL esté disponible para
diversas plataformas sin soporte de fabricante. Es de señalar la biblioteca de
software libre / código abierto Mesa 3D, una API de gráficos basada totalmente en
software y completamente compatible con OpenGL. Sin embargo, para evitar los
costes de la licencia para ser denominada formalmente como una implementación
de OpenGL, afirma ser simplemente una API muy similar.
Diseño
OpenGL tiene dos propósitos principales:
• Ocultar la complejidad del interfaz con las diferentes tarjetas gráficas,
presentando al programador una API única y uniforme.
• Ocultar las diferentes capacidades de las diversas plataformas
hardware, requiriendo que todas las implementaciones soporten el
conjunto completo de características de OpenGL (utilizando emulación
software si fuese necesario).
La operación básica de OpenGL es aceptar primitivas tales como puntos,
líneas y polígonos, y convertirlas en píxeles. Este proceso es realizado por una
pipeline gráfica conocida como la Máquina de estados de OpenGL. La mayor parte
de los comandos de OpenGL emiten primitivas a la pipeline gráfica o configuran
como la pipeline procesa dichas primitivas. Hasta la aparición de la versión 2.0
cada etapa de la pipeline ejecutaba una función establecida, resultando poco
98
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
configurable. A partir de la versión 2.0 varias etapas son completamente
programables.
OpenGL es una API basada en procedimientos de bajo nivel que requiere
que el programador dicte los pasos exactos necesarios para renderizar una escena.
Esto contrasta con las APIs descriptivas, donde un programador sólo debe
describir la escena y puede dejar que la biblioteca controle los detalles para
renderizarla. El diseño de bajo nivel de OpenGL requiere que los programadores
conozcan en profundidad la pipeline gráfica, a cambio de la libertad ofrecida en la
implementación de algoritmos novedosos de renderizado.
OpenGL ha influido en el desarrollo de las tarjetas gráficas, promocionando un
nivel básico de funcionalidad que actualmente es común en el hardware
comercial; algunas de esas contribuciones son:
• Primitivas básicas de puntos, líneas y polígonos rasterizados.
• Una pipeline de transformación e iluminación.
• Z‐buffering.
• Mapeado de texturas.
• Alpha blending.
Una descripción somera del proceso en la pipeline gráfica podría ser:
1. Evaluación, si procede, de las funciones polinomiales que definen ciertas
entradas, aproximando curvas y la geometría de la superficie.
99
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
2. Operaciones por vértices, transformándolos, iluminándolos según su
material y recortando partes no visibles de la escena para producir un
volumen de visión.
3. Rasterización, o conversión de la información previa en píxeles. Los
polígonos son representados con el color adecuado mediante algoritmos de
interpolación.
4. Operaciones por fragmentos o segmentos, como actualizaciones según
valores venideros o ya almacenados de profundidad y de combinaciones de
colores, entre otros.
5. Por último, los fragmentos son volcados en el Frame buffer.
Proceso en la pipeline de gráficos
Muchas tarjetas gráficas actuales proporcionan una funcionalidad superior
a la básica aquí expuesta, pero las nuevas características generalmente son mejoras
de esta pipeline básica más que cambios revolucionarios de ella.
100
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Anexo B: Comparación entre OpenGL y Direct X
A la hora de crear un entorno tridimensional, los programadores deben
decidir entre DirectX u OpenGL. En esta breve reseña detallarán los aspectos más
importantes de cada plataforma, su historia y se hará una comparación punto por
punto, para ver cuál es la más conveniente para implementar.
Si bien OpenGL ha perdido terreno en las últimos años (por lo menos en lo
que se refiere a videojuegos), continúa presentándose como la competencia más
dura de DirectX. La API de Microsoft se convirtió en la preferida de los
programadores a la hora de diseñar complejos entornos gráficos interactivos en
tres dimensiones y utilizar los conocidos shaders.
Pero antes de nada conviene aclarar que es una API. Su sigla proviene de
Application Programming Interface, lo que en castellano sería Interfaz de
Programación de Aplicaciones. Se trata de un conjunto de técnicas, funciones y
métodos utilizados para establecer una comunicación entre los diferentes niveles o
capas de un software.
Una API permite una abstracción en la programación entre las capas
inferiores (bajo nivel) y las superiores (alto nivel), de forma tal de poder
interactuar casi directamente con el hardware a través de funciones nativas del
sistema operativo o mediante una aplicación específicamente diseñada con ese
propósito.
101
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Tanto DirectX como OpenGL son APIs que se valen de librerías para
cumplir con su objetivo. Los diseñadores de software escogen la que mejor se
adapte a los requerimientos del producto y comienzan a programar en base a ella.
La elección correcta depende de varios factores, los cuales intentaremos detallar en
las próximas líneas. Antes de ello, se hará un breve repaso sobre el pasado y el
presente de estas dos APIs.
El conjunto de librerías de Microsoft nació allá por 1995, cuando en una
importante exposición se presentó lo que por ese entonces se conocía como
GamesSDK v1. Al ser un API encargada de varios aspectos (gráficos, sonido,
música, comunicaciones, etc.), estaba estructurada en varios componentes:
DDraw, DSound, DPlay y DInput. Cada uno de éstos controlaba un aspecto en
particular; en el caso de los gráficos 2D, DDraw era la responsable.
Estas herramientas de desarrollo estuvieron disponibles en Octubre de ese
año, un par de meses después que Windows 95 saliera a la venta. El próximo paso
fue incorporar Direct3D –para gráficos tridimensionales– al conjunto, algo que se
lograría recién en la tercera versión (DX 3.0). Los sucesores no tardaron en
aparecer, ya que DirectX 4 llegó en Diciembre del 96’ y DirectX 5 en Junio del año
siguiente. En realidad, la cuarta edición fue una modificación de la tercera que
venía preparada para ser compatible con el primer gran chip que llevaría la
bandera de la aceleración 3D: el Voodoo Graphics. Al ser compatible para atrás,
cada nueva versión de DirectX podía ejecutar, también, software preparado para
las versiones previas.
Fue por eso que el crecimiento en potencia y posibilidades de esta API fue
102
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
muy marcado en los años siguientes. En la actualidad DX 10 está, por ahora, en
sus primeras etapas de implementación y con un futuro enorme.
En todos los campos de la informática siempre hay una alternativa libre (de
código abierto) para escoger y trabajar. En este caso es OpenGL, con la que se han
obtenido resultados impresionantes, incluso fuera del ámbito de las compatibles
hogareñas.
La responsable de Open Graphics Library –su denominación completa– es
Silicon Graphics Incorporated (SGI). Existe más detalles sobre esta especificación
en el Anexo C: Acerca de OpenGL.
Existen diversos factores que los desarrolladores tienen en cuenta antes de
elegir y ponerse a trabajar sobre una plataforma. Lo más importantes los citaremos
a continuación, relatando cuál es más conveniente en cada caso.
Como se decía al comienzo, la elección de una u otra API depende de varios
factores, como la portabilidad, facilidad de uso, el rendimiento, los usuarios a los
cuales está destinada la aplicación y la extensibilidad, entre otros. En este caso, se
va a comparar las librerías de DirectX dedicadas al procesamiento de gráficos
(Direct3D) con OpenGL.
• Portabilidad: Si se atiende a la portabilidad, DirectX difícilmente supera a
OpenGL, dada su gran dependencia con Windows y sus componentes.
Fuera de este sistema operativo, solamente se encuentra implementada en
la consola Xbox. En cambio, OpenGL es compatible no sólo con Windows,
sino que se utiliza en sistemas Unix, Linux, Mac y hasta en consolas como
103
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
PlayStation 3 y Nintendo Wii. En resumen: exceptuando Windows y Xbox,
todos los sistemas que proveen soporte para aceleración 3D han escogido a
OpenGL.
• Facilidad de uso: En sus comienzos, muchos programadores evitaban tener
que trabajar con DirectX, debido a lo complejo de su utilización. Con el
correr de las versiones, la balanza se fue equilibrando y, hoy en día, a pesar
de que sigue un paradigma completamente distinto a OpenGL ya no es tan
complicado de usar. Lenguajes como Visual Basic o Visual Basic Script son
un ejemplo de los que trabajan con este modelo. Por el lado de OpenGL, al
estar basado en el lenguaje de programación C, es bastante más
comprensible y puede ser adaptado a cualquier otro lenguaje sin
demasiadas complicaciones.
La diferencia principal es que DirectX es una API cuya plataforma se basa
en lo que el hardware es capaz de realizar, mientras que OpenGL es un
tanto más independiente. A su vez, de su implementación depende la
administración de los recursos, algo que en DirectX corre por cuenta de la
aplicación. Este detalle permite un desarrollo de software más sencillo, pero
es más propenso a sufrir los tan temidos errores de programación (mejor
conocidos como bugs).
• Performance: El rendimiento del software creado por medio de una u otra
API sigue siendo un parámetro muy debatido. Dado que DirectX
implementa los drivers a nivel del núcleo en el sistema operativo y de nivel
usuario con un runtime provisto por Microsoft, existe la necesidad de hacer
un cambio entre un modo y otro en las llamadas a la API. Como
104
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
consecuencia, la CPU utiliza valiosos microsegundos en completar la
operación, quedando inutilizada para otra tarea. En cambio, OpenGL, a
través de una técnica conocida como marshalling, evita ese inconveniente y
obtiene una valiosa ventaja en la performance final. Desde Windows Vista,
DirectX podrá sortear esta deficiencia mediante este mismo procedimiento,
ya que los drivers estarán funcionando más a nivel de usuario que del
kernel del sistema operativo.
• Extensibilidad: OpenGL incluye una propiedad que le posibilita extender
sus capacidades a través de un driver, añadiendo nuevas funcionalidades.
Pero esto puede conducir a generar una gran cantidad de variantes de la
API, provocando cierta confusión entre los programadores. Por el lado de
DirectX, Microsoft se encarga de mejorarla pero con menos regularidad. No
obstante, desde hace un par de años que las actualizaciones aparecen cada
vez más seguido. Depende de la empresa conducida por Bill Gates la
incorporación de características en la API que aprovechen las novedosas
funciones de las GPU más modernas.
• Usuarios: La ventaja en el ámbito profesional está del lado de OpenGL.
Incluso la propia Microsoft admite la superioridad de ésta en estos campos.
De hecho, muchas de las placas profesionales sólo soportan esta API, lo que
es un decir. Las películas animadas por ordenador son desarrollados en
base a OpenGL, dado su carácter de plataforma de propósitos generales.
La situación cambia cuando se mira desde el punto de vista del mercado de
los videojuegos. DirectX no requiere de la implementación completa que
demanda OpenGL para funcionar (incluyo funciones no soportadas por el
105
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
hardware), por lo que se torna más sencillo de utilizar. Para hacerlo simple,
se puede decir que Direct3D es un acceso directo de bajo nivel a los
registros disponibles. Además, posee un mecanismo que determina si una
funcionalidad está o no presente en el dispositivo, evitando la
implementación obligatoria y dejando a elección del diseñador del
videojuego su incorporación en el software. Por este detalle se ven muchos
más juegos de ordenador programados en DirectX que en OpenGL.
Habiendo conocido las características más importantes de cada API, sólo
queda esperar y ver cómo siguen progresando en los próximos años.
DirectX 10 acaba de salir, convirtiéndose en la versión más sofisticada y
poderosa de esta API. En tanto que OpenGL continuará evolucionando poco a
poco gracias a su extensibilidad, manteniéndose a la misma altura – en cuanto a
capacidades – que su rival.
106
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
Anexo C: Relación de Clases
• Sistema de Partículas
o Base Files
Base.h
File.h
FileSys.cpp
FileSys.h
Log.h
MemoryBuffer.h
MyAssert.cpp
MyAssert.h
RefCounter.cpp
RefCounter.h
Types.h
WinFile.cpp
WinFile.h
o EngineDemo files
Base
Math
ParticleSys
EngineDemo.cpp
ParticleEmiter.cpp
Socket.cpp
Socket.h
Thread.cpp
Thread.h
107
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
o Math files
Constants.h
Matrix4x4.h
Matrix4x4.inl
Vector2.h
Vector2.inl
Vector3.h
Vector3.inl
o ParticleSys files
Modiffiers
• Modiffier.h
• UpdatePosModiffier.cpp
• UpdateVelModiffier.cpp
• UpdateVelModiffier.h
• UpdateWindModiffier.cpp
• UpdateWindModffier.h
Initializer
• BoxInitializer.cpp
• BoxInitializer.h
• Initializer.h
• RandomInitializer.cpp
• RandomInitializer.h
• SphereEmiter.cpp
• SphereEmiter.h
Renders
• Imageloader.cpp
• Imageloader.h
• PointRenderer.cpp
• PointRenderer.h
108
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
• Renderer.h
• SpriteRenderer.cpp
• SpriteRenderer.h
• Texture.2D.h
• Texture.2DPC.cpp
BaseEmiter.cpp
BaseEmiter.h
Colour.h
ColourDegree.cpp
ColourDegree.h
EmiterList.cpp
EmiterList.h
EmitersEmiter.cpp
EmitersEmiter.h
Particle.h
ParticleEmiter.cpp
ParticleEmiter.h
ParticleList.cpp
ParticleList.h
• Interfaz Gráfico
o DynamicTreeDemo.java
o EscribirFichero.java
o Socket.java
o DynamicTree.java
o Emisor.java
o LeerFichero.java
109
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
ANEXO D: El fichero de emisores.
En el fichero de emisores se almacena la información relacionada con los
emisores guardados en disco. Entre esta información se encuentran los parámetros
de los inicializadores y modificadores, el nombre del emisor, la tasa de emisión,
etc. El contenido del fichero está formateado de forma que, al leerlo, sea posible
extraer esta información.
Por ejemplo, un emisor con nombre “Efecto fuego”, con una tasa de emisión
de 10 partículas por segundo, con un pool de partículas de 1000, y con una
velocidad inicial (1, 3, 2) tendría un comienzo de fichero así:
Efecto fuego#1000#10#1,3,2#...
Estaría almacenado en un archivo con nombre Efecto_fuego.txt. Cuando se
accediera al archivo, la clase encargada de leerlo seccionaría el contenido usando
como separador el carácter “#”. Así, sabría que el contenido de la primera posición
corresponde al nombre del emisor, la segunda al tamaño del pool de partículas, la
tercera a la tasa, y así sucesivamente.
Este formato es el que se usa también como contenido del datagrama que
envía la capa de presentación a la parte de la lógica de la aplicación. La clase
ThreadSocket se encarga de recibir el datagrama y partir el contenido para saber
así cuáles son los parámetros de los inicializadores y modificadores.
110
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
BIBLIOGRAFÍA
[1] Autor: Barranco de Areba, J. Título: “Metodología del Análisis Estructurado de Sistemas”. Edita: Universidad Pontificia de Comillas, Madrid 1994.
[2] Autor: Eckel, Bruce. Título: “Thinking in Java”. Edita: Prentice Hall.
[3] Autor: Eckel, Bruce. Título: “Thinking in C++”. Edita: Prentice Hall.
[4] Autor: Gottfried, Byron. Título: “Programación en C Edita: McGraw Hill.
[5] Autor: Woo, M. Título: “OpenGL Programming Guide” Edita: Prentice Hall.
También se han consultado gran variedad de páginas web entre las que se pueden destacar:
• es.wikipedia.org [6] • www.opengl.org [7] • nehe.gamedev.net [8]
111
DISEÑO Y DESARROLLO DE UN SISTEMA DE PARTÍCULAS
112