Instancing now available


I’ve used instancing in two other projects before (one in C++/DirectX and another in XNA) but for the first time it’s now available on Meteor Engine with deferred rendering. I already uploaded the latest build which has this feature in place.

With instancing enabled, it is now possible to make more complex scenes relatively easily and with much fewer draw calls. Now, I’ve apparently hit a new GPU bottleneck, in rendering too many polygons because I went crazy with adding a lot of instances 😮 Remember, that with deferred rendering you’re drawing the geometry more than once- up to a maximum of six times with CSM shadows enabled!

So other optimizations are coming up. With instancing in place, I will next re-introduce scene culling, using quadtrees. Each instance will be culled individually.


A few other things… bounding boxes didn’t show up correctly before. Now they appear along with every instance. Also, lazy loading of meshes is supported, so instead of using two lines of AddModel(“mModel”) and then Model(“myModel”).Translate(…).Rotate(…) simply call Model() to get the mesh that is needed.

You may also notice that my recent updates are getting shorter. Well I don’t want to digress too much to the point where the articles turn into tutorials, but more about being quick to the point. If there is enough support for this project I might release periodic builds much sooner online. These won’t be official releases, but revisions when I implement new features.


Game, meet engine

Hey guys, this time the update will be short, but some significant updates that they are. I have successfully compiled a library from my engine that would work in other projects more transparently. In fact, I was able to get the Meteor Engine to run in Bubble Tower.

But hey, check it out, more exciting game screenshots! Here’s an example of the Meteor Engine running in it.

Menu screen with 3D render

Also, particle effects! That is actually not part of the engine (a lot of things in the game still rendered ad-hoc), but it could well be.

Note that I’m using a 2D sprite image for the background here. I have deliberately made the rendering engine not clear the screen automatically so that it’s possible for other GameScreens to be seen behind it. I plan to make auto-screen clearing a selectable option soon.


The engine runs in its own GameScreen class, so it can operate independently or swap data just as well as the other screens. It still needs to be loaded as a game component for the main Game class, which is necessary to do all its updating in the background. Both screens are active as shown in the text in the upper right corner, so both the camera controls and the menu controls are working! While using the arrow keys or mouse to select menu choices, the WASD keys still move the camera around the scenery.

This is all for testing purposes, but it shows great possibilities with this kind of interaction. With some further implementation, the camera can be scripted to move around the scene according the options you select. As of now, there is no interaction between the engine and the menu screen, but that will be worked on soon.

As this project is still far from complete, I am using a debug build of the DLL to link with my applications. At first, all the content files (such as shaders and sample textures) were referenced by the library, and I often had to copy the .xnb’s over to the working directory of the program. It’s not very practical, and not a good option for distributing it to other users. A couple days ago, I added a resource file to embed all of its contents. Still no public release of the binary yet, but all the latest content and project files are now uploaded to Codeplex. The full size of the binary came out to 430kb, still pretty small for a debug build.

Already, this game has the potential to take on a much more professional look. I’m still wanting to get my own 3D content, though.

Done fixing the shadow maps

It’s been a while, hasn’t it? I’ve been pretty busy trying to look for a job, then maintaining my freelance work on top of other things, but I still try to keep my programming skills sharp. This past week I opened up my XNA projects again and they are still fresh in my mind.

Removal of shadow flickering and swimming

In fact, with my mind so cleared up I finally resolved two problems that have plagued my shadow mapping code for so long. The first problem I resolved in an hour- it had to do with the shadow maps “tearing” between the cascade splits. Those portions would either be completely dark or filled with parallel lines. In other words, a glitchy mess. Originally, I went with using different near-far distances to generate each map, but they were misaligned if viewed from certain angles. Such was the case for parallel-split maps. So I decided to just go with traditional cascaded shadow mapping by making the near distance the same for all the splits.

This means that while some pixels are wasted for the farther cascades, it guarantees that there will always be overlap between them. The tearing is now gone! The next problem is a little less distracting but still something I always wanted to fix, and it’s the “swimming” of the texture shadows when the camera moves. The texels always move quickly and noticeably. Fortunately J. Coluna had the solution in his LPP demos, which he in turn took from a website he couldn’t remember. Fair is fair, so I used the code as well.

After a surprisingly few changes to the code, I removed the swimming effect. The camera for each light is set to move in texel increments, so movements stay “snapped” to an invisible grid. Shadows suddenly look a lot cleaner despite still using the same filtering technique.

Cascade shadow blending

One more trick was added to make the shadows look nicer in motion. CSM usually shows visible seams that divide each cascade, and they also pop in and out noticeably when moving the camera farther away. With the shadow maps now overlapping each other, it is possible to remove the seams that occur from changing different levels of shadow detail for each distance. I decided to start the blending at 85% of the distance between the near and far points of each split. This creates a smooth linear transition between the maps. The below image shows the effect of blending the cascades together, each  color representing a different shadow map.

I have uploaded these changes in the latest build of the Meteor engine, available on CodePlex. There may be some more updates on it, but I don’t foresee doing any more notable changes to the shadows for directional lights.

Between this and Bubble Tower, I’m slowly converging the two projects together in a way that makes them more practical. It’s also a great way to test the Meteor Engine in a real project. As you may know, the game uses a screen management system and I wish to keep this engine self-contained in one of the screens. I have been finding more limitations to the engine that are going to be resolved in order to make it work in a more flexible manner with the game code. More on that later.