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.
I provided a link to the C4 diagram just because I thought the OP might have been interested in seeing how one example of a professional game engine is put together. Nothing more. I'm not telling people that's the only way to do things, and I'm not saying that other solutions are wrong. The diagram itself is just a big picture of how a bunch of different systems are related, and there is nothing exact about it. The green/orange boxes represent large collections of code, and the gray boxes represent features. The green arrows loosely represent dependencies, and the little black arrows simply show where in the engine specific features are handled. Red arrows are the same as green arrows, but come from plugin modules as opposed to the main engine. Arrows that are not connected to anything mean that a collection of code is used throughout the engine and that it would be silly to connect arrows from that box to almost all the other boxes.
flodihn, some of your comments are way out of line, and you've shown a complete lack of respect for people (not just me) who clearly know a lot more than you. I have a Ph.D. in computer science, I've written or contributed to 9 books on the topics of game programming and computer graphics (and my game math book has been a bestseller for over a decade), I designed the graphics driver architecture for the PlayStation 3 (see patent #20090002380), I've worked in the industry for 16 years at companies including Sierra, Apple, and Naughty Dog, I regularly speak at the Game Developers Conference, and I've been running a successful game engine company for the past 7 years where I am the sole programmer for the C4 Engine. The C4 Engine architecture and source code are widely regarded by professional game programmers as some of the cleanest design in existence. Now tell me, exactly what qualifies you to say I don't have a clue about software engineering?
You would probably find "Voxel-Based Terrain for Real-Time Virtual Simulations" to be very interesting. It thoroughly addresses the problem of tangent-space normal mapping for triplanar projections in Section 5.5. You can find the paper here: