Rendering of Complex 3D Treemaps (GRAPP 2013)

Interactive Rendering
of Complex 3D-Treemaps
Matthias Trapp, Sebastian Schmechel, Jürgen Döllner

Hasso-Plattner-Institute, University of Potsdam, Germany

Agenda

I. Motivation

II. Conceptual Overview

III. Implementation Details

IV. Results & Discussion

V. Future Work & Conclusions

02/22/2013 Interactive Rendering of Complex 3D Treemaps :: Matthias Trapp 2

3D Treemap Example


Related Work
 2D Treemaps [Shneiderman ’92, Bederson ’02]:
 Common technique for space restricted hierarchy
visualization
 Various layouting algorithms available

 3D Treemap / StepTree [Bladh, 2004]
 Can be used to map additional attributes of the data items
 Significantly better performance in interpreting the
hierarchical structure
 Preserve performance in interpretational/navigational
tasks

02/22/2013 Rendering of Complex 3D Treemaps :: Matthias Trapp 5

Image-Synthesis of a 3D Treemap

Computation of 2D Treemap Layout

Mapping of Thematic Data to Treemap Items

Generation of 3D Rendering Primitives

Rendering/Rasterization of 3D Rendering Primitives


3D Treemap >600k Items


3D Treemap Item

Additional dimension =
additional complexity

 Observation: 3D treemap = 2.5D virtual
environment
 3-5 times more geometry required than 2D case
 Attributes for thematic mappings vary per item
 Number of items determines update performance

Challenges for Complex 3D Treemaps
3D Treemap ~ geometrical complex
representation:
 High memory footprint in VRAM
 High run-time complexity for item updates
 High run-time complexity for layout

Efficient rendering depends on/is determined by:
 Rendering run-time complexity
 Update run-time complexity
 Client/Server memory consumption/space
complexity

 Goal: Reduction ofComplex 3D Treemaps :: Matthias Trapp complexity
02/22/2013 Rendering of space and time 9

SECTION II

Conceptual Overview

Treemap Item :: Parameterization
 Goals:
1. Provide a small-as-possible memory footprint on client
2. Support fast client-server updates
 Layout-dependent attributes:
 2D item position & size (X, Y, W, H)
 Mapping-dependent attributes:
 Item color & item identity (R, G, B, ID)
 Item depth & Z-position (D, Z)
 Hierarchy Level (L)
 Binary flags, e.g., isLeaf, isVisible, isSelected,… (F)


Treemap Item :: Buffer Mapping

Assumption:
mapping and layout are often modified separately
 Two separate buffers: layout and mapping buffer
 Can be updated separately and saves bandwidth

Approach :: Overview

Three-stage deferred rendering process:
1. Generate and render attributed point cloud
2. Generate primitives & rasterize to G-Buffer (1 pass)
3. Apply post-processing techniques (1 pass)


Approach :: Attributed Point Cloud


Approach :: Generated Primitives


Approach :: Thematic Mapping


Approach :: Post Processing


Approach :: Summary

 Fully GPU accelerated shape generation
 Render attributed point cloud and generate triangles
 Enables a compact representation of treemaps


SECTION III

Implementation Details

Primitive Template

 Optimal GPU representation: 8 vertices + 12 indices
 Format: triangle-strip without swaps
 Omit bottom face of treemap item


Emitter Function


Culling Strategies
 Backface Culling:
 Goal: omit rasterization of back-facing primitives
 Performed using fixed-function pipeline feature
 Overhead if performed in geometry shader

 View-frustum Culling:
 Goal: omit shape generation for items outside the frustum
 Performed per-item in vertex shader

 Size Culling:
 Goal: omit rasterization of small treemap items
 Performed per-item in vertex shader


Size–Culling using a Screen-Space Metric

a max p0 x ,, p7 x min p0 x ,, p7 x b max p0 y ,, p7 y min p0 y ,, p7 y
true a b
passSizeCulling
false otherwise


Culling Implementation
bool passCulling(const in mat4 mvp, const in vec4 vertex, const in vec4 dimensions,
const in bool applyViewFrustumCulling, const in bool applySizeCulling)
{ float cPMaxX=-10000.0;float cPMinX=10000.0;float cPMaxY=-10000.0;float cPMinY=10000.0;
bool passCulling = true;
if(useViewFrustumCulling)
{ // 1. Do conservative culling and test only center of item
vec4 V = mvp * vertex;
passCulling=((-V.w<V.x)&&(V.x<V.w))&&((-V.w<V.y)&&(V.y<V.w))&&((-V.w<V.z)&&(V.z<V.w));
if(!passCulling)
{ // 2. Perform precise culling if item center is not in frustum
vec4 AABB[8];
for (int i = 0; i < 8; i++){
AABB[i] = mvp * (vertex + VERTEX[i] * dimensions);
vec4 p = AABB[i] / AABB[i].w;
p.xy = (p.xy + 1.0) * (viewport.zw * 0.5) + viewport.xy;
cPMaxX = max(cPMaxX, p.x); cPMinX = min(cPMinX, p.x);
cPMaxY = max(cPMaxY, p.y); cPMinY = min(cPMinY, p.y);
} //endfor
// 2. Perform precise culling if item center is not in frustum
int bounds[6] = int[6](0,0,0,0,0,0);
for(int i = 0; i < 8; i++){
if(AABB[i].x>AABB[i].w) bounds[0]++; if(AABB[i].x<-AABB[i].w) bounds[1]++;
if(AABB[i].y>AABB[i].w) bounds[2]++; if(AABB[i].y<-AABB[i].w) bounds[3]++;
if(AABB[i].z>AABB[i].w) bounds[4]++; if(AABB[i].z<-AABB[i].w) bounds[5]++;
}//endfor
for(int i = 0; i < 6; i++) if(bounds[i]==8) passCulling = false;
}//endif }//endif
// 3. Apply size culling if enable to every visible item
if(passCulling && applyViewFrustumCulling && useSizeCulling)
passCulling = ((abs(cPMaxX)-abs(cPMinX))*(abs(cPMaxY)-abs(cPMinY)))
> float(pixelSizeThreshold);
return passCulling;
}


Deferred Stylization :: Overview

 Performed in post-processing: low per-fragment cost
 Can be customized to user demands/rendering
speed
 Rendering overhead: ca. 1-3 ms @ 720p

Deferred Stylization :: Variances


SECTION IV

Results & Discussion

Comparison of Approaches

Difference: Geometry generation on CPU vs. GPU

Utilized stage/approach has impact on:
 Bandwidth required (CPU  GPU)
 Main (CPU) and video (GPU) memory footprints
 Number of draw calls issued


Existing Approaches
Vertex Buffer Objects (VBO):
 Generate geometry for each treemap item
client-side (CPU) and push to server (GPU)
 Index variant has low memory footprint and
leverage post-transform cache (~32 vertices)
 CPU bound for frequent treemap updates
Geometry Instancing (Pseudo, UBO, TBO)
Encoding of per-instance-data (PID) is bottleneck:
 Pseudo-Instancing: encode PID in shader constant
registers
 Uniform-Buffer Instancing: encode PID to L1-Cache
(~64K)
 Texture-Buffer Instancing:3Dencode PID to texture
02/22/2013 Rendering of Complex Treemaps :: Matthias Trapp 29

Rendering Performance
GPU: NVIDIA GTX 460 / CPU: Intel Xeon 2,79GHz
250

200

150
milliseconds

100

50

0
Pseudo UBO TBO Indexed Non-Indexed Intermediate
Shape Generation
Instancing Instancing Instancing VBO VBO Mode
13.884 0.38 1.68 1.47 1.49 0.63 1.37 5.12
98.858 1.75 6.28 4.01 4.01 3.42 8.67 35.45
365.645 6.15 27.49 15.91 14.93 12.57 32.35 133.05
614.920 14.76 60.88 31.12 31.51 28.46 54.71 220.01


Memory Footprint :: Metric

 #Bytes for n treemap items with a attributes
 compression ratios for VRAM consumption:
 1:2.5 over indexed vertex representations
 1:3.75 over non-index vertex representations


Memory Footprint :: Results
1E+09

10000000

10000000

1000000

100000
byte

10000

1000

100

10

1
CPU GPU CPU GPU CPU GPU CPU GPU
13.884 98.858 365.645 614.920
Shape Generation 444288 444368 3163456 3163536 11700640 11700640 19677440 19677520
Pseudo Instancing 444368 444368 3163536 3163536 11700640 11700640 19677520 19677520
UBO Instancing 444368 444368 3163536 3163536 11700640 11700640 19677520 19677520
TBO Instancing 444368 444368 3163536 3163536 11700640 11700640 19677520 19677520
Indexed VBO 1999296 1555008 14235552 11072096 52652880 40952240 88548480 68871040
Non-Indexed VBO 15439008 14994720 109930096 106766640 406597240 394896600 683791040 664113600
Intermediate Mode 444288 0 3163456 0 11700640 0 19677440 0


Discussion
 Outperforms all existing rendering techniques:
 Pseudo & UBO Instancing are CPU bound
 TBO instancing is bound by L2-Cache performance
 VBOs probably transform bound
 Indexed VBO leverage post-transform cache
 Generation and instancing have similar memory footprint
 All approaches are not fill-limited

 Theoretical limits of the presented approach:
 ~2.5 million 3D treemap items at ~20 frames-per-second
 Equals 1 pixel-per-item at full HD resolution (1920x1080)


SECTION V

Future Work & Conclusions

Future Work :: Reduce Overdraw

high overdraw low overdraw


Future Work :: Reduce Overdraw

Independent Representation Interdependent Representation

A B

L2
Item Origin

L1

L0

Unnecessary Item Overdraw L ~ Hierachy Level of Item


Future Work :: Improve Readability


Future Work :: Concept Transfer


Future Work :: Summary
Foundation for advanced visualization techniques:
 Animated transition between 3D treemap states
 Application of interactive focus+context lenses
 Multi-perspective views of 3D treemaps

Generalize approach for other treemap types:
 3D Voronoi treemaps
 Classical 2D (Voronoi) treemaps


Conclusions
 Rendering technique for complex 3D treemaps

 Outperforms existing approaches w.r.t.:
 Rendering speed
 Memory requirements (client & server)

 Building block for GPU framework for 3D treemaps

 Stylization possibilities are limited (e.g.
,transparency)

 Potentials for future work


Questions & Comments
Contact:
www.4dndvis.de

 Matthias Trapp
matthias.trapp@hpi.uni-potsdam.de
 Sebastian Schmechel
sebastian.schmechel@hpi.uni-potsdam.de
 Jürgen Döllner
juergen.doellner@hpi.uni-potsdam.de

Publications:
http://www.hpi.uni-potsdam.de/doellner/4dndvis/publikationen.html

This work was funded by the Federal Ministry of Education and Research
(BMBF), Germany within the InnoProfile Transfer research group "4DnD-Vis".


Rendering of Complex 3D Treemaps (GRAPP 2013)

More Related Content

What's hot

Viewers also liked

Similar to Rendering of Complex 3D Treemaps (GRAPP 2013)

More from Matthias Trapp

Recently uploaded

Rendering of Complex 3D Treemaps (GRAPP 2013)

Editor's Notes