UNIVERSIDAD PONTIFICIA COMILLAS · el movimiento del esqueleto automáticamente afectará las porciones ... medida al humor y la respuesta emocional generada por la escena, algo que

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í.


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.


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,


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.


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.


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.


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


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


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.


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


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


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


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


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


• 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


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


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


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


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


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


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


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


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




TIPO DE REQUISITO: Funcional IDENTIFICADOR: REQ‐02


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




TIPO DE REQUISITO: Funcional IDENTIFICADOR: REQ‐03


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




TIPO DE REQUISITO: de diseño IDENTIFICADOR: REQ‐04


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




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




TIPO DE REQUISITO: operativo IDENTIFICADOR: REQ‐06


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.


FECHA: 25/09/2006 VERSIÓN: v1.0 PRIORIDAD: Media

TIPO DE REQUISITO: de rendimiento IDENTIFICADOR: REQ‐07


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


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


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


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


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


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


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


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


P‐1.2 Aplicar inicializadores

1.2.1Aplicarinic ializador partículas

1.2.2Aplicarinic ializador emisor

Emisor emisores

Emisor partículas

Emisor partículas



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


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


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


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


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


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


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


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


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


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


• 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


(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


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


Partícula.Pos = x1, y1, z1}

Modificador Velocidad‐Atributos

‐Vel(x1, y1, z1)‐Métodos


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


• 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


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


• “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


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


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


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


• 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


• 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


• 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


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


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


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


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


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


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


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


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


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

http://es.wikipedia.org/w/index.php?title=Mapeado_de_texturas&action=edit

http://es.wikipedia.org/w/index.php?title=Alpha_blending&action=edit


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

http://es.wikipedia.org/wiki/Imagen:Pipeline_OpenGL_%28es%29.png


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

http://www.neoteo.com/Portals/0/neoteo/3612full.jpg



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


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




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


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


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




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


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


• 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


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


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

http://www.wikipedia.com/

http://www.opengl.org/


112

UNIVERSIDAD PONTIFICIA COMILLAS · el movimiento del esqueleto automáticamente afectará las porciones ... medida al humor y la respuesta emocional generada por la escena, algo que

Documents