ReCreation Studios

Unity GPU Noise (Part 4)

2011-09-25T22:26:00.000-07:00

Well, I'm a stubborn individual, so I continued working on the Android version of GPU Noise. I have actually been successful and made a little progress. Not without encountering more issues, of course.

First, I must say that GLSL hates conditional branches (including for loops). The main reason why my example scene wasn't running on Android was because I used an if-else tree in my shader (previously a switch statement) to select the noise type based upon a variable that was set on the Material by the C# side. While this works perfectly fine on Windows and DirectX, it's not the case for Android. I had to separate each noise type into its own shader/material and then have logic on the C# side to select the correct Material.

This is where things start to get strange. The basic Perlin noise function worked fine (as well as Voronoi), but none of my summations (like fBm) worked. They are simply for loops that call the Perlin function repeatedly. For testing, instead of having it take a variable for the number of times to loop, I hard-coded it to 4 octaves. This didn't work either. However, if I manually unrolled the for loop to have the code repeated 4 times, it finally worked.

Now, a little aside about my implementation. In order to speed up the noise functions, I precompute some values and store them in various textures which the noise functions then sample from. I wanted the noise functions to be accessible in both a vertex shader and pixel shader, so I used the tex2Dlod function to sample the textures. This is because tex2Dlod is the only permitted function for sampling from a vertex shader. (Automatic mip-mapping doesn't work in a vertex shader, so the developer must specify the mip-map level to use.)

Thinking that using tex2Dlod was somehow causing my for loop problems, I decided to look into a different implementation. I found a GLSL implementation of Perlin noise that didn't use any arrays or texture lookups (amazing!), thus making it highly cross-platform. I promptly ported it over to Cg in Unity. I was dismayed to discover that it yielded really terrible looking visual artifacts. The problem was even worse when using any summation. I quickly made a test scene in WebGL to test the shader in its original GLSL. Here, as you can see, it all worked perfectly. Going back to the Cg port, I went over line by line to see where it was failing. I first tried replacing the optimized "hacks" he used in place of modulus. That didn't fix it. Then, I looked at his inverse square root function. If I replaced his function with a call to rsqrt, the artifacts disappeared!

Armed with a new implementation, I tried running my test scene on Android again. And again, my summations failed. I happened to discover that the summations only worked when given certain octaves (for loop counter). This is the strangest thing of all. If I gave it 1, it worked. If I gave it 2 through 8, it failed. If I gave it 9 or greater, it worked.

I must say, I'm entirely perplexed. I have all of my noise functions working on an Android device now, but only with certain ranges on the summations. Why doesn't it work with 4 octaves when it works with 10? Does anyone have any insight into this strange issue?

Unity GPU Noise (Part 3)

2011-09-15T11:29:00.000-07:00

As I mentioned previously, I had updated my GPU Noise to hopefully get it working on Macs. One of my friends tried the web player build on his Mac, and I was saddened to see that it still came out as a black, non-displaced sphere.

As I was investigating, I found the Shader.isSupported API which looked like it might be helpful. I noticed in the documentation, however, that it will return true if any of the Fallback shaders will work. In my noise shader, I had given it a fallback of "VertexLit", thus why only a flat, black sphere was rendered on the Mac. I didn't want the API to always return true (since VertexLit obviously was working), so I commented out the Fallback statement. Bad move! Not only did the web player fail to load on a Mac, it completely locked the entire OS requiring a reboot! Since my friend's Mac is a dual-boot with Windows 7 on it, I had him try it out on the Windows side. Everything worked perfectly!

In order to help me with debugging possible hardware issues, I wrote a simple little Unity web player that listed the hardware specs according to how Unity sees the machine. It's been pretty interesting and helpful. You can run it over here.

Using that app, I was able to see that the Mac only runs OpenGL 2.1! For comparison, when I forced my Windows build to run in OpenGL mode (using -force-opengl), it reported that it was running OpenGL 4.1. My hatred for Apple increases daily.

Deciding to switch gears for a bit, I started looking into deploying the GPU Noise on my EVO 3D to see how it ran. (No, I don't have a personal Android license for Unity yet, but I do have one from work. I;m not going to publish anything from it, just use it to test my stuff after work.) So, I got everything setup and sent my package over to my phone, where I was greeted with the "Powered by Unity" splashscreen. That was it; it never made it beyond that point. I hooked up logcat and added some debug lines to see what errors were occurring. That wasn't helpful at all. It showed Unity loading, timing out, and then reloading. My level file was never loaded, none of my scripts were ever executed. If I switched my Material to be something else (I used a particle material), it would load properly and run. So, it was an issue with my noise Material, but I have no idea what, due to the lack of errors.

As it stands now, I'm not quite sure how to proceed. Do I release this on the Unity Asset Store as it is now and put a disclaimer that it only works on Windows currently, or do I invest more time and effort to get it working on Mac/Android first? Opinions?

Procedural Primitives (Unity Asset Store)

2011-09-12T09:34:00.000-07:00

I've released my first package, Procedural Primitives, on the Unity Asset Store. Check it out here.

It's based on the code I wrote to generate primitives in XNA. You can read about that code and download it on my old blog post here.

Basically, it allows you to create your own primitive 3D shapes (planes, cylinders, cones, and boxes) in Unity. Sure, Unity already has all of these as built-in primitives, but you can't change the resolution of these shapes at all. Plus, they provide no ability to create just the Mesh object and not a full GameObject. Procedural Primitives lets you pick the quality you want and gives you the option to create only the Mesh or the a full GameObject containing MeshFilter, MeshRenderer, and Collider components.

Procedural Primitives allows you to create the shapes either in the Unity Editor by way of a custom editor window, or you can call the methods in script.

To create them in the editor, you choose GameObject --> Create Other --> Procedural Primitive from the menu:

A new window will pop up that will allow you to tweak several parameters (depending upon the chosen shape) and then create a new primitive shape.

To create a new shape in script, you simply call one of the static methods on the Primitive class along with the desired parameters:

All money I get from the sales of Procedural Primitives will help fund my purchase of an Android license of Unity.

I'm currently preparing my noise package release. It should be coming out sometime in the next week.

Unity GPU Noise (Part 2)

2011-08-18T22:44:00.000-07:00

Sheesh! Yet another 5 months have passed by!

When I was creating the demo of GPU Noise in Unity, I kept getting a "function 'tex2Dlod' not supported in this profile" error. I couldn't figure out why except that it was an OpenGL issue. So, I simply forced my shaders to exclude OpenGL and OpenGL ES renderers (#pragma exclude_renderers opengl gles). Obviously this is not the best solution, so I decided to dive into it again.

It turns out that the error goes away if you instead force the shader to compile to GLSL (#pragma glsl). I have no idea why this fixes the problem, since it was an OpenGL issue in the first place, but whatever. Forcing the shaders to compile to GLSL brought up two other issues that I had to fix.

1) GLSL doesn't support default parameters (Cg and HLSL do). This means that I had to go duplicate all of my shader functions that used them, which were a lot.

2) GLSL doesn't support the switch statement. I had to go manually unroll my switch statements to be if-else trees. This one really confused me because all of the GLSL documentation seems to indicate that switch is indeed in the language, so this might just be a Unity issue.

You can check out the updated demo here:

http://re-creationstudios.com/unity/noise/

Hopefully it works on Mac now, but I haven't been able to test it out yet. Feel free to let me know!

Unity GPU Noise & Unity Issues

2011-03-08T13:55:00.001-08:00

It's amazing how much time keeps slipping by without any posts. Another 5 months have somehow passed since my last post. That means that I have only written 2 posts in the past year! I need to get back to my good update schedule.

GPU Noise in Unity

First, I'd like to show a simple demo I made of various types of noise on the GPU in Unity. You can check out the live demo on the web by clicking on the image below. You need to have a Shader Model 3.0 GPU in order to run the demo.

As you can see, there are 9 different types of noise in the demo and they are all implemented in Cg shaders on the GPU.

Perlin - "Standard" Perlin Noise (1 octave)
fBm - fractional Brownian motion summation of Perlin Noise (8 octaves)
Turbulence - fBm variation that sums the absolute value of the noise result (8 octaves)
Ridged - fBm variation from the book "Texturing and Modeling: A Procedural Approach" that performs a special ridge function on the noise result (8 octaves)
Voronoi (F1) - A "noise" type that uses a field of random 3D points and determines the distance to the closest point
F2 - Voronoi that determines the distance to the second closest point
F2 - F1 - Voronoi that determines the difference between the first and second closest points
(F1 + F2) / 2 - Voronoi that averages the distance between the two closest points
Crater - Voronoi variation that makes crater-like structures

Have fun messing around with the sliders and seeing how the noise can be manipulated on the fly!

Unity Issues

After completing the GPU noise demo in Unity (it's actually been done since November), I started proceeding with implementing a procedural planet generator in Unity. It quickly introduced me to some of the issues and limitations that Unity has.

Cannot disable/control view frustum culling.
This is the worst issue I ran into. The way I implement the planet is to have a small cube that is "blown out" to form a sphere and then offset with noise all on the GPU (à la displacement mapping). Unity has a camera system that determines which objects are inside each camera's view frustum and automatically culls (doesn't draw) any objects that are outside of the view frustum. The problem is, while the small cube is not in the view frustum, the final displaced planet is in the frustum. This causes the planet to suddenly stop rendering if the camera is pointed a certain direction.

I tried several fixes such as blowing the cube up to be the same size of the planet and forcing the view angle to be the maximum value (179 degrees) when Unity does the frustum check. Neither of these got rid of the problem entirely and just reduced how much it happened. In order to fix it, game developers should have control over which objects should be culled, or be able to disable frustum culling entirely.

Cannot run editor scripts when paused.
This problem stems from another problem in Unity. Unity doesn't send the View matrix (by design) or Projection matrix (current bug) to the shaders, so you need a script to send them manually. Because of this, you need to have this script continually updating the shader variables even when the game is paused. If they are not updated then the objects render in the same place on the screen no matter where you move the camera. This is a horrible problem with no real fix.

Cannot create a custom collider.
Unity provides no simple way to create your own physics collider object. You can inherit from their built-in Collider class, but you cannot override any methods inside of it. As you can see from the link, I came up with a work-around for what I specifically was trying to accomplish: make a spherical planet collider. It is very similar to what I did in Bullet in the past.

Cannot write depth in pixel shader. (Also explained here.)
I tried implementing a logarithmic depth buffer, but I was greeted with a Cg compilation error when trying to write to the depth register. This is actually a bug in the Cg compiler. It's been fixed in the compiler, but Unity is still using an old version of the compiler which has the bug. I need to test the latest releases of Unity to see if this is still a problem.

Update & Unity

2010-11-15T20:48:00.000-08:00

Wow! I can't really believe it's been 7 months (exactly!) since I last posted an entry here. I wish I had something to show, but sadly I do not. To be honest, I have been all over the place with my development. I experimented with a number of different things, but nothing for an extended period of time. I'm hoping to change that soon though. More on that later, first a list of the things I was working on:

Shadow Mapping
I had actually never done any shadow mapping programming before, so it was more of a learning experience in understanding the concept and what is required. I implemented a simple demo in SlimDX/DirectX 11 and posted a video of it on YouTube, but it really is nothing exciting. Standard, run of the mill, shadow mapping. No fancy tricks in the implementation.

Parallel City Generation
I pulled out the old procedural city generator code I blogged about before and updated and refactored the road generator to be able to run in parallel. This allowed me to draw the roads as they were being created. I thought it was pretty cool looking. My goal was to parallelize it to the point where I could implement it as a compute shader, but I couldn't seem to get it to that point. So, I kind of gave up on it.

Bullet Physics
I decided to go back and start messing around with physics again, and I used XNA and BulletSharp this time. I was working on an idea that I've had brewing in the back of my brain for quite awhile. I made some decent progress and was quite happy. However, I started thinking about how I was essentially writing my own game engine (terrain, lighting, shadowing, physics integration). Plus, looking at the target platforms for XNA (Xbox 360, Windows Desktop, Windows Phone), I started wondering if that was best for me. So, that led me to the next item.

Unity
For several months Unity had been looking appealing to me. Two of the biggest pulls for me were C# scripting (via the Mono Framework) and PhysX integration. The wide array of supported platforms was also a huge plus (Mac, Windows, iPhone, iPad, Web). When they announced support for Android as well, I was "sold" in a manner of speaking (as I have an Android phone myself). So, I installed the free version of Unity and tried to see if I could implement the functionality I had already implemented via BulletSharp and XNA inside of Unity scripting itself. One weekend later, I had accomplished that and more!

I'll be honest, Unity is far from the perfect engine. It severely limits you due to the wide range of hardware specs that it runs on. Don't expect to be doing any tessellation or compute shaders here. Heck, it doesn't even support geometry shaders! However, it does seem to be a very well organized engine with good documentation on their webpage and a component based system that I love. I like it enough to at least fiddle around with it some more over the next couple of months.

An added bonus is that my prototypes can be deployed to my server which means you (the reader) can run them in your browser without installing the them. Expect to see a Perlin Noise example soon. :-) That really has become my "Hello World" program for testing different graphics APIs.

A final note I'd like to leave here is regarding some other "big" game engines. I was slightly surprised last week to hear not just one, but two game engines have essentially "imploded". Both Torque and Gamebryo are closing up shop and looking for buyers. That leaves Unity looking even stronger.

Until next time!

Spherical Terrain Physics

2010-04-15T22:36:00.000-07:00

For quite a long while I have been trying to figure out how exactly to do collision detection on my procedurally generated, tessellated, spherical terrain.

The problem lies with the fact that terrain itself doesn't really exist until the GPU. I generate a simple spherical mesh on the CPU and then send it to the GPU to draw. Once there it is tessellated based upon the distance to the camera and then it is displaced via a summation of Perlin Noise.

Obviously this makes it very hard to do collision detection on the CPU side. Many physics engines support a special heightmap object for terrain, but they all assume the terrain is on a plane (usually the XZ) with one axis being the displacement axis (usually the Y). Of course that wouldn't work for spherical terrain. Most physics engines also have a generic triangle mesh object. However these are usually meant to be static meshes and therefore are hard to tessellate. It would require destroying and recreating a mesh on the fly, which would be rather slow and wasteful.

What I really needed was the ability to create a collision shape that was defined by an equation (the Perlin sum in my case). In the past I have always used PhysX, but since it is closed source I decided to try this out in another physics engine. I hopped onto the Bullet forums and posed the question. I was told that it should be possible if I created a new shape object that inherited from the base concave object and overrode its ProcessAllTriangles() method to use the equation.

So, I went and did exactly that. Lo and behold it worked!

First, I created a shape called btSphericalTerrainShape which inherits from btConcaveShape. It takes 3 parameters to setup: The center point of the terrain, the radius of the terrain (including the maximum offset of the terrain) which is used for the bounding box, and a function pointer that points to a function that defines the terrain's equation.

btSphericalTerrainShape(const btVector3& center, btScalar radius, btVector3 (*calcVertex)(const btVector3& position, const btVector3& center));

The function pointer passes along 2 parameters: the current point being evaluated (usually one of the corners of the other object's bounding box), and the center point of the terrain. This allows the terrain to be defined by practically any method desired.

For example, if you wanted to define the terrain as a simple sphere with a radius of 50, you would use the following method:

btVector3 calculateTerrainVertex(const btVector3& position, const btVector3& center)

    return (position - center).normalized() * 50.0f;

If you wanted to define the terrain as a sphere with a radius of 50 that was offset by 8 octaves of Perlin Noise, you would use this method:

btVector3 calculateTerrainVertex(const btVector3& position, const btVector3& center)

    btVector3 normalized = (position - center).normalized();

    double result = PerlinNoise::fBm(normalized.x(), normalized.y(), normalized.z(), 8);

    return normalized * btScalar(50.0f + result * 10.0);

Now, for the details on the ProcessAllTriangles() method. It takes an axis aligned bounding box (AABB) for the other shape being tested and a callback that is called for each triangle that collides with that bounding box.

These are the steps done in the method:

1) Calculate the 8 corners of the AABB
2) Calculate the midpoint of each of the 6 sides of the AABB
3) Calculate the position of the vertex on the terrain by calling the calculateTerrainVertex function pointer
4) Determine which of the corners of the AABB are colliding with the terrain by checking if the bounding box corners are closer to the center point than the respective terrain vertices
5) Find which 3 sides of the AABB are closest to the terrain in order to prevent extraneous triangle processing
6) Use the callback to process each triangle that collides

For the actual implementation details, be sure to download the source code for the btSphericalTerrainShape.

btSphericalTerrainShape.h
btSphericalTerrainShape.cpp

Sobel Filter Compute Shader

2010-04-08T22:24:00.000-07:00

Thanks to Josh Petrie, I now have the Compute Shader working with the swap chain backbuffer. I decided a good first test is to use a Compute Shader to run a Sobel Filter on an image and display the result in the backbuffer.

It was all very easy to get set up. First you create a DirectX 11 swap chain, just like normal. The only difference is the Usage property of the swap chain has an additional flag set which is (Usage)1024 and it represents UnorderedAccess. This allows the backbuffer to be used as an output UAV in the Compute Shader.

RenderForm form = new RenderForm("SlimDX - Sobel Filter Compute Shader");

form.ClientSize = new Size(1024, 1024);

SwapChainDescription swapChainDesc = new SwapChainDescription()

    BufferCount = 1,

    Flags = SwapChainFlags.None,

    IsWindowed = true,

    ModeDescription = new ModeDescription(form.ClientSize.Width, form.ClientSize.Height, new Rational(60, 1), Format.R8G8B8A8_UNorm),

    OutputHandle = form.Handle,

    SampleDescription = new SampleDescription(1, 0),

    SwapEffect = SwapEffect.Discard,

    //(Usage)1024 = Usage.UnorderedAccess

    Usage = Usage.RenderTargetOutput | (Usage)1024

};

Device device;

SwapChain swapChain;

Device.CreateWithSwapChain(null, DriverType.Hardware, DeviceCreationFlags.Debug, swapChainDesc, out device, out swapChain);

The rest of the setup is standard stuff. You grab the backbuffer texture, load the image to run the filter on, and load/compile the Compute Shader.

Texture2D backBuffer = Texture2D.FromSwapChain<Texture2D>(swapChain, 0);

RenderTargetView renderView = new RenderTargetView(device, backBuffer);

Texture2D flower = Texture2D.FromFile(device, "flower.jpg");

ShaderResourceView resourceView = new ShaderResourceView(device, flower);

ComputeShader compute = Helper.LoadComputeShader(device, "Sobel.hlsl", "main");

UnorderedAccessView computeResult = new UnorderedAccessView(device, backBuffer);

The "render" loop doesn't contain any actual rendering. It sets up the render target and viewport like normal, but then it sets the Compute Shader and runs it. After the Compute Shader is ran, the swap chain is told to present the backbuffer, which now contains the Compute Shader output.

device.ImmediateContext.OutputMerger.SetTargets(renderView);

device.ImmediateContext.Rasterizer.SetViewports(new Viewport(0, 0, form.ClientSize.Width, form.ClientSize.Height, 0.0f, 1.0f));

MessagePump.Run(form, () =>

    device.ImmediateContext.ClearRenderTargetView(renderView, Color.Black);

    device.ImmediateContext.ComputeShader.Set(compute);

    device.ImmediateContext.ComputeShader.SetShaderResource(resourceView, 0);

    device.ImmediateContext.ComputeShader.SetUnorderedAccessView(computeResult, 0);

    device.ImmediateContext.ComputeShader.SetConstantBuffer(constantBuffer, 0);

    device.ImmediateContext.Dispatch(32, 32, 1);

    swapChain.Present(0, PresentFlags.None);

});

That's it for the CPU side, now let's look at the GPU side. It's a standard Sobel Filter that only has an input texture and an output texture. The output can either be the Sobel result alone, or it can be the Sobel result laid over the input texture.


Texture2D Input : register(t0);
RWTexture2D Output : register(u0);

[numthreads(32, 32, 1)]
void main( uint3 threadID : SV_DispatchThreadID )
{
    float threshold = 0.20f;
    bool overlay = true;
    
    // Sample neighbor pixels
    // 00 01 02
    // 10 __ 12
    // 20 21 22
    float s00 = Input[threadID.xy + float2(-1, -1)].r;
    float s01 = Input[threadID.xy + float2( 0, -1)].r;
    float s02 = Input[threadID.xy + float2( 1, -1)].r;
    float s10 = Input[threadID.xy + float2(-1,  0)].r;
    float s12 = Input[threadID.xy + float2( 1,  0)].r;
    float s20 = Input[threadID.xy + float2(-1,  1)].r;
    float s21 = Input[threadID.xy + float2( 0,  1)].r;
    float s22 = Input[threadID.xy + float2( 1,  1)].r;

    float sobelX = s00 + 2 * s10 + s20 - s02 - 2 * s12 - s22;
    float sobelY = s00 + 2 * s01 + s02 - s20 - 2 * s21 - s22;

    float edgeSqr = (sobelX * sobelX + sobelY * sobelY);
    float result = 1.0 - (edgeSqr > threshold * threshold); //white background, black lines
    Output[threadID.xy] = result;
    if (overlay && result != 0.0)
    Output[threadID.xy] = Input[threadID.xy];       
}

That's it! I already improved the code so that the threshold float and overlay boolean are in a constant buffer that is set on the CPU side, but I figured I'd keep the code posted here as simple as I could.

Here was my input image:

And here is the the output image (input + Sobel result overlay):

Nothing too spectacular, but the main focus was the Compute Shader + backbuffer, not the actual Sobel Filter. Enjoy!

By the way, you may have noticed that my C# code snippets now use the same syntax highlighting as Visual Studio. I installed the CopySourceAsHtml add-on and it seems to work pretty well.

SlimDX Issue

2010-04-07T09:19:00.000-07:00

In my previous post I mentioned how my next goal was to use the Compute Shader to write directly to the backbuffer. Unfortunately, it appears that this is not currently possible using SlimDX.

In order to write to the backbuffer, the swap chain needs to be created with an unordered access usage flag. This means that that resource can then be used as a UAV output in a Compute Shader. There are a couple examples floating around online where people have done this using the DXGI_USAGE_UNORDERED_ACCESS flag in C++ code.

In SlimDX, that enumeration has been wrapped into the Usage enumeration in the DXGI namespace. However, it is missing an UnorderedAccess option. It contains all of the other ones defined in the original C++ code though. I believe it was just a mistake and accidentally missed during the update to DX11. (At least I hope it wasn't intentional!)

I posted an issue on the SlimDX Google Code page, so hopefully this gets resolved.

Simple Compute Shader Example

2010-04-04T22:23:00.000-07:00

The other big side of DirectX 11 is the Compute Shader. I thought I would write up a very simple example along the same lines as my tessellation example.

First let me say that the Compute Shader is awesome! It opens up so many possibilities. My mind is just reeling with new ideas to try out. Also I must mention that SlimDX really does a great job of minimalizing the code necessary to use the Compute Shader.

This example shows how to create a Compute Shader and then use it to launch threads that simply output the thread ID to a texture.

Device device = new Device(DriverType.Hardware, DeviceCreationFlags.Debug, FeatureLevel.Level_11_0);

ComputeShader compute = Helper.LoadComputeShader(device, "SimpleCompute.hlsl", "main");

Texture2D uavTexture;

UnorderedAccessView computeResult = Helper.CreateUnorderedAccessView(device, 1024, 1024, Format.R8G8B8A8_UNorm, out uavTexture);

device.ImmediateContext.ComputeShader.Set(compute);

device.ImmediateContext.ComputeShader.SetUnorderedAccessView(computeResult, 0);

device.ImmediateContext.Dispatch(32, 32, 1);

Texture2D.ToFile(device.ImmediateContext, uavTexture, ImageFileFormat.Png, "uav.png");

Believe it or not, but that is the entirety of my CPU code.

Here is what is going on in the code:
1) Create a feature level 11 Device, in order to use Compute Shader 5.0
2) Load/Compile the HLSL code into a ComputeShader object.
3) Create a 1024x1024 UnorderedAccesdView (UAV) object which will be used to store the output.
4) Set the ComputeShader and UAV on the device.
5) Run the Compute Shader by calling Dispatch (32x32x1 thread groups are dispatched).
6) Save the output texture out to disk.

My HLSL code is even simpler:


RWTexture2D<float4> Output;

[numthreads(32, 32, 1)]
void main( uint3 threadID : SV_DispatchThreadID )
{
    Output[threadID.xy] = float4(threadID.xy / 1024.0f, 0, 1);
}

As you can see a RWTexture2D object is used to store the output (this is the UAV). The shader is setup to run 32x32x1 threads. This means that since the CPU is launching 32x32x1 thread groups, then there are 1024x1024x1 separate threads being run. This equates to 1 thread per pixel in the output UAV. So, in the UAV, the color is just set based upon the thread ID.

This code results in the following output image:

Quite simple, eh? But not that interesting. We could easily do something like that with a pixel shader (although we would have to rasterize a full-screen quad to do it).

We should try to do something that shows the power of the compute shader; something you couldn't do in a pixel shader before. How about drawing some primitives like lines and circles?

For drawing lines, let's use the Digital Differential Analyzer algorithm. It translates to HLSL very easily.


void Plot(int x, int y)
{
   Output[uint2(x, y)] = float4(0, 0, 1, 1);
}

void DrawLine(float2 start, float2 end)
{
    float dydx = (end.y - start.y) / (end.x - start.x);
    float y = start.y;
    for (int x = start.x; x <= end.x; x++) 
    {
        Plot(x, round(y));
        y = y + dydx;
    }
}

For drawing circles let's use the Midpoint Circle algorithm. For brevity I won't list it here now.

Then, in my Compute Shader main function, I simply add this code:


if (threadID.x == 1023 && threadID.y == 1023)
{
   DrawLine(float2(0, 0), float2(1024, 1024));
   DrawLine(float2(0, 1023), float2(1023, 0));
     
   DrawCircle(512, 512, 250);
   DrawCircle(0, 512, 250);
}

The if check is just done to prevent the lines and circles from being drawn for every thread. This code results in the following image:

I must admit it seems quite odd writing a shader that draws primitives. It's like some strange recursive loop. But it definitely helps to illustrate the features of the Compute Shader and how powerful it is.

You may download the source code to this example here:
ComputeShader11.zip

My next goal is to setup a standard DX11 Swap Chain and use the Compute Shader to write directly to the backbuffer. Well that's all for now.

FYI: This is my 50th blog post! I never thought I would continue on this long. I think I should crack open a beer to celebrate.

Watertight Adaptive Tessellation

2010-03-09T13:29:00.000-08:00

The next obvious step for tessellation is to make it adaptive based upon the distance to the camera. It is important to keep the tessellated mesh watertight in order to prevent cracks from appearing between separate quads.

There are five different ways (that I can think of) to address this problem.

1) Do absolutely nothing

For the longest time with my original LOD algorithm this is the path I followed. If you are okay with having nasty cracks in your mesh, then this is definitely the way to go. But that is no longer acceptable to me.

2) Cheap fix (force all edges to be 1)

If all quad edges are not subdivided at all, then there will be no cracks and it will be fast. The problem is there will be no detail at the edges, and this quickly becomes very obvious and ugly.

3) Expensive fix (force all edges to be 64)

Here is the flip-side to the previous option. All quad edges are subdivided to the maximum level. This ensures that the best detail will be used at each edge. However this is too expensive to do for all quads.

4) Be smart about it (use adjacency information)

This is the method that Jack Hoxley uses and describes here. Basically he builds a vertex buffer that contains the 4 vertices of the quad plus another 8 vertices representing the 4 adjacent quads. In the hull shader, he calculates the midpoint of each quad and then calculates the distance (and thus a tessellation factor) from the midpoint to the camera. He chooses the minimum factor for each edge in order to have the quads match.

This is a pretty good solution, but it requires building a large vertex buffer containing adjacency information, as well as the additional midpoint calculation in the hull shader.

5) Do it right (calc factors from each vertex)

The next question is, can we do efficient watertight adaptive tessellation without adjacency information or the midpoint calculation? The answer is yes! If we calculate the tessellation factors from the vertices themselves, then we can guarantee that the surrounding quads will use the same factors (because they are using the same vertices).

The basic algorithm is this:
- Calculate the tessellation factor based on camera distance for each of the 4 vertices


float distanceRange = maxDistance - minDistance;
float vertex0 = lerp(minLOD, maxLOD, (1.0f - (saturate((distance(cameraPosition, op[0].position) - minDistance) / distanceRange))));
float vertex1 = lerp(minLOD, maxLOD, (1.0f - (saturate((distance(cameraPosition, op[1].position) - minDistance) / distanceRange))));
float vertex2 = lerp(minLOD, maxLOD, (1.0f - (saturate((distance(cameraPosition, op[2].position) - minDistance) / distanceRange))));
float vertex3 = lerp(minLOD, maxLOD, (1.0f - (saturate((distance(cameraPosition, op[3].position) - minDistance) / distanceRange))));

- Use the minimum value for each edge factor (pair of vertices)


output.edges[0] = min(vertex0, vertex3);
output.edges[1] = min(vertex0, vertex1);
output.edges[2] = min(vertex1, vertex2);
output.edges[3] = min(vertex2, vertex3);

- Use the overall minimum value for the inside tessellation factor


float minTess = min(output.edges[1], output.edges[3]);
output.inside[0] = minTess;
output.inside[1] = minTess;

Note: I originally thought the inside factor should be the maximum of the 4 vertices, but I after viewing it in action, I felt that the minimum was better.

That's it! Simple, fast, and easy watertight adaptive tessellation.

Check out the video of it in action: (I recorded the video at 1280x720, so be sure to view it at 720 to see the little details.)

Cube to Sphere Tessellation

2010-03-04T00:39:00.000-08:00

My previous tessellation example was just a 2D, screen-space quad. My latest example steps into the world of 3D.

No code to share, just a pretty little video. It shows a cube being tessellated on the fly to form a sphere. What's being done is each quad is being tessellated and then the vertex position is normalized.

I was lazy and instead of making an entire cube with 6 sides, I only built a vertex/index buffer for 3 sides. You can only tell when I move the camera around at the end of the video.

I was getting about 1500 fps for the cube and about 900 fps for the fully tessellated sphere. 63*63*3*2 = 23,814 triangles!

Here ya go:

Simple Tessellation Example

2010-03-01T22:11:00.000-08:00

I have finally got my computer all setup with the Radeon 5450 and started doing some DirectX 11 development. Obviously the first thing I tried out was the tessellation.

There are some nice sample projects included in the DirectX SDK that cover tessellation, but I felt that they were a little too ... complex. Don't get me wrong, I feel that they are great samples of doing things like model subdivision, detail tessellation, and bezier curves. I just felt that there should be a very simple demonstration of tessellation in the most basic sense. I decided to write one myself and share it here.

I should note that this was written using SlimDX. I love having the power of DirectX in C#!

As I stated, this is pretty much the most basic example of tessellation I could think of. It has one single quad with vertices defined in screen-space, which allows us to skip any transformation. The shader then tessellates the quad by using hard-coded tessellation factors. That's it!

The main application code isn't that important. It just creates the vertex buffer consisting of 4 vertices. It then draws using the new "4 control point patch" primitive. All the rest of the magic happens in the HLSL code.

The vertex shader isn't that impressive. It is simply a pass-through shader and passes the vertex position through to the hull shader.


VS_OUTPUT VS( VS_INPUT input )
{
 VS_OUTPUT output;
 
 output.position = input.position;
 
 return output;
}

The hull shader constant fuction simply sets the hard-coded tessellation factors for the edges and inside. Currently I have it hard-coded to a factor of 32. You may manually change this value to be anywhere from 1-64.


HS_CONSTANT_OUTPUT HSConstant( InputPatch<VS_OUTPUT, 4> ip, uint pid : SV_PrimitiveID )
{
 HS_CONSTANT_OUTPUT output;
 
 float edge = 32.0f;
 float inside = 32.0f;

 output.edges[0] = edge;
 output.edges[1] = edge;
 output.edges[2] = edge;
 output.edges[3] = edge;

 output.inside[0] = inside;
 output.inside[1] = inside;

 return output;
}

The hull shader itself does not perform a basis change, and therefore it passes through all 4 of the input points to the output. As you can see from the attributes, it is operating on the quad domain and it uses the standard clockwise winding.


[domain("quad")]
[partitioning("integer")]
[outputtopology("triangle_cw")]
[outputcontrolpoints(4)]
[patchconstantfunc("HSConstant")]
HS_OUTPUT HS( InputPatch<VS_OUTPUT, 4> ip, uint cpid : SV_OutputControlPointID, uint pid : SV_PrimitiveID )
{
    HS_OUTPUT Output;
    Output.position = ip[cpid].position;
    return Output;
}

Before explaining the domain shader, let me first explain the orientation of the UV coordinates coming from the tessellator.

Let's assume your vertices are defined in this manner:


   u
 0-----1
v|     |
 |     |
 3-----2

The U dimension ranges from [0-1] in the direction of vertex 0 to vertex 1.
The V dimension ranges from [0-1] in the direction of vertex 0 to vertex 3.

I specifically state this now because I had wrongly assumed that it was oriented such that the U and V coordinates were reversed, like so:


  WRONG!
 1-----2
 |     |
v|     |
 0-----3
   u

Now, about the domain shader itself. This is normally where the samples got rather complex calculating bezier curves and such. This is the simplest algorithm I could come up with. It uses three linear interpolations to calculate the vertex position. I visualize it as sliding two lines along the the quad and marking where they intersect as the vertex.

The first lerp finds the "midpoint" between vertex 0 and 1 by a factor of U.
The second lerp finds the "midpoint" between vertex 3 and 2 by a factor of U.
The third lerp finds the "midpoint" between the first and second calulated midpoints by a factor of V.

This is rather hard to "draw" a diagram for, but hopefully this makes some sense:


  lerp1
 0--|--1
 |  _  | lerp3
 |     |
 3--|--2
  lerp2

The color of the vertex is set based upon the tessellation UV coordinates.


[domain("quad")]
DS_OUTPUT DS( HS_CONSTANT_OUTPUT input, float2 UV : SV_DomainLocation, const OutputPatch<HS_OUTPUT, 4> patch )
{
    DS_OUTPUT Output;
    
    float3 topMidpoint = lerp(patch[0].position, patch[1].position, UV.x);
    float3 bottomMidpoint = lerp(patch[3].position, patch[2].position, UV.x);
    
    Output.position = float4(lerp(topMidpoint, bottomMidpoint, UV.y), 1);
    Output.color = float4(UV.yx, 1-UV.x, 1);
    
    return Output;    
}

The pixel shader just writes out the color.


float4 PS( DS_OUTPUT input ) : SV_Target
{
 return input.color;
}

There you have it! Hopefully this simple example of tessellating a single quad will be useful to other people and help to illustrate how the tessellator works.

You can download the full source to this example here: Tessellation.zip

Quick Update

2010-02-19T15:20:00.000-08:00

DirectX 11
I attended GameFest 2010. I can't say much except that I want to work with DX11 even more than before, if that was possible. As a result, I just bought a Radeon 5450 from newegg. Sure, it is a rather weak card, but it is only $35! Plus, it is much faster than the reference rasterizer and it only consumes 19 watts at full usage!

Here is the card I bought:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814131339

It should hold me over until the Nvidia 400 series cards come out in a month or two.

SlimDX
Talk about perfect timing! The latest version of SlimDX was just released today. The D3D11 wrapper should be even more stable than what it already was.

You can download it from here:
http://slimdx.org/download.php

Procedural Cities in XNA

2009-12-27T01:12:00.000-08:00

It's been quite a while since I've talked about any development I've been doing. To be honest I have been quite busy with work and flight lessons, so I don't have much time to work on my hobby projects.

Lately I have been working on a procedural city generator in C#/XNA. I'm basing my work on the Metropolis project, which was in turn based upon a research paper presented at SIGGRAPH 2001.

I began with the procedural road map generator. It takes a heightmap and generates a road network from it.

Zooming in you can begin to see the subdivisions between streets where buildings will be built.

Zooming in even further makes the building lots even clearer.

Next, I began work on the 3D building creation. Here you can see many simple buildings all using the same texturing.

I then added more texture variety.

I finally added in the terrain with road texturing.

Zoomed out view showing the vast number of buildings generated.

And the final image showing "Central Park" (this city was generated from a heightmap of Manhattan).

I want to eventually release the source code for this, but first I need to clean up the code some more. I also need to tweak the renderer to run faster. Right now it is just brute forcing it, and doesn't utilize any form of level of detail or frustum culling.

SlimDX August 2009 Release

2009-10-10T18:15:00.000-07:00

A new version of SlimDX is now available. This version wraps the latest DirectX SDK release (August 2009, thus the name). This means that things like DirectX 11 and Direct2D are now officially supported (previous releases were beta).

You can download the installer here:
http://code.google.com/p/slimdx/

You can also read a little more about this release at the GameDev.net forums:
http://www.gamedev.net/community/forums/topic.asp?topic_id=549927

I'm looking forward to trying it out. Unfortunately, I still don't have DX11 hardware, so I'll probably hold off on things like tessellation or the compute shader.

Disappointment

2009-10-03T19:05:00.000-07:00

Since I have never used the Geometry Shader, I've been reading tutorials on how to use it to generate silhouettes and stencil shadows via the adjacency information being passed through the index buffer.

From my posts in the past, it is pretty obvious that I am really excited about tessellation and I want to make use of it ASAP. So, a natural thing that came to my mind was combining the two together to tessellate a mesh and then generate silhouettes.

No can do. I was completely and utterly disappointed to find out that you can NOT use adjacency information alongside the tessellator.

I quote from the official DirectX 11 docs: "A geometry shader that expects primitives with adjacency (for example, 6 vertices per triangle) is not valid when tessellation is active (this results in undefined behavior, which the debug layer will complain about)."

DirectX 11 GPUs have arrived!

2009-09-24T19:50:00.000-07:00

The Radeon HD 5870 is now out in the wild and available for purchase. I'm still unsure if I want to buy it or wait for the 5850 coming out next month. The 5850 is $120 less than the 5870 and the specs aren't that much lower.

On the Nvidia side of things, it's not looking very good. The latest rumors are that they are having incredibly low yields from their chips and as a result have delayed the launch of their DX11 GPUs to the third quarter of 2010. I wonder how this generation will play out if Nvidia's cards don't show up until almost a year after ATI's.

Update:
Apparently the news of the Nvidia delay is just FUD. They have officially announced that the 300 series will still debut in December. Read about it here.

Perlin Noise in DirectX 10 (Shader Model 4.0)

2009-09-13T21:25:00.000-07:00

This is somewhat similar to the classic problem of Good, Cheap, and Fast where you can only have two of them at the same time.

I implemented Perlin Noise entirely on the GPU, meaning no textures are precomputed and no parameters are set on the GPU. The shader is simply loaded and ran. It is a very clean solution and it is incredibly simple to add to any project.

Unfortunately, it is slow. Mind you, it is still much faster than the CPU implementation, but it is slow compared to my original precomputed texture implementation.

I always run my tests using 12 octaves of 3D fBm Perlin Noise summations at a resolution of 1024x1024. It yields much more stable results than just 1 calculation of Perlin Noise. My original implementation ran at about 85 fps. At first, my new simple implementation was running at about 3 fps! Even though the documentation states that HLSL automatically marks all global variables as const, if I put the const keyword before my permutation array my frame-rate jumped up to 19 fps.

I added a gradient lookup table and changed the gradient calculation functions to just index into the table. However, this basically had no impact on the speed. I then reduced the permutation array from 512 to 256 and performed a modulus operation on any indexing into the array. This gave my about a 30% speed increase and got it up to about 25 fps.

I tried various other tweaks, and I was able to get it to go a bit faster, but it was always at the expense of the quality of the noise (wouldn't work with negative values, would look blocky, etc). The fastest I was able to get it and still maintain the high quality Perlin Noise was 25 fps.

I must say that I'm rather disappointed with these results. I had thought that constant memory indexing would be faster than texture lookups, however the texture lookup version was over 3 times faster than the memory indexing version. Perhaps I'm just missing something or I'm implementing the memory indexing incorrectly, but I don't know what I could possibly do to speed it up anymore AND keep the same quality.

For the time being, it looks like texture lookups are the way to go. I've decided to upload 2 versions of the noise code. The first version is a direct port of Ken Perlin's Java code to HLSL(19 fps). The second includes the tweaks to the gradients and permutation array (25 fps).

First Version
Tweaked Version

As I have said, the major advantage to this implementation is the simplicity. All you have to do is include the header in your HLSL code and you can call the noise() and fBm() functions. That's it! You don't have to do anything else. So if you just want to drag and drop some Perlin Noise into a shader, this is the best way to do it, if you don't care about speed.

Soon ... Very Soon

2009-09-09T17:41:00.001-07:00

The August DirectX SDK was released today (shh, don't tell them it's September). This brings with it the first official release of DirectX 11!

You can download it in all of it's glory here:
August DirectX SDK

Note: In order to run the DX11 samples on Vista, you need a patch. Unfortunately, that patch is not yet available, but when it is it should be available here.

In very related news, it looks like the first DirectX 11 GPUs will be available this month. The Radeon HD 5850 will be $300, the Radeon HD 5870 will be $400, and the Radeon HD 5870x2 will be $600.
Read more here

Byte Order Mark - The Invisible Enemy

2009-09-08T07:20:00.000-07:00

Alternate Title:
EF BB BF - The Three Bytes of Doom

Last night I decided to whip out a quick SlimDX / DirectX 10 project implementing Perlin Noise using Shader Model 4.0. In my Perlin Noise on the GPU article, I mentioned how much easier it would be to implement Perlin Noise using SM4.0+ vs SM3.0. I had done a quick port of Ken Perlin's Java example implementation in FX Composer a couple months back, so I thought I would be able to implement the stand-alone version in less than an hour.

I wanted to test it first in a pixel shader, so I made my own custom vertex as well as a class that would build a fullscreen quad vertex buffer. I took the Perlin Noise HLSL code and put it into a header file, and made a simple two-technique shader that included the header.

I fired up the code, but I quickly got an exception (E_FAIL: An undetermined error occurred (-2147467259)) at the point where I was trying to set the InputLayout of the vertex buffer to the shader signature. Not a very useful exception.

At first, I thought it might have been a problem with my custom vertex format. After looking it over and comparing against other custom vertex formats I've made in the past, I determined the issue wasn't there.

Next I looked at how I was creating the vertex buffer and index buffer for the fullscreen quad. That all appeared in order too.

After determining that the issue was not in my custom vertex format or my fullscreen quad, I slowly stepped through the code keeping a close eye on all of the variables. I didn't think there was a problem with my shader because no errors were being output from the compiler, and it was spitting out a valid Effect. However, when stepping through and watching the variables, I saw that even though it created an Effect and the IsValid property was true, it said the TechniqueCount was zero! In fact, all of the counts were saying zero. It was as if the compiler was seeing it as an empty file.

So, I next looked at my shader in detail. I thought maybe something funky was happening with the included header file, so I inlined all of the header code. I still got the exception. I thought it might be some random issue in one of my noise functions, so I changed them to all return 1.0. Exception. I triple checked all of my input and output structures. I looked over my technique description. I changed my vertex shader to be a simple pass-through and the pixel shader to just return white. Exception.

What the heck was going on? I had other shaders that were compiling just fine. So, just as a "stupid" test, I copied one of the my other working shaders and pasted all of the code into my fx file, overwriting everything in it. I still got the exception!

Now I knew something was really messed up somewhere. Here I had two fx files with the exact same HLSL code in them, but one was compiling while the other was not.

I opened both files up using the Binary Editor in Visual Studio to see byte by byte. The file that was not compiling had three extra bytes at the beginning - EF BB BF. I deleted these three bytes, and everything worked!

It turns out that that byte sequence is the Byte Order Mark. It is specifying that the file is UTF-8 encoded. Apparently this is the default for all files created in Visual Studio 2008. Unfortunately, the FX compiler in DirectX can't read UTF-8 files and just dies and returns an empty Effect.

I did a quick Google search after fixing the problem and I saw that several other people had the same problem and eventually came to the same solution. I really wish the compiler would return an error in a situation like this.

What I find very interesting is the fact that I have been programming shaders for over two and a half years, and I have never run into this problem before.

Hopefully this post helps someone else if they encounter this same problem.

Until next time...

Teaser

2009-08-25T08:40:00.003-07:00

I'm not yet ready to fully talk about what I'm working on, but I wanted to give a little preview to whet everyone's appetite.

Yep! 3001 boxes in 1 PhysX scene and still maintaining 29.81 frames per second. The really awesome part is the fact that this is all in C#!

I'll talk more about it later.

Until next time...

Infinite Depth Buffer

2009-07-29T11:34:00.000-07:00

I've been planning out how I'm going to rewrite my planet algorithm once DirectX 11 is out. I've decided to focus on problems I have now that will still be a problem in DX11. One such problem that I've always been having in the past is the depth buffer.

My planet is Earth-sized so in order to keep it visible as you fly away from it, I pushed the far clipping plane way out. Obviously this destroyed the precision of my depth buffer and I had big problems with Z-fighting (far off mountains were being drawn in front of closer ones).

Rant: Why the heck are most GPUs these days still stuck with a 24-bit depth buffer? The Xbox 360 and my GeForce 9800M GT both only support up to a 24-bit depth buffer. DX11 level GPUs will have 64-bit floating point (double) support in shaders, so why not a 64-bit depth buffer?

In the videos and screenshots I have posted in the past, I did two different things to try and fix my problem with the depth buffer. First, I had a "sliding" far clipping plane that would have a minimum value, but as you flew away from the planet, it would extend out in order to continually show the planet. My second solution was to just disable the depth buffer. Both of these solutions only worked because I was drawing only 1 planet and there were no other objects being rendered. Obviously I want to keep my depth buffer around, keep the high precision for any near objects, but continue to draw far off planets (not have them clipped by the far clipping plane).

In order to fully understand my problem, I read about how exactly the depth buffer works and how a position is transfomed and then clipped. I found this article very informative about the inner workings of the GPU in terms of the depth buffer. I did not change my depth buffer to be linear like he does though. The article helped me to understand the relationship between the Z component and W component of the transformed vertex position.

Between the vertex shader and the pixel shader, the Z component is divided by W in order to "normalize" the depth (range 0-1). If the Z value is greater than 1 then it is clipped. So, I needed to make it so that the normalized Z value never exceeded 1. This was a very simple thing to fix, once I understood it. In my vertex shader I check the Z value to see if it is greater than the far clipping plane value (which I pass into the shader). If it is greater, then I simply set the W component equal to the Z component. This means that the Z / W calculation thus becomes Z / Z = 1. Now I can have good depth buffer precision for things close to the camera, but I will continue to draw things even if they are an infinite (theoretically) distance away!

Obviously this solution isn't perfect and there are some "gotchas". If I am drawing a planet and a moon, and the moon is behind the planet, and I am flying away from the planet, AND the moon is being drawn after the planet in the C# code, then the moon will suddenly pop in front of the planet once the planet exceeds the far clipping plane. That means I'll have to have a manager of large objects in the "local system" to make sure they are drawn in back to front order. That should be really easy to implement.

Hopefully this all makes sense and it helps someone else struggling with the same problem.

Until next time...

Update: I would now strongly encourage people to use a Logarithmic Depth Buffer to solve all of your depth buffer precision issues. You can read about it here:

http://www.gamasutra.com/blogs/BranoKemen/20090812/2725/Logarithmic_Depth_Buffer.php

Perlin Noise in JavaScript

2009-07-01T12:39:00.000-07:00

I apologize for not having any update for the month of June, but I was gone on vacation for a majority of it.

I saw tons of places on the road trip. Illinois, Indiana, Michigan, Ontario, New York, Vermont, New Hampshire, Maine, Massachusetts, New Jersey, Delaware, Maryland, Virginia, Pennsylvania, West Virginia, and Ohio (in that order)! I had never been to the New England area of the country, so it was great being able to see it all.

In terms of development, I haven't really done any since I wrote that Perlin Noise article. I've been tossing around the idea in my head to go try out SlimDX again. I know, I know, I just can't make up my mind on things, right? It would just be very convenient to be writing C# again, and I found the great PhysX.Net wrapper that should allow me to continue to use PhysX with my C# development. Plus SlimDX already is supporting DirectX 11, which is awesome! (Tessellation, here I come!)

By the way, I was curious about JavaScript so I developed a simple little webpage that implements Perlin Noise in JavaScript.

You can find it here:
http://re-creationstudios.com/noise/

I used a Canvas element to display the result, so it won't work in Internet Explorer.

Be sure to check out the source code since I implemented several different types of summation as well (fBm, turbulence, and ridged multifractal). Enjoy!

Perlin Noise on the GPU

2009-05-31T09:53:00.001-07:00

I've written a tutorial on how to implement Perlin Noise in both a pixel shader and a vertex shader. The tutorial is available over at Ziggyware.

http://www.ziggyware.com/readarticle.php?article_id=246

Check it out! I welcome any feedback.

UPDATE
http://www.ziggyware.com/news.php?readmore=1125
I found out I have won first place in the Ziggyware contest! I'm very happy that my first XNA tutorial was such a success. Perhaps I will write up more in the future.

PhysX Planet

2009-05-29T10:37:00.000-07:00

Creating planetary gravity with a force field was much easier than I was expecting. Especially after finding this thread on the official PhysX forum.
http://developer.nvidia.com/forums/index.php?showtopic=3201&pid=9249&st=0&#entry9249

After doing that, I got curious and I removed the sphere "planet" but I kept the gravity force field. As expected, all of the shapes grouped together to form their own planet.

After I kept watching it, the planet started pulsing back and forth and eventually tore itself apart in a vortex that alternated back and forth.

The debris vortex started stabilizing and turned into a spinning ring.

The ring kept expanding and getting bigger and bigger.

I added some more cubes to the center, which formed a cool looking planet with a ring.

The planet at the center eventually started breaking apart and forming a ring as well, but what was most interesting was that the inner ring was rotating in the opposite direction of the outer ring.

PhysX and DirectX 10

2009-05-28T11:17:00.001-07:00

For the past week or so, I've been working on getting PhysX working in DirectX 10. I ported over my Shape3D class from my previous blog post to C++ in order to draw the boxes and spheres (no cylinders because PhysX doesn't have a cylinder shape).

I set up a simple scene with a ground plane (not rendered), normal Earth gravity, two boxes and a sphere. The space bar spawns new boxes at the origin and the Alt key spawns new spheres.

In my first implementation, the application would slow down to 20fps when I added about 75 shapes. I tracked down this slowdown to the creation of the vertex input layout each frame. Once I moved that out of the render loop, I could then have 1000 shapes in the scene and still maintain 30fps. I'm still trying to figure out if I can speed up the rendering even more because without rendering, the PhysX engine was able to handle 2000 shapes and maintain 60fps. I doubt I can speed it up much more though.

Here are some screenshots. Pretty simple, but the debug info helps to illustrate the speeds.

I have decided to share the Visual Studio 2008 project and source code to hopefully provide a nice starting point for others. I'm not using an official license or anything, but I'll state that is it free for whatever use you desire, be it commercial, hobby, or education.

Download the zip file: here

Next, I'm going to work on using static triangle meshes in PhysX to have a displaced sphere making up a planet, as well as using force fields to simulate planetary gravity.

Boxes, Cylinders, and Spheres (Oh My!)

2009-04-19T11:46:00.000-07:00

After deciding to use PhysX in combination with DirectX 11 last week, I thought about how I would go about drawing simple 3D shapes. In the samples and lessons, PhysX uses GLUT with has some shape drawing functions built-in. While DX9 has similar functions, neither DX10 nor XNA do. I believe it is safe to assume that DX11 will not have them either. I can understand why they were removed. They don't really make sense anymore in a programmable pipeline system. What is the vertex format of the shape created?

While most people these days get around it by creating a mesh in a 3D modeling application and then importing it into their game, I prefer to have my simple 3D shapes constructed programatically. This allows me to easily change the detail of the mesh without worrying about exporting/importing an entire new model.

Instead of implementing it in DX10 and C++ first, I decided to implement it in XNA. This allowed me to focus on the algorithms themselves and not have to worry about any C++ issues getting in the way.

My initial implementation was a static class that had static methods in it that built the shapes and returned the vertex buffer and index buffer. This worked well, but I thought it still placed too much burden on the user to remember how many vertices they had just created and how many triangles they were going to draw.

In order to make things simpler, I changed it to be a normal, instantiated class that contained the static methods that created an instance of the class. This allowed me to store the vertex count, triangle count, as well as the buffers in instance properties in the class. I even threw in a Draw method to make it incredibly simple to use the generated shape.

Because this is such a basic, fundamental class that can benefit several people ( have seen various people requesting something like this), I have decided to share it with the public.

You may download the C# file from here:
http://re-creationstudios.com/shared/Shape3D.cs

You can also download the entire test project here:
http://re-creationstudios.com/shared/ShapeTest.zip

To use, simply create a shape using one of the static methods:
Shape3D sphere = Shape3D.CreateSphere(GraphicsDevice, 1, 12, 12);

To draw, in your Effect block, call the Draw method on the shape:
sphere.Draw(GraphicsDevice);

The Create methods are made to follow the same structure as the DX9 shape drawing functions. You can read more about those here:
http://msdn.microsoft.com/en-us/library/bb172976(VS.85).aspx

Tactical RPG

2009-04-12T12:55:00.000-07:00

I've been engrossed with learning about DX11 lately. I've looked at slide presentations, listened to audio recordings of speeches, and read various articles discussing the new features being introduced. I believe it's a great understatement to say that I'm excited about DX11. I've finally come to the conclusion that once I have a DX11 GPU, I'm going to rewrite my procedural planet code using DX11.

In the meantime, I've decided to take about 1 month to implement a prototype for a tactical RPG I've been thinking about. I started about 2 weeks ago, and I plan to finish it by the end of April. One of my main goals is to have it completely mouse driven so that it can be played on a tablet.

I believe it is coming along rather well. I have a really nice 2D camera set up that behaves similar to Google Maps. You can use the mouse to drag around the view and you can zoom in and out using the scroll wheel. I have basic movement and attacking implemented as well. I even have one of my graphic designer friends making up some art for me. Overall, it should shape up to be a pretty decent prototype. Maybe I will even release it to the public, source and all.

PhysX

New content for Banjo-Kazooie: Nuts & Bolts was released last week. As a result, I pulled out the game again and played it some more. I wasted several hours just messing around with the vehicle editor to make various contraptions. I started thinking about how much fun it was to just tinker around like that without really following any goals, and then I started wondering about how hard it would be to implement a similar system myself.

Almost 4 years ago, I had implemented a "domino simulator" using what was then known as the NovodeX physics engine. It is now known as PhysX, is owned by Nvidia, and has hardware acceleration. So, I downloaded the SDK and played around with some of the samples.

First, the good. I was simply astounded by how many samples were provided in the SDK. There are 37 samples and 89 "lessons", all with documentation. It is amazing. Plus, the hardware acceleration really helps speed the physics engine up. One of the samples was getting about 40fps in software mode and 130fps in hardware mode. That was on a 9800M GT.

The bad is more about C++ than PhysX. I decided to create a C++ project from scratch and then add all of the libraries and code necessary to get the first lesson from the SDK working. It was horrific. It took me 3 hours to get everything to compile and run. In the end, here is what was in my project:

5 include directories
3 static libraries
- added to both the project and VS itself
- had to add one directly to solution to get to compile
12 include files (separate from the include directories)
8 cpp files
1 dll

Remember, all of that was to run the FIRST lesson, which is just three shapes on a plane. In C#, it would have been 3-4 DLLs and one CS file. As I said, this is more of a complaint about C++ and not PhysX. I forgot how tedious it was to setup a project for the first time. I do plan to stick with PhysX though, because once I do port my procedural planet code over to C++/DX11, then I will want a nice physics engine to go along with it, and it might was well be the only one with hardware acceleration.

Until next time...

Craters

2009-03-18T23:23:00.000-07:00

Another quick update. I have been working on adding craters to the procedural moon. I implemented a Voronoi diagram shader in HLSL and then I tweak it with quite a few different parameters to generate conical pits that are distorted slightly with fBm noise.

I tried for quite a while to get rims around the edges of the craters, but I couldn't get it to work. I tried using a colormap to alter the Voronoi results, but I was having issues with the it. I will continue to tinker around with it because I think having rims would add quite a bit.

Interesting fact: If I add even more fBm noise to the crater distortions, it forms pretty cool canyons:

That's No Moon ...

2009-03-03T22:14:00.000-08:00

Quick update. First, I switched to more "moon-like" textures.

Then, I tweaked some of the parameters to my existing noise function.

Finally, I started messing around with sums of two different noises.

Here's a detail shot showing the "better" noise at the surface.

There's a lot more work to do!

Fixed Lighting + Higher Res

2009-02-19T23:29:00.000-08:00

As I mentioned in my previous post, I was getting some strange vertical lines appearing in my deferred lighting result. After I turned down the ambient light to make the lighting a bit more realistic, the lines became even more pronounced.

Casting that problem aside for a bit, I decided to increase the resolution because 800x600 just wasn't cutting it anymore. I went with a widescreen resolution because both my laptop and my desktop have widescreen screens. I settled on 1280x720 because 1920x1200 would just be overkill right now, in my mind.

The problem with increasing the resolution was that the lines got even worse! Now I was getting horizontal lines as well as vertical lines, so it looked like a big checkerboard mess. I spent several days trying to figure out what was going wrong. At first I thought it was a bad driver/GPU in my laptop. So, I went to test it on my desktop, but I found out that my power supply was dead. Luckily my brother let me remote into his PC and run the app. I got the exact same results, so I knew it wasn't my GPU. I then installed FX Composer to have a better debugging IDE. I soon discovered that I was using wrong texel offsets to sample neighbors in the world position texture. This removed the lines from FX Composer, but they were still appearing in XNA. I was messing around with my sampler filters when I finally fixed the problem by switching them from Point to Linear. While it does get rid of the lines, it comes at a cost. I am now getting about 18fps average. Obviously the change in resolution also figures into that as well.

I have some interesting new screenshots to share.

Deferred Lighting

2009-02-08T17:55:00.000-08:00

This weekend I implemented a lighting system like the one I talked about in my last two blog posts. I'm calling it deferred lighting because it doesn't do any lighting calculation until I have render targets for the scene. I have one render pass that has two targets: one containing the diffuse color of the scene, and the other containing the world position of each pixel. In a second render pass, I calculate the normal of each pixel by sampling it's neighboring pixel world positions. I then simply do a standard lighting calculation using the normal and the diffuse color of the scene.

It also has much better performance compared to the brute force 32 noise calculations method. At low altitudes I was getting 16fps with the noise method and 33fps with the deferred method. At high altitudes I was getting 12fps and 30fps, respectively. As you can see, I was getting at least double the framerate all the time.

Now for some pretty pictures. They are not much different from my previous lighting pictures, the important thing is that they are being rendered much faster now. I also fixed a slight bug I had in the previous lighting that made the light direction the same for every side of the planet (there was no dark side). There are some strange vertical lines that are appearing which you can see in some of the screenshots below. I'm not sure why they are there, but I will continue to investigate them.

In the last picture you can see the detailed designs that are being generated for the terrain itself. Just to show a difference between the lit vs diffuse renderings, here is the diffuse texture alone for the last picture.

Per Pixel Normal Calculation

2009-02-05T13:06:00.000-08:00

Sorry, still no actual code or pretty pictures!

I just wanted to write up a quick note related to my second topic in my previous post. I did some Googling to see if any other people have implemented a similar system and indeed some people have. In fact I found an article by Microsoft that describes exactly what I was talking about.

http://msdn.microsoft.com/en-us/library/cc308054(VS.85).aspx

In the article, they are creating procedural materials dynamically, so they have to calculate normals dynamically as well.

From the article:
"One solution is to run the shader multiple times and compute the difference in height at each sample point. If we calculated the height one pixel to the right of the currently rasterized pixel and one pixel above the currently rasterized pixel, we could compute tangent and bitangent vectors to the central pixel. Doing a cross product on these would give us the normal for that point."

What I found funny is how they start talking about the ddX and ddY functions in HLSL but in the end they still use the render target + second pass method.

"The solution that this sample uses by default is to render the perturbed heights of the objects in the scene into an off-screen render target. That render target is then read back in on another pass. For each pixel on the screen, its right and top neighbors are sampled. Tangent and bitangent vectors are created from the neighbors to the central pixel. A cross product between these will give the normal."

I now feel very confident about this method of doing things and I will proceed to implement lighting in this manner. I will probably branch off of my existing planet codebase so I can easily compare the differences between the brute-force noise calculation vs the "deferred" style.

Hello 2009!

2009-02-03T11:43:00.000-08:00

I just realized that I never wrote an entry for January. It's the first month that I have not had an update since I started this dev blog. To be honest, I didn't have much to report. I haven't really written any code but I have been thinking about a lot.

At first I was thinking about physics. I thought it would be nice to actually have collision detection with my terrain and possibly throw balls around or maybe even drive a car. However there was a big problem with this. How do I detect collision with a mesh that is deformed entirely on the GPU? Obviously I would have to have some way of sending the physics data to the GPU, do the collision detection there, and then somehow pass the resultant data back to the CPU.

Getting the data to the GPU is the easy part, I think. If I only use bounding spheres for all of the objects, then I can simply pass one normal Color texture to the GPU containing the position of each sphere in the RGB and the radius of the sphere in the Alpha. It may even be possible to set a constant memory buffer (ie array) with the data, which would be even easier.

Once I have this data, I can run through each object in the vertex shader to see if it collides with the current vertex. The problem I ran into then is I don't know how to get the data back to the CPU. I would obviously want to write the data to a render target. Unfortunately, the collision data is in the vertex shader. Pixel shaders cannot index into memory in XNA/DX9/SM3.0. [In DX10/SM4.0 they can index into constant memory, in DX11/SM5.0 both the vertex and pixel shaders can read and write to dynamic resources.] I have no idea how I would pass the data from the vertex shader to the pixel shader.

That means I must somehow do the collision detection in the pixel shader. However, this means that I will be doing the checks for every object, for every pixel. That will be massive overkill. I couldn't come up with a good solution, so I pretty much gave up on physics for now. It should be a cinch in DirectX 11 and Shader Model 5.0!

The next thing I was thinking about was mainly efficiencies. Currently I am calculating the normal in the pixel shader by doing 32 noise calculations per pixel. This is quite a strain on the GPU. I was reading an article about deferred rendering and I had a thought. If I only output the height of each pixel to a render target, then I could have another pass that reads the neighboring pixels in the render target into order to calculate the normal. This means it would one pass that does 8 noise calculations per pixel and then a second pass that does 4 texture lookups per pixel. I imagine that would be a much faster way of doing things.

I have yet to actually implement anything though. So everything here is just speculation. Sorry for no pretty pictures. I will try to get something worth showing off sometime soon.

Starfields & Nebulas

2008-12-22T00:42:00.000-08:00

Instead of focusing on craters (which I implied I was going to do last time), I decided to look into generating starfields and distant (ie 2D) nebulas.

I started on simple starfields and I had a working solution in less than an hour by simply drawing star sprites in random positions.

This yields the following result:

Next, in order to make the stars more interesting, I looked into implementing nebula clouds. I knew that some summation of Perlin Noise would be the best solution. So, I decided to implement a Perlin Noise function in C#. I have a really fast implementation in HLSL, but I wanted the full power of breakpoints and variable watches. I ended up using a standard fBm summation with an exponential filter applied to it.

This helped to produce this nebula cloud image:

I still need to blend these two results together and construct them into a decent cubemap.

World of Warcraft + 360 Controller

All of that work done on the starfields and nebulas was done a couple weeks ago. My co-workers recently pressured me into playing World of Warcraft again. (About 6 months ago, I got up to level 18, and then quit.) As I was playing I kept thinking about how bad the controls were. I was moving my hands all over the keyboard to use all of my skills. It was fine for just grinding along and completing quests, but grouping and duels I always performed horribly. I desparately wanted to play with a game controller, however World of Warcraft didn't support them. There were a couple of applications that other people had written to allow gamepads, but I didn't care for them either. One was very ackward and built up macro commands that you had to then "submit" by pulling the right trigger. Another one seemed decent, but it had a subscription fee of $20 a year.

I decided that if I wanted something done right, I had to do it myself. So, I threw together a quick XNA application that read the 360 controller input. It would then use the Win32 function SendInput to place keyboard and mouse input events into the Windows input queue. I mapped out all of the controls and I was then able to play World of Warcraft using a 360 controller! I can target enemies, target allies, use all 12 skills on the current action bar, switch action bars, loot corpses, and even move the camera with full analog control using the 360 controller! It has completely changed the game for me and I even won my first duel last night.

I have now taken the app and added in mappings for Call of Duty 4 for my brother. I'm planning on converting the project to be more generalized so that the input mapping can be defined in XML and easily changed without recompiling.

Lighting Revisited (AKA I'm Back!)

2008-12-04T23:53:00.000-08:00

So, after almost 3 months of being sidetracked with various other projects I came up with, I finally decided to come back to C# and XNA with welcome arms.

And I have come back in a big way, in my opinion. After discussing it with one of my friends, I decided that it would be best to procedurally generate a moon instead of a planet. This greatly simplifies many things; no atmosphere, no fog, no water, no vegetation, etc. However, this meant that I needed to figure out how to properly do two things: generate craters and have realistic lighting.

You may recall that I had a previous blog entry about my attempts with realistic lighting. [http://recreationstudios.blogspot.com/2008/07/do-you-see-light.html] In the end, I determined that it would be too difficult to do now, and easy to do in the future once I had geometry shader support. So, I had settled with simple spherical lighting across the entire planet.

So, it took me quite a bit of effort to even start looking at alternative ways to render realistic lighting. In the past I was trying to calculate the other two vertices of the triangle in the vertex shader. It was with a great facepalm that I realized that what I was trying to find was the tangent of the surface and then I could use that to adjust the spherical normal. Well, as you may remember from your math classes, a tangent is calculated by taking the derivative of the original function. So, I looked into quite a few articles about how to find the derivative of a Perlin Noise function.

This article was very informative, but I wasn't quite sure on what speeds would be on the GPU:
http://rgba.scenesp.org/iq/computer/articles/morenoise/morenoise.htm

Finally, I found an article by Ken Perlin himself that shows how to approximate the derivative:
http://http.developer.nvidia.com/GPUGems/gpugems_ch05.html (Section 5.6)

With this little nugget of knowlege I went into my shader and wrote a function to do exactly that.

float3 NoiseDerivative(float3 position, float e)
{
//calculate the height values using Perlin Noise
float F0 = ridgedmf(position*noiseScale, 8);
float Fx = ridgedmf(float3(position.x+e, position.y, position.z)*noiseScale, 8);
float Fy = ridgedmf(float3(position.x, position.y+e, position.z)*noiseScale, 8);
float Fz = ridgedmf(float3(position.x, position.y, position.z+e)*noiseScale, 8);
float3 dF = float3(Fx-F0, Fy-F0, Fz-F0) / e;

//calculate the actual normal
return normalize(position - dF);
}

Then I simply added a call to this function in my pixel shader:
input.Normal = NoiseDerivative(input.Normal, 0.000001);

Lo and behold, it worked!

Check out the pics:

Sidetracked

2008-11-07T12:52:00.000-08:00

Wow, it has been awhile and I haven't really had time to work on my graphics projects. I have been really busy at work. When I do finally make it home, I usually get sidetracked with other things. I finally got to level 60 in Mass Effect. I am over halfway through the excellent novel Prey by Michael Crichton (I can't believe he's dead now). I have also been piecing together ideas for my own novel (I've always wanted to write a novel).

In terms of the DirectX 10 work, I did manage to get multiple render targets working. However, I got sidetracked by a bright idea I came up with involving using "strokes" generated in the geometry shader to do some NPR post processing. I was having a hell of a time trying to get multiple vertex buffers working. As I was investigating though, I found out that it wouldn't work anyway because the buffer size is limited to 16-bits (65,536 vertices). I needed more than that ... alot more. It would be a rather long explanation to explain why, so I'll just say that I was trying to essentially use the vertex shader as a pixel shader.

XNA 3.0 is out now, and I'm really surprised that I have not yet downloaded it. It sounds like they added in some nice features though (new Media classes, ClickOnce deployment, etc.).

I am really missing C#, so I may just go back to XNA and just wait for it (or some other C# graphics library) to get Geometry Shader support.

I was also reading about some of the features that are going to be in C# 4.0, and I am really excited. They are finally adding in optional parameters. Plus they are adding a dynamic type, which could prove useful in some cases.

It's getting close

2008-10-07T23:22:00.000-07:00

I've been continuing my work in DirectX 10, and it has been relatively slow progress, but progress nonetheless. I managed to render the simple character model that comes with the DirectX SDK using the first pass of my pencil shader. The first pass applies 6 different pencil textures based upon how lit that part of the model is. It is currently using the given texture coordinates of the model, so it doesn't look as good as it potentially could. That's an improvement for another time though.

I have been busy working on getting the second pass of the pencil shader working. It's pretty much just a Sobel filter that is applied to the normal map of the scene. In order to get the Sobel filter working though, I had to first figure out how to do post-processing image filters in DirectX 10. Obviously the first step was to render a full-screen textured quad. In XNA, I "cheated" and just used a SpriteBatch. It's not the most efficient way, but it allowed for the fastest development.

There ARE sprites in DX10, but I figured I might as well do it the "proper" way this time. So, I set up my own vertex format (with Position and Texure Coords), created my own vertex buffer (with the 4 vertices positioned in clipspace), and my own index buffer. I then wrote a simple shader that simply passed the vertices through the vertex shader, and applied the texture in the pixel shader. I fired up the app for the first time and Vista completely froze! Ctrl-Alt-Del didn't work, the mouse didn't move, nothing. So I shut it down and restarted and I got the Blue Screen of Death! I booted back into Safe mode and it said that my video card driver had gotten screwed up. I was able to boot back into Windows regularly the next time without changing anything.

I set a breakpoint in my code and stepped through the Update/Render loop about a dozen times without any errors, so I just let it run free again. The exact same problems occurred again, thus causing a reboot. I had no idea what I was doing wrong to screw up my computer, so I looked at several of the DX tutorials line by line. I realized that I had forgotten to tell the video card what my vertex input layout was. I added in the 3 lines of code to do it, and bam, everything worked! So I now have full screen textured quads working in DX10. An added bonus is since I positioned the vertices in clipspace, then it works on any resolution without requiring any updates or changes, plus there are no matrix multiplications that are needed to be done.

The next task I have to work on is to get mutiple render targets working in DX10. I need this because as I mentioned earlier, my goal is to render a normal map of the scene, and then pass that normal map into the Sobel filter shader.

DirectX 10

2008-09-26T12:48:00.000-07:00

I've decided to finally start dabbling with DirectX 10. The main reason behind it is that I want to work with Geometry Shaders. There is no official C# wrapper around DX10, but I did manage to find two third-party ones. One had not been updated since April 2006, so I threw that one out the window. The other, SlimDX, has been in very active development and a new version was just released this month. I downloaded it and played with some of the samples and was rather impressed. However, SlimDX also provides a wrapper around DX9 and it is very clear that that was the priority of the project. There are quite a few things missing from the DX10 wrapper that would have been very useful.

So, instead of fighting through a third-party C# wrapper, I figured I might as well go back to the straight C++ version. This has the advantage of having tons of official samples and tutorials from Microsoft. However, this has the major disadvantage that I have not worked in C++ directly for almost 4 years. It is rather rough going back to C++ from C#. There were so many helpful things built into C# that aided in rapid development. I mean, C++ doesn't even have a string type, you have to use char arrays. (Edit: I forgot that it does support strings, but you have to include the header for it first. Doh!) I feel like I'm stepping back into the dark ages! :-P

I'm hoping to have just the basic C++ code to draw a model using a shader, and then all of the rest of my work will be in HLSL. We shall see!

(Edit: I found a really helpful C++ tutorial for getting me back up to speed. http://www.cplusplus.com/doc/tutorial/ )

Switching Gears

2008-09-14T01:05:00.000-07:00

So I was chatting with one of my friends about what was up next on the todo list for my procedural planet. I explained that I was working on fog and that after that I would focus on water. He suggested that I get HDR and Depth of Field put in next. I then mentioned how I want to get Atmospheric Scattering in as well.

With all of these features laid out, the project seems rather daunting. That is easily several months worth of work right there. (I still do have a full time job!) I started thinking about how to make it easier, yet still make it stand out. I mean no matter how many awesome looking things I put in, I will never even come close to the level of Crysis. I am only one guy! So, I decided I should focus more on something that would be feasible for a team of one to accomplish in a lifetime.

Time for a personal history lesson!

Back when I first started fiddling around with XNA (over 2 years ago now), I also started looking into shaders for the first time. I have always been interested in Non-Photorealistic Rendering (cel shading, painterly rendering, hatching, etc), so I thought that might be a good subject to test with shaders. In my research, I came across a great paper about doing real-time pencil sketch rendering. http://cg.postech.ac.kr/research/pencil_rendering/

In January 2007, I began work on my own pencil shader. I actually started with 4 separate shaders that would require all models to be rendered 4 times. Fairly quickly I realised that I could speed things up greatly by having 1 shader with 4 passes. I tinkered around with it, and other things, for several months before I found out about using multiple render targets. Using this, I was able to get it down to 3 passes. Not long after that, I demoed the shader in a job interview and I actually got a job as an XNA Game Developer! That job lasted until the company got bought out by a larger company. Toward the end of my employment there, I started getting into procedural generatation, and that's how I came to have the procedural planet that I have today.

As you know, I have a new laptop now, and during the transfer of files from my old laptop, I saw my old pencil shader again. It had gone untouched since the day I demoed it in my job interview. Yesterday I finally decided to take all of the code and update it to XNA 2.0 and clean up what I could. I realized that I had learned quite a bit over the last year about both XNA and C#, so I was able to make the code much cleaner. Not only that, but I was also able to get the shader down to 2 passes! This gave me a 100fps speed boost. (On my GeForce 9800 GT, the 4 pass = 470fps, 3 pass = 480fps, 2 pass = 580fps.)

This has really given me a desire to work on NPR stuff again. So, currently my next goal is to have a procedural planet that is rendered using my pencil shader.

Procedural Texturing

2008-09-02T21:47:00.000-07:00

Well I am now producing what in my opinion are decent procedural textures for the planetary terrain. They are generated per pixel every frame. This has the advantage of allowing infinite resolution as well as eliminating any texture coordinate warpings around a sphere, since the textures are actually 3D.

As I mentioned before, this does require a significant performance hit. I have managed to simplify the texture generation to the point of having reasonable framerates while maintaining decent texture quality. What I am doing is calculating 4 separate textures using 2 octaves of turbulence noise at different scales for each one. These 4 textures represent sand, grass, rock, and snow. They are then blended together based upon the terrain height to generate a final texture.

I am getting anywhere between 25-50 frames per second depending upon how many pixels of the terrain are taking up the viewport. The average for normal travel is 35 frames per second.

Here are some screenshots of the results.

New Laptop, New Opportunities

2008-09-01T12:05:00.000-07:00

It's been awhile since I've written an update. As expected I got slightly side-tracked by Too Human, but what was an even worse offender was Mass Effect. I picked it up at a sale at Toys R Us, and I became addicted to it. I am currently working on my third playthrough of the game.

I finally received my new laptop 3 days ago. I haven't had much time to do programming on it because I had to first install all of my desired applications, transfer all of my files from my old laptop, and then prepare my old laptop for my sister.

I did manage to run a "benchmark" on the new laptop though. In the past, I wrote an XNA app that generates a texture using Perlin Noise in a pixel shader. This is usually a good evaluator of a GPU's performance. Here are some specs:

Generating 12 octaves of 1024x1024 3D fractional Brownian motion Perlin Noise:
8600 GT ~20 frames per second
9800 GT ~80 frames per second

Yep! My new laptop's GPU is 4 times faster than my desktop! Just to put a little perspective on it, these results mean that my new GPU was performing over 1 billion perlin noise calculations a second!

I also started fiddling around briefly with generating procedural textures for the planetary terrain. My idea was to use 4 different noise calculations per pixel and then blend the results together based on the planetary height of the pixel. As expected though, there was a severe penalty for doing a noise calculation per pixel. I never did get up to 4 calculations. Here are my initial findings, on my 9800 GT of course!

~120 fps using 4 existing textures
~40 fps using 1 8-octave ridged multifractal per pixel
~30 fps using 2 8-octave ridged multifractals per pixel

The performance hit is not linear though, so I expect that if I did 4 noise calcs, I would be getting about 20fps. However, that is on a 9800 GT, which is one of the best cards on the market now. Sure there are about half a dozen better cards, but how many people really have them?

I do have some ideas to potentially speed it up though. I could reduce the number of octaves, but then increase the scale. I could also try to make a fancy gradient so that I don't have to use as many different noise calcs.

Here are some screenshots showing different simple gradients using just 1 noise calc.

Relaxing

2008-08-17T11:04:00.000-07:00

I decided that since I had accomplished so much by pretty much working non-stop for almost a month, I was going to take a break for a bit. So, I have not worked on my procedural planet for this past week. Of course, I could never really break myself away from it, so I have been reading books and websites to research the next phase. I even put together an HLSL project to do some experimentation. So, don't worry, progress is still being made, just at a much slower rate now. I'm guessing I will start working on it again this week. After I get my new laptop (sometime after the 28th) I'm hoping to really pick up the pace again. Although, I do have a word of warning: I may get distracted with DirectX 10 and Geometry Shaders. We shall see. (Not to mention that Too Human comes out on Tuesday, Tales of Vesperia next week, Infinite Undiscovery the week after, and Spore the week after that! Too many good games coming out so soon.)

Until next time.

Success!

2008-08-10T11:34:00.000-07:00

I have completed the items on my to-do list!

I finally stopped the terrain from disappearing (for the most part ... I still had two instances where it happened). I discovered that I had a key subtraction backwards. How it even worked at all before, I will never know.

I got each terrain level to move at its own stepping distance by storing and updating a world matrix for each level. Luckily my CPU was hardly being used at all so I could easily spare the CPU cycles to do these extra calculations.

I fixed the gap between separate levels by simply making the square mesh slightly larger. Previously, the mesh would extend from (-1, -1) to (1, 1), but I updated it so that the range is (-1.25, -1.25) to (1.25, 1.25).

Now for what you've been waiting for: a new video. In fact this time I have two new videos for your enjoyment. One showing off the new terrain, and another showing it in wireframe mode.

Normal Terrain:

Wireframe:

On a separate note I just ordered a new laptop, so I will finally be able to do development on my laptop again. My current laptop only has a GeForce 6100, so it couldn't handle my shaders anymore (no unified pipeline). My new laptop has a GeForce 9800 GT which is about 20 times faster than my current GPU. It will be awesome!

Huh?

2008-08-08T08:21:00.000-07:00

Well I beat Braid last night. I think it took me about 6 hours total to beat it. It's a very good game and I highly recommend it. That is, if you enjoy "action puzzle" type games (think along the lines of Portal). There are 60 puzzles in the game and I was able to do 59 of them myself. I couldn't figure out one of them and I tried it for an hour. I finally looked online and I learned about a dynamic of the game that I wasn't even aware of.

I had read a posting on the XNA forums about how matrix transformations can cause slight errors over time, so I added code after my transformations to renormalize the vectors and even recalculate the cross products in order to maintain orthogonality. However, when I fired up the program, the terrain was disappearing even more! The angle between the two vectors is still randomly coming up as NaN and Pi.

Sigh, well I guess I know what I'm working on this weekend.

To-Do List

2008-08-07T10:01:00.000-07:00

Here is a list of things that I want to get working before I create the next video:

- Fix disappearing terrain
- Make each level move at it's own step size (right now they all move at the smallest step size)
- Fix gaps between changing detail levels (you can see the gaps in the last screenshot I posted)

As for the disappearing terrain, in my previous post you will see that I've narrowed the problem down to the angle calculation. I've read the documentation on acos() and it says that NaN is returned as a result if the input parameter is < -1 or > +1. I'm passing in the dot product of what should be two normal vectors, thus the input should never exceed 1. Apparently I'm not sending in true normal vectors, so I'm going to add more normalization calculations, just to make sure they are coming out normal. That should remove the NaN results, but hopefully it fixes the Pi results as well. (I'm crossing my fingers tightly.)

I'll give it a try when I get home.

No real progress

2008-08-06T23:17:00.000-07:00

I have been busy playing Braid, which is a great game that just got released on the Xbox Live Arcade. Therefore, I haven't really put much time into the procedural planet.

I did put in some code that would always display the calculated angle between the camera and the terrain mesh in order to see if that was causing the disappearing errors. I actually believe it is, although I'm not quite sure why.

First, I was surprised to see that probably a quarter of the time, the result was NaN. Even more surprising is that my terrain works perfectly even when the result is NaN.

The errors occur when the result suddenly comes back as pi randomly. I should never be getting an angle that big back. Heck I shouldn't ever be getting pi/2.

I will continue to investigate this problem (when I have time between Braid of course).

Nothing is easy

2008-08-04T22:01:00.000-07:00

I thought that my camera was moving way too slowly after I increased the size to 6.5 million meters, so I increased its default speed. I also have a couple of keys that act as multipliers in order to get really high speeds. Unfortunately I realized that my terrain couldn't keep up with me because I was moving too fast. This is because the terrain would only move a maximum of 1 step each loop. So, if I traveled 3 steps' distance in one update loop, the terrain would fall 2 steps behind.

I wrote a solution to this by calculating the number of steps the camera has moved and then rotate the terrain the appropriate number of steps. This worked great and the terrain always kept up with the camera. BUT! Yes, the big dreaded but. The terrain randomly disappears. It will be fine for quite a while and then flash on and off like crazy. Even worse, sometimes it completely disappears and doesn't return, no matter which way I turn or move.

I have no idea what is causing this problem and I have tried debugging the code for awhile now. So either I find a fix to this bug, or I'll have to limit the speed to be slow enough that the terrain can keep up.

I feel bad for not having any media for so long, so here is a screenshot to appease the horde. I desperately need to get better texturing on the terrain, but that will come after I get the terrain working to my satisfaction.

Everything revolves around the camera

2008-08-02T23:46:00.000-07:00

Well I fixed the problems I was having with the camera. First, let me explain why I was having trouble. I had my planet centered at the origin (0,0,0) and I gave it a radius of about 6.5 million meters. I initialized the camera position to be right at ground level of the planet (6.5 million meters plus the height of the tallest mountain [I use 100,000 meters]). My camera always looks at a spot 1 meter in front of its position. Once you are dealing with positions up in the millions (about 6.6 million), the accuracy is lost and so it doesn't always register that 1 meter difference.

I found an article online where someone was having similar issues with having the sun at the origin and having the camera out at Earth's distance (about 150 billion meters = 1 AU). He fixed the problem by always making the camera situated at the origin and just positioning all objects based on the camera position. I thought I would give that a try.

I didn't have translation code for my planet yet, so I had to first write that and get it debugged. Once I had that working, it was pretty simple to switch the coordinates around (I added 2 lines of code and commented 1 out). Now my camera works perfectly even when dealing with a planet with a radius of 6.5 million.

I also managed to tweak the Z-fighting occuring with the depth buffer. So it looks alot better than what it did, but it's still not perfect and there are still triangles fighting with each other on the horizon. As soon as I have that fixed, I'll post some more screenshots.

Planets are Too Big!

2008-07-31T22:28:00.000-07:00

Last night I decided to increase the scale of the planet to Earth's size. The original size of the radius was 60,000 meters. Earth's radius is about 6.5 million meters. So, I had to make my planet over 100 times larger.

Unfortunately, all sorts of problems arose from attempting to do this. First, my depth buffer went to crap. If I wanted to be able to see anything from even a low altitude, I had to extend the far clipping plane back to at least 1 million meters. This resulted in all sorts of errors with triangles that were fighting over their depths because the range was trying to be stretched over such a long distance.

The second problem that occurred was that my camera was rotating in "steps". If I moved the mouse up, instead of smoothly rotating the view upwards, it would snap every Pi/4 or so. This snapping problem was alleviated by shrinking the size of the planet. Shrunk in half it was still too bad to use, shrunk by 4x was much better, but the problem was completely gone if I shrunk by 10x.

I really need to fix all of these problems so that I can have Earth-sized planets. There are many other planets that are even larger than Earth so this is very important. I have found some articles online where people have found solutions to these problems. I'm just unsure of how feasible these solutions are for XNA (they are all OpenGL solutions).

On a side note, I switched my Perlin noise function from fBm to ridged multifractal and it looks much better. I am very impressed with the terrain results. I would post screenshots, but with the depth issues and such, I figured I would wait.

Go Simple, Go Fast

2008-07-30T18:04:00.000-07:00

I've made the executive decision to just go with the simple spherical lighting. It's already working and it's 3 times faster than the surface normal generation method. Besides, it will be simple to calculate the surface normal in a geometry shader later. Unfortunately XNA doesn't support geometry shaders currently. However if it ever adds that functionality in the future, I'll be able to add very realistic lighting rather quickly.

I'm now going to move onto something else. What that is exactly, I'm still not sure of. I have a list of TODOs, but I need to determine which one is a higher priority right now.

Do You See the Light?

2008-07-29T21:32:00.000-07:00

I promised myself that I wouldn't post another update until I had lighting on my planetary terrain. I have partially fulfilled that promise.

While I did successfully get lighting on the terrain, it is not as realistic as I want it. I currently have two solutions. The first is that I'm simply illuminating the planet as a sphere. While this looks great in places where the light is coming straight down, it looks bad on the edges where there should be long shadows. (Ignore the square-ish terrain.)

The second solution I have actually tries to calculate the surface normal in the vertex shader. I estimate where the neighboring vertices are to the right and above the current vertex. I calculate the two edge vectors and then take the cross product of them to acquire the normal of the surface. While this all sounds good and makes sense in theory, it isn't yielding the correct results. I have random shadow and light "splotches" scattering over the planet, except for one quarter-sphere (is that what a half of a hemisphere is called?) that turns out all black.

On a sidenote that's rather strange, if I use the XNA screenshot component that I wrote, the shadows all come out as white. If I use Alt-Print Screen and capture the whole window, it comes out as black (which is what is actually displayed). Check out the white versions:
[Edit: Ha ha! I didn't realize until I posted the screenshots that they aren't coming out as white, they are coming out as transparent, which makes much more sense!)

Rotation Solved!

2008-07-23T19:25:00.000-07:00

Well I implemented my pseudocode in XNA last night, made just some minor changes, and then I had a working rotating mesh. The guidance I received from Steve Hazen on the official XNA forums really helped me out and pointed me in the right direction.

I would post the code here, but I don't know how to post it without it looking atrocious.

I have the code posted in the XNA forums:
http://forums.xna.com/forums/p/14547/76204.aspx

As you can see from the final postings, Steve recommends some tweaks to the code that would increase accuracy and make it more efficient.

I'm really happy to finally have this problem solved. It took me four days to finally get a working solution. Now I can move on to the next item to implement. It's going to be tough as well, but no where near as tough as the rotation. At least that's what I'm hoping.

Until next time...

Rotation Solution?

2008-07-22T22:32:00.000-07:00

I think I may have a solution to the rotation problems I was having. I have pseudocode scrawled out on some paper I found. (Along with several drawings of 3D axes with angles, cones, and cameras in various positions.)

My goal tonight is to implement the pseudocode in XNA and experiment with it. I'll report my findings tomorrow.

Until next time...

Rotation Issues

2008-07-21T19:23:00.000-07:00

I have been working hard on coming up with a new LOD algorithm that eliminates that pesky "water" effect. I think I have a pretty good idea for a system that would not only remove that problem, but would also make the vertex shader faster.

Unfortunately I am currently stuck facing some problems with rotations. I have a mesh that I want to rotate around a sphere so that is always points at the camera. I could create a billboard matrix and use that, but there is a problem. That would create the water effect again. What I need to do is move the mesh in steps. If the camera moves beyond an angle threshold for either left/right or up/down, then the mesh should be moved one step in the appropriate direction.

I decided to use spherical coordinates to calculate the horizontal and vertical angles of the camera. This works great until you reach the north or south poles. Once you cross the poles, the mesh is rotated 180 degrees.

Here is the reason why that happens:

The "vertical" angle, theta, ranges from 0 to pi. Where 0 is pointing down the -Y axis and pi is pointing up the +Y axis. The "horizontal" angle, phi, ranges from 0 to 2pi. Where 0 is pointing along the +X axis, pi/2 is pointing along the +Z axis, pi is pointing along the -X axis, and 3pi/2 is pointing along the -Z axis.

In the case when the camera passes over the north (+Y) pole, theta is at its peak (pi) but then starts decreasing as you continue to the other side. Whereas phi essentially gets +pi added to it (or -pi depending up where the pole is crossed). That is why the object is being rotated 180 degrees (pi radians).

Whew!

The problem is that I don't know how to fix this rotation. I have been tinkering around with it for the last several days to no avail. I certainly hope I come up with a solution soon. I really want to continue work on my new LOD algorithm.

Until next time...

LOD Algorithm

2008-07-20T10:07:00.001-07:00

I thought I would explain the algorithm I used for the planetary LOD in more detail.

When you first start the program, two meshes are generated: a cone and a ring. Both of these meshes are configurable at creation. For a cone, you can define how many "slices" it is broken into (imagine a pie and cutting into equal slices). For a ring, you can define how many slices as well as how many inner rings the ring has. For example, you can have a ring mesh that is made up of five inner rings and split into forty-five slices. Both of these meshes are scaled to a unit sphere (its actual just a hemisphere) which is centered at the the origin and "points" out along the -Z axis.

At the lowest level of detail, the planet is just a cone. If the level is increased, the cone is shrunk in half and a ring is drawn attached to the bottom of the cone. If the level is increased again, the cone is shrunk in half again, the existing ring is shrunk in half, and another new ring is attached to the bottom of the existing ring. This process continues until the highest level of detail is reached.

The resizing of the meshes is all done in the vertex shader. The terrain height is also calculated in the vertex shader via 8 octaves of fBm Perlin noise. This means that after the mesh generation in the beginning, the CPU does practically nothing. It just keeps track of what the current level is, and updates the shader parameter as necessary.

The hemisphere is updated every frame to be centered at the camera by simply calculating a billboard matrix as the world matrix of the hemisphere.

Well that should give you a decent grasp of how my LOD algorithm functions. As I mentioned in my previous post, it's not perfect because the centering of the hemisphere every frame really has a nasty looking "water" effect. I'm already at work on fixes for that, so if I get that working, I'll post what I did.

I'll leave you with a quick video of my LOD algorithm at work.

Planetary LOD

2008-07-19T08:10:00.000-07:00

I have been spending the last week writing my own implementation of an LOD system for a planet. It is inspired by Spherical Clipmaps, but it is not an actual implementation of them.

As I said, I began writing it last week (exactly a week ago today) and I finally have it all up and running (using real-time 3D Perlin Noise in the Vertex Shader and texture blending, no less!). Unfortunately, I have it running too smoothly, if you can believe that. I have the vertices being updated and centered under the camera every frame. This leads to the terrain looking similar to flowing water as you fly around the planet. As long as the camera is stationary, everything looks great. You can spin the camera around and look at all of the terrain around you. As soon as you start moving though, the "water" effect is very apparent.

I first tried to fix it by having the terrain position updated only once a second, but that looked terrible. So, I ended up saving the old camera position and then calculating the angle between the current camera position and the old position each frame. If the angle becomes greater than a threshold (I used something like Pi/64, yes that's sixty-four!) then I update the terrain position. This looks alot better than the time-based updating and it removes the "water" effect. Unfortunately, it also makes the terrain very "poppy". For example, if you see a mountain in the distance and you start to fly toward it, you would suddenly see more detail "pop" in as you got closer.

I think what I have now is pretty decent, but I want to have very smooth terrain, with no popping and no water effect. So, I'm kind of back to the drawing board trying to think of a system that fixes both of those problems. Not everything I have now is throw-away code though. I think I should be able to carry over alot from this project to the updated LOD system.

First Blog Entry

2008-07-18T20:59:00.000-07:00

Greetings! Here is my first blog post .... um ever!

I will attempt to use this space to talk about some of the graphics projects that I am working on. Hopefully I actually stay devoted to it. I always seem to slack off on things similar to this.

It's your duty as a reader to reprimand me if I fall behind on updates!

Until next time...