FML
Friday 15 January, 2010
What computer sciencese really is about: spending 40+ hours looking for a bug only to find out that this so-called “bug” is caused by somebody else his code. FML
Over the past months I’ve spent countless hours working on my project of Computer Animation (given at UHasselt). In short, I have to make a tennisgame containing realistic animations. One of the tasks is to animate a human skeleton (using Inverse Kinematics) so it can swing his tennis racket back and forth. (And hopefully hitting some balls in the process to.) Over the past few weeks however I couldn’t get this thing to work. All it did was moving the arm somewhere randomly, then keep moving untill it got stuck:
Skeleton preparing his arm to swing. Instead he's bending forward.
Hours and hours I’ve wasted looking for the bug in my code. I read my book several times, checked the original thesis again and again and again, I read course materials from other universities about the same subject and recently I’ve been having e-mail correspondence with my professor. Result: nothing, squadush.
This afternoon however I found out what’s wrong. Take a look at the following line:
plMath::plVectorf result = position.outerProduct(axis);
As any non-math-wizard would expect, calculating the cross product of two vectors simply gives you a new vector, right?
Well, it would if I had written the vector class. Unfortunately, I did not. The implementation for the vector class was written by somebody who works at UHasselt and apparently prefers returning a matrix as the result of a cross product. Add in the fact that C++ simply converted the matrix to a vector (not the one I wanted of course) and my calculations were way off. At least I can continue working on my project now, deadline is next week 
.
Goals for 2010
Friday 1 January, 2010
Like probably every person in the world, I also have my list of things to do in 2010. First of all I should really, really, write more blogposts. One post per week is a nice goal …
Next to that I should also get back to work on my thesis. The last month I’ve barely made progress. Main cause are a bunch of school projects I had to finish, which, by tradition, are always given at the end of the semester. (And of course one of these projects has to play the role of b*tch.)
Pokerwise I only played 80k hands last year. As a reference, some people play 80k hands per month … Needless to say my volume should increase if I want to make some nice profits. As a general guideline I want to play at least 100k hands at 100NL. Possible 200k or more with the help of polyphasic sleeping. Of course a lot of my volume depends on how the current legislation concerning online gambling will evolve. Rumors has it PokerStars is already negotiating with the Belgium comission on gambling, and yesterday I also read an article about Ladbrokes probably not getting banned. Taking into account that the current law doesn’t require us, pokerplayers, to pay taxes on our winnings, the new legislation might not be as worse as expected.
The polyphasic sleeping thing I mentioned earlier, is something I plan to do once my exams are finished. I’m not a 100 percent certain which sleeping pattern I want to try, but most likely it’ll be Everyman or Uberman. I still have some practical planning to do (like deciding when to take my naps), but I’m really looking forward to try it out and having gazillions of time to spend.
Results
Tuesday 24 November, 2009
Stanford Dragon 16384 Depth Maps (60 Mb)
Stanford Dragon 65536 Depth Maps (136 Mb)
Stanford Dragon 262144 Depth Maps (302 Mb)
Optimized
Tuesday 24 November, 2009
4096 depth maps with resolution of 128 x 128 = 512 Mb of data.
16384 depth maps with resolution of 128 x 128 = 2 Gb of data.
Compression, first tests looking good!
Tuesday 24 November, 2009
256 depth maps, 32 samples per pixel.
Stanford Bunny Uncompressed
Stanford Bunny Compressed
Red areas indicate difference with the uncompressed version. In general I have less noise/self-shadowing, but some trivial points on the bunny are now miscalculated. It might have something to do with a special case where my current implementation of the compression algorithm isn’t a 100% correct.
Before I’m going any higher in my number of depth maps (read: 64k and up), the throughput of my compression pipeline should increase. For the record, the implementation of Tobias et al. requires only a couple of seconds to compress 1024 depth maps. Mine requires around one hour 
.
CSM on CPU
Monday 23 November, 2009
Some screenshots of my current implementation on the CPU (uncompressed):
Stanford Bunny, 1024 shadow maps, 64 samples per pixel
Stanford Dragon, 1024 shadow maps, 512 samples per pixel
Notice the banding of the shadows in the last picture. This is a consequence of using “only” 1024 shadow maps. With four times as much shadow maps there is a considerable improvement:
Currently I’m still using an uncompressed version of the algorithm. Task for this week however is to integrate the compression so I can go full-scale. If I find some time I’ll try to make a render using 16k uncompressed shadow maps (which is already 2Gb of data to put in memory).