There are several important things you have to do in order to optimize your meshes, and one of them is packing your vertex/index data. Packing index data is trivial – for any sane mesh there are no more than 65536 unique vertices, so a 16-bit index buffer is enough; this is a small thing, but trivial to do. Reducing the vertex size is more complex.

In order to compress your vertex data you have to know the nature of your data (sign, range, special properties (like, is it a normalized vector), value distribution) and the available compression options. This is the topic for the next article; today I want to talk about quantization.

All methods of vertex compression that are trivially implementable on GPU involve taking the floating-point source data and storing it in a value with less bits of precision; usually the value is either an integer or a fixed-point with a limited range (typically [-1; 1] or [0; 1]). This process is known as quantization.

The goal of quantization is to preserve the original value with as much accuracy as possible – i.e., given a decode(x) function, which converts from fixed-point to floating-point, produce an encode(x) function such that the error, i.e. abs(decode(encode(x)) - x), is minimized. Additionally it may be necessary to perfectly encode a finite set of numbers (i.e so that the error is zero) – for example, it is usually useful to preserve endpoints, i.e. if you’re quantizing pixel component values, you’re encouraged to encode 0 and 1 perfectly, or pixels that were previously fully transparent will start to slightly leak some color on the background, and pixels that were previously completely white will give a dark color if you exponentiate their intensity.

Note that the error function is defined in terms of both encode and decode functions – the search for quantization function should start with the decode function. For GPU, decode functions are usually fixed – there are special ‘normalized’ formats, that, when used in a vertex declaration, automatically decode the value from small precision integer to a limited-range floating point value. While it is certainly possible to use integer formats and do the decoding yourself, the default decode functions are usually sane.

So, what are the functions? For DirectX 10, there are *_UNORM and *_SNORM formats. Their decoding is described in the documentation: for *_UNORM formats of n-bit length, the decode function is decode(x) = x / (2^n – 1), for *_SNORM formats of n-bit length the decode function is decode(x) = clamp(x / (2^(n-1) – 1), -1, 1). In the first case x is assumed to be an unsigned integer in [0..2^n-1] interval, in the second case it’s a signed integer in [-2^(n-1)..2^(n-1)-1] interval.

In for the UNORM case the [0..1] interval is divided in 2^n – 1 equal parts. You can see that 0.0 and 1.0 are represented exactly; 0.5, on the other hand, is not. The SNORM case is slightly more complex – the integer range is not symmetric, so two values map to -1.0 (-2^(n-1) and -2^(n-1) – 1).

This is only one example; other APIs may specify different behaviors. For example, OpenGL 2.0 specification has the same decoding function for unsigned numbers, but a different one for signed: decode(x) = (2x + 1) / (2^n – 1). This has slightly better precision (all numbers encode distinct values), but can’t represent 0 exactly. AMD GPU documentation describes a VAP_PSC_SGN_NORM_CNTL register, which may be used to set the normalization behavior to that of either OpenGL, Direct3D 10 or a similar method to Direct3D 10, but without [-1..1] range clamping (i.e. the actual range is not symmetrical).

Once we know the decoding formula, it’s easy to infer the encoding formula which gives the minimum error on average. Let’s start with unsigned numbers first. We have a [0..1] floating point number, and a 3-bit unsigned integer ([0..7] integer range).

First let’s mark all values that are exactly representable using the decode function on the 0..1 range (the top row of numbers, and black lines denote these) – just decode all integers from the range and draw a line. Now, in order to minimize the error, for every number we have to encode we have to pick the closest line, and select the corresponding number. I’ve drawn red lines that are exactly in the middle of corresponding black lines; all numbers between two red lines (which correspond to values in the row labeled ‘original’) will be encoded to the same number. The number each subrange should encode to is specified in the bottommost row.

Now we can visualize the encoding; all that’s left is to provide a function. Note that the encoding is not exactly uniform – the size of leftmost and rightmost subranges is half that of all other subranges. This is not a problem, since we’re optimizing for the minimal error, not for the equal range length.

The function is easy – if you multiply all numbers from the row ‘original’ by 7 (2^n – 1), you’ll see that all that’s left is to apply the round-to-nearest function; since we’re limited to unsigned numbers, the encode function is encode(x) = int (x / 7.0 + 0.5). (which is a standard way to turn round-to-zero, which is the C float-to-int cast behavior, to round-to-nearest for positive numbers).

Here is another image for the signed numbers, using Direct3D 10 rules. The range is [-1..1], we still have a 3-bit integer with [-4..3] range – we’re going to provide an encoding function that gives us the number in [-3..3] range. Using exactly the same reasoning as above, to encode the number we have to multiply it by 3, and then round to the nearest integer. Be careful – since float-to-int cast does a round-to-zero, or a truncate, the round function is slightly more complex. The encode function is as follows: encode(x) = int (x / 3.0 + (x > 0 ? 0.5 : -0.5)).

Just for reference, three functions for quantizing values to 8 bits are:

// Unsigned quantization: input: [0..1] float; output: [0..255] integer
encode(x) = int (x * 255.0 + 0.5)

// Signed quantization for D3D10 rules: input: [-1..1] float; output: [-127..127] integer
encode(x) = int (x * 127.0 + (x > 0 ? 0.5 : -0.5))

// Signed quantization for OpenGL rules: input: [-1..1] float; output: [-128..127] integer
encode(x) = int (x * 127.5)

These functions are the perfect foundation for the next step: reducing the size of vertex buffer by reducing the vertex size. Until next time!

In the world of command-line tools, success/failure is represented with exit code. However, it is important to understand that exit codes are to be treated carefully.

Here is a rough set of guidelines to handling exit codes:

• The canonical success code is 0, not 1. This is also true for return codes of functions – 0 always makes success. Never return 1 from your command-line tool to communicate success – no caller will expect this.
• Related to the above – there should be only one success code, i.e. everything else should be treated as error. There is no unambiguous encoding for several success values; the user probably does not care about details, the success is enough; for some system calls, like system(), cross-platform handling of different success values results in extra work (Windows returns the exit code as is, Linux returns a value that contains the exit code and additional information).
• In utmost majority of cases you don’t need more than one error code either. The reasons are the same.
• Even if you decide to use several error codes, do not use negative numbers. Some negative numbers may be used as special values for functions that normally return exit codes – in fact, one such number is -1; the family of spawn functions return -1 on error, so if you return -1 from your tool, the resulting error will be unexpected – we had one such case with SCons, where the matters were additionally complicated by the fact that -1 raised an OSError exception, which was swallowed by the SCons internals for some weird reason).
• If the tool fails, returning an error code is not enough – you should output the additional error information, which should be as detailed as needed to be able to further investigate the issue (i.e. don’t return ‘file load failed’ flag, print the name of file that the program failed to open, and the error code).
• As a somewhat related thing, if the tool succeeds, prefer less verbose output. An ideal tool is the tool that outputs zero lines of information if it succeeded (which reduces the clutter, enables easier detection of warnings, and generally makes people pay attention to the problems in the automated process because they are the only thing that’s printed!). If you need debugging/statistics information, consider adding a separate command-line flag. If you need version information for diagnostics, output it when a special command-line flag is used, not for every build.
• Be careful with batch files. It is very easy to accidentally lose an exit code in the batch file. In fact, if you can avoid batch files completely or make them one-liners that call your script interpreter of choice, do it; if you can’t, still try to go that way as far as possible.

So basically, if you only use 0 (success) and 1 (failure) exit codes, return additional failure information via stdout/stderr, and don’t pollute stdout with things that are not indications of some problem, the users of your command line tool will love you.

Since optimization is not a process with only positive effects, in production it’s important that optimization process follows certain guidelines that make sure the optimization does more good than bad. An example set of optimization steps would be:

1. Make sure that the code you’re optimizing works. If possible, it should be covered by tests; otherwise one can resort to saving the results that the code produces, i.e. a data array for a particular input or a screenshot.
2. Measure the performance of the target code in a specific situation, for example on a fixed set of input data, or, in case of games, at the very beginning of the level, or measure the average/maximum timings across the whole level.
3. Verify that the measurements are precise enough, i.e. don’t have a very large variation between runs.
4. Verify that the performance is inadequate for your target requirements (you can’t start optimizing if you don’t know your target requirements). It’s important that the measured situation is common enough – ideally you should measure in the worst possible circumstances for the code, which are still possible in the target product (i.e. if the unit number cap is 1000, profile with 1000 units). If necessary, make several measures in different situations.
5. Record the timings/memory statistics/other performance-related information.
6. Optimize the code using any available means, starting with the ones that are easier to code and minimally affect maintainability. In game development, if there is a substantial gain that is necessary, maintainability reasons should probably be cast aside.
7. Check that the code still works (run unit tests, compare the results with that from 1.)
8. Measure using the same data from 2., compare the results, repeat the process if necessary.

There are two absolutely crucial things here – make sure that the code still works, and have proper profiling before- and after- results. Often it’s useful to make a note of the results after each significant chunk of optimization, and save the results somewhere – some optimizations might get in the way later, and with the records you’ll probably be able to separate critical optimizations from less critical.

If you did not verify the code, it’s possible that the code now does something different – such optimization is usually bad (one exception is rendering algorithms, where usually you can replace ‘is exactly the same’ with ‘looks something like’ or even ‘is noticeably different, but the artists like it better/can live with it’).

If you did not profile the code, you don’t know if it works faster, and if it does, if it is considerably faster. Such optimization is worthless.

I have an actual story about that. Unfortunately, the information I have is incomplete – I have the code with an “optimization” that considerably decreases the actual performance, but I don’t have the change history. Still.

There is (was?) a COLLADA Exporter by Feeling Software, which, given an input Maya scene, produces a COLLADA XML document. This process is done at export time, which is either triggered by the artist manually, or is done automatically during the build process. The performance requirements for such tools are obviously different from the ones of a game – but optimizing the content pipeline response time is arguably equally important to optimizing game framerate, because faster iteration times and a good team mean more iterations, and more iterations mean more polished product.

Back at CREAT Studios, we used COLLADA pipeline for Maya/Max export; we tried to avoid touching the code, but sometimes we could not avoid it. An awesome export response time for a mesh is one second; a good one is ten seconds. We had some models that exported for several minutes. After some profiling several issues showed up – and here is one of them.

During the export, there are several parts of a document that can reference the same nodes from Maya DAG (Directed Acyclic Graph, pretty much the entire scene in Maya is a DAG); it is necessary to ‘sample’ the said nodes (i.e. to get the values of some attributes for these nodes for different time values). Sampling can be slow in Maya, because it can involve complex updates of the DAG – to accelerate that, there is a special class, CAnimCache, that caches the sampling requests. The key for the sampling request is a pair (object, attribute), the value is the list of attribute values and several flags. object is represented as MObject, plug is represented as MPlug.

The cache is organized as follows: there is an associative container with the key being the object, and the value being a list of parts. Each part holds the attribute and the cached value:

struct Part { MPlug plug; FloatList values; };
struct Node { MObject node; vector<Part> parts; };

struct Cache
{
    map<MObject, Node*> cache;
};

The code looks reasonable – the cache lookup is logarithmic in terms of object count and then linear in attribute count – objects usually have a modest amount of attributes, it should be fast enough. The cache key could probably be a pair of pointers, but oh well.

Still, somebody thought that this code is not fast enough. I do not know if the necessary performance tests were made – I guess they were not, or maybe the map was not a map but a vector when the change was made – anyway, somebody thought that this code is not fast enough, specifically that the map lookup is slow.

It’s easy to optimize the map lookup if we assume that the consecutive cache lookups happen with the same object, but with a different attribute – this is a reasonable assumption and it holds in practice. So, the code was modified and looked like this:

struct Cache
{
    map<MObject, Node*> cache;
    Node* search;

    Cache(): search(NULL) {}

    bool FindCacheNode(const MObject& node)
    {
        iterator it = cache.find(node);
        if (it != cache.end())
        {
            search = it->second;
            return true;
        }
        return false;
    }

    void CachePlug(const MPlug& plug)
    {
        if (search == NULL || search->node != plug.node()) FindCacheNode(plug.node());
        if (search == NULL)
        {
            search = new Node(plug.node());
            cache.insert(plug.node(), search);
        }

        /* additional processing of the search node */
    }
};

Can you spot the problem?

At the first call to CachePlug, search is NULL, so the function FindCacheNode is called, which does not find the node. search is still NULL, so a new node is inserted; now search points to this node.

At the next call to CachePlug with a different MObject, search is non-NULL, but the node is different, so FindCacheNode is called again. It can’t find the desired node – after all, nobody inserted it! – so it returns false… without resetting search to NULL!. In fact, nobody ever resets search to NULL – so nobody adds new Node’s – so the map always has one element, and the parts vector contains all attributes of all nodes in the scene! As you can imagine, this makes all functions from the cache linear in terms of scene object count, and thus the whole export process quadratic. All functions still worked, but the export was slow for large scenes.

It is hard to reconstruct the sequence of events without a change history – however, one thing is certain. At some point here somebody did an optimization without any prior profiling (map lookup could not be a serious factor – after I fixed the bug, the functions from this class were nowhere near the profile top), and without any profiling after the change – otherwise he’d spot the bug.

The code travels in sometimes unexpected ways. A year ago I found the same issue in OpenCOLLADA, which inherited some code from Feeling Software exporter. (it was fixed after my report).

Optimization without profiling is wrong. Profiling without measuring and comparing the results is wrong. Please do not do either of that. And please, look at your code in the profiler once in a while, even if the performance is tolerable – you’ll find things you didn’t expect.

P.S. The credit to discovering the optimization bug actually goes to Peter Popov (of the Linux RSX fame).


]]> http://zeuxcg.org/2010/11/29/optimizations-that-arent/feed/ 0 zeuxcg http://zeuxcg.org/2010/11/22/z7-everything-old-is-new-again/ http://zeuxcg.org/2010/11/22/z7-everything-old-is-new-again/#comments Sun, 21 Nov 2010 21:45:27 +0000 zeuxcg http://zeuxcg.org/?p=333 Continue reading →]]> Debug information is the data that allows the debugger to, uhm, debug your program. It consists of the information about all types used in the program, of source line information (what instruction originated from what source line), of variable binding information (to know where on the stack frame/in register pool each local variable is stored) and other things that help you debug your program.

There are two different ways to store the debug information for C/C++ code: one follows the ‘separate compilation’ model of C++ and stores debug information in the object file for each translation unit, another adopts the ‘everything is a huge database’ model and stores debug information for the whole project in a single database. The first approach is the one taken by GCC; MSVC, on the other hand, uses the second approach by default.

Here’s how it works in practice: suppose you have an application project, game, that references two static library projects, render and sound. There is a single database file (which has .pdb extension) for each project – they usually are located in the same intermediate folder as object files – so in this example we have three PDB files, which by default are all called something like vc80.pdb, depending on the MSVS version – but, since you can change that, we’ll assume they’re called game.pdb, render.pdb and sound.pdb. While the files in all projects are compiling, the compiler computes the debugging information for the current translation unit and updates the corresponding .pdb file.

However, the debugger can’t work with multiple pdb files – it wants a single PDB file. So the linker, in the process of linking the final application, in our case game project, merges all PDB files in a single file – let’s call it gamefinal.pdb. The linker gets paths to all PDB files from object files (or from object files inside static libraries), reads debug information from them, generates a single PDB file, writes it to disk and stores the path to this file in the executable (exe or dll). Debugger reads the PDB path from the executable module and uses the debugging information from that file.

There are some nice properties of this system:

• The resulting debugging information is separate from the executable – you can generate it for all builds, including retail, but don’t redistribute the pdb. In fact, please always generate the debugging information for all builds! Prior to Visual Studio 2010 the default settings for Release configuration excluded any debug information, which is unfortunate.
• The mechanism for discovering the “source” PDB files at link stage is flexible – I’ve described the default setup for freshly created projects, however you can modify it – you can have all projects update a single PDB file, or you can have 1 PDB per object file. Linker will work regardless of the setup.

However, there is a problem – what if several files are compiled in parallel? In case they refer to the same PDB file, we have to use some synchronization mechanism. This concern (perhaps there were other reasons that I’m not aware of) led to the following design – there is a server process, called mspdbsrv.exe, which handles PDB file operations and ensures safe concurrent access. Compiler uses the server to update PDB files, linker uses the server to read source PDB files and update the final PDB file. Some operations are apparently asynchronous – you can sometimes observe that even though the linker process has exited, the final PDB file processing is not finished, which can lead to file access errors.

So, now everything works fine, right? Almost.

When you’re using distributed compilation, i.e. via IncrediBuild, the compiler processes are run on different machines. They update some PDB file locally, which is then transferred to your machine. However, this effectively disables the PDB server operations – instead of a single server process that updates all PDB files, there are now multiple server processes, one for each worker machine! This leads to disaster, which manifests in corrupted PDB files and can be easily observed if you try to use make/scons/jam/any other build system with MSVC + IncrediBuild + compiler-generated PDB files.

IncrediBuild has a special hack in order to make this work – when you compile the solution via Microsoft Visual Studio, IncrediBuild modifies the build command line by splitting the PDB file for each project into several files, making sure that all files with the same PDB name go to the same agent. You should be able to use the same hack for make/scons/jam, since you can declare that you tool behaves like cl.exe in IncrediBuild profile, but I don’t know the details and couldn’t get it to work.

It turns out that MSVC initially used the first debug information storage approach – i.e. it stored the debug information in object files. Moreover, this mode is still available via the /Z7 switch (this is the so-called ‘old style debug information’, or ‘C7 Compatible’ in the MSVC GUI – you can find the setting in Project Properties -> C++ -> General -> Debug Information Format). This has the following implications:

• Debug information is now local to translation unit – there are no races in case of concurrent compilation by design.
• The PDB server is no longer used during the compilation, because it is not needed.
• The linker reads debug information from object files directly, instead of looking for PDB path and opening the PDB (in fact, there is no PDB path in object files).
• Static libraries contain embedded object files, so a static library file is now self-contained – it contains all information that’s necessary for linking

Obviously, the compile and link file access pattern change greatly. The change in compilation/linking times is hard to estimate – on one hand, with /Zi all debug information was consolidated in a single PDB file (per project), now it’s scattered throughout object files (which, by the way, increases the size of intermediate files because now there is duplicate debug information), on the other hand the linker should read object files anyway, so locality should not be worse. Also, we eliminate a theoretical synchronization bottleneck (the PDB server), so multiprocess builds can get faster.

Here are my completely unscientific benchmark results on OGRE builds with cold cache in four build variants: /Zi (PDB files, single core build), /Zi /MP (PDB files, multicore build), /Z7 (no PDB files, single core build), /Z7 /MP (no PDB files, multicore build). For each configuration, I did a clean build of the OgreMain.dll using a new source folder every time, then I rebooted to force file cache cleanup, changed a single source file and did a build once again. Both compilation and linking times are included. The tests were done on a Core i7 920.

	/Zi	/Zi /MP	/Z7	/Z7 /MP
clean cl	6:45	1:51	6:32	1:32
clean link	0:20	0:20	0:17	0:17
incremental cl	0:15	0:15	0:08	0:08
incremental link	0:17	0:17	0:24	0:24

While there are some savings for the clean build, the total incremental build time is the same (which can be explained if this is the cost of reading old debug information – since it is moved from link time to compilation of the single changed source file). With that in mind, Z7 and Zi are probably more or less interchangeable – unless you need Edit & Continue support, which is not supported with old-style debug information. Still, I like the /Z7 approach better.


]]> http://zeuxcg.org/2010/11/22/z7-everything-old-is-new-again/feed/ 1 zeuxcg http://zeuxcg.org/2010/11/15/include-rules/ http://zeuxcg.org/2010/11/15/include-rules/#comments Mon, 15 Nov 2010 19:45:25 +0000 zeuxcg http://zeuxcg.org/?p=323 Continue reading →]]> We’re stuck with C++, at least for another console generation. C++ has many quirks that I wish were not there, but there is no real alternative as of today. While modern languages tend to adopt the bulk compilation and/or smart linkers and so can have a proper module system and eat the cake too, C++ is stuck with header files (on the other hand, C++ builds are incremental and almost embarrassingly parallel). While the strategy of dealing with header files and staying sane seems more or less obvious, I’m amazed as to how many people still get this wrong. I hope that this post helps to clear the mud somewhat. The post applies to C as well, but is useless for people who are blessed to work with other languages.

The problem with include files is that the preprocessor is usually quite dumb – you tell it to include the file, it includes the entire contents of the file, recursively. If you don’t tell it to include the file but try to use the symbol from that file – you get a compilation error. If you tell it to include too many files, it includes all of them, and the compilation time suffers.

In general, the more a header is included in other files (including transitive inclusion, i.e. A includes B includes C means that A indirectly includes C), the more files you’ll need to recompile once the header changes. Iteration time is very important – which is a topic for another time – so we’d like to minimize the amount of header inclusion. This brings us to the first important rule: Each file should include the minimum amount of files. The rule helps ensure that your code builds fast.

Now, let’s suppose that the header file contains a class declaration. By the nature of C++, a class declaration won’t compile without some other declarations – for example if a class A inherits from a class B and contains a field of type C, then you have to give the compiler declarations of both B and C in the same translation unit (i.e. in the cpp file that you’re compiling – after preprocessor has done its work) – before A’s declaration. Now, there are two options here – you can either include the relevant header files in the header with A’s declaration, or force the user to always include B and C headers manually before A. The problem is that sometimes the user does not know about these dependencies (i.e. the field of type B can be private), sometimes the dependencies change, so every time you’re adding some declaration dependencies to your types you’re breaking user’s code, and, since declaration dependencies are transitive, often to include a single header you’ll need a dozen or more seemingly unrelated ones. For this reasons, it’s important for all headers to be self-contained – anybody should be able to include any header in any cpp file without compilation errors. Which brings us to the second important rule – each file should include all dependent headers, i.e. for each declaration that’s required by the compiler there should be a corresponding include. This rule helps ensure that the programmers stay sane.

These two rules together define the algorithm for proper header file authoring: for each required declaration, include a corresponding header in your header file; don’t include more headers than that. In order to guarantee that you did not forget the necessary headers, make sure that your header file is the first #include in the corresponding source file, except the common header, if your codebase has one.

Do not include a header for a dependency declaration where a forward declaration will suffice; use forward declarations when possible (if you’re not familiar with forward declarations, google it). Sometimes it pays off to go to extra lengths to remove header dependencies, using techniques like pimpl – this depends on the exact situation, but avoid including heavy platform files, like windows.h or d3d9.h, to popular headers (I’ve written about a way to make a slim version of d3d9.h in a blog post, scroll down to the last section).

With the rules above, there is only one thing left – since we can include a header twice accidentally (i.e. A depends on B and C, and B depends on C, so C is included twice into A), we’ll need some protection against that. So each file should include the guards against multiple inclusion. There are two methods for this – either use #pragma once or use header guards. #pragma once is a non-standard technique, that tells the preprocessor explicitly “don’t include this file more than once in a single translation unit”. Header guards can emulate the behavior using preprocessor defines:

#ifndef FILE_NAME_H
#define FILE_NAME_H
...
#endif

Many people don’t know this, but #pragma once is widely supported in modern compilers. It’s superior to header guards in two ways: it can be faster than header guards (i.e. MSVC does not read the file with #pragma once more than once, but does read the file with header guards several times), and it’s foolproof – you don’t have to invent the identifier for a header so you can’t screw it. So use #pragma once if you can, use header guards if you must. If some compilers that you use don’t support #pragma once and you can’t convince the vendors to add the feature, make sure that the header guards are unique using a deterministic generation algorithm. For example, you can use something like “take the list consisting of the name of the project, and all components of the relative file path; convert all elements to upper case and join with underscore”, resulting with identifiers like THEGAME_RENDER_LIGHTING_POINTLIGHT_H. Do not use short file names alone, they are not unique! (unless your coding standard requires that). Oh, and if you don’t use an autogenerating macro, don’t put a comment after the #endif (i.e. #endif // THEGAME_RENDER_LIGHTING_POINTLIGHT_H) – such comments are only useful as a copy-paste history.

While using header guards allows you to have the same file included several times in a single translation unit, it also allows you to test whether the file was already included, i.e. #ifdef THEGAME_RENDER_LIGHTING_POINTLIGHT_H. You should never conditionally exclude a section of a header file based on whether some file was included! Doing this introduces the inclusion order dependency which is unnatural, and hard to debug without a preprocessor output. If you’re thinking about something like “oh, if the renderer interface was included, I should probably provide a light renderer class, but otherwise it would just add unnecessary clutter”, you should split your header file in two parts, and the second part should explicitly include the renderer interface, since it depends on it.

At least in game development, the language is frequently extended with some generally useful primitives that are used throughout the whole codebase. The most used one is probably an assertion macro (since the standard one sucks, you should have your own), but there are other examples – logging facilities, fixed-size types, min/max functions, various platform/configuration defines (“are we on a big-endian platform?”), memory management-related macros. It’s common practice to put all of those in a single common header file; you should control the size of this file (where by ‘size’ I mean the cumulative size of all headers it includes, of course), and you should make sure that each source file includes the common header before everything else – otherwise you’ll get into trouble (sometimes you’ll spend several hours looking for the reasons – i.e. if you include a header that checks platforms endianness before the common file, you’re in the world of hurt).

Well, I think that’s all about header files; there are also the include paths though. In order to include the file, you have to specify the path to it – either a “relative to the current file” path, or “relative to one of the include directories” path. There are two important goals here:

• If you’re writing a library – a relatively small one, i.e. not a platform like Unreal Engine – the header files should require minimal configuration, so ideally the user does not have to add include directories to compile or use your library. For such projects, consider making all include paths current file-relative.
• Otherwise, include paths should be easily greppable – the path to the same file should ideally be the same in all other files. So make all include paths include directory-relative; moreover, try to make sure that include paths are unambiguous – i.e. that you don’t have two different representations for the same file path, like and inside render project.
• Whatever rule you use, try to make sure it’s consistent between different projects, as much as necessary. Ideally even the include directories should be the same, i.e. include directories for the engine project should be a strict subset of include directories for the game project.

And as a final advice – learn to use the preprocessor output (cl /E, gcc -E), learn to use the include output (cl /showIncludes, gcc -M), gather the codebase statistics (average size after preprocessing, most included header files, header files with largest payload, etc.) and optimize your codebase by eliminating dependencies and spreading the word. Nothing beats a sub-second iteration time.

Oh, did I mention that good header dependencies decrease the linking time?


]]> http://zeuxcg.org/2010/11/15/include-rules/feed/ 23 zeuxcg http://zeuxcg.org/2010/11/07/lua-callstack-with-c-debugger/ http://zeuxcg.org/2010/11/07/lua-callstack-with-c-debugger/#comments Sun, 07 Nov 2010 18:40:03 +0000 zeuxcg http://zeuxcg.org/?p=304 Continue reading →]]> Lua is a very popular scripting language in game development industry. Many games use Lua for various scripting needs (data representation, UI scripting, AI scripting), and some go as far as write the majority of the game in Lua. At CREAT, we used Lua for all of UI scripting, and for AI and other game logic on some projects. And, well, there were times when the game crashed – and the callstack consisted mainly of Lua functions.

While there are probably very few bugs in Lua library code, and the language is safe so you can’t get buffer overruns or other madness only via script code, script code itself is useless, because it can’t do any interaction with the outside world – user, world state, scoreboard servers, etc. So naturally there is a Lua binding for some C/C++ functions, so that scripts can call them. Now, if one of these functions crashes – for example, because they got invalid input data – how do we trace the problem back to the script code?

Assuming we don’t want to modify C++/Lua code in any way, nor do we want to restart the game with tracing hook enabled – the easily reproducible bugs are often a luxury – we’re left with the following methods:

1. If the external Lua debugger was attached, it’s likely that we’ll be able to get the callstack and the related information from it.
2. We can trick the game into calling a call stack dumping function (using lua_getstack and lua_getinfo).
3. We can get the call stack manually, by inspection of Lua data structures.

It is possible that you don’t have a working Lua debugger, do not have it attached or that it does not work at the moment (oh, and the deadline was yesterday). I’m going to describe the last two approaches here.

Use a stack dumping function

This approach is superior to the third one because you can have arbitrarily complex logic in the stack dumping function – i.e. you can print local variables along with the call stack – and it’s less tedious. Just make sure your stack dumping function does not crash :) However, unless you have good debugger support for this, calling the function so that the program can work after the point can be problematic.

Anyway, at first you’ll need the function itself. The trivial implementation looks like this:

void lua_stacktrace(lua_State* L)
{
    lua_Debug entry;
    int depth = 0; 

    while (lua_getstack(L, depth, &entry))
	{
        int status = lua_getinfo(L, "Sln", &entry);
		assert(status);

		dprintf(%s(%d): %s\n", entry.short_src, entry.currentline, entry.name ? entry.name : "?");
        depth++;
    }
}

In order to get local variable information, you’ll have to use lua_getlocal and ordinary functions for getting values from Lua stack; this is left as an exercise to the reader.

Now we have the function; you’ll have to make sure that the function is linked in your executable; just reference it from some other function like this:

volatile bool x = false;
if (x) lua_stacktrace(NULL);

Now you have to call the function. If you’re lucky to have a debugger that can do this – for example, Microsoft Visual Studio can often do this from the Watch or Immediate windows – then just add the expression lua_stacktrace(L), where L is the pointer to the Lua state (games often have a single Lua state, in which case I recommend you to save it to the global variable to make debugging easier).

Otherwise, you’ll have to save all registers and other relevant CPU state, setup the registers/stack so that you can call the function, set the instruction pointer to the first instruction of the function, add a breakpoint to the returning instruction of the function and hit F5. The function code will execute and stop on the breakpoint; here you have to restore all registers and CPU state, restore the instruction pointer and hit F5 again.

You don’t want to do that.

Seriously, it’s way too complex and chances are, you’ll screw something up so that the game will crash anyway. So I recommend to pick a thread you don’t care about anymore, setup the necessary stuff to call the function and call it – the thread will not work anymore, but you’ll have your callstack. I often used the approach to for post-mortem crash debugging, so the program is dead anyway.

Depending on the platform ABI, the relevant setup is different; for example:

• On x86, the argument is read from stack, using the esp register (esp + 4 should contain the pointer); for MSVC, add a watch *(void**)(esp + 4), change the value to the lua_State pointer, get the address of the target function by adding a watch lua_stacktrace, go to the function in disassembly window, use “Set Next Statement” command on the first instruction, hit F5.
• On PowerPC, the argument is read from register r3; add a watch r3, change the value to the lua_State pointer, go to the function in the disassembly window, use “Set Next Statement” or the equivalent command of the debugger on the first instruction, hit F5.

You’ll see the call stack and the game will crash, but now you have additional context for the problem and can debug the crash further. If you’re using this method a lot, I suggest making a less trivial function, which is able to dump locals. Just in case, dprintf in the code above dumps the string to debug window (using OutputDebugStringA); use whatever debugging output available on your platform.

Inspect Lua data structures

The approach with calling the function is dangerous, since it can stop or corrupt the execution flow; also it requires code execution, which may be unavailable – for example, you can’t use it if you’re debugging via crash dumps on some platforms. Therefore it’s useful to know how Lua represents the call stack, so that you’re able to get the call stack information using the safe debugger features, i.e. object state inspection.

As before, I’ll assume you know the lua_State pointer; it’ll be referred to as L.

First, we’ll need to get low-level call stack information. It’s stored in an array of CallInfo structures, and L has three pointers to it: base_ci, ci, end_ci. Get the stack frame count with L->ci - L->base_ci + 1 (let’s assume it’s 6), then display all of them with L->base_ci,6 (this is a special watch expression, it’s supported by Microsoft debugger and PS3 debugger – debuggers for other platforms might have an equivalent feature).

Each callstack entry has two important fields: func, which points to a function object representing the call frame (we’ll get the function and source file from it), and savedpc, which points to a saved program counter (we’ll get the line from it).

Function object is a Lua object, which can represent either a Lua function or a C function. We can verify that the interesting entry is a function by checking that L->base_ci[5].func->tt equals 6 (LUA_TFUNCTION); after that we’ll check the type of function with L->base_ci[5].func->value.gc->cl.c.isC.

If it’s 1, then it is a C function; we can get the function pointer with L->base_ci[5].func->value.gc->cl.c.f, and that’s it. This function will be in the ordinary call stack of the relevant thread; also, the top stack entry should be the C function, unless you’re inspecting the state while Lua code is running inside the VM.

The previous frame in our case contains a Lua function (L->base_ci[4].func->value.gc->cl.c.isC is 0), so we’ll get the additional information for it. The Lua function contains a pointer to the prototype, which is stored in L->base_ci[4].func->value.gc->cl.l.p (it contains a pointer to the Proto object, which is 0x00330d80 in my case – I’ll use this pointer to reduce the watch expression complexity).

Now, we’re close. The prototype contains the source file path, you can get it with (char*)(&((Proto*)0x00330d80)->source->tsv + 1). It’s a string, and in Lua string data is situated right after the string header (you can also skip the char* cast and use the ,s watch modifier). Now all we need is line information.

Remember savedpc from earlier? This is a pointer which points to some instruction in ((Proto*)0x00330d80)->code array – you can get the instruction index like this: L->base_ci[4].savedpc - ((Proto*)0x00330d80)->code, which is 5 in our case (if you’re doing address arithmetics by hand, don’t forget to divide by 4 – this is the instruction size, thankfully all instructions in Lua are 4 bytes in size). However, this is the instruction that follows the call; we actually need the previous instruction to get the point of call, so the instruction index is 4.

Now all we have to do is to get the line number from lineinfo array: ((Proto*)0x00330d80)->lineinfo[4] (which is 41 in our case).

That’s all – we know the source file, we know the source line – now we can repeat the process above for each call stack entry.

Some final remarks:

• Since Lua implements tail call optimization, the callstack will sometimes be unexpected – some entries will be skipped. You can check if that’s the case by looking at tailcalls field inside CallInfo: L->base_ci[2].tailcalls.
• The first call stack entry (with the index 0) contains nil value; just ignore it.
• In complex cases you’ll have several Lua states (multithreading, coroutines) – the process of stack unwinding is the same.
• You can get local variable values too by using CallInfo top field and looking at function debug metadata; this is more complicated but doable.
• If you’re writing an embeddable language, please make sure that in your product, getting a call stack is at least as easy.

]]> http://zeuxcg.org/2010/11/07/lua-callstack-with-c-debugger/feed/ 1 zeuxcg http://zeuxcg.org/2010/11/03/moving-on/ http://zeuxcg.org/2010/11/03/moving-on/#comments Tue, 02 Nov 2010 20:18:30 +0000 zeuxcg http://zeuxcg.org/?p=298 Continue reading →]]> The day has come – I’ve left CREAT Studios and started working at Saber Interactive as a PS3 (well, that was obvious) programmer (well, that was obvious too).

I worked at CREAT for three years and a half; I’ve enjoyed it immensely – I had the privilege of working with some smart people, together we built an engine for next generation (then) consoles, and I’m quite proud of the results. During these years I’ve helped ship a lot of PS3 projects – though none of them were AAA (what does AAA mean anyway?), all of them are good games and some have interesting tech inside. On my last day I got into a TerRover match with my colleagues and only came to at 10 PM – it was that much fun.

You should not have a favourite weapon. To become over-familiar with one weapon is as much a fault as not knowing it sufficiently well.

Still there was a brave new world out there – I wanted to work on projects of larger scale, I wanted to see what other companies look like and to delve into unknown technology to further enhance my understanding of game development – and here I am. Count me excited!


]]> http://zeuxcg.org/2010/11/03/moving-on/feed/ 1 zeuxcg http://zeuxcg.org/2010/10/25/source-code-implementing-direct3d-for-fun-and-profit/ http://zeuxcg.org/2010/10/25/source-code-implementing-direct3d-for-fun-and-profit/#comments Mon, 25 Oct 2010 19:21:26 +0000 zeuxcg http://zeuxcg.org/?p=288 Continue reading →]]> Almost a year and a half ago I blogged about several useful things that you can do with custom IDirect3DDevice9 implementations. I don’t know why I did not post the code back then, but anyway – here it is:

dummydevice.h – this is just an example of a dummy device implementation; it implements all device methods with stubs that can’t be called without a debugging break. This is useful for other partial implementations.

deferreddevice.h – this is the implementation of the device that buffers various rendering calls and then allows to execute them on some other device. Note that it lives in a fixed size memory buffer, which can be easily changed, and that it implements only a subset of rendering-related functions (i.e. no FFP).

texturedevice.h – this is the implementation of the device that works with D3DXCreateTextureFromFile for 2D textures and cubemaps (3D texture support is missing but can be added in the same way).

DL_BREAK is the replacement for __debugbreak, DL_ASSERT is a custom assertion macro (with neat (void)sizeof(!(expr)) trick that I hope everybody knows about by now), everything else should be obvious.


]]> http://zeuxcg.org/2010/10/25/source-code-implementing-direct3d-for-fun-and-profit/feed/ 3 zeuxcg http://zeuxcg.org/2010/10/25/quicksort-killer-sequence/ http://zeuxcg.org/2010/10/25/quicksort-killer-sequence/#comments Mon, 25 Oct 2010 19:07:35 +0000 zeuxcg http://zeuxcg.org/?p=281 Continue reading →]]> Today I’m going to describe a not very practical but neat experiment, the result of which is a sequence that’s awfully slow to sort using Microsoft STL implementation; additionally, the method of generating such sequence naturally extends to any other quicksort-like approach.

First, a quick refresher on how std::sort [in Microsoft STL] works. It is a variant of introsort with insertion sort for small chunks. It proceeds as follows:

• For small sequences (32 elements or less), it uses insertion sort, which has O(n^2) average complexity, but has a better constant than a quick sort;
• For other sequences, a median of either three or nine elements, depending on the sequence size, is selected as a pivot;
• The array is partitioned in place, resulting in three chunks: the leftmost chunk has all elements that are less than the pivot, the middle chunk has all elements that are equal to the pivot, and the right chunk has all elements that are greater than the pivot;
• Left and right chunks are sorted recursively (actually, only the smaller one is sorted via a recursive call, but that’s not significant);
• Finally, if the recursion depth is too big (more than 1.5*log2(N)), the algorithm switches to heap sort, which has a worst-case complexity of O(n*log(n)).

This, given a careful implementation, results in a good general sorting function – it uses quicksort (which has a lower constant than heapsort), but falls back to heap sort on inputs that sort slowly with quicksort. However, due to unfortunate debug checks inside pop_heap function in MSVC2005 and 2008, the heap sort is quadratic in debug builds (this has been fixed in MSVC2010), so if we can make a sequence that’ll make quicksort quadratic, this introsort implementation will also go quadratic in debug builds.

Since all quicksort-like sorts only depend on the order between elements (they’re comparison-based), we can build the sequence of any type (i.e. a list of strings), and then make a sequence of some other type (i.e. integer list) with the same order; the number of comparisons will be the same.

Each quicksort-like sort has the following algorithm:

1. Select the median(s) either using pseudo-random numbers or some fixed set of elements inside the given range;
2. Partition the range in several chunks, with rightmost chunk consisting of all elements larger than the largest median (my method can be naturally extended to multi-pivot sorts);
3. Recursively sort the chunks.

Our goal, in order to make the worst possible sequence, is to maximize the size of the rightmost part; then the recursive call depth will be linear in terms of original element count, and the whole routine will be quadratic. To achieve that, we’re going to incrementally build the strings in the list with the following algorithm:

1. Get the locations of median candidates for the first sorting pass (i.e. not including recursive calls);
2. One of them (the middle one, assuming that it’s moved appropriately) is the median (pivot); we append the following letters to all strings:
   • ‘a’ to all median candidates to the left of the pivot;
   • ‘b’ to the pivot itself;
   • ‘c’ to all other elements.
3. With the previous pass we maximize the amount of elements that are larger than the pivot; after this, we proceed recursively.

In order to get the information about the median candidates, the median and the partition results, we need to slightly instrument the sorting function; I made the following interface:

struct sort_context
{
	virtual bool less(const element& lhs, const element& rhs) { return lhs.last < rhs.last; }
	virtual void partition_begin() {}
	virtual void partition_median(const element* med) {}
	virtual void partition_end(const element* right_begin, const element* right_end) {}
};

struct predicate
{
	sort_context* context;

	bool operator()(const element& lhs, const element& rhs) const
	{
		return context->less(lhs, rhs);
	}
};

The sorting function should call partition_begin before each sorting pass, partition_median after the median is selected, and partition_end after the array is partitioned, passing the range of the rightmost chunk.

Then we can implement the function that retrieves indices of median candidates:

std::pair<std::vector<size_t>, size_t> get_first_median_positions(element* data, size_t count)
{
	struct median_context: sort_context
	{
		bool inside;
		unsigned int counter;

		const element* median;
		std::vector<const element*> positions;

		median_context(): inside(false), counter(0), median(0)
		{
		}

		virtual bool less(const element& lhs, const element& rhs)
		{
			if (inside && counter == 0)
			{
				positions.push_back(&lhs);
				positions.push_back(&rhs);
			}

			return sort_context::less(lhs, rhs);
		}

		virtual void partition_begin()
		{
			assert(!inside);
			inside = true;
		}

		virtual void partition_median(const element* med)
		{
			assert(inside);
			inside = false;
			if (counter++ == 0) median = med;
		}
	};

	// collect median data
	median_context c;
	sort(data, count, &c);

	if (!c.median)
	{
		assert(c.positions.size() == 0);
		return std::make_pair(std::vector<size_t>(), 0);
	}

	// sort & remove duplicates
	std::sort(c.positions.begin(), c.positions.end());
	c.positions.erase(std::unique(c.positions.begin(), c.positions.end()), c.positions.end());

	// convert from pointers to offsets
	std::vector<size_t> result(c.positions.size());

	for (size_t i = 0; i < result.size(); ++i) result[i] = c.positions[i] - data;

	// get median position
	std::vector<const element*>::iterator median = std::find(c.positions.begin(), c.positions.end(), c.median);
	assert(median != c.positions.end());

	return std::make_pair(result, median - c.positions.begin());
}

a function that sorts the array and returns the partition information for the first pass:

std::pair<size_t, size_t> get_first_partition_right_modify(element* data, size_t count)
{
	struct partition_context: sort_context
	{
		unsigned int counter;
		const element* begin;
		const element* end;

		partition_context(): counter(0), begin(0), end(0)
		{
		}

		void partition_end(const element* right_begin, const element* right_end)
		{
			if (counter++ != 0) return;

			begin = right_begin;
			end = right_end;
		}
	};

	// get partitioning data
	partition_context c;
	predicate pred = {&c};
	std::sort_instrumented(data, data + count, pred);

	// get indices
	return (c.begin == 0 && c.end == 0) ? std::make_pair(0, 0) : std::make_pair(c.begin - data, c.end - data);
}

and finally the main function, that uses the above helpers:

void update_array(element* data, size_t count)
{
	// get positions of the first median candidates (along with the median itself)
	std::pair<std::vector<size_t>, size_t> p = get_first_median_positions(data, count);

	if (p.first.empty()) return;

	// fill elements as follows:
	// - elements from median candidates before median get an 'a' appended
	// - median element gets a 'b' appended
	// - all other elements get a 'c' appended (so that they go into the right half after partition)
	std::map<size_t, char> actions;

	for (size_t i = 0; i < p.second; ++i) actions[p.first[i]] = 'a';
	actions[p.first[p.second]] = 'b';
	char action_otherwise = 'c';

	for (size_t i = 0; i < count; ++i)
	{
		std::map<size_t, char>::iterator ait = actions.find(i);

		data[i].last = (ait == actions.end()) ? action_otherwise : ait->second;
		*data[i].data += data[i].last;
	}

	// copy the elements to preserve the original data
	std::vector<element> copy(data, data + count);

	// get the right partition (left should be very small so we don't care)
	std::pair<size_t, size_t> partition = get_first_partition_right_modify(&copy[0], count);

	// process the right half
	update_array(&copy[0] + partition.first, partition.second - partition.first);
}

Note that as an optimization, the predicate only compares the last characters of the strings; since after each partition the contents of the right chunk consists of equal elements, the only difference is in appended character (which is one of ‘a’, ‘b’, ‘c’).

The only task that remains is to convert the string array to the integer array with the same order; this is straightforward, except that we have to use std::multiset for sorting since std::sort is slow on this set of data (which was the goal, after all :):

std::vector<size_t> generate_array(size_t count)
{
	// create element array with empty strings
	element* data = new element[count];

	for (size_t i = 0; i < count; ++i)
	{
		data[i].data = new std::string;
		data[i].last = 0;
	}

	// update it to make worst possible order
	update_array(data, count);

	// make a sorted copy using std::multiset because std::sort is slow on this data (we prepared the data this way!)
	std::multiset<element> copy_set(data, data + count);
	std::vector<element> copy(copy_set.begin(), copy_set.end());

	// create an order remap
	std::map<std::string*, size_t> order;

	for (size_t i = 0; i < copy.size(); ++i) order[copy[i].data] = i;

	// create an integer array with the same order
	std::vector<size_t> result;

	for (size_t i = 0; i < count; ++i) result.push_back(order[data[i].data]);

	// cleanup
	for (size_t i = 0; i < count; ++i) delete data[i].data;
	delete[] data;

	return result;
}

Here is the full source code for this post. It contains the above code for generating the killer sequence for a quick sort implementation, and additionally the instrumented sorting function from MSVC2008 STL. This code may not compile on other compilers because of the MS-specific parts of the sorting function itself, but otherwise should work fine.


]]> http://zeuxcg.org/2010/10/25/quicksort-killer-sequence/feed/ 2 zeuxcg http://zeuxcg.org/2010/10/17/aabb-from-obb-with-component-wise-abs/ http://zeuxcg.org/2010/10/17/aabb-from-obb-with-component-wise-abs/#comments Sun, 17 Oct 2010 18:23:22 +0000 zeuxcg http://zeuxcg.org/?p=268 Continue reading →]]> This post is about a neat trick that is certainly not of my invention, but that should really be more well-known; at least, I haven’t heard of it till I stumbled across it while reading Box2D sources.

There are a lot of bounding volumes out there; the most widespread are certainly spheres and boxes, which come in two flavors – axis-aligned bounding boxes (AABB) with faces parallel to the coordinate planes, and oriented bounding boxes (OBB), which is essentially a AABB and an orientation matrix.

It’s common to use AABB in spatial subdivision structures, like octrees, kD-trees, ABT and so on – the intersection test between two AABB is pretty straightforward. However, when dealing with dynamic meshes, it is needed to recalculate the AABB of the mesh when the mesh transformation changes.

Assuming that the mesh has a local bounding box (which is an AABB), the usual way to get world-space AABB for the mesh is as follows:

1. Get 8 corners of the mesh AABB
2. Transform all corners to the world space with the mesh transformation matrix
3. Find the component-wise minimum and maximum of the resulting 8 vectors

However, there is a better way, which reduces the amount of floating-point operations to one quarter of the above. It’s easily derived once we slightly change the AABB representation – while AABB are commonly represented with two vectors, min and max, let’s assume that our box is represented with the center and extent vector:

min = center – extent
max = center + extent

or

center = (min + max) / 2
extent = (max – min) / 2

Now, the 8 corners of the original AABB are in the form of center + (±extent.x, ±extent.y, ±extent.z). Transforming those by the matrix M is thus

M * (center + (±extent.x, ±extent.y, ±extent.z))

Let’s expand the matrix-vector multiplication; the result looks like this:

M00 * (center.x ± extent.x) + M01 * (center.y ± extent.y) + M02 * (center.z ± extent.z) + M03
(and likewise for other two components)

We can slightly rearrange the equation to get this:
(M00 * center.x + M01 * center.y + M02 * center.z + M03) + (±M00 * extent.x + ±M01 * extent.y + ±M02 * extent.z)
(and likewise for other two components)

Now, the left part is shared by all 8 points, and is equal to M * center (i.e. to the AABB center, transformed to the world space); this is the center of the new AABB.

The right part is different for all points; however, it’s obvious that, since extent vector has non-negative components, that the minimum of the right part is reached when all of ±M00, ±M01, ±M02 are negative, and the maximum is reached when all of them are positive. Thus, the maximum of the right part is:

abs(M00) * extent.x + abs(M01) * extent.y + abs(M02) * extent.z
(likewise for other two components).

Note that this is the matrix-vector multiplication, with the matrix being the component-wise absolute value of the original transformation matrix, and the vector being the extent vector (which has to be transformed as if it is a direction, i.e. without taking matrix translation into account).

The resulting code looks like this (this is F# with SlimDX math classes):

let matrix_abs (matrix: Matrix) =
    let mutable m = Matrix()
    for i in 0..3 do
        for j in 0..3 do
            m.[i, j] <- abs matrix.[i, j]
    m

let transform_aabb_fast (aabb: BoundingBox) matrix =
    let center = (aabb.Minimum + aabb.Maximum) / 2.f
    let extent = (aabb.Maximum - aabb.Minimum) / 2.f

    let new_center = Vector3.TransformCoordinate(center, matrix)
    let new_extent = Vector3.TransformNormal(extent, matrix_abs matrix)

    BoundingBox(new_center - new_extent, new_center + new_extent)

Instead of 8 shuffles, 8 matrix-point multiplications and 8 vector min+max operations, we need to convert the AABB to and from center+extent representation (extent can be alternatively computed as aabb.Maximum – center) and do one matrix-point and one matrix-direction multiplications, which is usually faster.

In case the original mesh bounding volume was an OBB (in my experience, this is usually not necessary, as local-space AABB give a good enough approximation for common cases, but still), this can be applied in the same way – you’ll have to get a full transformation matrix by multiplying the OBB and mesh transformation matrices.

When I’ve seen this in Box2D, at first I did not understand why the code works at all – the meaning of component-wise absolute value is not immediately obvious. Now I know; and I hope that this was of some interest to you.


]]> http://zeuxcg.org/2010/10/17/aabb-from-obb-with-component-wise-abs/feed/ 0 zeuxcg