From c376d6ce0058d0aa6a3e52ac2270913e0be3e1e4 Mon Sep 17 00:00:00 2001 From: Sebastian Lipponer Date: Wed, 18 Feb 2015 21:05:51 +0100 Subject: [PATCH] Surface Splatting: Add a readme. --- README.md | 63 ++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 49 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 201c639..5df8c29 100644 --- a/README.md +++ b/README.md @@ -1,25 +1,60 @@ -# GLviz +# Surface Splatting -GLviz is a small collection of C++ classes and GLSL shaders to facilitate the development of OpenGL demos. It is built on top of [CMake](http://www.cmake.org/), [SDL](http://libsdl.org), [GLEW](http://glew.sourceforge.net), [Eigen](http://eigen.tuxfamily.org/), and [AntTweakBar](http://anttweakbar.sourceforge.net/) and requires at least OpenGL 3.3. GLviz has been tested on a NVIDIA GTX 680 GPU using driver version 347.52 on Windows (compiled with MSVC 2013) and 340.65 on Linux (compiled with GCC 4.9). It includes all external dependencies to make compilation on either Windows or Linux as simple and convenient as possible. +This demo implements a point rendering and texture filtering technique called *Surface Splatting*1. More specifically, it implements the GPU accelerated surface splatting approach by Botsch et al.2 using OpenGL 3.3 (core profile). This basically comprises a raycasting based rasterization of elliptical splats, a deferred shading pipeline and an approximation to the original EWA filter1. The demo has been tested on a NVIDIA GTX 680 GPU using driver version 347.52 on Windows (compiled with MSVC 2013) and 340.65 on Linux (compiled with GCC 4.9). It is built on top of [GLviz](https://github.com/sebastianlipponer/glviz) and is therefore rather simple to compile. -**Author**: [Sebastian Lipponer](http://sebastianlipponer.de), **License**: MIT +**Author**: [Sebastian Lipponer](http://sebastianlipponer.de), **License**: GPL v3 -## Features +[![](http://sebastianlipponer.github.io/surface_splatting/dragon_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/dragon.png)[![](http://sebastianlipponer.github.io/surface_splatting/dragon_splats_tail_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/dragon_splats_tail.png) -* Camera with trackball navigation. -* Shader management. -* Triangle mesh shader (supports flat or Phong shading and an optional high-quality wireframe1 overlay). -* Sphere shader (for the sake of performance not perspectively correct spheres). -* Supports embedding of shaders in the executable. +_**Left**: Surface splatting of the Stanford Dragon model. **Right**: Closeup showing artificially shrunk splats to illustrate the splat distribution._ -## Screenshots +## Basic Principle -[![](http://sebastianlipponer.github.io/glviz/dragon_thumbnail.png)](http://sebastianlipponer.github.io/glviz/dragon.png)[![](http://sebastianlipponer.github.io/glviz/dragon_wireframe_thumbnail.png)](http://sebastianlipponer.github.io/glviz/dragon_wireframe.png)[![](http://sebastianlipponer.github.io/glviz/dragon_spheres_thumbnail.png)](http://sebastianlipponer.github.io/glviz/dragon_spheres.png) +Surface splatting1 renders point-sampled surfaces using a combination of an object-space reconstruction filter and a screen-space pre-filter for each point sample. This effectively avoids aliasing artifacts and it guarantees a hole-free reconstruction of a point-sampled surface even for moderate sampling densities. The object-space reconstruction filter resembles an elliptical disk, also referred to as a *splat*, whose position, orientation, major axis, and semi-major axis are usually chosen to provide a good approximation to a given geometry. After a perspective projection of all splats to screen-space, rendering proceeds by applying a bandlimiting prefilter to avoid frequencies higher than the Nyquist frequency of the pixel sampling grid and summing up all contributions from the overlapping splats for each individual pixel with a subsequent normalization. -## Documentation +[![](http://sebastianlipponer.github.io/surface_splatting/checkerboard_ewa_filter_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/checkerboard_ewa_filter.png)[![](http://sebastianlipponer.github.io/surface_splatting/checkerboard_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/checkerboard.png) + +_Surface splatting of a checkerboard. **Left**: EWA filter approximation enabled. **Right**: EWA filter approximation disabled._ + +## Splat Rasterization + +Since today's GPUs are mostly optimized for triangle based rendering and do not provide any specialized fixed-function hardware for splat rasterization, it is required to use the programmable vertex and fragment shader units for this task. The most performant way to do so, at least on NVIDIA hardware, seems still to be to draw point primitives as screen-space squares of a certain size, and to cast a ray for each fragment to test whether it is part of the splat. While the corresponding formulas proposed by Botsch et al.3,2 are efficient to compute, they constitute only an approximation to the exact screen-space position and extents of a splat. Moreover, under certain conditions, the screen-space extents of a splat are underestimated by this approximation, which then causes rendering artifacts. + +[![](http://sebastianlipponer.github.io/surface_splatting/plane_splats_pch_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/plane_splats_pch.png)[![](http://sebastianlipponer.github.io/surface_splatting/plane_splats_bhzk05_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/plane_splats_bhzk05.png) + +_**Left**: Correct rendering. **Right**: Some splats are chopped off due to Botsch et al.'s2,1 approximation of the screen-space extents of a splat._ + +A very simple fix for this problem consists in multiplying the estimated splat extents with a safety factor larger than one, but this causes the generation of large number of unnecessary fragments and since the fragment stage is the performance bottleneck anyway, this is not a particularly good solution. + +Computing the exact screen-space position and extents of a splat in a reliable and robust way turns out to be difficult in practice. For example, using the centralized conics approach of Zwicker et al.4, the resulting formulas involve the inverse of a 2D-to-2D projective mapping from a splats parameter space (given by the position of its center, and two vectors spanning the ellipse) to screen-space. The condition number of this mapping increases rapidly as the projection of a splat approaches a line. Zwicker et al.'s4 approach is therefore numerically unstable and plagued by large roundoff errors. The demo nevertheless also includes an implementation of this method. + +In the context of GPU-based raycasting of quadric surfaces Sigg et al.5 noted that a reliable and robust solution to this problem must not use the inverse of the projective mapping. This is indeed possible by exploiting the fact that normal vectors, as opposed to ordinary vectors, transform by the inverse transpose of a mapping. The underlying idea is to find a plane in screen-space which is tangent to a quadric in its parameter space, i.e. tangent to the unit sphere. Mathematically, this requires the solution of a quadratic equation for each dimension and does not involve the inverse projective mapping. Weyrich et al.6 later adapted this method to the special case of surface splatting. It is important to note that this approach yields a splats position and extents in screen-space, i.e. normalized device coordinates. It is therefore not possible to clip the obtained bounding box by the view-frustum. Furthermore, while conics are closed under projective mappings, the perspective projection of an ellipse may yield a parabola or hyperbola, in which case the proposed method does not work anymore. To avoid these problems, my implementation considers only those splats whose bounding sphere intersects with the view-frustum. + +[![](http://sebastianlipponer.github.io/surface_splatting/cube_closeup_pbp_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/cube_closeup_pbp.png)[![](http://sebastianlipponer.github.io/surface_splatting/cube_closeup_whaf07_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/cube_closeup_whaf07.png) + +_Closeup of a cube consisting of 24 clipped splats. **Left**: Using my method of a projected bounding polygon produces a correct image. **Right**: Using the method proposed by Weyrich et al.6 produces artifacts._ + +In the course of implementing and analyzing all these methods, I also devised my own approach. The idea is to bound a splat by a polygon in its parameter space and to only employ this bounding polygon to compute the screen-space position and extents of a splat. To this end, the polygon is first transformed to clip space where it is clipped by the view-frustum using the Sutherland-Hodgman algorithm. A perspective division of each vertex then yields the clipped polygon in screen-space where the desired quantities are simple to compute. This method is not exact, but it produces a correct upper bound to the extents of a splat and unlike previous methods also works for large splats being close to the near plane. + +## Sharp Features + +The demo also implements clipped splats4 to facilitate the rendering of sharp features like edges and corners of a cube. + +[![](http://sebastianlipponer.github.io/surface_splatting/cube_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/cube.png)[![](http://sebastianlipponer.github.io/surface_splatting/cube_splats_thumbnail.png)](http://sebastianlipponer.github.io/surface_splatting/cube_splats.png) + +_**Left**: Surface splatting of a cube consisting of 24 clipped splats. **Right**: Cube with artificially shrunk splats to illustrate the splat distribution._ -Currently there is no documentation, but the code includes an example. From the source code it should become apparent how GLviz is intended to be used. ## References -[1] Bærentzen, J. A., Munk-Lund, S., Gjøl, M., Larsen, B. D.: **Two Methods for Antialiased Wireframe Drawing with Hidden Line Removal**. In Proceedings of the Spring Conference in Computer Graphics, 2008. +[1] Zwicker M., Pfister H., van Baar J., Gross M.: **Surface Splatting**. In Proceedings of the 28th Annual Conference on Computer Graphics and Interactive Techniques, SIGGRAPH '01, pp. 371-378. + +[2] Botsch, M., Hornung, A., Zwicker, M., Kobbelt, L.: **High-Quality Surface Splatting on Today's GPUs**. In Proceedings of Eurographics Symposium on Point-Based Graphics, 2005, 17-24. + +[3] Botsch, M., Spernat, M., Kobbelt, L.: **Phong Splatting**. In Proceedings of the First Eurographics Conference on Point-Based Graphics 2004, SPBG '04, 25-32. + +[4] Zwicker, M., Räsänen, J., Botsch, M., Dachsbacher, C., Pauly, M.: **Perspective Accurate Splatting**. Proceedings of Graphics Interface, 2004, GI '04, 247-254. + +[5] Sigg, C., Weyrich, T., Botsch, M., Gross, M.: **GPU-based Ray-casting of Quadratic Surfaces**. Proceedings of the 3rd Eurographics / IEEE VGTC conference on Point-Based Graphics, 2006, SPBG '06, 59-65. + +[6] Weyrich, T., Heinzle, S., Aila, T., Fasnacht, D. B., Oetiker, S., Botsch, M., Flaig, C., Mall, S., Rohrer, K., Felber, N., Kaeslin, H., Gross, M.: **A Hardware Architecture for Surface Splatting**. ACM Transactions on Graphics, 2007.