Grammerjack

From Scientific American: Binary Body Double: Microsoft Reveals the Science Behind Project Natal Short summary: They used machine-learning algorithms and lots of training data to come up with an algorithm that converts moving images into moving joint skeletons. Given the huge variation in human body shapes and clothing, it will be interesting to see how well this performs in practice. I bet people will have a lot of fun aiming the Natal camera at random moving object to see what happens. I can already imagine the split-screen YouTube videos we'll see of Natal recognizing pets, prerecorded videos of people, puppets and marionettes. Oh, and of course, people will point Natal back at the TV screen and see if the video game character can control itself. Great fun!

An excellent little performance optimization presentation that shows how important memory layout is for today's processors: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf The beginning of the talk makes the observation that since C++ was started in 1979 the cost of accessing uncached main memory has ballooned from 1 cycle to 400 cycles. The bulk of the presentation shows the optimization of a graphics hierarchy library, where switching from a traditional OO design to a structure-of-arrays design makes the code run 3 times faster. (Because of better cache access patterns.)

I just noticed Tom Forsyth, aka tomf, is speaking at the Stanford EE CS Colloquium on January 6, 2010. The video will hopefully be posted on the web afterwards. The topic is "To be announced", but is very likely to be Larrabee related.

I'm writing a skinning sample for a future Android SDK. This has prompted me to construct a toolchain to get skinned animated models into Android applications. I'm really only just getting started, but so far I'm thinking along these lines: Wings 3D -> Blender 2.5 -> FBX ASCII -> ad-hoc tool -> ad-hoc binary file -> ad-hoc loader. For what it's worth, right now Blender 2.5 doesn't support FBX export, so I have to do Collada -> FBX Converter -> FBX. But Blender 2.5 support should be ready fairly soon. You may wonder why I'm considering using the proprietary and undocumented FBX standard rather than the open source Collada standard. I'm doing it for the same reason so many other tool chains (e.g. Unity, XNA) do, namely that FBX is a simpler format that just seems to work more reliably when exchanging data between DCC applications.

The open-source Blender 3D DCC tool has long suffered from an ugly, non-standard, hard-to-learn UI. I'm very happy to see that the latest release, which just entered alpha status, has a much improved UI. It's not quite Modo quality, but it's starting to get into the same league as commercial DCC tools.

Here's the first public version of the slides from Tom Forsyth and Michael Abrash's GDC 2009 talks on Larrabee's instruction set, by way of Japanese magazine PC Watch, as seen on Beyond 3D's Forums. (You have to manually click on each of the little thumbnails of each slide.): http://pc.watch.impress.co.jp/docs/2009/0330/kaigai498.htm Hopefully Intel (or GDC) will release a better version of these slide decks sometime soon. Say, was it just me, or was blogging really light about GDC this year? In past years I was a lot more technical writeups than I saw this year. I wonder if blogging is down in general? Is everyone on Facebook and Twitter now? I can't imagine Twitter being very useful for reporting technical information. Here's Michael Abrash's Doctor Dobbs Journal article on the Larrabee instruction set. http://www.ddj.com/hpc-high-performance-computing/216402188 Here's the Intel GDC 2009 Larrabee talks: Rasterization on Larrabee: A First Look at t...

Ars Technica published an excellent interview with Tim Sweeney on the Twilight of the GPU . As the architect of the Unreal Engine series of game engines, Tim has almost certainly been disclosed on all the upcoming GPUs. Curiously he only talks about NVIDIA and Larrabee. Is ATI out of the race? Anyway, Tim says a lot of sensible things: Graphics APIs at the DX/OpenGL level are much less important than they were in the fixed-function-GPU era. DX9 was the last graphics API that really mattered. Now it's time to go back to software rasterization. It's OK if NVIDIA's next-gen GPU still has fixed-function hardware, as long as it doesn't get in the way of pure-software rendering. (ff hardware will be useful for getting high performance on legacy games and benchmarks.) Next-gen NVIDIA will be more Larrabee-like than current-gen NVIDIA. Next Gen programming language ought-to-be vectorized C++ for both CPU and GPU. Possibly the GPU and CPU will be the same chip on next-gen consol...