departamento de arquitectura y tecnologÍa de …oa.upm.es/6016/1/pfc_omar_agudo_silva.pdf ·...
Post on 19-Jul-2020
4 Views
Preview:
TRANSCRIPT
-
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.2. Primer frame de la secuencia 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.3. Primer frame de la secuencia 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.4. Primer frame de la secuencia 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 87
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
-
CAPÍTULO 1. INTRODUCCIÓN
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
-
CAPÍTULO 1. INTRODUCCIÓN
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
• 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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.2. TÉCNICAS DE RENDERIZADO DE ALTA CALIDAD
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.2. TÉCNICAS DE RENDERIZADO DE ALTA CALIDAD
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.3. APLICACIONES PARA EL RENDERIZADO DE ALTA CALIDAD
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.
Sus características más importantes son:
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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.
Sus características más importantes son:
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
-
2.3. APLICACIONES PARA EL RENDERIZADO DE ALTA CALIDAD
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).
Sus características más importantes son:
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
Sus características más importantes son:
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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. ARQUITECTURA SOFTWARE DEL BBP
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.4. ARQUITECTURA SOFTWARE DEL BBP
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.4. ARQUITECTURA SOFTWARE DEL BBP
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.4. ARQUITECTURA SOFTWARE DEL BBP
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
-
CAPÍTULO 2. ESTADO DE LA CUESTIÓN
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
-
2.4. ARQUITECTURA SOFTWARE DEL BBP
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
top related