It's getting close to another year since my last blog post, so for anyone still out there I thought I'd put up this little video of a pet project I've been tinkering on. It simulates how Foucault's Pendulum behaves at various latitudes. In case you're wondering what on earth Foucault's Pendulum is -and if you'd actually want to know- you can find more information over here and this here book provides a well-written history on the subject. The short and sweet is that this Pendulum device demonstrates that the earth rotates, which is a pretty neat feat. To get on with the imagery, here's that video:

I'm still tinkering on XNA3.1 so I won't bother you with the hideous source. I'm really not up to speed on the more recent XNA developments, so I have no clue if there's any need out there for another rant on how hard spheres are to texture correctly, or some info on how to paint on your meshes like the pendulum is doing. If there is however, drop me a line and I'll try to put together a tutorial explaining the technique (could be a good reason to finally upgrade to XNA4). And it might be nice to have some fresh content on the site again :)

I spent some time the past few weeks tinkering on the GPGPU framework to make it a bit more flexible and more robust. First of all, it got renamed to the acronym Sage (Simple Abstraction for GPU-based Evaluation), mainly so I don't have to type simple GPGPU framework all the time. The main goal of the recent developments was to support the usecases presented by Navier-Stokes fluid simulation as implemented by Epsicode. After quite a bit of pondering and redesign we managed to get it to run 100% on the GPU and I have to say the result looks absolutely stunning:

The main change here is that since this simulation deals exclusively with texture output, the data isn't needed on the CPU at all and the data and computations can remain solely on the GPU. The update to 0.3 turned out to be lacking in terms of flexibility to support this properly and truth be told the GPUBufferUsage.PassThrough flag was far from intuitive. With the upcoming version of the GPGPU framework this will be addressed by having GPUBuffers own their GPU resources, instead of borrowing them from the GPUProcessor. This makes GPUBufferUsage.PassThrough more straightforward, since it's more obvious that a buffer with this flag set will be using its own RT when asked for input, instead of using some RT internal to the GPUProcessor. Perhaps renaming GPUBufferUsage.PassThrough to GPUBufferUsage.UseOutputAsInput would be even more obvious, but it just doesn't sound as mysterious :)

Another change to the GPUBuffer is that the output (the owned RenderTarget) can now be double-buffered. That means that a GPUBuffer can be set as both input and output (texture and RT) simultaneously, while the system transparently takes care of the details. With the help of the excellent 3rd party support by MS, these changes mean the data doesn't need to come back to the CPU at all, which can drastically improve performance. When we started porting the fluid simulation over to Sage we were happy to have it running on a grid of 64x64 data points. With this upcoming version of sage, it can simulate a 512x512 grid smoothly in (mid-to-high end) SM3 hardware and reportedly simulates a 256x256 grid at a leisurely 60fps on the 360.

At the moment the development focus is on migrating the framework into a library project of its own (for easier maintenance and upgrading) and reviewing the design of the new features, to make sure there aren't any gotcha's like GPUBufferUsage.PassThrough in the upcoming release. The samples from the earlier releases will also be ported over and added to the solution. With some more fancy features in the works I don't have a particular release date in mind just yet, so if anyone should want a 'CTP release' in the meantime just drop me an e-mail to feedback@xnainfo.com.

There seem to be a lot of exciting things happening at the moment. XNA 4.0 has been announced which adds Windows Mobile 7 phones to the list of supported platforms, but you already knew that of course. While Shawn is busy at GDC, I took the liberty of stealing his Fractals code. It doesn't improve anything upon his release in 2006, but I happened upon it and I thought I'd be nice to have this available as a ready-to-run sample. On that page you'll also find my take at handling input (inspired by this discussion) which seems to be all the rage these days.

Other than that, I've started tinkering on a little animation pipeline for XNA together with a 3D artist as a learning experience. I have no idea if this will be anywhere near finished any time soon, or if it'd even be useful for the community since there seem to be a lot of libraries out there already. Like any good software project I settled on an acronym for the name anyway before its anywhere near done, so I lay claim to Uxmal. It's a good fit since the artist is working in Maya and I'm on my third rewrite of the codebase already. Xna Model Animation Library also fits, but my development efforts are currently stumped by trying to come up with what the U should mean. Useful would be ideal, but it might also be Unnecessary or Useless.

Time will tell :)

  
I really gotta stop doing things like this. What started out as a Soft Body Physics demo ended up in writing a barebones GPGPU library, which ended up in writing a stand-alone GPU-particle demo for release on XnaInfo (coming soon!), which ended up in a little black hole:

I hope to find some time for the write-ups and posting code soon, please bear with me :)

I've been working on a soft body physics demo (more details). I haven't had time to write up more about it to post here, but I wanted to try to see if posting YouTube videos works on this infernal blog software. Stay tuned for more on this :)

I came across an excellent discussion of setting up a logarithmic depth buffer in Cameni's Journal. I heard of those before, but I was surprised to find implementing them is as easy as adding only one simple line of code to your vertex shader:

output.Position.z = log(C*output.Position.z + 1) / log(C*Far + 1) * output.Position.w;

The C constant allows you to define the resolution you want at the near plane and Far is the value you use for the far plane. More details can be found in the journal linked above. I happened to be tinkering on a model of our solar system with a bunch of stars surrounding us (from Hipparcos data) to scale. The lightyear distances for the stars and the AU distances within the system were a source of woes with the depth buffer, but using this simple line made my z-fighting stars play nice.

I haven't gotten around to writing interesting samples or uncovering any deep XNA truths lately. Instead I've been tinkering on a little beat-em-up game with stylized stick men to do the fighting. These little actors are entirely procedural, so the game itself generates the geometry and animations rather than using models created by artists. Obviously nothing can replace a good artist and this proved painfully true when it came to the animations.

The animations are generated by a particle-based physics system (described here), which works by applying force to the attacking limb towards the victim, checking collisions and letting the simulation run its course. The base skeleton displayed below is set up easily enough, but without additional contraints the resulting movements are far from natural. As noted in the original article, a lot of tweaking can also be done using the mass of particles to get some control over how easily particles (i.e. joints) can move.

So if the skeleton and animations are that hard to tweak, you might be wondering what good this procedural technique is then. The beauty of this -admittedly simple- physics based rendering setup is that you essentially get inverse kinematics for free. If I want to hit my opponent with a hand, I just apply some force on the hand towards where I want to hit him. With sufficient tweaking, this produces convincing animations for accurately hitting the victim anywhere with any part of the attacking actor. Headbutts, kicks and more exotic attacks are just a matter of picking target and subject particles on either side.

Another nice benefit of this procedural approach is that the geometry is very accessibly to the program and thus can be altered in a variety of ways. With a few minutes of tinkering, style variations like those below are easily implemented.

The project is still a pretty long way off from becoming a playable game, but it's already made its way around the office for passive-aggressive stress relief   I'm afraid I can't put a playable build out anytime soon, but in the meantime here's a little movie (WMV, 7mb) showing some basic pummeling and the style so far. Since a lot of tweaking is involved and much of the style is still up in the air, comments and/or suggestions would be much appreciated.

 

Foregoing lamenting my own slacking, I want to point everyone who cares to read this to a great online resource I stumbled upon today:

A free online book called "Programming Vertex, Geometry, and Pixel shaders"

It is geared towards D3D10, but it contains an incredible wealth of information about nearly every graphics topic you'd want to implement. The concise and thorough theory certainly holds for XNA and most shaders should give you a good idea how stuff gets implemented, if they don't work out of the box. It's written by these guys, who deserve a truckload of cookies in my opinion!

_{Oh and Jack, if you ever should find your way here, we have to discuss your definition of 'not very active' :)}

Last night I decided to sit down and do some nitty gritty optimization on the 60 version of my game.  The PC version has been running great even when I crank up every setting I have (although that might have something to do with the 4870 I just bought), but as well all know by now things are never so easy on the Xbox.  For the past few weeks I'd been struggling to keep the framerate above 60Hz, with it slipping down to 55Hz during complex scenes.  Now 55fps wouldn't be so much of a problem if I weren't the kinda guy who hates screen tearing, but it just so happens I am.  Which means I want VSYNC to be enabled, which means the game drops to 30fps whenever it's below 60.  Definitely unacceptable.  For a while I avoided the problem by doing the unthinkable...I dropped the resolution from 1280 x 720 to 1024 x 600.  I even considered leaving it this way for the final release...I mean if Halo 3 and Metal Gear Solid 4 can do it, why can't I? 

But no, I'm too finicky to settle with the lowered resolution.  It just looks so much better in 720p!  So I cranked the res back up, and decided to see where I could squeeze out some extra performance.  Naturally, the first place I went to was my show mapping shader.  I already knew this particular shader was giving me trouble, since I'd discovered that decreasing the size of the buffer that I render the shadow occlusion to (since I do a deferred shadowing pass) resulted in significant performance gains.  I'd already reduced thigns to 4 PCF samples on the 360 (did I mention I ditched VSM for the 360?  Performance and precision ended up being so awful it wasn't worth it) so I couldn't squeeze that down anymore.  At this point my eyes drifted down to little loop I had for determining which split of shadow map cascade to use, when I remembered an excellent presentation on shader performance that I'd read a long time ago. One of the things mentioned in there was that unrolling loops can have a significant impact on general purpose register usage, ALU usage, and shader compiler optimization.  So I thought, "hey, let's try unrolling this loop and flattening this branch".  I then changed my code from this:

for (int i = 1; i < NUM_SPLITS; i++)
{
    if (vPositionVS.z <= g_vClipPlanes[i].x && vPositionVS.z > g_vClipPlanes[i].y)
    {
        matLightViewProj = g_matLightViewProj[i];
        fOffset = i / (float)NUM_SPLITS;           
    }
}  

to this:

[unroll(NUM_SPLITS)]
for (int i = 1; i < NUM_SPLITS; i++)
{
    [flatten]
    if (vPositionVS.z <= g_vClipPlanes[i].x && vPositionVS.z > g_vClipPlanes[i].y)
    {
        matLightViewProj = g_matLightViewProj[i];
        fOffset = i / (float)NUM_SPLITS;           
    }
}         

I ran the game again, and BAM:  I shot up from 55fps to 65fps!  Huge difference!  I was very impressed with myself.  Moral of the story:  experiement with stuff, and make sure you profile it!

Today I decided to read through some other presentations to see what other useful bits I could find. This one from Gamefest 2007 pointed out that vfetch's should be aligned to 32-bytes on the 360.  I did the math on the vertex declaration used for most of my models, and found out it's 48 bytes.  Later tonight I'll have to see if I can squeeze it down to 32, and see if it makes performance any better. 

I also came across this one from Gamefest 2008, which is all about how texture and surface formats are handled on the 360.  This gave me some insight into some problems I'd come across already.  For example, R32G32F (Vector2) isn't actually a format the GPU can render to!  Apparently it renders to R16G16F, and then just expands it upon resolve from eDRAM.  This explained why my VSM's with exponential warp were have such precision problems.  Another thing pointed out in there is that the 360's texture units filter fp16 at 1/4 the rate of INT8!  This would help explain why my VSM performance was so poor.  Definitely good things to keep in mind.

-MJP

 

A bit of an off-topic post for any Dutch readers that may come across our little blog. MS decided to revamp their Dutch .NET Magazine and change the subscription to Opt-In, meaning you'll explicitly need to tell them you want to keep receiving the magazine after the next issue of September 22nd. You can find more details and re-subscribe over at this page:

http://www.microsoft.nl/netjesgeregeld

It's quite a risky step for them to take, but they want to make sure they're reaching their reader base and get a clearer picture of the interests of their readers. The magazine remains free and they've drummed up a full-blown redactional team for the revamp, so if you've enjoyed the magazine so far make sure you re-subscribe!