Skip to main content

Posts

Image based lighting notes

These are some of my notes from implementing image based lighting, a.k.a. IBL. I thought I understood it pretty well until I started implementing it. Now, after a lot of reading, discussing and trying things out, I'm finally getting back to the stage where I tentatively believe I understand it. Hopefully these notes will save future me, or anyone else reading them, from going through the same difficulty. I'll update them if I find out anything further. Some helpful references GPU-Based Importance Sampling , GPU Gems 3, Chapter 20 . Real-Time Computation of Dynamic Irradiance Maps , GPU Gems 2, Chaper 10. Physically Based Shading in Theory and Practice , SIGGRAPH 2013 Course. In particular, the course notes for "Real Shading in Unreal Engine 4" are very helpful. The radiance integral $$L_o(v) = L_e(v) + \int_\Omega L_i(l) f(l, v) (n \circ l) dl$$ The amount of light reflected at some point on a surface is the sum, over all incoming directions, o...

Faster morton codes with compiler intrinsics

Today I learned that newer Intel processors have an instruction which is tailor-made for generating morton codes: the PDEP instruction. There's an instruction for the inverse as well, PEXT . These exist in 32- and 64-bit versions and you can use them directly from C or C++ code via compiler intrinsics: _pdep_u32/u64 and _pext_u32/u64 . Miraculously, both the Visual C++ and GCC versions of the intrinsics have the same names. You'll need an Intel Haswell processor or newer to be able to take advantage of them though. Docs for the instructions: Intel's docs GCC docs Visual C++ docs This page has a great write up of older techniques for generating morton codes: Jeroen Baert's blog ...but the real gold is hidden at the bottom of that page in a comment from Julien Bilalte, which is what clued me in to the existence of these instructions. Update: there's some useful info on Wikipedia about these intructions too.

Awesome tools for Windows users

I moved back to Windows on my home computer a few months back. There are a few amazing free tools I've found since then that have been making my life better and I thought they deserved a shout-out. They are: SumatraPDF A fantastic PDF reader. Does everything I want and nothing I don't. RapidEE A sane way to edit environment variables. The simple joy of just being able to resize the window is... incredible. 7-Zip The best tool for dealing with compressed files on windows, bar none. GPU-Z A really handy way to see details about your GPU(s). XnView An amazingly good image viewer, which can also do bulk file format conversions. If you haven't already got these... go get them!

Whole program lexical analysis

I was thinking about parsing and lexical analysis of source code recently (after all who doesn't... right??). Everywhere I've looked - which admittedly isn't in very many places - parsers still seem to treat input as a stream of tokens. The stream abstraction made sense in an era where memory was more limited. Does it still make sense now, when 8 Gb of RAM is considered small? What if, instead, we cache the entire token array for each file? So we mmap the file, lex it in place and store the tokens in an in-memory array. Does this make parsing any easier? Does it lead to any speed savings? Or does it just use an infeasible amount of memory? Time for some back-of-the napkin analysis. Let's say we're using data structures kind of like this to represent tokens: enum TokenType { /* an entry for each distinct type of token */ }; struct Token { TokenType type; // The type of token int start; // Byte offset for the start of the token int end; ...

Project Tethys Post-mortem

Project Tethys was my entry for Ludum Dare 29 . Here's the elevator pitch: Project Tethys is a fast-paced underwater 2D shoot-em up inspired by the likes of Defender and Resogun . You control an advanced combat submarine tasked with defending an underwater research facility against an invading army. If you enjoy classic arcade-style action, this game is for you! So far the game has been getting pretty good feedback. It's the most polished entry I've ever submitted for a Ludum Dare and the one that I'm most proud of so far. Here's what it looks like in action: I've carried on working on it since the end of the competition, fixing some of the problems people have commented on and adding more of the features I'd originally planned. Expect another post about that when I'm ready to release it. Tools Unity 4.3 (free version) GarageBand for iPad bxfr Nuke 8.0 (specifically the ModelBuilder node) Paint.NET VLC What went right Makin...

Ludum Dare 29: Beneath the Surface

I'm halfway through making a game for Ludum Dare 29 . The theme this time around is "Beneath the Surface". For once I've had an idea right from the start that's practical, fun and in keeping with the theme. It's a lovely change from my usual pattern of starting with an idea that turns out to be impractical or boring & having to start over halfway through the competition. So on that basis alone I have high hopes for this one. Here it is: Project Tethys It's an underwater shoot-and-rescue-em-up inspired by the likes of Defender and Resogun . You control a state-of-the-art combat submarine tasked with defending an underwater research facility from an invading army. Or at least, that's what it should be if I can finish it in time... The controls are arrow keys or WASD to move, left mouse button to fire. There's still loads left to do: implementing the rescue mechanic; sound effects; enemy AI; a high score table; a menu system; better model...

OpenGL in OS X 10.9

Apple announced details of OS X 10.9 "Mavericks" today. For anyone who writes cross-platform graphics software, one of the biggest bits of news was that it will finally support OpenGL 4. Specifically: OS X 10.9 will support the OpenGL 4.1 Core Profile This info comes from their release notes . I haven't been able to find any info about supported extensions yet. While welcome, the news is still a bit disappointing. OpenGL 4.1 is now a 3 year old standard, so I'd hoped for something a bit more recent. I believe the Intel HD4000 and HD5000 chips used the MacBook Air & Pro only support up to OpenGL 4.1, so I guess that played a part in the decision.  OS X will be still be the lowest common denominator for OpenGL, relative to Windows and Linux; but at least the denominator is not quite as low any more!