Capítulo 4: Visualización Out-of-CoreLas operaciones que requieren del acceso y estado de los recursoscríticos como ramList, C y sincronizar necesitan de un semáforo paragarantizar exclusión mutua en el acceso. Por ello se utilizan dossemáforos en el algoritmo.Como estado inicial para ambos procesos, se tiene que tanto la selecciónS como S + contienen únicamente al nodo raíz (representación más burdadel volumen), el cual ha sido cargado previamente en memoria principal(ramList) y memoria de textura (texList). El resto de las páginas enmemoria principal y memoria de textura están libres, es decir,disponibles para alojar bricks.4.5 Consideraciones Adicionales para Texturas 2DCuando se utilizan texturas 2D, típicamente se requieren 3 copias delvolumen, una por cada eje principal de visualización [LAM99]. Debido aque el rendering utiliza aceleración en hardware, empecemos poranalizar las posibilidades de almacenamiento en memoria de textura. Laprimera alternativa es almacenar las 3 copias de S en memoria detextura. Como consecuencia, sólo 1/3 de esta memoria es utilizada parael despliegue, y hay que cargar los bricks por triplicado, en detrimento dela eficiencia en el uso de la memoria y ancho de banda. La ventaja deesta técnica es que al cambiar de eje principal, no se notará ningúncambio en la fluidez de visualización.Otra alternativa consiste en almacenar en textura sólo la copia que estásiendo desplegada. Aunque temporalmente esto aumenta la eficiencia enel uso de la memoria y ancho de banda, el cambio de eje conlleva arecargar todos los bricks de S, lo cual redunda en una discontinuidad enla fluidez de la visualización. La opción intermedia consiste en generaruna representación de menor detalle Snew, con a lo sumo M bricks, en elmomento del cambio de eje. Acorde al esquema de paginación de disco amemoria principal utilizado, cualquier representación de menor detalle ala última selección (Sold) se encuentra en el caché de memoria principal, ypor consecuencia no genera requerimiento de lectura de memoriaauxiliar. Aunque la calidad en la visualización decae en el momento decambio de eje, la representación multi-resolución se irá refinandorápidamente, puesto que los bricks de resolución inferior a Soldpotencialmente se mantienen en memoria principal.Para mantener compatibilidad con el prototipo implementado en estetrabajo, se sugiere almacenar sólo una copia de los bricks en disco ymemoria principal, y justo antes de cargar un brick en textura, este estransformado en cortes 2D perpendiculares al eje principal actual.-74-
Capítulo 4: Visualización Out-of-Core4.6 SumarioEn este capítulo se ha realizado una adaptación a la solución parasoportar volúmenes multi-resolución que no pueden ser almacenadostotalmente en memoria principal. El algoritmo out-of-core para cargar yreemplazar bricks en memoria principal se basa en el algoritmo de Splitand-Collapse,sobre una representación multi-resolución S +generalmente de mayor detalle a la que se está desplegando (S). Pese aque las operaciones se realizan igualmente sobre los nodos de unaselección (en este caso sobre S + ), se mantienen en caché todos los nodosinternos del sub-árbol delimitado entre el nodo raíz del octree y los nodosde S + . El reto es actualizar este sub-árbol de manera tal que las próximasoperaciones de split y collapse realizadas sobre S no generen fallos depágina. En este sentido, se toma en cuenta el error en cada nodo paramantener y cargar los bricks, potencialmente requeridos en futurosframes, en memoria principal.En el próximo capítulo se detallan las diferentes técnicas utilizadas parael despliegue con aceleración en hardware gráfico, incluyendo el raycasting basado en GPU, la clasificación pre-integrada, y diversas técnicasde aceleración, todas adaptadas al caso multi-resolución.-75-