So, I had this smooth shadows idea recently. Turns out that it’s not an idea, Willem de Boer already has done a very similar thing (Smooth Penumbra Transitions with Shadow Maps). Now, the only way to have my idea back is to ‘optimize’ (i.e. hack/cheat) this method. Specifically, if we target projected shadows (not real shadowmaps), and can do some approximations, then we can get it working faster. I’ve done some experiments, right now it involves rendering to shadow map once, then Gaussian blurring it (two separable passes), then Poisson-blurring it. Works pretty fast :) I need to experiment some more and see if I can get anything.

I want to implement automatic mesh unwrapper (for normalmapping, lightmapping or similar). Not that I need it much, just so, for it’s own purpose. The most recent thing I’ve read is Bounded Distortion Piecewise Mesh Parametrization; now I only need to find some time to actually do something. Ain’t an easy task!

The other thing to try is: take ATI’s NormalMapper and take a look at their octree implementation. Try replacing it with several regular grids, or tweak the octree. Fun project, also without any real purpose… (again, the reason I don’t do this is “no time” :))

Finally, I have one really stupid&simple soft-shadows idea for oldskool projected shadows. It’s something between Mitchell’s ‘Poisson Shadow Blur’ and Valient & de Boer’s ‘Fractional Disk Soft Shadows’ in ShaderX3. I think actually trying to implement it (instead of just an idea that came up while taking a bath) would be only several hours…

I must sound like a loser complaining about lack of time. The truth is, I could get that time probably, if I’d were more organized.

And I though my own freetime projects were coded like a bunch of hacks, with no clear structure, with lots of code duplication etc… These are nothing compared to the code I now work with!

I’m working on ImagineCup2005 realtime rendering demo now, and one thing we are planning to do is fracturing/exploding walls of some room (in realtime of course). I’ve been thinking how to implement all this, and together with Paulius Liekis we came up with half-precomputed, half-cheated solution.

Our ‘walls’ are perfectly flat, so all fracture process is 2D, just the pieces that fly/fall out turn into 3D simulation. In the demo, some things will hit the walls, and the fracture must start there.

The first cheat we thought is to have some precomputed ‘fracture patterns’ (bunch of connected lines in 2D). Choose one pattern, ‘put’ that onto wall and there you go. Now, the problem is that the pattern has to be ‘clipped’ to the existing patterns, the falling out pieces and the remaining wall has to be triangulated, etc. I think it’s not ‘slow’ process (i.e. suitable for realtime), but pretty tedious to implement.

The next idea was: why not precompute the fracture pattern for the whole wall, and make it pretty detailed? When something hits the wall, you take out some elements from it and let them fly/fall. Now, the fracture pattern is always fixed for the whole wall, so this isn’t entirely ‘correct’ fracture, but I think it’s ok for our needs. I coded up some lame ‘fracture pattern generator’ (tree-like, nodes either branch or not, branches are at some nearly random angles, and terminate when they hit existing branch), and the patterns do look pretty cool.

The only problem with this is when I tried calculating how many fractured pieces our walls will contain. I get half a million or so for the whole room; that’s certainly a bit too much.

One idea to cope with this is: have a (sort of) quadtree for the wall, and each cell ‘combines’ the pieces it contains entirely into one ‘super piece’ (what a term!). Some of the internal nodes vanish, hence the super-piece contains less triangles, and it gets better when we walk up the quadtree. Now, when a wall is hit somewhere, only a small portion of it ‘fractures out’, so most of the wall can still be displayed as super-pieces, and it gets detailed only around the fractured area.

So, in the end there’s almost no computations performed for the fracture. The fracture pattern and the super-piece hierarchy is precomputed once, and at runtime we just use it. Of course, we still need to simulate the physics of flying/falling pieces, but that’s another story.

In one moment, we’ll have most of the walls ’exploded’ at once, I think for that case we’ll just use larger fractured elements, and everything will be ok :)

If I ever see code that I think could be written in ‘much better’ way, I have a really big temptation to rewrite/refactor it. Sometimes this can be good, eg. when I spot buggy code. Sometimes it depends, as I often spot the code that is (or I think is) ‘sub-obtimal’.

The worst situation is when the code is buggy, but some other part of the codebase depends on that code being buggy. If you find one, and not the other, it’s bad.

Working on some big unknown codebase remotely (I’m a contractor for one game in development) makes this worse. I must resist the temptation to alter the code, no matter how bad it looks…