Lost in the triangles moved! find it here: aras-p.info/blog

They suck! Well, this probably isn't fresh news to anyone, but right now I'm working with code where basically everything includes everything else. The code is template-heavy so that makes things even worse. Try changing that file without 20 minute rebuild later - good luck!

Yeah, I know, the code is a product of 2 years of wandering in the darkness :) - prototyping, adding something and removing something, and when you constantly have to actually produce "working demos" in short timeframes, it ain't easy to actually sit down and refactor whole thing. Oh well, the reality...

Still, code with lots of dependencies does suck of course.

On the other hand, I'm pretty happy with the module I'm writing. All the outside just needs one header file that's right now 76 lines long and that includes only very basic "resource id" header file. The insides of my module also need some of the outside functionality; I've written some "outside interface" for that - a header file with something like 50 lines and also absolutely no includes.

That's what I consider to be a low-dependency interface. That's good. That doesn't suck :)

[EDIT] The code I was referring to isn't so bad (e.g. it really doesn't "includes everything else", but "includes quite large amount of stuff"). I'm just somewhat frustrated at the moment, and anything that's not very ideal in the codebase irritates me.

Some time ago I thought that 3dsMax had pretty bad usability (hey, it doesn't even do real hit testing :)). 3dsMax is nothing compared to one certain CAD package that I'm writing customizations for at work!

There's one conceptual problem that Paulius told me the other day: imagine that you have a white sheet of paper and a black pencil. How would you draw an object that emits light?

It's puzzling at first, but surely it can be done :)

I'm facing with the same problem in our next demo: we have a white character in a white, brightly lit room. Even more, there will be some light emitting "stuff" in there. Now, how to render all this so that it's not "washed out", too bright and with no contrast?

I'm not happy with the way it looks right now, but we're heading there.

Woohoo! My demogroup is nominated to scene.org awards 2004, in 'breakthrough performance'! Pretty cool, considering that Syntonic Dentiforms, which we got nominated for, is my first 'real' attempt at making a demo... Well, there were other attempts before, but they were really lame and childish :)

I was pretty happy with my demo-related performance last year. Three demos in half a year (ok, one of them was crappy). Now it's already half a year with no demos, and I already want to make one. Well, I'm already trying to make one, but so far there's lots of higher priority stuff surrounding me.

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.

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...

Today received my 'contributor copy' of ShaderX³. Pretty sad that the authors themselves receive the book only now, when it has been released in November. Well, maybe that's because for some reason my shipping address contained city 'Kannas' instead of 'Kaunas', and an obsolete postal index (we've got 'refactoring' of postal indices recently here :)). Anyway.

Like with most similar books, half of this one is old, well known or pretty basic stuff. At a first glance, Generating Shaders from HLSL Fragments by Shawn Hargreaves is really good; Dean Calver's stuff (Accessing and Modifying Topology on the GPU and Deferred Lighting on PS3.0 with HDR) also looks very cool. Probably these alone are worth the book; much like Kozlov's article on PSMs in GPU Gems was. My own articles - oh well; one (Shaderey...) is really useless; the other (Fake Soft Shadows...) is maybe 'interesting', but of unknown practical purpose :)

Ok, back to reading...

I'd like to redefine the term 'linear programming'. No, it's not about optimization problems; instead it's about programming style. You know you deal with linear programming when:

The other name for it could be 'copy-paste programming', except for the 1st point, where everything is coded linearly.

I tend to find lots of linear programming at work.

I was working on our next demo the other day. Boy, the video cards are damn fast nowadays!

We have a high-poly model for the main character (~200k tris), for the demo we use low-poly (~6500 tris) and a normalmap. Now, I've put 128 lights scattered on the hemisphere above him, each using shadow buffer. I have 4 shadow buffers, render to these from four lights, then render the character, fetching shadows from four shadowmaps at once. The result is that it's almost realtime ambient occlusion for the animating character, and it runs at ~40FPS on my geforce 6800gt!

This is of course pretty useless, we don't need realtime AO in the demo. But it has been nice :)