Shadow Mapping

Man I'm slow at shadowing. I've been reading techniques for soft shadows since at least 2008, yet here I am only just implementing shadow mapping. That's probably Carmack's fault for making me believe in stencil shadows.
No fancy features yet, just plain shadow mapping:

Deferred Shading and Ambient occlusion

Over the past four or so days, I have been rewriting the renderer of pdEngine to be deferred rather than forward. It is much easier than I thought to do this, even in Direct3D 9 (I will translate it to Direct3D 10 when I am satisfied).
With a deferred renderer, there are so many interesting things one can implement. One is ambient occlusion, and I had an idea for an improvement of this to use it for global illumination. Talking to people and searching I found someone already proposed a similar technique, described here. I have been following this to implement my Screen Space Directional Occlusion (SSDO). The attached image shows just the AO on the right, and the final image on the left. The framerates are bad on my old card, but don't judge it by that.

An update!

I haven't posted anything here for ages, so I thought I'd better give a glimpse at what I've been doing. I'm now working pretty much full time on pdEngine, but rather than making any major changes I've been tidying lots. I have made a nice mesh viewer for the .pdmesh and .pdmat formats in C# and WPF. pdEngine now also supports .NET languages because of this, but not fully yet.


I have a new website for game developers' news, here.

C++/CLI

Since I finished (except for materials) .pdmesh file loading in pdEngine, I have been working on a mesh viewer application. Now, this is not a game and requires a proper GUI, and everyone knows that C# is the only satisfactory way to do this. I don't want to be meddling in MFC, I want nice windows, made by WPF.
This means that I need to create a wrapper for pdEngine in C++/CLI, so that I can get it working through C#. I'd never used C++/CLI at all before last week, so it was an interesting learning experience. I was previously biased against it as a horrible language hacked together, between native and managed, which in some ways it is, and yet it works and doesn't have many annoyances.

That is the language however. I am using Visual Studio 2010 (release candidate, but I will get the final through DreamSpark in due course), and for all its bells and whistles, can't handle C++/CLI for shit. There is absolutely no C++/CLI intellisense. It sounds stupid, but intellisense makes it so much easier to program, especially when writing a wrapper. I don't have to remember all the variable names I have given, when copying lots from one location to another, it prompts me.
This is why, when I found out there was no intellisense in VS2010 (and there was in VS2008) I got very annoyed. I ended up downloading an addon, called Visual Assist X, which essentially does intellisense better, through an extension. It includes C++/CLI. Now, I think if one small company can get out C++/CLI within months of a beta of the IDE, a multinational corporation shouldn't have to drop it because of "time constraints".

Templates in .cpp files

I blogged a few days ago about the need to define templated members within header files, and why I found that annoying. Well, when looking through the propositions for C++0x, the next specification of C++ that could be released as a draft this year, I was pleased to see the heading "Extern Template". The syntax would be thus:
extern template class std::vector<myclass>;
See the full infromation, and the rest of teh changes in this spec here.

You learn something new every day

I frequently see function prototypes written as
void function(type& param);
but until today have never found out what the relevance of the & was. I assumed it was the opposite of a *, a dereference, but didn't understand how that worked. I always treated functions like this as if they were written
void function(type param);
and no harm came of it.
But, looking at a physX function early that was
void NxBoxShape::saveToDesc(NxBoxShapeDesc& desc)
I wondered how it could return from this. I had the additional problem that I had a pointer I wanted it to save the desc to, of type BYTE*. I tried various casts that didn't work, and after a while on Bing I found out that this type of parameter takes a normal variable as an argument, but within the function treats it as a reference, so the value can be changed and it will affect the argument.
It is odd that I never knew this before, either I missed it in the various tutorials and books I read, or no-one thinks it worthwhile to mention. Well, now I know.
In the end, I solved my little problem by just passing a new NxBoxShapeDesc then using CopyMemory to save it to the pointer.

Templated class

For some reason unbenknownst (that's an awesome word) to me, templated classes must not only be declared, but defined, in header files rather than C++ files. I assume this is becasue templating is done at compile time, and the compiler does not have access to other C++ files, that is done with the linker.
The upshot of this is that whenever modifying the functions in this, a compile of every other C++ file that sues this header has to be done. This slows down development time significantly. I can take long compiles, but it's annoying when I'm only making small changes in one file.

Collision shapes

Until now, on pdEngine, there were three choices when it came to collision shapes: a box around the whole objects, a sphere around the whole object or an accurate triangle mesh. The first two do not produce accurate results for complex shapes, and the last being slow for physX to handle.
What I have been wanting to do for a while, and something I have now achieved, is rather than generate a bounding box around the whole mesh, generate one for each subset. I have also done this using spheres, although it's more academic and I can't see this type of bounding actually being used.
In the attached screenshot there are three objects of the same mesh, a biplane that comes with the DirectX SDK. The leftmost uses spheres, the middle uses boxes and the one on the right uses the mesh.
The trouble with this technique I have experienced is converting between the physX coordinate system and the Direct3D coordinate system, one of which is twice the other. At the moment, this only works for axis-aligned bounding boxes, so it is not very useful for some objects, but I shall experiment with alternatives.

Confusion?!

I get very confused when debugging these days. This is because I can no longer tell the difference between my Direct3D 9 and 10 renderers. That's a good thing :)
In terms of progress, fluids are coming along in DX10 but are not yet done. Models now support multiple subsets per mesh, and the next thing to do is to get the physics to use these too.

In other news, I recently reinstalled StumbleUpon. I have not had it since Windows 7, as I saw it as something of an addiction I needed to free myself from. However, I do very little at soem points on the computer, and StumbleUpon is better than Omegle or 4Chan or wherever else I am tempted to go.

Celebrate good times

I finally did it! I got stencil shadows working within a Direct3D 10 renderer. The problem in the end, as ever, was a very small one. The stencil and depth buffer needed the format DXGI_FORMAT_D24_UNORM_S8_UINT, I was previously using a float. So, with that done I can move on to getting sprites, pointsprites and text rendering.

Debugging

It turns out the reason PIX didn't work with Direct3D 10 programs was that I was using a D3DDEVTYPE_NULLREF device. I binged this and found nothing, so I assume I am the first person in eh world to find out that PIX does not like these. Simply changing it to a HAL device worked fine. Now I can debug it in PIX, it looks like I regurgitated the index buffer somewhere, because that is messed up :/.
What I have done today successfully is generate adjacency data for my meshes. Adjacency indices are passed into the geometry shader, and normally this is done by DirectX with meshes. But as we know, meshes are being phased out in DX10?! Following a thread at GameDev it was quite simple, just a case of doubling the size of the index buffer and putting in the index for the adjacent triangle in between each other.

Mesh format

When Direct3D 10 was released way back in 2007, lots of people were surprised at the lack of a decent mesh class. Whilst there is one, it cannot load from file in the same way that Direct3D 9's could, and it is essentially more of container for the vertex and index buffers.
With this is mind, designing an engine that supports both Direct3D 9 and 10 is difficult. What I was doing was loading everything through DirectX 9, then converting in to 10 when that was running. The problem with this is that two Direct3D devices need to be running simultaneously, which not only hits the performance but also makes it very difficult to debug using PIX.
What I have been working on for pdEngine today is my own mesh format that can render to Direct3D 9 and 10 (and hopefully 11 when I buy a card that supports it), and can load from file. The file loading is not yet done, but it won't be .x, it will be my own format probably similar to .sdkmesh.

New blog!

I felt a desperate urge to blog something today, so I made a new blog. The old one won't be back up again anytime soon, and I doubt I'll update it even if it does come back, now I've made this. What happened was that the web hosting expired, and I forgot to take a backup before it did, so I've lost everything on their unless it gets renewed soon.
I used blogger once before, ages ago, and it was recommended to me by a friend again recently, so I thought "why not".
For anyone interested, pdEngine is still beign worked on, and every now and then I will update the SourceForge SVN. The entire source is available at SourceForge: http://sourceforge.net/projects/pdengine/