GPU Based Point Information

Point splatting is a well-known technique to visualize point based data sets. Point splatting can be used very efficient for point information as shown in [Gross and Pfister, 2007], [Kobbelt and Botsch, 2004], [Sainz et al., 2004]. The key idea is to display points by deforming each point shape in a way that no holes are visible in the resulting image. The technique indicates that there is no complex mesh structure generated and therefore, the main advantage of point splatting is

the reduced geometric complexity. This visualization technique fits perfectly the needs for our large-scale point datasets.

The original point splatting technique uses a textured rectangle for every vis- ible point containing the pixel information of the point splat. The textured rect- angle can be stretched or otherwise adjusted based on the camera’s viewing angle to cover bigger or smaller regions with one single splat image. Modern GPUs take over this concept for their hardware accelerated point rendering pipelines. Fig. 4.3(a) shows the semantic structure of a colored point within the point-rendering pipeline.

When the point data runs through the rendering pipeline described in Sec. 2.1.4,

the points get mapped from their 3D coordinate pi(xi,yi,zi)to something what is

called a fragment coordinate si(x,y,d(xi,xj)). Often fragments are misinterpreted

as pixels on the screen. But the major difference between a fragment and a screen pixel is that fragments are pixel coordinates per object. This means that for one single screen pixel S(x,y) on the final image it is possible to have multiple frag-

ments si(x,y,d(xi,xj))influencing the color of the final screen pixel S(x,y). Often

the most upfront fragment is used, i.e. the one with the smallest depth value, and all others are discarded. This is what we call depth culling or z-culling, because the depth values of the fragments are compared.

At this stage, the points are rendered as squared areas according to the given point size, as visible in Fig. 4.3(a). The point size specifies the point shape extent in screen pixel. A fragment shader program is performed for every fragment of this area. Within this fragment shader program, it is possible to access the frag-

ment coordinate si(x,y,d(xi,xj))and also the fragment coordinate relative to the

point shape. This fragment coordinate relative to the point shape is aligned be- tween 0.0 and 1.0 within the point splat. Up to this step, the point shape is still a rectangle. The circle shape in point rendering appears, because the fragment program discards all fragments farther than a certain distance to the center point.

For our chart rendering, we used the hardware accelerated point splatting method by extending this fragment shader functionality. Fig. 4.4 shows results from our application using point splatting for charts. We implemented three types of charts: bar charts, pie charts, and rose diagrams.

• Bar charts: A bar chart is computed by the division of the x-axis accord- ing to the number of incoming data table columns. The fragment shader decides about the correct color and group for every fragment. Depending on the amount of columns n of the incoming data table, the bar sections can be identified by x mod n for every fragment. The fragments color can be chosen based on a color predefined in the data table. Fragments exceeding bar section are discarded to make fragments not belonging to bars opaque. • Pie charts: Pie charts can be computed using a division of angle relations

1.0 1.0 0.0 x i(x,y) pi(x,y) (a) Point Splat

1.0 1.0 0.0 x x α₁ β1 β2 β3β4 ri S_i(x,y) (b) Pie Chart

Figure 4.3: Two case for the chart rendering.

from the polar coordinates of a chart. Figure 4.3(b) shows a sketch of the concept. The resulting sections correspond to the data table columns. For

every fragment si(x,y,d(xi,xj))within a point splat, the corresponding angle

aiis computed. This angleaiis compared against every anglebj. bjare

computed from the input data values and represent relative percentages to

Ân

j=0(bj)for all j between 0 and the amount of table columns n. Analog

to bar charts, the color value is chosen by the index j from a color lookup table. In addition, a fragment is discarded if the distance to the center is bigger than the splat radius r to produce a round shape.

• Rose diagrams: Rose diagrams can be seen as combination of pie and bar charts. In case of a rose diagrams, pie sections have the same angle size, but each slice differs in extent. This means, that x mod n is done based on the angle, so that the section or group can be identified for every fragment

si(x,y,d(xi,xj)). In addition the radius of each section is adjusted to relative

values. 4.1.2 Results

Results of our chart rendering can be seen in Figs. 4.4, 4.5 and 4.6 for two dif- ferent voting data sets. Fig. 4.6 shows a voting dataset from 2012 containing 4588 charts. Our implementation runs on an Intel Core i7 3.5 GHz, 16 GB RAM, Nvidia GTX1080 (4GB RAM, 3840 ⇥ 2160). The data set can be explored in- teractively in 3D. For the Vorarlberg charts as well as for the US voting data we

(a) Bar Chart (b) Pie Chart

(c) Rose Chart

Figure 4.4: Chart Renderings of voting results for the Austrian National Council in 2013.

achieve rendering times around 3-4 milliseconds per frame. The technique can also be applied on mobile devices or other portable graphic hardware with lower hardware capabilities.

Figs. 4.4 show the different kinds of charts described above on the basis of the national elections in Austria in the year 2013. The rose diagram example in Figure 4.4(c) shows a red line within the rose diagram describing the 50% border, which means for the voting example that the absolute majority is reached. These simple examples show that the technique is applicable to more complex chart structures. Furthermore, Fig. 4.5 shows that a full integration of such charts can be achieved within the perspective 3D view of a terrain render engine.