torcode.com

Another web game :)

Monday, October 26th, 2009 | Uncategorized | 2 Comments

Woo, the game I worked on:

http://www.kongregate.com/games/inxile_Ent/fantastic-contraption-prius-edition

Just got released. It was a ton of fun, we took the original fantastic contraption and redid some things, as well as got it working with the kongregate level sharing api, it was pretty rad. I also got to learn actionscript 3.0

New web game :)

Thursday, May 14th, 2009 | Uncategorized | 5 Comments

This is the entry between myself and my friends for the wildpockets bay area game jam.  It was a ton of fun, but please have a look at vote for us over at the site!

Click here to play!

Also please feel free to leave us comments! We’d appreciate them!

HLSL Workshop Week3 - Non-photorealistic Rendering (Cell-Shading)

Saturday, February 28th, 2009 | Uncategorized | 2 Comments

because everything is just an edge

Last week we discussed some general render topics and went more into depth with AMD’s Render Monkey (I know it’s kinda ghetto but it’s the most simplistic setup for getting shaders up and running!  By design!).

Now, onto the fun stuff: Toon/Cell shading.  We will start the workshop off learning about how to properly shade our models.

The general principle behind toon shading is to give models and 3d geometry a “stepping” gradient of shade/light.  The ninja head to our left is what it looks like.  Notice the relatively harsh shading on the model?  How it jumps from deep red to light red to white for the highlights?  That is toon/cell “shading”.  It makes up one part of the process.  The other process involves the edge detection of the model and we will get into that after the shading part.

Cell Shading:

If you would be so kind as to keep the diffuse lighting equation in your head… that’d be sweet.

(l == light vector and n == normal vector!)

Armed with this knowledge, we can apply our warping of physics to our virtual reality.  How do we turn this relatively smooth lighting system into something to use in our nefarious purposes?  Simple.  We bootleg it like everything else in realtime shaders, we’ll use a lookup map (with the y axis stretched out so we can actually see it, the real image should be 32×1)!

So, armed with our new lookup texture, we can do some math-fu and get out the value to look up the texture with.  (remember, it’s a “1d” texture so we only need a scalar value!).

//same thing as above but with the normal!
float3 normalW = mul((float3×3)view_matrix, Input.Normal);

//here we are using the lighting equation of
float diffuse = max(0, dot(-lightDir, normalW));

Output.TexCoord.x = diffuse; //store the value into the outgoing texcoordx value
Output.TexCoord.y = 0.0f;

By getting the dot product of the normal (applied with the view_matrix so it’s view space) and the lighting direction (a global vector we set), we can get a rough estimate of the change between the lighting direction and the actual vertex normal.  This gives us a good value to use as a lookup as we can directly reference the toonlookup with this scalar value!

Finally, we do a very simple lookup on the texture withing the pixel shader

Out.Color.xyz = tex2D(ToonShaderLookUp, Input.TexCoord).xyz;  //use the texcoord lookup to get the actual toon shade value

Now, normally, you would take this value and multiply it by the base texture of the model, but in this case it’s superfluous as we don’t have a base texture :).

I know this seems a little confusing, but in reality, all we are doing, is intercepting the draw call, and rather than directly outputing the light vs our normal as usual, we are producing a lookup that allows us to “step” the color at our whim (try changing the lookup texture to different values and notice what’s going on).

The RenderMonkey solution file can be found here:

http://torcode.com/HLSL_Projects/ToonShade.rfx

Part Two: Edge Detection!

The easy part is the shading of the model.  That is simply the stepping of the lighting equation to fit into a more two-tone/simple tone system.  In order to really REALLY complete our effect, we need to add an edge creation system (remember, cartoons have those dope black outlines? OH YEA!)

There are two main ways to do this.  The first one, is the brute force method (which we will go over first) and the second, is a much more elegant silhouette detection!

Brute Force Method:

How about, in order to make our outline, we just dupe all the triangles that are backfacing, reverse their normals, and scale them out so we can create an outline that follows the model?  Well, that’s what we’re gonna do!  And let’s show ya how!

Ok, how did we get this badboy? Very very simply.  All we do is draw the base mesh once, then, run a second pass and on this pass, take all the vertex positions, scale them along their normal, and make the whole face black!  We also reverse the triange draw mode (flipping the normal) so that the back faces are drawn rather than the front faces (otherwise we’d just see black!).

Output.Position= (Input.Position + (Input.Normal*  LineThickness.x));
Output.Position = mul( Output.Position, WorldViewProj );

that’s pretty much the bulk of the code and the work.  All the pixel shader does is just turn the color black.

So what is wrong with this method?  well, first of all, this method really falls apart on an overly complex piece of geometry with lots of faces that come at weird angles.  It has the added benefit of being EXTREMELY simple and working on all shader targets.  But, there is a better solution:

Sobel Edge Detection:

Bam, kick it up a notch!  Sobel filters have been used for a while to figure out the edges on static 2d images for a while (it works, simply, by just judging the gradient of color between the pixel and it’s neighbors giving you a fairly clear idea of where edges are in a well lit image).  (lecture we go through how it works…)

HLSL Workshop Week 1b - Shader Intro

Sunday, February 22nd, 2009 | Uncategorized | 3 Comments

“Philosophy is a game with objectives and no rules. Mathematics is a game with rules and no objectives.”
Ok, great.  So we covered some super basic lighting principles in the last lesson and we learned that shaders are really just there to change the way lighting affects our visual representation of the material.  This isn’t entirely true, as the shader can affect quite a few different qualities of the material, but for arguments sake, lighting is a HUGE factor of this (HDR lighting, bloom, specular highlights).

So why do we use vertex/pixel shaders? (We’ll call them PS or VS from now on).  Well, in the older days of directX(5/6/7)/OpenGL, effects were done through the api and each graphics card had to implement the effect in the driver/hardware.  This led to a lot of wonky behaviours and a whole slew of features that graphics cards had to start supporting.  Multitexturing, hardware Transform + Lighting (nice per-pixel lighting!), fog effects, shadow operations, etc etc etc.  This is quite a bit of work on the graphics card manufacturers as they have to create the logic gates that can do these operations on the actual gpu.  So any major features required by the new version of the directX api specifications requires a significant amount of work.  Game developers were constantly looking for new effects (gaussian blurs, toon shading, better lighting/shadows).  These effects could be done on the CPU but with games going up in complexity (physics, better AI, bigger screen resolutions, networking systems) it was getting to be a huge bottleneck.

Queue in the graphics card!  With GPUs blasting out at new CPU level clock rates, it was quickly realized that increasing the frequency of the card only helps so much, what was really needed was parallelization (multi-cores) and some serious memory + on die memory bandwidth (gddr3 ram, etc).

The launch of the directX 8 series cards provided some extra processing units on them (the geforce3/4 and ati 8000x) that were programmable!  This was a huge leap and provided some very interesting effects.  While the number of vertex/pixel shader units were really low, this was drastically important to future titles as it allowed games to make custom shaders for their games (you will notice that around this time a lot of games REQUIRED dx8 cards, this is why, the older cards did not have a vs/ps 1.x).

Ok, great, again, what the hell is all of this?

A PS/VS is really just a small bit of code that needs to be executed a few thousand times a frame and is used to describe how something will look.  The vertex shaders are iterated over all the vertexes on the model and the pixel shaders are iterated over the visible pixels of the model.   This allows us to do some really cool effects on a massively fast scale.  The real beauty of all this is that it is a purely parallel process.  All the VSs can be executed across all the models at the same time, and then all the PSs can be executed across the whole of the visible surfaces.  This allows us to still get 60+ fps with operations that would have brought ANY cpu to it’s knees.  Hell, even a quad core can really only execute 4 instructions in parallel (SSE/etc not included).  While, the newer graphics cards can execute over 128+ shaders in parallel (or as close to it as it matters for this article).

Wow, awesome, so what’s the downside?

Well, like I said, these are SMALL instructions that are supposed to be executed extremely quickly.  There are hardset limits on the lower models (1.0-2.0) and while 3.0 ideally has an unlimited number of instructions there is a practical limit.

Instruction limits:

PS 2.0 - 64 arithmatic/32 texture instructions

PS 3.0 - 512

VS 2.0 - 256 instruction limit

VS 3.0 - 512 instruction limit(minimum)

VS/PS 1.x - these shaders are generally significantly harder to program for and vary wildly.  The best bet is to target a vs 1.1 model and stick to that count.  Avoiding the 1.2 -1.4 specs is advised as they are manufacturer dependant and are very different from current shader instructions.

What’s an instruction limit?

Instructions are the assembly lines of the shader (High Level Shader Language is similar to C/C++, the code gets compiled down to ASM).  Each operation has an instruction count, and must be tallied (assinging variables, texture look ups, dot product on two vectors, etc).  The shader represents a sort of mini function that is sent to the stream processors and executed across the meshes in the scene.  They must be tiny in order to fit on the tiny mini-cores of the GPU, this is what allows so many of them to be executed in parallel.  Tiny bite(byte, haha)-sized pieces of code that can be chomped down multiple times by very tiny mouths (stream processors on the GPU).

The GPU is basically the idiot savant brother of the CPU, it can do a few things amazingly well but it will just fail miserably at trying to do anything super complex.  The CPU can do many many things and isn’t bound to the same conventions the GPU is.  The CPU has significantly more resources at it’s disposal but it can really only execute one instruction at a time (per core).

So, what this all means is, that the GPU is a beast for small amounts of executions that happen hundreds of times and in parallel fashion(IE, shaders!).  Next we’ll talk about AMD’s rendermonkey!

HLSL Workshop Week 1a - Basic Lighting Intro

Saturday, February 7th, 2009 | HLSL | 2 Comments

Real time shaders is serious business.

Probably one of the hardest things about graphics programming now is understanding what exactly shaders are and how they make your game look so dang awesome.

First off, lets analyze the term shader.  In order to shade something, it must not be completely and fully lit.  If you look at a fully lit object it would just be washed out entirely with ambient light and show no shading.

Right, can you tell if that is a circle or a sphere? (here’s a hint, it’s a sphere… it’s just evenly lit all across it so you can’t tell it’s 3 dimensional.  The way we light an object tells us it’s depth (ok, really, we’re just tricking our eyes into thinking something has depth).  When you evenly light something across the board it looks very very ugly.  Not to mention boring.  So let’s look at a more shaded view.

Doesn’t that look a lot more 3dimensional?  We can tell it’s at least round in this picture due to the way the light doesn’t quite reach the outer edges of the sphere.  This basic principle of lighting gives the object depth.  Take a quick look at this picture to get an idea of what is going on.  Don’t worry I’ll explain it.

What we have here is a diagram of diffuse reflection.  When light hits the surface of an object, it bounces off at an angle (it’s reflection vector… dont’ worry about this right now) and goes off all over the place.  And because surfaces aren’t perfect, the light bounces around quite more than you would expect.  Now, the sphere looks shaded above because the surface that is oriented perpendicular to the light source and our eye is directly illuminated (the light bouncing off this part of the sphere all goes towards us, and thus, is super visible, imagine shining a flashlight at an object and it being illuminated, it’s illuminated because you are shining a light head onto it and the light rays are bouncing immediately back into your eyes).  The objects near the outer edge of the sphere are lit less because there is less light being completely reflected back to us due to the angle between the surface, our eyes, and the light source.  And finally, the back of the sphere is not lit at all, because no light is reaching there (this doesn’t really happen in real life, aside from celestial bodies, like the moon, as photons bounce quite a bit, take a look around your room right now and you’ll notice the shading in the corners and other areas that aren’t facing towards the light source, but are still illuminated).

Ok so, great, a whole bunch of science and an ungodly amount of math behind it.  I’m sure you’ve heard of raytracing, and that is a very expensive operation that traces each individual photon coming out of a lightsource and tracing it back to your eye (screen).  This isn’t really possible in real-time (for now).  So we aren’t gonna go into that.  How real time lighting works, is that we use the polygon triangle face as the surface, and light that in relation to the nearest light sources and the direction of the view.  In math terms:

k = dot_product( l , n)

now, K is the resulting value of the illumination (how bright the point is), l is the vector of the incoming light, and n is the surface normal of the surface (it’s perpendicular vector, those lines that pop out of the center of the surface in Maya).  This is called lambert lighting and it is very VERY basic.  But, it’s very easy to implement and it is extremely fast (only one real calculation per face per light!  VERY FAST!!

The downside? It looks ugly as hell.  But at least it is better than no shading!

Now, you can improve this lighting model by doing this calculation per vertex, and interpolating that lighting across the surface of the object inbetween verticies (ugh, I know this is complicated, but bear with me).

In these pictures, it is exactly the exact same sphere.  One is lit per face, and the other is lit per vertex and with the shading interpolated between verticies.  As you can tell, one looks like utter shit and the other one looks pretty decent for a not so smooth sphere.

So, what is a shader exactly?  It helps us define in game, how lighting affects and object.  This is why I went over lighting in a whirlwind tour.

First Post

Saturday, August 23rd, 2008 | Uncategorized | 4 Comments

Look over at the projects page for info on some of the projects I’m working on/have worked on!