The Quest for Shadows

Cosmopolis has a very large dynamic world. Players can modify terrain and building placement at runtime, in addition to day/night cycles. This brings up a plethora of issues in regards to shading and shadowing. Most video games use precomputed global illumination lightmaps to make the lighting look great at the cost of a single texture lookup. Unfortunately for us (well, fortunately for me as I enjoy attempting to solve this problem immensely) we must make things look pretty at runtime.

Starting with shadows, there are a number of issues that I have run into and I just wanted to prevent people from doing the same mistakes, so here are a few tips:

• All shadow tech demos/examples generally have a tiny scene to show off their shadowing technique.
  • Don’t be fooled into thinking that it could scale to fit your 8km view distance scene (or even 150m view distance).

• Most shadow tech demos/examples have a static/hardcoded positional light.
  • If you have a sunlight (directional with infinite position) you run into a new set of problems.
    • The light view matrix must be placed somewhere… How do you determine this point? CameraPosition + (-LightDirection * 10000) seems like a good idea, but if you do that you have no resolution in your depth map. CameraPosition + (-LightDirection * 100) seems like the obvious answer to that, but that creates a parallax effect as the camera moves.

• Screen Space Shadow Maps are an interesting idea, but blurring them is a terrible idea.
  • Viewed up close the “pixels” of your shadow map are way too big on your screen to be blurred together
  • Viewed far away the shadows will bleed into nearby objects that are not supposed to have shadow at all

With that in mind, I have mixed together PSSM (Parallel Split Shadow Maps) and SSSM (Screen Space Shadow Maps) with acceptable results (for now). PSSM is used to position 3 “light cameras” based on the position and rotation of the player camera, each at a different distance. The first covering the immediate surroundings and last covering about 250m view distance. To avoid the hard shadow edges I render a screen space shadow maps using PCF (Percentage Close Filtering) and then use the results of that map as an input to the objects that can receive shadows.

I render a depth map every other frame as opposed to rendering every depth map (remember there are 3) every frame. They are scaled to cover more than exactly the player’s view frustum to afford some leniency. I do however have to create the SSSM every frame, with a pretty expensive pixel shader, which is probably what I’ll try to tweak in the future.

Here are the results:

And here you can see the 3 depth maps rendered on the screen (top) and the SSSM results in the middle-left:

Point sprite scaling in XNA

Today, to my horror, I realized after creating a point-sprite based particle system for Cosmopolis that XNA does not seem to support point-sprite scaling. Meaning that if you set your point sprite to be of size 100, it will occupy 100 pixels on your screen whether you are viewing it up close, or miles away. After a decent session of googling I found a solution which involves setting renderstates that the XNA does not allow you to set in code. You instead need to set them in the HLSL shader pass definition (which I normally do not like to do for various reasons). This will suffice (and set up a “correct” scale according to the previously linked article):

1
2
3
4
5
6
7
8
9
10
11
12

pass Pass0
{
      VertexShader = compile vs_1_1 VS_Particles();
      PixelShader = compile ps_1_1 PS_Particles();
 
      POINTSCALEENABLE= TRUE;
      POINTSCALE_A = 0.0f;
      POINTSCALE_B = 0.0f;
      POINTSCALE_C = 1.0f;
      POINTSIZE_MIN = 0.0f;
      POINTSIZE_MAX = 9999.0f;
}

Just be aware that you can not set these renderstates back through XNA, although it shouldn’t affect anything else.

Cosmopolis Introduction

The project I’m working on right now (and our submission to the Imagine Cup) is called Cosmopolis, previously known as Codename Life or Warpipe. In short, it’s a testbed for behavioral model research, funded by the Department of Defense, engineered at USC GamePipe with some design inputs from CMU. I could copy and paste a whole bunch of academic jargon about the idea and purpose, but as a proud non-PhD student I try not to get lost in the imaginary (they call it theory) world too much and just focus on programming and making things look pretty, at 60 FPS minimum.

My role is graphics and engine programming. Our team is pretty small right now, so I’m responsible for most things rendered on the screen, except UI. Balki (AKA Balakrishnan Ranganathan, but no one knows that’s his real name), a PhD student at USC Gamepipe, is leading the project and works mostly on engine, server and whatever dirty work that needs to be done. Marc Spraragen is another PhD student on the project, taking care of most of our paper writing needs as well as some AI. Then we have Nitin Venugopal, working mainly on patcher and deployment things. Last but not least there is Aadarsh Patel who was heavily involved in the summer but drowned by coursework at the moment. He wrote the animation system and content pipeline for the models.

Imagine Cup Challenge!

As a part of entering the Imagine Cup competition and getting a free PDC ticket to boot (worth ~$1600), I have been challenged to start writing some random blurbs about my Imagine Cup development experience as well as my experience at PDC.

So… yeah! Our team at USC are making a game called Cosmopolis. The gameplay will not be discussed but I’ll try to share some random technical details, both from the past and as they are implemented. Subjects could include for example: Ambient Occlusion, Parallel Split Shadow Maps, 3D Particle Systems, Terrain visualization and Nvidia Nexus experiences.

However, chances are that I will fail miserably like 95% of other “blo**” (I despite that word), so come back often to laugh in my face when I don’t post anything! :)

My Little Bundle of Joy

Hey!

My name is Bjarni Thor Arnason and I’m a (or at least aspire to be) Game Programmer. I’m not looking for a job right now (working for Mythic Entertainment as a Software Engineering Intern on Warhammer Online), but I like to keep track of my work because we all know it can be a pain to get that old project running 2 years down the road when you want to show it to someone.

I’m less than a year away from graduating from USC with a Master’s degree in Computer Science – Game Development, so I’ll probably get more active in job searching when that moment draws close. But by then I’ll also probably edit this text :)

Thanks for stopping by! If you are curious about any of my projects, feel free to send me an email. Even if you are a student, not just recruiters!