Welcome to Game Rendering!

Uncategorized | Wednesday 24 September 2008 2:03 am

While developing games I’ve been collecting lots of links to useful pages and as they increased in amount I needed some way to organize them. I realized that they might be useful for others too so I decided to create a simple website with the links and other information I’ve collected. I have just finished studying for my Master degree in Software engineering and is especially interested in computer graphics and game rendering. This site is therefore also created as a learning project for me and can therefore contain information that is incorrect somewhere. If you ever find something that’s wrong I would be happy if you informed me by commenting the site.

New articles will be posted as often I can.

I’m currently working on adding online demos for the articles so one can view the result immediately.

/ Robert

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

VPOS

Shaders | Monday 7 December 2009 5:35 pm

Starting with DirectX Pixel Shader Model 3.0 there exist an input type called VPOS. It’s the current pixels position on the screen and it’s automatically generated. This can be useful when sampling from a previously rendered texture when rendering an arbitrarily shaped mesh to the screen. To do this, we need uv-coords that represents where to sample on the texture. These coordinates can be gained by simply dividing VPOS with the screen dimensions.
When working with older hardware, that doesn’t support shader model 3.0, there is a need to manually create the VPOS in the vertex shader and pass it to the fragment shader as a TEXCOORD. This is the way to do so ( including the scaling to uv-range which manually has to be done for VPOS if you’re using it).

Vertex Shader:

float4x4 matWorldViewProjection;
float2 fInverseViewportDimensions;
struct VS_INPUT
{
   float4 Position : POSITION0;
};
struct VS_OUTPUT
{
   float4 Position : POSITION0;
   float4 calculatedVPos : TEXCOORD0;
};
float4 ConvertToVPos( float4 p )
{
   return float4( 0.5*( float2(p.x + p.w, p.w - p.y) + p.w*fInverseViewportDimensions.xy), p.zw);
}
 
VS_OUTPUT vs_main( VS_INPUT Input )
{
   VS_OUTPUT Output;
   Output.Position = mul( Input.Position, matWorldViewProjection );
   Output.calculatedVPos = ConvertToVPos(Output.Position);
   return( Output );
}

Pixel Shader:

float4 ps_main(VS_OUTPUT Input) : COLOR0
{
   Input.calculatedVPos /= Input.calculatedVPos.w;
   return float4(Input.calculatedVPos.xy,0,1); // test render it to the screen
}

The image below shows an elephant model rendered with the shader above. As can be seen, the color (red and green channels) correctly represents the uv-coords for a fullscreen quad. Since 0,0,0 = black, 1,0,0 = red, 0,1,0 = green, 1, 1,0 = yellow.

VPOS Elephant
This is how the pixel shader would have looked like if VPOS were used instead (note: no special vertex shader needed in this case).
struct PS_INPUT
{
   float2 vPos : VPOS;
};
float4 ps_main(PS_INPUT Input) : COLOR0
{
   return float4(Input.vPos*fInverseViewportDimensions + fInverseViewportDimensions*0.5,0,1); // test render it to the screen
}

The original code, more info and proof can be found here:
http://www.gamedev.net/community/forums/topic.asp?topic_id=506573

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

Render Thickness

Rendering Methods | Friday 25 September 2009 4:24 pm

In [1] they describe a clever way of rendering the thickness of an object in a single pass. The method only correctly works for convex objects but this limitation isn’t that bad, the method can often be used to get the approximated thickness of concave objects as well. For example, [1] uses it to fake the light scattering in clouds rendered as billboards. The methods works like this:

The object is rendered and the distance from the near plane is saved in a color channel R. Also, the distance to the far plane is saved in channel G. By rendering with the blend color mode MIN, one will get the minimum distance from the near plane in R, and the minimum distance to the far plane in G. By using these two distances, one can easily calculate the thickness of the rendered object with the following formula (1-G) – R (if distance is scaled so one is the the distance between the clip planes). Alpha can be saved as well in the same render pass, by outputting it to the A channel. And selecting blend alpha mode ADD (color and alpha can have different modes). This will add up the alpha.

All this is done in only one pass. Just remember to clear to white before rendering.

The image below shows the thickness of the popular Hebe mesh rendered with this method. This model is not convex, and the problem areas are for example the arm holding the bowl. As one can see, the algorithm believes that the bowl and the shoulder are connected, and therefore believes that part of the object is the thickest.

Hebe

[1] The Art and Technology of Whiteout
http://ati.amd.com/developer/gdc/2007/ArtAndTechnologyOfWhiteout(Siggraph07).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

Instanced Billboards

Particle Systems | Wednesday 23 September 2009 1:27 pm

In DirectX9, one can use instanced billboards to render lots of particles with good performance. Since we presume all particles to be billboards constructed from two triangles forming a quad, by using instancing, we can reuse this geometry data (only uv-coordinates needed) for each particle and therefore saving bandwidth. When rendering, two streams with different frequency should be used.  The quad-geometry data makes the first stream, the second stream consists of the per instance data that is unique for each particle. This instance data could be the position, rotation, color and more. The big drawback with this rendering approach is that it requires hardware instancing support, which means Shader Model 3.0. (or Shader Model 2.0 for ATI cards if using a trick described in the first source below).

This particle rendering approach described in details:
http://zeuxcg.blogspot.com/2007/09/particle-rendering-revisited.html

DirectX9 info about rendering multiple streams
http://msdn.microsoft.com/en-us/library/bb147299(VS.85).aspx

DirectX9 instancing info
http://msdn.microsoft.com/en-us/library/bb173349(VS.85).aspx

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
Next Page »