DEPARTAMENTO DE ARQUITECTURA Y TECNOLOGÍA DE …oa.upm.es/6016/1/PFC_OMAR_AGUDO_SILVA.pdf ·...

DEPARTAMENTO DE ARQUITECTURA Y TECNOLOGÍADE SISTEMAS INFORMÁTICOS

Facultad de InformáticaUniversidad Politécnica de Madrid

TRABAJO FIN DE CARRERA

Mayaneuron: motor para la generación deimágenes de alta calidad de simulaciones de

circuitos corticales

AutorOmar Agudo Silva

TutoresJosé María Peña SánchezJuan Hernando Vieites

Madrid, Febrero 2011

A todos los que siemprehan confiado en mí

Agradecimientos

Cinco años han pasado desde que entré por primera vez en la facultad de informática.

Durante este tiempo he estado estudiando y preparándome para el futuro, y he conta-

do con la ayuda de mucha gente a la que tengo que agradecer su apoyo y confianza.

En primer lugar, a mi familia, que me animó a tomar la decisión de cursar esta ca-

rrera y me ha ayudado en todo cuanto he necesitado. A mi madre, por su apoyo, pacien-

cia y comprensión, sin ella todo hubiese sido más difícil. A mi padre, por escucharme

y enseñarme, a su manera, los consejos que siempre tendré presentes. También a mis

hermanos, con los que siempre estaré en deuda. A mi hermana Celia, que siempre ha

estado a mi lado cuando más la necesitaba y me ha prestado su ayuda. A mi hermano

Iván, por desearme suerte, también a su manera, antes de cada examen y por ser la

persona que me enseñó a apreciar la informática. A mi abuela Mercedes, por preocu-

parse de mi y enseñarme tantas cosas de la vida. También al resto de mi familia, con un

especial agradecimiento a mi tía Mercedes, que aunque no esté entre nosotros, estoy

seguro está muy orgullosa de mí.

En la facultad he tenido la oportunidad de compartir muchos momentos y expe-

riencias con gente a la que también he de agradecer mucho. Gracias a mis amigos

Adrián, Alberto, Alfonso, Edu, Ferni, Javi, Jóse Luis y Vicente que me han apoyado du-

rante estos años. No me quiero olvidar de mis compañeros del Laboratorio de Sistemas

Operativos, con los que también he compartido bastante tiempo y de los que he apren-

dido mucho.

Fuera de la facultad también he estado rodeado de mucha gente que me ha servido

de gran ayuda. Agradezco a mi novia Yolanda su apoyo incondicional y su comprensión

en todas las decisiones que he tomado. También estoy muy agradecido con mis ami-

gos del barrio y de la sierra, que me han animado en los malos momentos, dándome

fuerzas para superar las dificultades que se me han presentado.

Por último, tengo que agradecer especialmente a mis tutores Chema y Juan su aten-

ción y ayuda prestada a lo largo del desarrollo del proyecto, ya que sin ellos este último

paso no hubiera sido posible.

A todos, muchas gracias.

Omar Agudo Silva

Febrero de 2011

II

Índice general

Índice de figuras VII

Capítulo 1. INTRODUCCIÓN 1

1.1. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Blue Brain Proyect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Capítulo 2. ESTADO DE LA CUESTIÓN 9

2.1. Terminología básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Técnicas de renderizado de alta calidad . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. REYES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2. Trazado de rayos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Aplicaciones para el renderizado de alta calidad . . . . . . . . . . . . . . . . 19

2.3.1. Mental ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2. RenderMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.3. Autodesk Maya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.4. Autodesk 3ds Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.5. Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.6. POV-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4. Arquitectura software del BBP . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.1. Tecnologías y herramientas empleadas en el BBP . . . . . . . . . . . 25

2.4.1.1. CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III

2.4.1.2. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1.3. Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1.4. Técnicas de envoltorio C++/Python . . . . . . . . . . . . . . 27

2.4.1.4.1. SWIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.1.4.2. Boost Python . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1.5. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1.6. OmniORB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.2. BBP-SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.3. BlueHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.3.1. BlueHubCore . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.3.2. BlueHubClient . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.3.3. MovieProducer . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Capítulo 3. PLANTEAMIENTO Y SOLUCIÓN DEL PROBLEMA 37

3.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.1. Objetivo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.2. Objetivo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.3. Objetivo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.4. Objetivo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2. Solución del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1. Motor de renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2. Objetivo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.3. Objetivo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.4. Integración del motor de renderizado . . . . . . . . . . . . . . . . . . 50

3.2.5. Objetivo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.6. Objetivo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.7. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Capítulo 4. PROCESO DE DESARROLLO 59

4.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.1. Actores y casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2.1.1. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

IV

4.2.1.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2.1.3. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . 65

4.2.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2.3. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2.4. Red de sombreado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Capítulo 5. RESULTADOS 83

5.1. Comparativa de soluciones para representar la información de simulación 84

5.1.1. Consumo de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.1.2. Tiempo de antes del renderizado de la escena . . . . . . . . . . . . . 89

5.1.3. Tiempo de renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.1.4. Tiempo de actualización entre frames . . . . . . . . . . . . . . . . . . 92

5.1.5. Tiempo total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2. Imágenes generadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.1. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.2. Intensidad de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.2.3. Intensidad de sombras . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.2.4. Puntos de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2.5. Intensidad de brillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2.6. Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2.7. Imagen 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2.8. Profundidad de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.2.9. Mapa de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2.10. Campo de visión vertical . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.2.11. Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.2.12. Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Capítulo 6. CONCLUSIONES Y LÍNEAS FUTURAS 103

6.1. Conclusiones técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.3. Líneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

V

Bibliografía 109

Apéndice A. MANUAL DE USUARIO 113

A.1. Instalación del motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.2. Configuración del renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.3. Arranque del motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

VI

Índice de figuras

1.1. Columna de 10.000 neuronas utilizada en la simulación del BBP . . . . . . 4

2.1. Resumen del algoritmo REYES . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2. Rayo de sombra durante el trazado de rayos . . . . . . . . . . . . . . . . . . 17

2.3. Arquitectura CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4. Clase Microcircuit y sus relaciones con clases de más bajo nivel . . . . . . 32

2.5. Niveles y relaciones entre las interfaces del BBP-SDK . . . . . . . . . . . . . 33

3.1. Visualización de un modelo del BBP a través de la interfaz gráfica de Maya 42

3.2. Acceso a los datos del BBP y creación de la escena por parte del motor de

renderizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3. Shader del motor de renderizado . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4. Operaciones realizadas por el shader para acceder al voltaje asociado a

un vértice con índice X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5. Mapa de colores por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6. Texturas unidimensionales por defecto . . . . . . . . . . . . . . . . . . . . . 48

3.7. Solución del enlace C++ - Python . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.8. Modificación de la aplicación MovieProducer . . . . . . . . . . . . . . . . . 55

3.9. Arquitectura antigua del BBP . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.10.Arquitectura nueva del BBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1. Diagrama de casos de uso del motor de renderizado . . . . . . . . . . . . . 63

4.2. Diagrama de secuencia antes del renderizado . . . . . . . . . . . . . . . . . 66

VII

4.3. Diagrama de secuencia durante y después del renderizado . . . . . . . . . 68

4.4. Diagrama de secuencia de las operaciones internas al motor de Maya pa-

ra la llamada startRendering . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.5. Diagrama de clases (primera parte) . . . . . . . . . . . . . . . . . . . . . . . 72

4.6. Diagrama de clases (segunda parte) . . . . . . . . . . . . . . . . . . . . . . . 73

4.7. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.8. Grafo de dependencia de la red de sombreado de Maya para una escena

con tres neuronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1. Primer frame de la secuencia 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 85




5.5. Consumo de memoria durante el renderizado . . . . . . . . . . . . . . . . . 88

5.6. Tiempo empleado antes del renderizado del primer frame (medido en se-

gundos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.7. Tiempo de renderizado (medido en segundos) . . . . . . . . . . . . . . . . . 91

5.8. Tiempo de actualización entre frames (medido en segundos) . . . . . . . . 92

5.9. Tiempo total empleado (medido en segundos) . . . . . . . . . . . . . . . . . 93

5.10.Opción de transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.11.Opción de intensidad de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.12.Opción de intensidad de sombras . . . . . . . . . . . . . . . . . . . . . . . . 96

5.13.Opción de puntos de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.14.Opción de intensidad de brillo . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.15.Opción de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.16.Opción de imagen 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.17.Opción de profundidad de campo . . . . . . . . . . . . . . . . . . . . . . . . 100

5.18.Opción de mapa de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.19.Opción de campo de visión vertical . . . . . . . . . . . . . . . . . . . . . . . 101

5.20.Opción de shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.21.Opción de materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

VIII

Capı́tulo 1INTRODUCCIÓN

Índice1.1. Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Blue Brain Proyect . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1. Motivaciones

Vivimos en una sociedad que depende profundamente de la ciencia y la tecnolo-

gía. Sin embargo, la mayor parte de la ciudadanía carece de una base científica que le

permita comprender el mundo en el que vive. Existe por ello la necesidad, por parte de

la comunidad científica, de atender esta demanda, dando a conocer los aspectos más

relevantes e interesantes de sus investigaciones. En este contexto la divulgación cien-

tífica juega un papel esencial, permitiendo el acercamiento de la ciencia a la sociedad.

En proyectos científicos interdisciplinares la divulgación de resultados cobra aún

más importancia. Por un lado, no sólo persigue aumentar el entendimiento del ciuda-

dano medio, sino también el de los propios científicos que participan en el proyecto,

ya que, en la mayoría de los casos, éstos no tienen conocimientos del resto de disci-

plinas que intervienen en el mismo. Por otro, la repercusión social generada a causa

1

CAPÍTULO 1. INTRODUCCIÓN

de esta divulgación influye directamente en la clase política, responsable última de la

financiación de este tipo de proyectos.

El Blue Brain Proyect[BBP], dentro del cual se ha realizado este trabajo, es un ejem-

plo de proyecto interdisciplinar en el que existe una necesidad de divulgación. El BBP

es el primer intento global de ingeniería inversa del cerebro de los mamíferos, con el

fin de entender la función y disfunción cerebral a través de simulaciones por orde-

nador. Este proyecto internacional, en el que España participa[CBB], tiene como ob-

jetivo principal proporcionar a los científicos una serie de herramientas informáticas

que faciliten la investigación basada en simulación. De esta manera, el estudio de nue-

vos fármacos, alteraciones fisiológicas, enfermedades neurodegenerativas o incluso la

consciencia, podrán llevarse a cabo sin necesidad de experimentación con sujetos. Se

trata de impulsar un cambio de paradigma: de la experimentación “in vitro” o “in vivo”

a experimentación “in silico”.

Existen numerosas formas de dar a conocer contenidos de carácter científico: ar-

tículos y libros de carácter general, programas de televisión, congresos, museos, ferias,

páginas de internet, etc. En todas estas formas de divulgación, la comunicación visual

mediante el uso de imágenes y vídeos es de vital importancia por tres motivos: facilita

la comprensión del mensaje, fomenta el interés y la curiosidad y refuerza la retención

de los conocimientos adquiridos.

El presente trabajo tiene como objetivo principal facilitar a los científicos la genera-

ción de imágenes, vídeos y películas 3D de alta calidad para comunicar los resultados

del BBP a la comunidad científica y al público general.

1.1.1. Blue Brain Proyect

El BBP centra actualmente su estudio en la corteza cerebral o córtex del cerebro

humano, aunque su intención final es la de estudiar la totalidad del cerebro. El córtex

conforma el 80 % de la masa cerebral y es responsable de nuestra capacidad de recor-

dar, pensar, reflexionar, sentir empatía, comunicar y planificar el futuro.

Las neuronas son las células más importantes que participan en el procesamiento

de la información en el cerebro. La función principal de una neurona es la de integrar

las señales químicas que reciben sus dendritas y generar una señal eléctrica, también

denominada impulso nervioso, la cual se propaga a través de su axón. La señal eléctrica

2

1.1. MOTIVACIONES

generada alcanza los puntos de conexión entre el axón y las dendritas de neuronas re-

ceptoras. En dichos puntos de conexión, llamados sinapsis, la señal eléctrica del axón

se transforma en la señal química que reciben las dendritas. De esta forma, los impul-

sos nerviosos se van transmitiendo de neurona a neurona por todo el cerebro.

Existen del orden de decenas de tipos de neuronas, cada uno de los cuales presen-

ta geometrías bastante complejas. La forma y estructura de cada neurona influye en

sus propiedades eléctricas y en la conectividad que presenta con otras neuronas. El

cerebro humano contiene unas 1011 neuronas, las cuales se conectan unas con otras

formando una especie de cableado biológico con un total aproximado de 1014 cone-

xiones [RK88]. La distribución y conexión de las neuronas a lo largo del cerebro no es

aleatoria, y son varias las hipótesis que han surgido para intentar explicar este hecho.

La principal hipótesis acerca del principio de organización de la corteza cerebral

es la hipótesis columnar. Según esta hipótesis existe una unidad funcional elemental,

con una arquitectura microcircuital concreta, que se repite a lo largo de toda la cor-

teza, aunque con variaciones citoarquitectónicas en función del área cortical. Estas

unidades funcionales, también conocidas como columnas neocorticales, operan co-

mo microcircuitos en un ordenador. En humanos, cada columna neocortical contiene

aproximadamente 60.000 neuronas y tiene un volumen cilíndrico de 0,5 mm de ancho

y 2 mm de largo. En las columnas neocorticales las neuronas se organizan en seis capas,

cada una de las cuales presenta funciones específicas. Dichas funciones son el resulta-

do de una conectividad diferenciada: aparte de las conexiones locales en una capa, las

neuronas de una determinada capa proyectan sus axones para establecer conexiones

con otras capas en sentido vertical (las cuales son más abundantes) y otras regiones en

sentido horizontal. La probabilidad de conexión entre neuronas varía según su capa y

tipo, además de su distancia.

El conocimiento de esta estructura repetitiva permite la creación de un modelo de

la corteza cerebral. El BBP comenzó la construcción de un modelo de la columna neo-

cortical hace 15 años. Durante ese tiempo, se han ido diseccionando las unidades ele-

mentales de una región de la corteza somatosensorial primaria de la rata. Para ello se

han llevado a cabo unos 15.000 experimentos de electrofisiología en los que se han uti-

lizado técnicas como voltage y patch clampling para caracterizar el comportamiento

eléctrico y las preferencias de conectividad de cada tipo de neurona.

3


Figura 1.1: Columna de 10.000neuronas utilizada en la simula-ción del BBP

Los datos extraídos de los experimentos se uti-

lizaron para crear una primera recreación a ni-

vel celular de la columna neocortical, aunque el

proceso de experimentación con animales para la

extracción de datos no ha finalizado y el estudio

de esa región de la rata aún continúa. El mode-

lo actual, en el cual se basa este trabajo, consiste

en una columna cortical de 10.000 neuronas, las

cuales son instancias de 368 reconstrucciones tri-

dimensionales de morfologías de neuronas reales

extraídas de ratas. Los mallados poligonales de es-

tos modelos neuronales que se utilizan en visua-

lización tienen, de media, 46.310 vértices y 92.616

triángulos. Las morfologías que presentan las neu-

ronas de las ratas son muy similares a las de los hu-

manos, de ahí el uso de ratas para modelar la co-

lumna. La diferencia entre humanos y ratas radica

en el número de columnas neocorticales y de neu-

ronas presentes en ellas, ya que en las ratas éstas

poseen unas 10.000 en comparación con las 60.000

presentes en humanos.

La simulación del circuito se refina iterativamente. Semanalmente se incorporan

nuevos datos y mejoras en el modelado estructural y funcional de las neuronas y sus

conexiones. Este ciclo iterativo comienza con la construcción del circuito utilizando

una serie de métodos estadísticos. El cálculo de los contactos, y de las sinapsis que

derivan de ellos, son resultado de un proceso de cálculo intensivo que termina produ-

ciendo el cableado que se utiliza para la simulación. Por otra parte, los datos recogidos

durante los experimentos se utilizan para ajustar el comportamiento eléctrico de las

células. Después de construir el circuito, se estimula la columna y se simula, a través

de complejas ecuaciones matemáticas, la actividad que tiene lugar en cada neurona,

así como las interacciones eléctricas que tienen lugar entre ellas. La ecuaciones utiliza-

das en la simulación se basan en el modelo eléctrico de Hodgkin y Huxley [GK02], que

4

1.2. OBJETIVOS

permite transformar el circuito neuronal en un circuito eléctrico.

Para llevar a cabo la simulación se utiliza el supercomputador Blue Gene[BGe]. Sus

8192 procesadores ejecutan en paralelo y se comunican a través del estándar MPI (Mes-

sage Passing Interface). Actualmente el tiempo de ejecución de una simulación es cien

veces mayor que el tiempo que una columna real necesitaría para propagar el estímulo

introducido. Las simulaciones generan una cantidad enorme de datos, sólo con el po-

tencial eléctrico de la membrana celular se producen del orden de cien gigabytes por

segundo simulado (muestreando a intervalos de 0,1 ms).

La visualización de estos datos no es trivial, así como tampoco lo es la divulgación.

Con este trabajo se espera facilitar esta labor, de manera que los científicos no tengan

que atender a cuestiones técnicas como el acceso a los datos o el proceso que conlleva

la generación de imágenes de alta calidad, y se centren en cuestiones propias de la

divulgación científica, como qué se quiere mostrar y por qué.

1.2. Objetivos

Como se ha mencionado anteriormente, el objetivo principal del proyecto es la

creación de imágenes, vídeos y películas 3D de alta calidad para comunicar los resul-

tados del BBP. Este objetivo se puede dividir en una serie de subobjetivos que se citan

a continuación:

Creación de un motor de renderizado que permita la generación de imágenes,

vídeos y películas 3D de alta calidad de los modelos y simulaciones neuronales

del BBP.

Diseño e implementación de una técnica que permita representar la información

de simulación mediante la asignación de color y transparencia a las neuronas

representadas.

Integración del motor de renderizado en la arquitectura software del BBP.

Proporcionar mecanismos sencillos de configuración del motor de renderizado

para permitir al usuario elegir entre distintas opciones de renderizado.

5


El término ‘motor de renderizado’ empleado en la descripción de los objetivos se

explica en la sección 2.1 del siguiente capítulo.

1.3. Estructura del documento

Además del capítulo de introducción, este documento contiene otros seis capítulos

estructurados de la siguiente forma:

Capítulo 2, Estado de la cuestión. Este capítulo se centra en describir el contex-

to del trabajo realizado. En primer lugar se incluye una terminología básica para

una mejor comprensión del documento. Seguidamente se ahonda en las apli-

caciones y algoritmos habitualmente utilizados en el campo de la informática

gráfica para la generación de imágenes de alta calidad. Por último se describen

las tecnologías y componentes software presentes en el BBP.

Capítulo 3, Planteamiento y solución del problema. En primer lugar se plan-

tean los problemas que se deben resolver para alcanzar los objetivos del proyec-

to. Una vez identificados dichos problemas, se presentan las soluciones adopta-

das, sin profundizar en aspectos técnicos. Seguidamente se muestra una com-

parativa del sistema antes y después del trabajo realizado, permitiendo conocer

qué componentes del ecosistema de software del BBP han sido afectados y cuáles

han sido creados como consecuencia de dicho trabajo.

Capítulo 4, Proceso de desarrollo. Se explica el proceso de desarrollo llevado a

cabo, dividido en las fases de requisitos, diseño, implementación y pruebas.

Capítulo 5, Resultados. Se comparan tres métodos utilizados para la representa-

ción de la información de simulación, centrándose en los aspectos de consumo

de memoria y tiempo empleado. También se muestran imágenes generadas con

distintas opciones de renderizado.

Capítulo 6, Conclusiones. En este capítulo se reflexiona sobre el trabajo realiza-

do en el ámbito técnico y personal. Finalmente se incluyen algunas líneas futuras

que se abren tras la realización del proyecto.

6

1.3. ESTRUCTURA DEL DOCUMENTO

Capítulo 7, Apéndice. Se incluye un manual de instalación, configuración y uso

del motor de renderizado.

7

Capı́tulo 2ESTADO DE LA CUESTIÓN

Índice2.1. Terminología básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2. Técnicas de renderizado de alta calidad . . . . . . . . . . . . . . . . . . 12

2.2.1. REYES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2. Trazado de rayos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3. Aplicaciones para el renderizado de alta calidad . . . . . . . . . . . . . 19

2.3.1. Mental ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2. RenderMan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.3. Autodesk Maya . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.4. Autodesk 3ds Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.5. Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.6. POV-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4. Arquitectura software del BBP . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.1. Tecnologías y herramientas empleadas en el BBP . . . . . . . . . 25

2.4.1.1. CMake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.1.2. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1.3. Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4.1.4. Técnicas de envoltorio C++/Python . . . . . . . . . . . . 27

2.4.1.4.1. SWIG . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.1.4.2. Boost Python . . . . . . . . . . . . . . . . . . . . 28

9

CAPÍTULO 2. ESTADO DE LA CUESTIÓN

2.4.1.5. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1.6. OmniORB . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.2. BBP-SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.3. BlueHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.3.1. BlueHubCore . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.3.2. BlueHubClient . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4.3.3. MovieProducer . . . . . . . . . . . . . . . . . . . . . . . . 35

En este capítulo se describen las técnicas y aplicaciones utilizadas para la genera-

ción de imágenes de alta calidad. También se explica el ecosistema software existente

en el BBP, describiendo las tecnologías y aplicaciones presentes en el mismo.

2.1. Terminología básica

A lo largo del documento se mencionan términos empleados en computación grá-

fica. En esta sección se incluyen las definiciones de esos términos para una mayor com-

prensión. Las fuentes bibliográficas utilizadas para las definiciones son [Fer07], [3Da],

[Mv96] y [Wik10g].

Aliasing : Efecto indeseable que se produce cuando una señal de cualquier clase

se muestrea (espacial o temporalmente) a una frecuencia inferior a la requerida

para conservar la información de las frecuencias más altas. Tiene relación con el

teorema de muestreo de Nyquist-Shannon [Wik10h]. En el caso de los gráficos

por ordenador este efecto se produce en los bordes de los objetos y las líneas,

dando lugar a la aparición de un dentado o pixelado característico.

Anti-aliasing : Técnicas que tratan de minimizar el impacto del aliasing en la

calidad final una imagen.

Caja circunscrita: Es la caja de menor tamaño que envuelve un conjunto de pun-

tos en un espacio tridimensional.

Frame: Imagen particular dentro de una sucesión de imágenes que componen

una animación.

10

2.1. TERMINOLOGÍA BÁSICA

Mallado poligonal: Un mallado poligonal, o simplemente mallado, es una colec-

ción de vértices, aristas y caras que definen la superficie de un objeto poliédrico.

Motor de renderizado: Software que se encarga de la generación de imágenes de

escenas 3D.

NURBS: Acrónimo del inglés Non Uniform Rational B-Splines. Es un modelo ma-

temático utilizado para generar y representar curvas y superficies.

Píxel: Menor unidad posible con la que se compone cualquier imagen digital.

Primitiva: Elemento que se utiliza para describir los objetos geométricos que

forman la escena. Para una escena particular, se llaman primitivas porque son

los elementos geométricos más simples que se usan para representarla.

RGB: Modelo de color que permite representar un color mediante la mezcla de

los tres colores de luz primarios: rojo (R-Red), verde (G-Green) y azul (B-Blue).

RGBA: Extensión del modelo de color RGB al que se añade un valor alfa (A-Alpha)

para la gestión de la opacidad.

Renderizar: En el ámbito de gráficos 3D, se refiere al proceso computacional de

síntesis de imágenes 2D.

Shader: Programa utilizado para realizar transformaciones geométricas y/o de-

terminar las propiedades de la superficie de un objeto virtual en alguna etapa de

su proceso de renderizado.

Textura: Una textura es un vector o matriz de valores utilizados para aplicar, ge-

neralmente, color o alguna otra propiedad a la superficie de un objeto virtual

durante su renderizado. Existen cuatro tipos de texturas:

• Textura 1D: Textura que tiene una sola dimensión (vector de colores). Este

tipo de textura se suele emplear para transformar propiedades escalares de

la superficie en un gradiente de color sobre el objeto.

11


• Textura 2D: Son las texturas que más se emplean. Pueden ser cuadradas

o rectangulares, y pueden representar un patrón a repetir, como un trozo

de pared o de césped, o ser una imagen completa, como un cuadro o una

ventana.

• Textura 3D: Son mapas de bits que almacenan un valor en cada celda en la

que se divide un volumen. Normalmente las celdas, también denominadas

voxels, son de forma cúbica y el volumen se subdivide de manera regular.

Este tipo de texturas consumen bastante memoria, por lo que se suelen uti-

lizar técnicas de compresión para reducir su tamaño. Se utilizan en deter-

minadas aplicaciones como el renderizado volumétrico o el uso de mapas

de luz para iluminar la escena ya que ofrecen ventajas sobre las texturas de

una y dos dimensiones.

• Texturas procedurales: Son texturas generadas matemáticamente por un

algoritmo y por lo tanto no se almacenan en el disco duro. Este tipo de tex-

turas normalmente requieren que un shader incluya el algoritmo de gene-

ración de los valores.

2.2. Técnicas de renderizado de alta calidad

2.2.1. REYES

REYES [RLCC87] es un algoritmo utilizado para renderizar imágenes de alta cali-

dad, comúnmente empleado en la industria cinematográfica. La palabra REYES es un

acrónimo de Renders Everything You Ever Saw (Renderiza todo lo que has visto). Este

algoritmo fue desarrollado en los años 80 por el equipo de Lucas Film que más tarde

formaría la compañía Pixar.

La arquitectura de REYES intenta cumplir una serie de requisitos (la mayoría de los

cuales responden a limitaciones del hardware de la época):

Soporte para modelos complejos y diversos: Para generar imágenes realistas los

usuarios de un sistema de renderizado necesitan tener libertad para modelar es-

tructuras geométricas complejas.

12

2.2. TÉCNICAS DE RENDERIZADO DE ALTA CALIDAD

Permitir técnicas de sombreado complejas: La mayor parte de la complejidad vi-

sual en una escena radica en el modo en que los rayos de luz interaccionan con

las superficies de los objetos sólidos. Normalmente, en computación gráfica, esto

se modela utilizando texturas. REYES permite a los usuarios incorporar shaders

a través de los cuales se implementa la estructura de las superficies y su inter-

acción con la luz mediante algoritmos matemáticos (texturas procedurales). De

este modo se consigue minimizar el tiempo empleado por los procesadores para

acceder a las texturas en memoria.

Reducir el uso de trazado de rayos: En el momento que REYES fue publicado, los

sistemas informáticos tenían menor capacidad de proceso y almacenamiento.

Trazar rayos a través de una escena llevaba decenas o cientos de horas por pí-

xel. Algoritmos como REYES, que no realizan trazados de rayos, ejecutaban más

rápido.

Velocidad: El tiempo empleado en generar las imágenes debe ser razonable (den-

tro los plazos de entrega de la industria cinematográfica).

Alta calidad de imagen: El proceso de renderizado debe reducir significativamen-

te el aliasing u otro tipo de errores en la imagen final.

Flexibilidad: La arquitectura debe ser lo suficientemente flexible como para in-

corporar nuevas técnicas, sin necesidad de reimplementar completamente el al-

goritmo.

En REYES los objetos están normalmente modelados con primitivas tipo NURBS o su-

perficies con subdivisión recursiva. Estas primitivas se renderizan dividiéndolas en mi-

cropolígonos, pequeños cuadriláteros cuyo tamaño óptimo se sitúa en torno a medio

píxel. Aunque se necesitan muchos micropolígonos para aproximar las superficies de

las curvas con precisión, éstos se procesan utilizando simples operaciones en parale-

lo. El algoritmo REYES divide, bajo demanda, las primitivas de alto nivel en primitivas

más pequeñas, repitiendo el proceso tantas veces como sea necesario para conseguir

una apariencia suave en la imagen final. Cada una de las primitivas resultantes se divi-

de, a su vez, en micropolígonos. Tras realizar la división de las primitivas, el sistema de

sombreado asigna un color y opacidad a cada micropolígono. Tal y como se contempla

13


en la arquitectura, el algoritmo permite al usuario asignar funciones de iluminación

y aplicar texturas escritas en un lenguaje de sombreado mediante el uso de shaders.

Finalmente, cada micropolígono sombreado se muestrea para calcular cuál es su con-

tribución en aquellos píxeles que lo contienen, y así producir la imagen final.

Más detalladamente, cada primitiva pasa por las siguientes etapas:

Bound: Se comprueba la caja circunscrita de cada primitiva, para ver si es visible

en pantalla.

Split: Si una primitiva es muy grande, se divide en otras más sencillas, y se vuelve

a realizar el test de “Bound”.

Dice: Se divide la primitiva en un conjunto de micropolígonos.

Shade: Se calcula la iluminación y sombreado del conjunto de micropolígonos.

Bust: Se comprueba la visibilidad y se realiza el test de “Bound” para cada micro-

polígono del conjunto.

Hide: Se muestrean los micropolígonos, generando la imagen final.

En la figura 2.1 se representa un resumen del algoritmo REYES.

14


Figura 2.1: Resumen del algoritmo REYES

2.2.2. Trazado de rayos

Trazado de rayos (o ray tracing) [Mas],[Mac08] es otra técnica para el renderizado

de alta calidad. Fue propuesta inicialmente en 1980 por Turner Whitted y está basada

en un algoritmo de determinación de superficies visibles llamado ray casting [Mac08]

creado en 1968 por Arthur Appel.

Esta técnica consigue producir efectos de gran realismo, pero con un alto coste

computacional. Esto hace del trazado de rayos un algoritmo adecuado para aplica-

ciones donde el tiempo empleado en renderizar no es el aspecto más importante, por

ejemplo, aplicaciones para crear efectos especiales en cine o publicidad. El trazado de

rayos es capaz de simular una amplia variedad de efectos ópticos, tales como la refle-

xión, refracción o dispersión de la luz.

La idea básica del trazado de rayos consiste en imitar el modo en que los rayos

15


de luz interactúan con las superficies en la naturaleza. En el mundo real una fuente

de luz emite rayos luminosos que viajan hasta chocar con una superficie. Se podría

pensar que un rayo es como un chorro de fotones que viajan a través de la misma ruta.

Cuando la luz alcanza una superficie se puede producir cualquier combinación de los

siguientes fenómenos: absorción, reflexión, refracción y fluorescencia.

De esta manera, un rayo de luz se puede ver reflejado parcial o totalmente en una

o más direcciones. También puede ocurrir que parte de la luz sea absorbida, dando

lugar a una pérdida en la intensidad del rayo reflejado o refractado. En el caso de que la

superficie sea transparente o translúcida, una porción del rayo de luz se refracta. Con

menor frecuencia puede ocurrir que una superficie fluorescente absorba parte de la

luz y vuelva a emitirla con una longitud de onda distinta. A partir de aquí, los rayos

reflejados y/o refractados pueden golpear otras superficies, que con sus propiedades

de absorción, refracción, reflexión y fluorescencia afectan de nuevo al progreso de la

luz. Finalmente, algunos de estos rayos alcanzan nuestros ojos permitiéndonos ver la

escena.

El algoritmo de determinación de superficies visibles ray casting funciona de ma-

nera inversa al flujo de luz en la naturaleza, es decir, en vez de seguir el camino de la

luz de la fuente al observador, éste consiste en lanzar rayos desde el observador hacia

la escena a través del plano de la imagen. Se traza un rayo por píxel, y se calculan las

intersecciones de cada rayo con los objetos de la escena. El objeto más cercano que

se interpone en el camino del rayo es el que se ve a través de ese píxel. Utilizando las

propiedades del material y de la luz procedente de las fuentes de luz de la escena (di-

rección, intensidad, etc.), el algoritmo calcula el sombreado para ese objeto en dicho

píxel.

El algoritmo de ray casting traza rayos desde el observador hacia la escena, pero

una vez los rayos alcanzan un objeto, éstos no proyectan más lejos. Whitted mejoró

el algoritmo continuando el viaje que un rayo realiza a través de la escena. Dicha va-

riante se conoce como trazado de rayos de tipo Whitted. En este algoritmo, cuando un

rayo alcanza una superficie, se pueden generar hasta 3 tipos de rayos nuevos: reflexión,

refracción y sombra.

En materiales reflectantes, un rayo reflejado continúa en la dirección que deter-

mina el ángulo de reflexión respecto a la normal de la superficie. A continuación,

16


el algoritmo se aplica recursivamente al rayo reflejado.

Los rayos de refracción viajan a través de materiales transparentes. Éstos se eva-

lúan utilizando la ley de Snell, teniendo en cuenta que un rayo refractado puede

estar entrando o saliendo de un material.

Para evitar trazar todos los rayos en la escena, se utilizan rayos de sombra. Éstos

evalúan si una determinada superficie está iluminada o no. Cuando un rayo al-

canza una superficie se traza una línea para cada fuente de luz que va desde el

punto de impacto hasta dicha luz. Si se encuentra algún objeto opaco en la línea

que une el punto y la luz, la superficie está en sombra, por lo que esa fuente de

luz no contribuye a su sombreado. Esta nueva comprobación añade sombras a

los objetos de la escena, incrementando el realismo que se puede obtener con

respecto a la versión básica de REYES.

En la figura 2.2 se muestra el trazo de un rayo de sombra durante la ejecución del

algoritmo.

Figura 2.2: Rayo de sombra durante el trazado de rayos

17


Al igual que en el algoritmo REYES, con trazado de rayos también se permite pro-

gramar los sombreados de las superficies mediante el uso de shaders. De esta mane-

ra, es posible asignar distintos materiales a los objetos que componen la escena. Los

shaders calculan el color de un determinado píxel en función de la luz incidente y las

propiedades del material (funciones del shader).

La finalización del algoritmo está determinada por el número máximo de veces que

un rayo puede ser reflejado y refractado (parámetros de entrada del trazador de rayos),

así como por el coeficiente de absorción de los objetos alcanzados por los rayos.

A continuación se muestra en pseudo-código el algoritmo estándar de trazado de

rayos.

Para cada píxel de la imagen {Crear un rayo desde el punto de visión a través del píxelActualInicializar NearestT a INFINITO y NearestObject a NULLPara cada objeto de la escena {

Si el rayo intercepta el objetoActual {Si t de la intersección es menor que NearestT {

Poner NearestT = t de la intersecciónPoner NearestObject = objetoActual

}}

}Si NearestObject = NULL {

Rellenamos píxelActual con el color de fondo}Sino {

Lanzar un rayo a cada foco de luz para comprobar las sombrasSi la superficie es reflectiva, generar un rayo reflectivo (recursivo)Si la superficie es transparente, generar un rayo refractante (recursivo)Usar NearestObject y NearestT para computar la función de sombreadoRellenar este píxel combinando los resultados de la función de sombreadolocal, el rayo reflejado y el reflectado

}}

Actualmente el algoritmo estándar de trazado de rayos se extiende con otras técni-

cas que permiten mejorar determinados aspectos de su ejecución y/o simular de forma

más realista ciertos fenómenos naturales. Algunas de estas extensiones al algoritmo es-

tándar son: trazado de rayos de distribución, radiosidad, métodos de Montecarlo, path

tracing y photon mapping.

18

2.3. APLICACIONES PARA EL RENDERIZADO DE ALTA CALIDAD

2.3. Aplicaciones para el renderizado de alta calidad

2.3.1. Mental ray

Mental ray [MRa], [Wik10f] es un software multiplataforma que genera imágenes

de alta calidad utilizando trazado de rayos como algoritmo de renderizado principal.

Se trata de una herramienta muy utilizada en la industria cinematográfica: películas

como Hulk, Matrix o Star Wars han hecho uso de esta aplicación.

Sus características más importantes son:

Posee un alto rendimiento. Para ello emplea sistemas multiprocesador y granjas

de renderizado (varios ordenadores realizan el trabajo en paralelo). Este software

utiliza técnicas de aceleración como scanline para la determinación de superfi-

cies visibles y estructuras de datos tipo BSP (Binary Space Partitioning o parti-

ción binaria del espacio) o kd-tree para acelerar los test de intersección de rayos

secundarios.

Mental ray fue diseñado para ser utilizado como un programa independiente.

El formato de escena “.mi” permite el renderizado en segundo plano. Además

Mental ray puede ser integrado en otra aplicación usando una API (Application

Programming Interface) o interfaz de programación de aplicaciones. A día de hoy

existen algunos programas que integran este motor de renderizado, tales como

Autodesk Maya, 3D Studio Max o AutoCAD. Muchas de estas aplicaciones pro-

porcionan su propia biblioteca de shaders. Sin embargo, asumiendo que estos

shaders están disponibles en Mental ray, cualquier fichero “.mi” puede ser ren-

derizado por Mental Ray, sin tener en cuenta el software que lo generó.

Mental ray permite programar shaders personalizados en C o C++. Los shaders

se compilan como bibliotecas dinámicas (o plugins) que se cargan en tiempo de

ejecución.

Proporciona soporte para múltiples primitivas geométricas. Entre ellas se inclu-

yen polígonos, NURBS y curvas de Bézier (curvas definidas usando puntos de

control).

19


2.3.2. RenderMan

RenderMan [RMa], [Wik10k] es un software multiplataforma de renderizado que

genera imágenes de alta calidad utilizando el algoritmo REYES. También incorpora el

algoritmo de trazado de rayos para renderizar partes de una escena que requieren efec-

tos de iluminación específicos. Se utiliza principalmente en la industria cinematográ-

fica. Algunas de las películas generadas con este motor de renderizado son Ratatouille,

Wally-E y Cars.

Sus componentes y características más importantes son:

RISpec (RenderMan Interface Specification), una API escrita en C utilizada para

describir la escena y transferir dicha descripción a un programa de renderizado.

También permite el acceso desde los lenguajes de programación Python, Ruby y

Lua.

RIB (RenderMan Interface Bytestream Protocol), formato de fichero usado para

almacenar la información de la escena (datos del modelo, luces, cámaras, sha-

ders, atributos y opciones) que se le pasa al motor de renderizado de Render-

Man. Permite al cliente de Renderman Interface enviar solicitudes a un servicio

de renderizado remoto o almacenar las peticiones en un fichero “.rib” y lanzar la

solicitud más tarde.

Renderman también dispone de un lenguaje para implementar shaders, RSL (Ren-

derman Shading Language). Su sintaxis es parecida a C y se definen 5 tipos de

shaders: surface, light, volume, imager y displacement shaders.

Tiene soporte para múltiples primitivas tales como polígonos, NURBS y Béziers.

Múltiples aplicaciones de modelado 3D incluyen herramientas para exportar las

escenas a un formato RIB que permite el renderizado con RenderMan. Además,

RenderMan se puede integrar en dichas aplicaciones mediante el uso de su API.

2.3.3. Autodesk Maya

Autodesk Maya [May], [Wik10b] es una aplicación software multiplataforma utiliza-

da en animación, modelado 3D, simulación, efectos visuales, renderizado y composi-

20


ción. Maya se usa en la industria televisiva y cinematográfica, así como en videojuegos

y en diseño y visualización de modelos arquitectónicos. Muchas películas de anima-

ción se han creado con Maya. Algunas de ellas son Ice Age: La edad de hielo, Resident

Evil o Avatar.


Posee un SDK (Software Development Kit) o kit de desarrollo software que per-

mite, por ejemplo, cambiar la apariencia estándar de la interfaz utilizando sólo

el núcleo. Esta característica hace que grandes estudios utilicen Maya con un có-

digo personalizado para sus producciones.

A bajo nivel, Maya es una base de datos que almacena información gráfica. Es-

ta base de datos se llama grafo de dependencias o DG (Dependency Graph). La

información en el DG se guarda en un conjunto de objetos llamados nodos. Los

nodos tienen una serie de propiedades, llamadas atributos, que guardan las ca-

racterísticas de cada nodo. Atributos del mismo tipo se pueden conectar, permi-

tiendo el flujo de datos de un nodo a otro. Existen atributos de entrada, de salida

y de entrada/salida.

Maya utiliza redes de sombreado para configurar el sombreado de la escena. Una

red de sombreado es una colección de nodos que conectan sus atributos y que

definen cómo los colores, las propiedades de los materiales y las texturas con-

tribuyen al resultado final de las superficies. El conjunto de materiales, texturas

y luces que describen todos los atributos requeridos para sombrear o renderi-

zar una imagen se denomina grupo de sombreado. La construcción de la red de

sombreado es de vital importancia, ya que su diseño influye directamente en el

consumo de memoria y tiempo de renderizado.

El SDK define una API que se puede usar desde C++ y Python. Esta API ofrece

acceso a todos los elementos de la escena y permite la creación de nuevos ti-

pos de nodos, shaders, manipuladores, exportadores e importadores de ficheros

y demás funcionalidades de Maya.

Maya permite el uso de NURBS, polígonos y superficies con subdivisión recursi-

va. También incluye la posibilidad de realizar conversiones entre todos los tipos

21


de geometría.

Posee su propia colección de shaders.

Maya tiene un lenguaje de scripting integrado, llamado MEL (Maya Embedded

Language), similar a Perl. MEL ofrece un fácil acceso y control de la interfaz grá-

fica. Algunas de las opciones avanzadas sólo son accesibles a través de MEL. To-

dos los comandos, preferencias, barras de herramientas y menús están escritos

en este lenguaje. MEL no es orientado a objetos, por lo que es imposible crear

clases y métodos como en C++ o Python. Esto lo hace más accesible y fácil de

comprender para usuarios de Maya y programadores no experimentados.

Maya soporta dos formatos de escena, uno binario “.mb” y otro ASCII “.ma”. El

formato ASCII permite leer y editar la escena con cualquier editor de textos, guar-

dándose la escena como secuencias de operaciones MEL.

Esta aplicación permite la integración de diferentes motores de renderizado me-

diante el uso de su API. Mental ray o Renderman son algunos de esos motores.

2.3.4. Autodesk 3ds Max

Anteriormente conocido como 3D Studio Max, Autodesk 3ds Max[3ds], [Wik10a] es

un programa de modelado, animación y renderizado que sólo funciona en la platafor-

ma Microsoft Windows. Al igual que las aplicaciones anteriores, se utiliza ampliamente

en la industrias del videojuego y del cine, así como en estudios de arquitectura. Varios

son los videojuegos y películas que han utilizado este software, entre otros Splinter Cell

y Spider-Man 3.


Al igual que Maya, Autodesk 3ds Max posee su propio lenguaje de scripting. Éste

puede ser usado para automatizar tareas repetitivas, combinar las funcionalida-

des existentes o desarrollar nuevas herramientas e interfaces. También es posible

crear plugins usando este lenguaje.

Esta aplicación permite el uso de diferentes primitivas para describir la escena.

Entre ellas cabe destacar el modelado con polígonos y NURBS.

22


Su API puede ser utilizada para integrar diferentes motores de renderizado. Men-

tal ray o Renderman son algunos de los motores que se pueden utilizar.

Ofrece un SDK mediante una instalación opcional que permite extender o im-

plementar cualquier aspecto de la aplicación utilizando el lenguaje de progra-

mación C++.

Tiene una serie de shaders predefinidos.

2.3.5. Blender

Blender [Ble] es un software multiplataforma dedicado al modelado, animación y

renderizado. A diferencia de todos los anteriores, que son aplicaciones comerciales,

Blender se distribuye bajo la licencia GNU (General Public License).


Tiene una API escrita en Python que permite acceder y modificar los elementos

de la escena, así como extender las funcionalidades de la aplicación.

Trabaja con diversas primitivas geométricas, tales como NURBS, polígonos o Bé-

ziers.

Ofrece la posibilidad de integrar motores de renderizado gratuitos basados en

trazado de rayos, como kerkythea, POV-Ray, YafRay o Yafrid.

En comparación con otras aplicaciones del mismo tipo, Blender requiere me-

nos espacio para su instalación. Sus requisitos hardware (procesador y memoria)

también son menores.

Por defecto, es posible utilizar shaders para el sombreado de los objetos de la

escena.

2.3.6. POV-Ray

POV-Ray [POV], [Wik10i] es un software multiplataforma de renderizado que utiliza

el algoritmo de trazado de rayos. Se distribuye bajo la licencia POV-Ray, la cual permite

la libre distribución del código fuente y binarios, pero restringe su uso comercial.

23



El código fuente es accesible. Esto es especialmente útil para aprender cómo fun-

ciona el trazado de rayos.

Existen gran cantidad de recursos para POV-Ray disponibles en la web: herra-

mientas, texturas, modelos, escenas y tutoriales.

Además de las primitivas geométricas estándar, POV-Ray ofrece la posibilidad de

describir matemáticamente curvas usando polinomios, fractales y demás fórmu-

las matemáticas. Esto difiere de la mayor parte de aplicaciones de modelado 3D,

que usan mallados de triángulos para componer los objetos. La ventaja de este

sistema de descripción de primitivas es que no se requieren multitud de polí-

gonos para describir un objeto. Por otra parte, este método no es práctico para

crear objetos complejos como coches o personajes de animación. Éstos han de

crearse en entornos basados en mallados y luego ser convertidos en el formato

de mallado de POV-Ray.

POV-Ray no dispone de una herramienta para modelar los objetos de la escena.

Por lo tanto, es necesario crear los objetos utilizando aplicaciones de modelado

externas y exportar los mallados a un formato POV-Ray.

POV-Ray interpreta ficheros ASCII de extensión “.pov” en los que se describen la

posición y los parámetros de los elementos de la escena (luces, cámaras y obje-

tos).

Soporta un ligero lenguaje informático similar al lenguaje C que permite realizar

tareas complejas con los objetos.

2.4. Arquitectura software del BBP

En esta sección se muestran las tecnologías, herramientas y aplicaciones presentes

en el BBP.

24

2.4. ARQUITECTURA SOFTWARE DEL BBP

2.4.1. Tecnologías y herramientas empleadas en el BBP

2.4.1.1. CMake

CMake [CMa], [Wik10d] es una herramienta multiplataforma para la automatiza-

ción del proceso de compilación de proyectos de sotftware que utiliza ficheros de con-

figuración independientes de la plataforma y el compilador. CMake permite compilar

código fuente, crear bibliotecas estáticas y dinámicas, generar documentación y crear

ejecutables. Esta herramienta está diseñada para permitir complejas jerarquías de di-

rectorio y aplicaciones dependientes de varias bibliotecas.

Los ficheros de configuración, llamados CMakeLists.txt, se utilizan para generar

instrucciones de compilación para los entornos de desarrollo que soporta (como Ma-

kefiles en Unix o soluciones para MS Visual Studio). Esto facilita el mantenimiento y

elimina la necesidad de tener varios conjuntos de ficheros para cada plataforma. Cada

fichero de configuración está compuesto por uno o más comandos. CMake tiene varios

comandos predefinidos, pero también permite la creación de comandos personaliza-

dos.

Sus principales características son:

Ficheros de configuración escritos en un lenguaje de scripting específico para

CMake.

Soporte para compilaciones en diversas plataformas (UNIX, Microsoft Windows

y Mac OS X) y distintos entornos de desarrollo/compilación (GNU make, Xcode,

Microsoft Visual Studio, etc.)

Análisis automático de dependencias para C, C++, Fortran y Java.

Amplia colección de módulos para facilitar el uso de una gran variedad de herra-

mientas y bibliotecas habituales (Qt, Boost, doxygen, SWIG, etc.)

Soporte para varias versiones de Microsoft Visual Studio.

Vista global de todas las dependencias, usando CMake para generar un diagra-

ma.

25


2.4.1.2. Qt

Qt [Qt], [Wik10j] es una biblioteca multiplataforma utilizada principalmente para

el desarrollo de interfaces gráficas de usuario aunque también puede usarse para el

desarrollo de programas multiplataforma sin interfaz gráfica, como aplicaciones con

interfaces de línea de mandatos. Qt es de código abierto y se distribuye bajo varias

licencias, GNU LGPL entre ellas.

La biblioteca está implementada en C++, pero se puede utilizar también en otros

lenguajes de programación a través de enlaces o “envoltorios” (adaptaciones de biblio-

tecas para ser usadas en un lenguaje de programación distinto de aquél en el que han

sido escritas). Qt ofrece múltiples funcionalidades, entre ellas cabe destacar el acceso

a bases de datos mediante SQL, el uso de XML, la gestión de threads, el soporte de red

y una API multiplataforma para la manipulación de archivos.

2.4.1.3. Boost

Boost [Sch10], [Wik10c] es un conjunto de bibliotecas multiplataforma escritas en

C++ que extienden las funcionalidades de ese lenguaje de programación. Se distribu-

yen bajo una licencia BSD, que permite su utilización en cualquier tipo de proyecto, ya

sea comercial o no.

El diseño e implementación de las bibliotecas de Boost posibilita su uso en una

amplia gama de aplicaciones. Boost contiene desde bibliotecas de propósito general

hasta bibliotecas que implementan abstracciones del sistema operativo. Para asegurar

la eficiencia y flexibilidad, se utilizan frecuentemente plantillas, mecanismos de pro-

gramación genérica que permiten que una clase o función trabaje con tipos de datos

abstractos.

La implementación actual de Boost contiene 80 bibliotecas individuales, incluyen-

do bibliotecas para álgebra lineal, generación de números pseudo-aleatoria, progra-

mación concurrente, procesamiento de imágenes, expresiones regulares y pruebas uni-

tarias entre otras. La mayor parte de las bibliotecas de Boost están basadas en ficheros

de cabecera, funciones en línea y plantillas.

26


2.4.1.4. Técnicas de envoltorio C++/Python

Las técnicas de envoltorio (o wrapping en inglés) [SWI] C++/Python permiten “in-

crustar” código Python en C++ o “envolver” código C++ para ser utilizado en Python.

Al “envolver” código C++ se genera una biblioteca dinámica que puede ser cargada por

el intérprete de Python.

Existen principalmente tres razones para “incrustar” Python en una aplicación C/C++:

La aplicación se puede desarrollar más rápidamente, utilizando Python en lugar

de C/C++.

Se puede dotar de extensibilidad o de un intérprete a la aplicación en tiempo de

ejecución.

Incluso si el producto final no va a contener Python, este puede ser útil para es-

cribir scripts que prueben la aplicación.

Existen varios motivos para crear bibliotecas dinámicas que puedan ser cargadas

en Python, entre ellos cabe destacar:

Proveer acceso a una biblioteca C++ que no tiene equivalente en Python.

Escribir primero el programa completo en Python, y después de analizar el com-

portamiento, reescribir en C++ la parte del código en la que el rendimiento sea

un aspecto crítico.

Python facilita la escritura de pruebas de unidad del código C++, mejorando la

eficacia de las mismas.

2.4.1.4.1. SWIG SWIG (Simplified Wrapper and Interface Generator) [SWI], [Wik10l]

es un software de código abierto utilizado para conectar programas o bibliotecas es-

critas en C/C++ con lenguajes de scripting como Tcl, Perl, Python, Ruby, PHP, Lua, R y

otros lenguajes como Java, C#, Scheme y Ocaml. El objetivo es lograr la conexión en-

tre programas y lenguajes de scripting con el mínimo esfuerzo. Para ello se añaden un

pequeño número de directivas a las cabeceras de los ficheros C/C++ que SWIG ana-

liza sintácticamente para crear un código fuente que permite el enlace entre C/C++ y

27


el correspondiente lenguaje. Dado que cada lenguaje tiene sus particularidades y, nor-

malmente, su conjunto de características no se corresponde con el de C/C++, existen

directivas específicas de lenguaje para llevar a cabo conversiones de tipos, tratamiento

de plantillas, sobrecarga, etc.. Dependiendo del lenguaje, el enlace puede ser de dos

formas:

Una biblioteca dinámica que un intérprete carga como un módulo de extensión.

Una biblioteca dinámica que se carga desde otros programas compilados en el

lenguaje objetivo.

2.4.1.4.2. Boost Python La biblioteca Boost Python [AGK03] es un miembro de la

colección de bibliotecas Boost que permite enlazar los lenguajes de programación C++

y Python. Esta biblioteca exporta funciones y objetos de C++ a Python y viceversa sin

utilizar herramientas adicionales, sólo el compilador de C++. Está diseñada para “en-

volver” interfaces de C++ sin necesidad de cambiar el código, haciendo de Boost Py-

thon ideal para exportar bibliotecas de terceros a Python. La biblioteca utiliza planti-

llas (técnicas avanzadas de metaprogramación) para simplificar su sintaxis, por lo que

el código de envoltura se parece a un IDL (Interface Definition Language).

2.4.1.5. CORBA

CORBA (Common Object Request Broker Architecture) [SK00], [Wik10e] es una ar-

quitectura estándar que establece una plataforma de desarrollo de sistemas distribui-

dos facilitando la invocación de métodos remotos bajo un paradigma orientado a ob-

jetos. El OMG (Object Management Group) es el responsable de definir las APIs, el pro-

tocolo de comunicaciones y los mecanismos necesarios para permitir la interopera-

bilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en

diferentes plataformas.

En términos generales, CORBA empaqueta el código escrito en un determinado

lenguaje y añade información adicional sobre las capacidades del mismo y cómo lla-

mar a sus métodos. Los objetos que resultan se pueden invocar desde otro programa

(u objeto CORBA) a través de la red utilizando el protocolo estándar de CORBA cono-

cido como IIOP (Internet Inter-ORB Protocol). CORBA utiliza el término ‘servant’ para

28


hacer referencia a un objeto, en el lenguaje de programación del servidor, que contiene

los métodos para manejar las invocaciones remotas del objeto CORBA. Por lo tanto, un

servant no es un objeto CORBA, sino un representante del mismo.

La especificación de CORBA también establece la existencia de un ORB (Object Re-

quest Broker), una capa de software intermedia o middleware. El ORB implementa la

solicitud al objeto remoto: localiza el objeto en la red, comunica la solicitud, espera los

resultados y los envía al cliente cuando estén disponibles. Este mecanismo de solici-

tudes es transparente al cliente ya que las peticiones al objeto CORBA se realizan con

independencia de su localización. El cliente que realiza la petición puede estar escri-

to en un lenguaje de programación diferente y ejecutar en una arquitectura distinta a

la implementación del objeto CORBA. El ORB realiza las traducciones necesarias para

que la comunicación sea posible.

La clave de la portabilidad de CORBA radica en el IDL (Interface Definition Langua-

ge) que es el lenguaje que se utiliza para definir las interfaces de los objetos que los

clientes utilizan. Mediante el IDL se pueden escribir interfaces independientes de la

plataforma, describiendo los tipos de datos y métodos. El estándar de CORBA especi-

fica cómo una interfaz IDL se traduce a un lenguaje determinado, describiendo cómo

los tipos de datos CORBA deben ser utilizados en las implementaciones del cliente y

del servidor. Existen implementaciones estándar para Ada, C, C++, Smalltalk, Java, Py-

thon, Perl y Tcl.

Al compilar una interfaz se genera código para el cliente y el servidor. El código

del cliente o stub sirve para poder realizar las llamadas a métodos remotos a través de

un proxy o representante del objeto remoto en el lado del cliente. El código generado

para el servidor consiste en unos skeletons o esqueletos que se deben rellenar para

implementar los métodos del objeto.

En la figura 2.3 se muestra un esquema simplificado de la arquitectura de CORBA.

29


Figura 2.3: Arquitectura CORBA

2.4.1.6. OmniORB

Algunas de las aplicaciones del BBP utilizan OmniORB [Omn], un ORB que cum-

ple las especificaciones de la versión 2.6 de CORBA y que está disponible para C++ y

Python. Las bibliotecas y herramientas se distribuyen bajo los términos de la licencia

GNU. Algunas de sus características más importantes se muestran a continuación:

Permite el uso de IIOP 1.0, 1.1 y 1.2.

Multithread.

Soporte para el paso de objetos por valor.

Soporte para interfaces abstractas.

Soporte para IPv6.

Invocación dinámica.

Servicio de nombres, omniNames.

Flexible gestión de threads.

30


Multiplataforma.

Plenamente interoperable con otros ORBs de CORBA.

Soporte para SSL (Secure Socket Layer).

2.4.2. BBP-SDK

El BBP-SDK es una biblioteca multiplataforma escrita en C++ que ofrece una API

para el acceso a la información de los experimentos de simulación de circuitos cor-

ticales. A esta biblioteca se puede acceder desde los lenguajes de programación Java,

Python y Matlab.

Para acceder a toda la información relacionada con un experimento, tal como ma-

llados, circuitos e información de simulación, es necesario usar la clase Experiment del

API. El constructor de esta clase recibe como parámetro un fichero de configuración

donde se especifican las rutas de los ficheros que contienen toda esta información.

Los mallados representan la estructura geométrica de las neuronas. Un mallado

está formado por multitud de vértices que se conectan entre sí formando triángulos. La

API permite obtener los vértices que componen cada neurona así como sus triángulos,

permitiendo construir los mallados de las neuronas.

Un circuito es un conjunto de neuronas junto con su información de colocación

en el espacio y los contactos o sinapsis que se establecen entre ellas. La API permite

la carga selectiva de circuitos y subcircuitos (minicolumnas, capas, subpoblaciones de

determinado tipo de células, etc.), por lo que es posible enfocar los estudios en ciertas

regiones de la columna. También es posible la carga personalizada de un conjunto de

neuronas, para lo que se utiliza el identificador global de cada neurona.

Al microcircuito de la columna neocortical se accede a través de una capa de abs-

tracción orientada a objetos. El modelo de datos se organiza en objetos que reflejan

la estructura lógica y física de un microcircuito. De tal manera, es posible acceder a

neuronas individuales o partes de una neurona, como secciones y segmentos.

Una sección es un cable volumétrico y cilíndrico que forma parte de una rama y que

no posee ramificaciones entre sus extremos. En la API una sección se considera o bien

una neurita (una dendrita o parte de axón) o un soma. Las secciones están formadas

31


por uno o más segmentos. Un segmento representa un trozo de cable y se describe

utilizando dos puntos y el diámetro del cable que une esos dos puntos.

La información de simulación está presente en cada neurona y es accesible a través

de la clase Compartment o compartimento. Un compartimento es un trozo de sección

que representa una unidad mínima para la simulación, por tanto el voltaje o corriente

es idéntico a lo largo de todo un compartimento. No tiene por qué existir una corres-

pondencia uno a uno entre segmentos y compartimentos.

La figura 2.4, extraída de la documentación del BBP-SDK, muestra la clase que per-

mite el acceso a los datos del microcircuito y sus relaciones con las clases de más bajo

nivel.

Figura 2.4: Clase Microcircuit y sus relaciones con clases de más bajo nivel

Actualmente el modelo es de sólo lectura, y no se permite la modificación del mi-

crocircuito, la introducción de estímulos o el control de la simulación de la columna.

32


El diseño de alto nivel de la interfaz tiene un enfoque destinado a la investigación y

permite a los neurocientíficos trabajar con el modelo, ocultando los niveles de detalle

técnicos de la implementación de bajo nivel.

El diagrama esquemático representado en la figura 2.5 forma parte de la documen-

tación del BBP-SDK y muestra los niveles y relaciones entre las interfaces. Éstas permi-

ten un acceso jerárquico al experimento y a los componentes del modelo.

Figura 2.5: Niveles y relaciones entre las interfaces del BBP-SDK

Como se ha mencionado anteriormente, el modelo de datos es accesible a través

de ficheros. La API traduce la organización interna de los datos y permite su carga en

memoria. Es posible cargar y comparar varios experimentos y microcircuitos a la vez.

33


Además, determinados aspectos del microcircuito se pueden cargar por separado pa-

ra un uso más eficiente de la memoria. La reserva de memoria se gestiona haciendo

uso de los punteros “inteligentes” de la biblioteca Boost, lo que permite que la recolec-

ción de basura sea automática y se reduzcan los posibles errores de programación. La

biblioteca está documentada con códigos de ejemplo, instrucciones de compilación y

una referencia generada automáticamente a partir del código por medio de la aplica-

ción Doxygen.

El BBP-SDK también implementa interfaces CORBA que permiten el acceso a algu-

na de sus clases a través de CORBA. Esto es especialmente útil para aplicaciones que

accedan remotamente a la información del BBP. Además, una parte de la API expone

un intérprete de Python incrustado que permite ejecutar código Python enviando las

sentencias como cadenas de texto y recibir la salida generada también como cadena

de texto.

Con todas estas funcionalidades, la API permite la creación de aplicaciones para el

análisis de los datos o la generación de imágenes.

2.4.3. BlueHub

BlueHub es una aplicación escrita en C++ que permite la visualización de las neu-

ronas y la reproducción de la información de simulación mediante el uso diferentes

motores de renderizado. BlueHub utiliza el BBP-SDK para acceder a los metadatos de la

simulación y gestionar los distintos motores de renderizado. Tiene un modelo cliente-

servidor en el que la comunicación se lleva a cabo mediante el estándar CORBA. El

ORB utiliza la implementación de OmniORB.

2.4.3.1. BlueHubCore

Servidor de BlueHub. Recibe peticiones de clientes y genera las imágenes. Sus cla-

ses más importantes son:

RenderingEngine: Clase abstracta que contiene los métodos virtuales que todos

los motores de renderizado deben implementar.

Director: Esta clase es la encargada de controlar el flujo de ejecución en la ge-

neración de imágenes. Su bucle interno llama iterativamente a las funciones del

34


motor de renderizado hasta que termina la reproducción de la simulación. Tam-

bién es la encargada de cargar las bibliotecas dinámicas que contienen los mé-

todos de los motores de renderizado.

2.4.3.2. BlueHubClient

Cliente de BlueHub. Es una interfaz gráfica de usuario escrita en C++ que utiliza la

biblioteca Qt. Se utiliza para controlar remotamente el servidor durante la visualiza-

ción de los mallados e información de simulación en tiempo real.

2.4.3.3. MovieProducer

Es una aplicación escrita en C++ que sirve para la generación de películas e imáge-

nes. Hace las veces de cliente de BlueHub por lo que se comunica con BlueHubCore a

través de CORBA. El objetivo principal de esta aplicación es la generación de películas

de alta calidad de manera no interactiva. Por tanto, MovieProducer no tiene interfaz

gráfica, el usuario especifica las opciones de renderizado utilizando un fichero de con-

figuración. En el apéndice A.2 se explican las distintas opciones presentes en el fichero

de configuración de MovieProducer.

35

Capı́tulo 3PLANTEAMIENTO Y SOLUCIÓN DEL

PROBLEMA

Índice3.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.1. Objetivo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.2. Objetivo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.3. Objetivo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.4. Objetivo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2. Solución del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.1. Motor de renderizado . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.2. Objetivo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.3. Objetivo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.4. Integración del motor de renderizado . . . . . . . . . . . . . . . . 50

3.2.5. Objetivo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.6. Objetivo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.7. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . 56

En este capítulo se plantean primero los problemas que se deben resolver para al-

canzar los objetivos del proyecto. Una vez identificados dichos problemas, se presen-

tan las soluciones adoptadas.

37

CAPÍTULO 3. PLANTEAMIENTO Y SOLUCIÓN DEL PROBLEMA

3.1. Planteamiento del problema

3.1.1. Objetivo 1

Creación de un motor de renderizado que permita la generación de imágenes, vídeos y

películas 3D de alta calidad de los modelos y simulaciones neuronales del BBP.

La creación del motor de renderizado plantea tres problemas: cómo acceder e inter-

pretar los datos de los experimentos, cómo transformarlos en un modelo 3D adecuado

para su renderizado y cómo renderizar ese modelo.

La API del BBP-SDK proporciona el acceso a los datos del modelo y de las simula-

ciones llevadas a cabo en el Blue Gene. El motor de renderizado necesitará un acceso

ordenado y selectivo de los datos, en concreto, de los mallados e información de simu-

lación de las neuronas seleccionadas para el renderizado.

La representación del modelo 3D ha de llevarse a cabo utilizando alguna aplicación

de modelado que permita la carga de los mallados e información de simulación. Para

ello se deberá hacer uso de las interfaces de programación que dicha aplicación posea.

El renderizado del modelo se debe llevar a cabo mediante algún software de ren-

derizado que utilice alguna técnica de renderizado de alta calidad. El software de ren-

derizado debe ser capaz de interpretar el formato del modelo cargado en la aplicación

de modelado y generar la imagen final. Esto elimina la necesidad de realizar una tra-

ducción del formato utilizado por la aplicación de modelado al formato utilizado por

la aplicación de renderizado.

3.1.2. Objetivo 2

Diseño e implementación de una técnica que permita representar la información de si-

mulación mediante la asignación de color y transparencia a las neuronas representadas.

La información de simulación más importante consiste en el potencial de mem-

brana o voltaje de las neuronas, es decir, la diferencia de potencial entre el interior de

las neuronas y el espacio extracelular en distintos puntos de su superficie. El motor de

renderizado debe ser capaz de acceder a esta información y transformarla en un color

y transparencia que asignar a cada una de las regiones de las neuronas representadas.

38

3.1. PLANTEAMIENTO DEL PROBLEMA

La traducción voltaje-color RGBA se realizará utilizando un mapa de colores, una es-

tructura de datos que asocia los voltajes de simulación (textura unidimensional) con

una serie de colores y transparencias.

La técnica empleada para la asignación del color RGBA debe minimizar en lo posi-

ble el consumo de recursos, aumentando el número de neuronas que se pueden rende-

rizar y disminuyendo el tiempo necesario para la generación de las películas. Además,

dicha técnica debe ser compatible con la aplicación utilizada para renderizar el mode-

lo 3D, ya que el software que genera las imágenes debe poder acceder a dicho color o

calcularlo para aplicarlo a los mallados del modelo 3D en tiempo de renderizado.

3.1.3. Objetivo 3

Integración del motor de renderizado en la arquitectura software del BBP.

El diseño del motor de renderizado debe tener en cuenta su posterior integración

en la arquitectura software existente en el BBP, en concreto, en la aplicación BlueHub

(vista en el apartado 2.4.3 del capítulo anterior). Para ello se deben identificar los com-

ponentes de la arquitectura de BlueHub que se verán afectados por dicha integración,

intentando reducir en todo momento los efectos que la inclusión del motor pueda te-

ner sobre dichos componentes. Probablemente será necesario realizar algunas modi-

ficaciones sobre determinados elementos software del BBP. En ese caso se requerirá

de un estudio del diseño, documentación y tecnologías empleadas en los mismos pa-

ra minimizar la probabilidad de insertar errores en el software existente. Finalmente

se deberán realizar las pertinentes pruebas de integración para comprobar la correcta

integración del motor en la arquitectura del BBP.

3.1.4. Objetivo 4

Proporcionar mecanismos sencillos de configuración del motor de renderizado para per-

mitir al usuario elegir entre distintas opciones de renderizado.

El diseño del motor también debe considerar las distintas configuraciones que el

usuario puede elegir. Para ello se deberán identificar primero dichas configuraciones,

que más tarde deberán ser implementadas en el motor de renderizado. Además será

39

CAPÍTULO 3. PLANTEAMIENTO Y SOLUCIÓN DEL PROBLEMA

necesaria la especificación del formato de un fichero a través de la cual se pueda elegir

la configuración del renderizado. El formato del fichero debe ser lo más simple posi-

ble, permitiendo a un usuario no experimentado elegir entre las distintas opciones de

renderizado de una forma rápida y fácil de comprender.

3.2. Solución del problema

En esta sección se presenta, en primer lugar, la solución adoptada para la creación

e integración del motor de renderizado. El apartado motor de renderizado hace refe-

rencia a las soluciones que resuelven los problemas relacionados con la consecución

de los objetivos 1 y 2, mientras que el apartado integración del motor hace lo propio

para los problemas relacionados con la consecución de los objetivos 3 y 4.

Seguidamente se muestra una comparativa entre la arquitectura software original

y la nueva arquitectura surgida de la integración, permitiendo entender mejor qué ele-

mentos han sido modificados y cuáles han sido creados como resultado del trabajo

realizado.

3.2.1. Motor de renderizado

El modo de afrontar los problemas que presenta la creación del motor de renderi-

zado depende, en gran medida, de la aplicación para el renderizado de alta calidad que

se utilice. Por lo tanto, antes de trazar las soluciones de estos problemas, se explica qué

aplicación se ha elegido y por qué.

De entre todas las aplicaciones para el renderizado de alta calidad, Autodesk Maya

se ha escogido como la mejor opción para la creación del motor de renderizado. Los

motivos de la elección de Maya se presentan a continuación:

Maya posee una API que posibilita la creación del modelo de la escena a renderi-

zar.

La API de Maya puede ser accedida a través de Python. Esto ha permitido la im-

plementación íntegra del motor de renderizado en Python, lo que conlleva las

siguientes ventajas:

40

3.2. SOLUCIÓN DEL PROBLEMA

• Reducción del tiempo de implementación, dado que se trata de un lenguaje

de scripting.

• El uso de la API a través de Python permite la creación de aplicaciones stan-

dalone que utilizan todas las funcionalidades de Maya sin necesidad de car-

gar su interfaz gráfica, con el consiguiente ahorro de memoria.

• Facilidad para incorporar código externo a través del uso de módulos.

• No requiere compilación, ya que es un lenguaje interpretado.

• Se trata de un lenguaje multiplataforma, lo que posibilita la portabilidad del

motor de renderizado en caso de ser necesario.

• Reducción en el número de líneas de código, ya que el código fuente en

los lenguajes de scripting suele ser más corto. Esto permite incrementar la

legibilidad del mismo.

• El BBP-SDK también puede ser accedido a través de Python, por lo que el

no es necesario “envolver” el BBP-SDK.

Maya tiene soporte para utilizar Mental ray y RenderMan. Por defecto se incluye

el software de renderizado de Mental ray, mientras que RenderMan requiere el

pago de una licencia adicional.

El uso de Maya a través de una licencia académica reduce significativamente su

coste.

Existen gran cantidad de recursos en la red.

Maya incluye un renderizador por defecto, Maya Software, que utiliza el algorit-

mo de trazado de rayos.

Maya perm

DEPARTAMENTO DE ARQUITECTURA Y TECNOLOGÍA DE …oa.upm.es/6016/1/PFC_OMAR_AGUDO_SILVA.pdf ·...

Documents

Transcript of DEPARTAMENTO DE ARQUITECTURA Y TECNOLOGÍA DE …oa.upm.es/6016/1/PFC_OMAR_AGUDO_SILVA.pdf ·...