"If a man speaks in the forest and there is no woman around to hear him, is he still wrong?"
More pages: 1 2 3 4 5 6 7 8 9 10 ... 12
Framework 3 (Last updated: October 11, 2016)
Framework 2 (Last updated: October 8, 2006)
Framework (Last updated: October 8, 2006)
Libraries (Last updated: September 16, 2004)
Really old framework (Last updated: September 16, 2004)
AntiAlias
Saturday, June 4, 2005 | Permalink

Executable
Source code
AntiAlias.zip (361 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
This demo implements supersampling antialiasing by rendering the scene multiple times with just a tiny tweak to the projection matrix between the renders and accumulating the results in the accumulation buffer. It allows you to change between 1x (no AA), 2x, 4x and 11x (default). If you enable antialiasing in the control panel you can get really large AA modes, for instance 6x multisampling + 11x supersampling, which would give you essentially 66x AA.

Cel-shading
Monday, February 21, 2005 | Permalink

Executable
Source code
CelShading.zip (216 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
This demo implements one of the most common cel-shading algorithm. Do simple lighting, then look up in a grayscale texture with a few colors. But in addition to that, it draws the outline of the object as well as internal edges (adjustable on the F1 menu). The outline is extracted entirely on the GPU. The idea is similar to shadow volume extrusion on the GPU. You extract all edges on the model and store the face normals from the both triangles the edge connects. When one is front-facing and the other backfacing, it's a silhuette edge. After figuring out whether we're on a silhuette edge or not we need to destroy edges that aren't. There's no direct way to destroy it, but we can throw it out to infinity though. This is easily done by setting w to 0.

In addition, internal edges are detected by simply dotting the normals and comparing it to a threshold value. The lower the value of the dot-product, the sharper the edge is.

Metaballs
Sunday, January 2, 2005 | Permalink

Executable
Source code
MetaBalls.zip (808 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
This demo implements the marching cubes algorithm for constructing a polygonal model from an isosurface. The isosurface chosen here is a classical metaballs setup. Metaballs are defined by field function that's the sum of R2 / ((ball.x - x)2 + (ball.y - y)2 + (ball.z - z)2) for all balls. The surface is defined to be where the sum is one.

The marching cubes algorithm constructs the isosurface by intersecting the space with cubes (also referred to as cells). At each vertex point the field function is evaluated. An edge on a cube is known to intersect the surface if one has a value above one, or in my implementation, is positive (I subtract one so I can just use the sign bits, which speeds things up). At each edge that intersects the surface an approximate intersection point is computed by interpolating between the edge points. As there are 8 corners in a cube that are either above or below the surface there are 28 = 256 possible ways for the surface to intersect the cube. These are stored a lookup table for quick assembly. Many implementations on the web evaluate the vertices directly for each cube and doesn't evaluate the surface topology. This is simpler, but means a lot of computations are repeated. My implementation however evaluates the full topology with both an index array and vertex array, which is faster and requires less data to send to the graphic card, but it uses a bit more memory and requires a bit more advanced data structure. The topology may also be useful for other tasks such as computing smooth surface normals. I'm evaluating the normals directly from the field function however as this was both faster and gave higher quality normals.

The main bottleneck in this process is evaluating the field function. To speed things up a bit I implemented 3DNow and SSE versions of it as well. It should choose the most appropriate for your system as default. You can change what field function to use on the F1 menu.

As a final output of all this I apply a water-esque shader on the surface.

This demo should run on all GLSL capable hardware such as the Radeon 9500 and up and GeForce FX 5200 and up.

Depth of field II
Sunday, December 19, 2004 | Permalink

Executable
Source code
DepthOfField2.zip (363 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
This demo renders a depth of field effect by rendering 8 different views on a spherical cap around a focus point and averaging the results. The focus point is computed by shooting a ray in the middle of the screen and intersecting it with the geometry. As you look around, the focus point changes smoothly as you're either looking at closeup details or in the distance.

The good thing about this way of implementing the effect is that the results are very good, at least if you render enough views. The bad thing is that it's very expensive. For this reason this demo uses a simple lightmapped scene and fairly small render target resolution. For depth of field situations you can get away with using low resolution render targets though as most of the scene is a bit blurry anyway.

This demo should run on Radeon 9500 and up and Geforce FX 5200 and up.

Light trail
Tuesday, October 26, 2004 | Permalink

Executable
Source code
LightTrail.zip (225 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
GL_EXT_blend_color
This demo implements a simple light trail technique. The light sources are rendered into a texture. This texture is then blurred and scaled down slightly between each frame and new light rendered into it the next frame. This creates a corona around the light and a light trail as the light moves or the view position changes.

This demo should run on Radeon 9500+ and up and GFFX 5200 and up.

Soft shadows II
Sunday, September 19, 2004 | Permalink

Executable
Source code
SoftShadows2.zip (1.1 MB)

Required:
Pixel shader 2.0
Vertex shader 1.1
This demo implements a more dynamic version of soft shadows than the previous one. The light isn't restricted to a predefined path, nor does the geometry have to be static. The basic idea is to first generate a hard shadow using regular shadow mapping, then blurring it as needed. Special care is taken to ensure that shadows and light doesn't bleed over from the background or foreground by scaling down sample weight with difference in depth.

A good thing with soft shadows is that they can easily be combined with lightmaps for static lights, while combining dynamic hard shadows with lightmaps can look a bit odd where some shadows are soft and others are hard.

This demo should run on Radeon 9500 and up and GFFX 5200 and up.

2004-09-22: Should work on nVidia cards now.

Raytraced shadows
Monday, August 30, 2004 | Permalink

Executable
Source code
RaytracedShadows.zip (949 KB)

Required:
GL_ARB_shader_objects
GL_ARB_vertex_shader
GL_ARB_fragment_shader
GL_ARB_shading_language_100
This demo shows how to generate shadows through raytracing. This is easy enough to do with simple object such as spheres, which this demo uses. Shooting a ray through a list of spheres requires few computations. In fact, assuming the GLSL compiler generates optimal code it will only need 5 instructions per sphere, and then we're getting soft shadows for free. The limit is instead on the number of interpolators, which limits the number of spheres to 7 on current hardware, unless of course you go multipass (which would be straightforward).

Press the left mouse button to kick balls around. The longer you hold the button, the stronger the kick. It will kick in the direction you're looking.

This demo should run on Radeon 9500 and up and GeForce FX 5200 and up.

2004-08-31: The demo should now work properly on nVidia cards too.


Instancing
Wednesday, August 18, 2004 | Permalink

Executable
Source code
Instancing.zip (422 KB)

Required:
Pixel shader 1.1
Vertex shader 1.1

Recommended:
Instancing support
Vertex shader 2.0
This demo renders a particle system using a range of different methods. The most basic (and slowest) method simply draws each particle with its own draw call. The next method assembles everything in a large vertex array and draws it with a single draw call. The third method assembles it into a vertex buffer instead, resizing the buffer if needed. The two remaining methods implements instancing in two different ways. Using instancing means that the only information that needs to be passed to the card is the data specific for each instance, cutting it down to a fraction of what would otherwise be needed. Less than 1/4 in this case. One method uses SetStreamFrequency() and passes the instance data through a second vertex stream that's read on a much lower frequency. This is what people generally are referring to when they talk about "instancing" and requires special hardware support. The other method uses a technique to implement instancing without special hardware except for VS2.0 support. The instance data is passed through vertex shader constants instead. This has a couple of drawbacks. First, the number of spare vertex shader constants are limited, which limits the number of instances that can be drawn in a single draw call. This also means you'll overwrite previously set constants for subsequent draw calls, so you can't reuse the data in another pass without passing it to the card again. Another drawback is that the source model will be larger because you need to create multiple copies of the model with indices that selects the right vertex shader constant. We are usually talking about relatively small objects when we're doing instancing anyway, so this may not be much of a problem.

Use the 1-5 keys to select between the different rendering paths.
1 - Instancing
2 - Vertex shader constant instancing.
3 - Vertex buffer copy
4 - User pointer vertex array
5 - One call per particle

Use the + and - keys to change the particle spawn rate.

This should run on Radeon 8500 and up, and on GeForce3 and up. The instancing path will be only be available on 9500 and up with Catalyst 4.8 or newer drivers and on the GeForce 6800 series. The instancing through vertex shader constants path will only be available on 9500 and up and on GeForce FX 5x00 series and up.

More pages: 1 2 3 4 5 6 7 8 9 10 ... 12