VoxLink—Combining sparse volumetric data and geometry for efficient rendering

Daniel Kauker; Martin Falk; Guido Reina; Anders Ynnerman; Thomas Ertl

doi:10.1007/s41095-016-0034-8

| Sign up

PDF (4.1 MB)

Cite

EndNote(RIS) BibTeX

Collect

Submit Manuscript

Show Outline

Figures (8)

Fig. 1

Fig. 2

Fig. 3

Fig. 4

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Tables (4)

Table 3

Table 1

Table 2

Table 4

Research Article | Open Access

VoxLink—Combining sparse volumetric data and geometry for efficient rendering

Daniel Kauker^¹, Martin Falk^²(), Guido Reina^¹, Anders Ynnerman^², Thomas Ertl^¹

1 VISUS, University of Stuttgart, 70569 Stuttgart, Germany.

2 Immersive Visualization Group, Linköping University, 601 74 Norrköping, Sweden.

Show Author Information

Abstract

Processing and visualizing large scale volumetric and geometric datasets is mission critical in an increasing number of applications in academic research as well as in commercial enterprise. Often the datasets are, or can be processed to become, sparse. In this paper, we present VoxLink, a novel approach to render sparse volume data in a memory-efficient manner enabling interactive rendering on common, off-the-shelf graphics hardware. Our approach utilizes current GPU architectures for voxelizing, storing, and visualizing such datasets. It is based on the idea of per-pixel linked lists (ppLL), an A-buffer implementation for order-independent transparency rendering. The method supports voxelization and rendering of dense semi-transparent geometry, sparse volume data, and implicit surface representations with a unified data structure. The proposed data structure also enables efficient simulation of global lighting effects such as reflection, refraction, and shadow ray evaluation.

Keywords

ray tracing voxelization sparse volumes GPGPU generic rendering

References

[1]

Yang,

J. C.

; Hensley,

; Grün,

; Thibieroz,

Real-time concurrent linked list construction on the GPU. Computer Graphics Forum Vol. 29, No. 4, 1297-1304, 2010.

Volume	Resolution		Non-empty voxels (%)	Non-empty bricks (%)	Memory (MB)	Voxel per byte	FPS
Kronecker	512	[8]	34.7	39.7	738.0	16.6	11.6
Kronecker	1024	[8]	34.6	37.1	5874.3	16.6	1.9
Kingfisher	1024	[8]	0.5	2.3	107.6	19.6	35.4
Kingfisher	1024	[16]	0.5	3.5	97.9	17.8	21.0
Mouse	1024	[8]	1.7	6.2	322.3	18.2	15.9
Mouse	1024	[16]	1.7	7.5	302.8	17.1	8.4

Scene	Render mode	Resolution	Number of voxels ( $10^{3}$ )	Non-empty bricks (%)	Memory (MB)	FPS
Dragon	Plain	256 [8]	81.6	5.0	9.4	307.8
		512 [8]	326.2	2.6	70.0	134.5
		1024[16]	1303.2	2.6	277.0	87.3
Dragon	Ray tracing	256 [8]	81.6	5.0	9.4	47.6
		512 [8]	326.2	2.6	70.0	39.6
		1024[16]	1303.2	2.6	277.0	33.0
House	Ray tracing	256 [8]	560.0	18.8	16.7	45.2
		512 [8]	2319.3	12.2	100.0	38.8
		1024[16]	9444.9	12.2	401.0	31.1
Bunny	Ray tracing	256 [8]	139.2	6.9	10.2	37.3
		512 [8]	557.3	3.6	73.5	26.4
		1024[16]	2233.8	3.6	291.0	20.8

Resolution	256			512			1024
Brick size	4	8	16	4	8	16	4	8	16
Dragon	132.1	157.1	159.1	62.1	76.5	81.1	21.4	28.4	31.0
House	29.4	29.6	29.5	6.1	6.2	6.3	1.4	1.4	1.4
Bunny	20.5	21.0	20.7	4.8	4.9	4.9	1.2	1.2	1.2

Approach	Volumes	Meshes	Data storage	Rendering technique
VoxLink (ours)	Yes	Yes	Two layers of voxel lists	Ray tracing
LDI [26]	—	Yes	Layered depth images	Ray tracing
VDI [28]	Yes	—	Volumetric depth images	Proxy geometry
GigaVoxels [13]	—	Yes	Octree	Ray casting
Voxel DAGs [14]	—	Yes	Directed acyclic graphs	Ray tracing
Sample-based coloring [29]	—	Yes	Orthogonal fragment buffer	Ray casting
Hybrid surface rendering [30]	—	Yes	Grid and indirection buffers	Rasterization / ray tracing hybrid