WPF3D Team Blog : Lighting

WPF3D Lighting and Shading

wpf3d — Tue, 30 Jun 2009 04:54:00 GMT

We use the standard fixed-function Blinn-Phong model. You can read up on all of the equations here at MSDN.

If you have a Tier 2 card, we actually do our lighting in a vertex shader. If you don’t have a Tier 2 card, we do the lighting on the CPU. Why not just use D3D9’s fixed-function APIs you might ask? We wanted to be able to blend a texture (SpecularMaterial.Brush) only with the specular component and it turns out the D3D9 fixed-function APIs can’t do that.

An important thing to know is all Material Brushes are treated as textures even though they might not be implemented as such (e.g. SolidColorBrush). This means if the amount of light hitting a vertex is more than 1.0, it will be capped at 1.0 before being blended with the texture. This is an unfortunate behavior of the fixed function pipeline. I discussed this more in the color knobs post.

There is one thing that may be unique to out lighting model. Since we are a retained system, we factor in a Light’s transform to all of its properties. We approximate the scale being applied to the light by taking the cube root of the absolute value of the determinant of the upper 3x3 part of the Light’s transform. For a uniform scale this will be the actual scale but for non-uniform it’s good enough (the real solution is too costly for something uncommon). Internally, this number is factored into the range and attenuation values so things make sense. For example, if the Light undergoes a uniform scale of 2.0, we’ll multiple its range by 2.0.

-- Jordan

Cel Shading

wpf3d — Sat, 08 Sep 2007 07:02:00 GMT

Charles Petzold has been experimenting with cel shading on his blog at the request of Chris Cavanagh (whom has updated his 3D physics XBAP btw). Though we do use shaders internally, WPF3D's API is fixed function so you have to dig out the ol' fixed function playbook to achieve fancier effects. The plays usually boil down to abusing textures :)

First, make a small, one dimensional texture containing the colors you want. Here are a couple of examples I've zoomed in on and highlighted the pixels to make things clearer. Why I'm using grayscale will make sense in a minute:

Next, we need a function that maps to [0, 1] and takes into account the light position relative to a vertex. How about the cosine of the angle to the light? Turns out we can compute that fairly quickly because it's equal to the dot product of the normal and the vector to the light divided by their lengths.

    Int32Collection idxs = mesh.TriangleIndices;
    Point3DCollection pts = mesh.Positions;
    Vector3DCollection nrms = mesh.Normals;
    PointCollection txs = mesh.TextureCoordinates;
    mesh.TextureCoordinates = null;
    for (int i = 0, count = idxs.Count; i < count; ++i)
    { 
        int idx = idxs[i]; 
        Vector3D toLight = lightPos - pts[idx]; 
        toLight.Normalize(); 

        // The normals are pre-normalized, no need to do it again  
        double dp = Vector3D.DotProduct(toLight, nrms[idx]); 
        
        // A negative dot product means the vertex is facing away  
        // from the light so let's set that to the darkest color  
        if (dp < 0) 
        { 
            dp = 0; 
        } 
        
        txs[idx] = new Point(dp, 0); 
    } 
    mesh.TextureCoordinates = txs;

Naturally, you're going to need to redo this calculation any time the relationship between the light and the mesh changes so it needs to be fast. This is why I go through all of that collection nonsense (read this).

So why did I use a grayscale texture? If I baked the color in, I'd have to make a new texture any time I wanted to change the color. Instead, I can use the color knobs to set the color and use the grayscale texture like a mask. In these photos, I have a single AmbientLight with a DiffuseMaterial with AmbientColor="green" and Brush equal to the one dimensional texture. I don't actually have a real point light in the scene which helps performance.

Being that it's per-vertex, more vertices means a higher quality image and you're going to see some popping when it's animated. The teapot doesn't have too many vertices so the spout and black line on the body don't look great. On the highly tesselated torus, those issues are gone but it's still hard to get a clean, crisp edge because of the linear interpolation of the texture.

-- Jordan

P.S. If you use a texture with two colors and instead dot the normal with the direction to the camera, you'll get silhouette edges but they could look really bad because of the per-vertex nature again.

Material Color Knobs

wpf3d — Fri, 08 Dec 2006 23:40:00 GMT

We affectionately refer to DiffuseMaterial.Color, DiffuseMaterial.AmbientColor, SpecularMaterial.Color, and EmissiveMaterial.Color as the "color knobs." The color knobs are probably the least understood WPF3D feature because they were one of the last (if not the last) features we added and most of the things you can do with them are not obvious. Hopefully this article will give you insight into how the properties work and help you write better XAML exporters.

The full lighting equation used by WPF is definitely something we need to cover later, but essentially the final color for a single Material is going to be: Color * lighting result * Brush. DiffuseMaterial includes both ambient and diffuse lighting so it has two color properties making the equation: (AmbientColor * ambient lighting result + Color * diffuse lighting result) * Brush. From this equation, you can see that you can't just set Color and be done -- you also need a Brush. By default, all of the Color properties are white giving them no effect on the final appearance.

Now let's look at a few ways to use these properties. (By the way, if I refer to a color channel going from 0.0 -> 1.0 it's the same as 0 -> 255 if you're using bytes)

Color Knobs as a Filter

Let's say a GeometryModel3D with a DiffuseMaterial is being hit by a light containing red. If you set the red channel of the color knob to 0, the mesh won't reflect any red light. If you set it to 1, it'll reflect all of the red light the Brush reflects. By changing the value between 0 and 1 you can "dial in" how much you want to reflect back. This is how we started calling them "knobs."

The color knobs are full colors so they do have alpha. Setting the alpha value does what you would expect (e.g. alpha of 0.5 makes it half transparent). There is one exception to things and, surprise, it's DiffuseMaterial. Only DiffuseMaterial.Color.A affects the transparency of the Model. Turning down DiffuseMaterial.AmbientColor.A does make the ambient component transparent and increase the impact of the diffuse component, but it does not affect Model transparency.

AmbientMaterial

DiffuseMaterial, SpecularMaterial, EmissiveMaterial... where's AmbientMaterial? We don't have it. What do you if you want a Model to respond to only ambient light? Before color knobs, it couldn't be done. With color knobs, create a DiffuseMaterial, set Color to (0,0,0,0), and all diffuse contribution will be wiped out leaving you with just ambient!

Fully Illuminated Solid Colors

Say you wanted to make a Model look green. You have two good options: a white brush with a green color knob or a green brush with a white (the default value) color knob. Is there a difference between the two? It depends on how much light is hitting the Model. If the amount of light hitting isn't greater than 1.0 in each channel, then they're equivalent. If not, here's what happens:

Both pictures are of a sphere mesh with a DiffuseMaterial and two full power point lights shining on it. On the left, the the Color is set to #ff006000 and the Brush is set to white. On the right, the Color is set to white and the Brush is a #ff006000 SolidColorBrush. Why is the one on the left so vibrant and the one on the right so lackluster?

In the graphics pipeline, lighting is calculated in the vertex processing stage and textures are sampled later on in pixel processing. In WPF, all Brushes applied to 3D are done as textures -- even SolidColorBrushes. Unfortunately, the graphics card clamps colors coming out of the vertex stage to 1 so no matter how many hundreds of lights you have you will never be able to exceed the color of the SolidColorBrush. As you can see in the image on the right, the big solid color splotch in the middle has a value of #ff006000, the color of the SCB. The color knob value is incorporated during vertex processing so it is multiplied by the unclamped lighting result. For those of you used to per-vertex colors in other APIs, you can think of the color knob as a single vertex color for the entire mesh. This explanation is tricky and requires some knowledge of graphics hardware but hopefully it made some sense :)

In general, you may end up wanting to use the color knobs for all of your solid color needs*.

-- Jordan

* There is one minor perf issue to take note of if you don't have a Tier 2 graphics card: If you have a MaterialGroup with more than one DiffuseMaterial or more than one SpecularMaterial and those duplicate Materials have different color knob values, you will incur a performance penalty. For example, a MaterialGroup with two DiffuseMaterials one with Color (.5, .5, .5) and one with Color (1, 1, 1). Fortunately, this doesn't happen too often. See this MSDN article for information about tiering.