For building Qt, you typically have to reserve an hour or so. There’s a much faster way to build it though (besides the optimisations I already described) — build it using jom. Jom is a multi-threaded nmake replacement. The only thing you have to keep in mind is to configure without -fast for versions before 4.6.3; if you configure with -fast, there’s a bug which will lead to Qt being build with a single thread. So just configure as usual, and run jom instead of nmake, your build-times should be drastically reduced.
Building Qt — fast
Deus Ex 3 Trailer, or what you can do for a few hundred $ per frame
In case you’re a computer graphics enthusiast, you should really take a break and look at the Deus Ex 3 trailer. It’s a really excellent 3 minute CGI film which shows what can be done with the proper people and a lot of money. Also notice how well the action is synced with the music (this is something I always envy the film guys for, they can really make sure the sound is in sync and also spend huge amounts of money on great composers.) I also like the voices of the characters, they fit very well.
Some things to look at:
- Extremely nice depth-of-field, notice the bokeh effects.
- The skin is pretty flat, look at the scene at the beginning when Adam is smoking. The skins looks really weird there (no subsurface scattering?)
- Super-cool metallic and plastic shaders (look at the ship starting at around 1 minute or at the cybernetic implants)
- Very nice hair (especially in the fight scene)
- There seems to be some ray-tracing on the police’ riot shields (hard to guess)
- Funny: The blinds cast a solid shadow in the trailer (correct, as the shadow blurs out), but in the in-game shots, they cast a line pattern.
- Nice matte-painting (the cities seem to be 2D with some 3D models added to them to increase depth perception.)
I’ve seen some estimates on the web which puts the trailer cost at several million dollars; at 2.5M$ it would result in approximately 500$ per frame … however, I’m not totally sure about this extreme estimates, as there is a lot of matte painting going on. Most sets are also barely visible, so they saved on props and environment modelling. Notice how they use depth-of-field and fog/smoke so you can’t see the full sets. The fully modelled characters are relatively few, so I would assume that the vast majority of the money went into animation and character modelling. For the latter, they might have been able to reuse parts from the game (high-polygon models for the characters?) So it might have been a bit cheaper in the end; anyway, it’s amazing work which you shouldn’t miss!
Posted in Offline/Rendering
Leave a comment
GPU Pro available
The GPU Pro book is available now, including my article about virtual texture mapping (it’s called “Virtual texture mapping 101″; I’m one of the authors. Thanks to all colleagues who helped with it, and in particular J.M.P. van Waveren for taking a look.) The book is actually “Shader X8″, but in an improved version. It’s a very nice edition with full-colour pages throughout. Make sure to grab your copy while it’s hot 
Posted in Realtime
Leave a comment
C++ unit testing frameworks revisited
For a long time, I’ve been using UnitTest++ for all of my C++ unit testing needs. UnitTest++ is a very nice and small unit testing library, which covers all basic needs and is very easy to integrate with a project. The problem is that the development has been on halt since 2008; I’ve been doing some minor adjustments locally, but in the long run, I would like to use an up-to-date library and get new features from time to time.
So I went out to search for a modern unit-testing framework in C++. Primary requirements were:
- Mature: It should be used on larger projects and have a stable API. I don’t want to have to update all my unit tests anytime soon again.
- Portable: Linux and Windows is a must, Mac OS X is a nice-to-have, console platforms is bonus. It should be at least reasonably easy to port if necessary.
- Fast integration: It should require minimal work to integrate. Tests should require at most one macro (something like
TEST(Foo).) It should not require to link against a shared DLL and the framework itself should be very easy to integrate. Ideally, I would like to compile it as part of the project (using CMake.)
After some searching, I found two major contenders:
- Google Test: The framework used by Google (internally), LLVM and Chromium
- Boost.Test: The Boost testing framework, used by Boost
Boost.Test
Boost.Test is a huge library bundled with Boost. It has to be built using the Boost tools, but as I’m a heavy Boost user anyway, this is no problem. On the fast integration side, it has BOOST_AUTO_* which make it very easy to get started. The test macros are easy to use, and provide check and require test levels (i.e. if a require fails, the test execution stops, while it continues over checks. This is very useful, you can break a test for instance if the result has zero size, and then check all contents of the results with checks.) It also brings collection equality tests, which are handy.
As you would expect from a good test framework, it has also support for fixtures and output customisation. From the portability side, it runs everywhere Boost runs, which covers all platforms mentioned above. Being used to test Boost, it also qualifies as mature, even though I’m not aware of any bigger project outside Boost that uses it.
Google Test
Google Test is the framework used internally by Google and now available for free. Building is trivial, as there is a single-source amalgamation file. Integrating is easy as well, for each test, you have to use a single macro. Test suites are defined along with each test, which means you’re forced to group them — which is not as bad as it sounds, as you usually want to group all tests for a submodule/class together anyway. The test functionality is very similar to Boost; on the one hand, GoogleTest provides death tests which Boost hasn’t, but it is missing a few tests that Boost provides (collection equality.) Adding additional tests is straightforward though.
The output customisation is very simple through an event-based interface. Portability is slightly worse than Boost; some features are supported on a one platform only (some only run on Linux.) On the other hand, it has nice platform-dependent tests (for instance, you can check HRESULTs on Windows.) It’s used on LLVM, which is a quite large library, as well as on Chromium, so it also qualifies as mature.
Conclusion
It’s a really tight race between Google Test and Boost.Test with no clear winner. For small one-off projects, I typically use Boost.Test now, as it’s really dead simple to integrate and puts the least burden on the client (i.e. I assume all users of my stuff have Boost installed.) For utmost portability, you should also stick with Boost.Test, as it focuses on standard-conformant C++ and should run almost everywhere.
On the other hand, the simple customisation of Google Test and the nice Google Mock library makes it an excellent candidate for larger libraries. In my case, I’ve integrated it into the build of my in-house stuff, so it gets built along with the rest of the projects. In this case, I also spent some time to customise the output etc. By providing platform-dependent tests, it also excels for applications which are supposed to run on Linux/Windows/Mac OS X.
It’s actually good to see that there are two equally good C++ testing frameworks out there which are on par with the tools you get for Java/C# and other languages. A much more comfortable situation than several years ago, where you basically were forced to write your own testing framework if you were serious about unit testing.