This version explains that the edgeArray parameter should point to a preallocated buffer large enough to hold the maximum number of edges possible, which is three times the number of triangles in the mesh.
What I really miss from all this exchange formats, especially when using them to export stuff for a game engine, is the lacking support of custom attributes. You can add custom attributes in modelling tools, but you never got them exported to Collada/FBX. It is possible with OpenGex ?
It depends on exactly what kind of custom attributes you're talking about. OpenGEX supports custom per-vertex data and custom material attributes, but intentionally does not allow for general custom data all over the place. The reason for this is to avoid the creation of software-specific standards like you see in the Collada format through the use of the <technique> elements, making it necessary for importers to understand information whose format is specified over multiple poorly-maintained documents. Now if you're just talking about custom user-defined key-value properties like those supported in 3DS Max, then I can tell you that support for these is being considered for the next version of OpenGEX, and it's something that can easily be added to the existing exporters.
It means the dot product between the four-dimensional plane L = (Nx, Ny, Nz, D) and the homogeneous point P = (Px, Py, Pz, 1). The plus sign in the book is correct. If you're familiar with my more recent talks on Grassmann Algebra, then this is more accurately stated as the wedge product between the antivector (Nx, Ny, Nz, D) and the vector (Px, Py, Pz, 1).
In general, a correctly implemented Marching Cubes algorithm generating a mesh with a single LOD will only produce cracks if it doesn't have a consistent way of choosing polarity for the so-called "ambiguous cases". This can be solved by using a fixed polarity based on corner states or some face-level choice function as used in the MC33 algorithm. See Section 3.1.2 of my dissertation at the above link for some discussion of these. Using fixed polarity is easy, and it never generates any holes in the resulting mesh.
A good MC implementation will generate a smooth mesh to begin with if the data at each voxel location has a range of values instead of just a binary in or out state. The ugly stair-stepping only shows up if you're forced to put each vertex right in middle of each isosurface-crossing edge because you don't have enough information to do anything more intelligent.
Are you scaling after the rotation, so as to cause a skew? This would cause the tangent and bitangent to no longer be perpendicular, so calculating the bitangent as the cross product between the normal and tangent won't quite work. Instead, if you calculate the bitangent in terms of tan1 just like you calculated the tangent in terms of tan0, you'll get the right vector. But then you can no longer assume that the inverse of the TBN matrix is just its transpose when you do your shading.
If you're looking for an engine that teaches the proper techniques and general theory of game programming, then you'll probably want an engine that includes source code, and that eliminates Unity and UDK.
Please check out the C4 Engine, which has been used in game programming classes at many universities for several years. Here is an example of a specific course that uses the C4 Engine:
The GL driver also keeps a copy of the texture image in RAM. The contents of the VRAM accessible to the GPU can be dumped at any time (for example, if the screen resolution is changed), and the driver needs to be able to restore your textures from its copy in RAM without you having to do anything.