Fluid Simulation and Rendering

Particle Systems, Smoke | Tuesday 15 September 2009 2:51 pm

For effects like smoke or water, a fluid simulation and rendering approach is needed. There are currently two popular methods for this:

  1. Simulate the fluid on the CPU and send the result as particles to the GPU for rendering as billboards. This is often called a particle system. The technique has been around since the dawn of computer graphics.

  2. Simulate the fluid on the GPU and render the result into textures. This will then be rendered by doing volume ray casting (or ray marching) on the GPU. This technique is new and rather unexplored, and there are few real-life implementations. The result can be very realistic but slow.

Technique one burdens both CPU, bandwidth and GPU. Although in modern solutions, it’s the bandwidth that’s the bottleneck. The GPU based technique only burdens the GPU ( but a lot ).

The movie shows the GPU method of fluid simulation and rendering. More info about this particular implementation in the two last links.

Building an Advanced Particle System
http://www.mysticgd.com/misc/AdvancedParticleSystems.pdf
Building a Million Particle System
http://www.2ld.de/gdc2004/MegaParticlesPaper.pdf
Real-Time Simulation and Rendering of 3D Fluids
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch30.html
The previous page’s authors homepage:
http://www.cs.caltech.edu/~keenan/project_fluid.html

Please share:
  • Print this article!
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Current
  • LinkedIn
  • Live
  • MySpace
  • Netvibes
  • StumbleUpon
  • Twitter
  • Reddit
  • Technorati
  • Yahoo! Bookmarks

Uniform Grid

Spatial Data Structure | Monday 17 November 2008 10:54 pm

This is maybe the easiest way to manage the objects in a scene and is also often a very good choice. It’s a simple uniform grid with equally sized cells/buckets/patches (or whatever you want to call it). When rendering, all that is needed for culling is to check the view frustum against these cells to determine which ones are visible. This grid can most of the time be in only 2D but can of course in special cases be 3D if necessary. This spatial data structure works well with both static and dynamic objects.

A Uniform Grid
Some information of traversing a grid structure
Please share:
  • Print this article!
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Current
  • LinkedIn
  • Live
  • MySpace
  • Netvibes
  • StumbleUpon
  • Twitter
  • Reddit
  • Technorati
  • Yahoo! Bookmarks

Real-Time Cloud Rendering

Sky | Thursday 13 November 2008 5:24 pm

A very fast technique to render clouds as imposters which are only updated when the viewport has changed enough to make a visible error. Here’s the abstract from the paper:

This paper presents a method for realistic real-time rendering of clouds for flight simulators and games. It describes a cloud illumination algorithm that approximates multiple forward scattering in a preprocess, and first order anisotropic scattering at runtime. Impostors are used to accelerate cloud rendering by exploiting frame-to-frame coherence in an interactive flight simulation. Impostors are particularly well suited to clouds, even in circumstances under which they cannot be applied to the rendering of polygonal geometry. The method allows hundreds of clouds with hundreds of thousands of particles to be rendered at high frame rates, and improves interaction with clouds by reducing artifacts introduced by direct particle rendering.”

Cloud Rendering
Link to a webpage with much more information about this technique:
http://www.markmark.net/clouds/

Link to the paper:
http://www.markmark.net/PDFs/RTCloudsForGames_HarrisGDC2002.pdf

Please share:
  • Print this article!
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Current
  • LinkedIn
  • Live
  • MySpace
  • Netvibes
  • StumbleUpon
  • Twitter
  • Reddit
  • Technorati
  • Yahoo! Bookmarks

Deferred Lighting

Rendering Methods | Saturday 1 November 2008 1:39 am

This is a lighting technique that lately has increased a lot in popularity. The normal way of shading is to perform the lighting calculations on a fragment when it is rasterized to the screen. This is often good but requires a lot of calculations if there are many lights. And the bad thing is that this fragment might later on be overwritten by some other fragment so the calculations might be a waste.

In deferred lighting (or deferred shading, or deferred rendering), you save the information about the fragment that is necessary to perform the shading (lighting) by rendering them to textures instead of doing the actual lighting calculation. When all geometry is rendered, the lighting will now be calculated only once per pixel on the screen. So no calculations will be wasted. You can perhaps say that it is some sort of a lazy evaluator.

The information saved per fragment is often:

  • position ( or just depth )
  • albedo ( the diffuse texture )
  • normal
  • specular

And these are sometimes also used:

  • shininess
  • material ID (for selecting material behaviour)

When all geometry has been rendered and it’s time to perform the lighting, the lights needs to be represented as something when sent to rasterization. Point lights can be drawn either as spheres or just square billboards. Directional light should be drawn as a full screen rectangle. And spotlights will be cones. Note that this shading technique allows for lights shaped in any form, not just these traditional ones.

The big reason for using deferred rendering is how well it scales with more lights. Another reason that it has increased in popularity lately is how nice it works with new rendering methods like SSAO and depth of field. The problem areas with deferred lighting is transparent objects and multisampling (antialiasing). If the original scene didn’t have per pixel lighting (but instead maybe vertex lightning) on the whole scene then the deferred rendering might be slower than traditional rendering.

Deferred Lightning example

Deferred Lighting example

Explanation of deferred lighting (and source code)
http://www.beyond3d.com/content/articles/19/

Deferred Rendering in S.T.A.L.K.E.R.

Deferred Rendering in S.T.A.L.K.E.R.

Explanation of how deferred lighting was used in the game S.T.A.L.K.E.R.
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html 

The result of the deferred rendering XNA tutorial

The result of the deferred rendering XNA tutorial

A very good tutorial of how to implement deferred lighting in XNA 2.0. This is good reading even when you are rendering in an other API.
http://www.ziggyware.com/readarticle.php?article_id=155

A long discussion on the gamedev.net forum of pros and cons of using deferred rendering compared to traditional forward rendering.
http://www.gamedev.net/community/forums/topic.asp?topic_id=424979

DirectX9 implementation if deferred shading, and some optimization talk
http://www.gamedev.net/reference/programming/features/shaderx2/Tips_and_Tricks_with_ DirectX_9.pdf

Deferred Lightning in Leadwerk Engine

Deferred Lightning in Leadwerk Engine

Info about the implementation of deferred shading in the Leadwerks Engine.
http://www.leadwerks.com/files/Deferred_Rendering_in_Leadwerks_Engine.pdf

Deferred Lighting in Killzone 2

Deferred Lighting in Killzone 2

A presentation about deferred lighting in the game Killzone 2:
http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf

Please share:
  • Print this article!
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Current
  • LinkedIn
  • Live
  • MySpace
  • Netvibes
  • StumbleUpon
  • Twitter
  • Reddit
  • Technorati
  • Yahoo! Bookmarks
« Previous PageNext Page »