Eric Lengyel

The tangent and bitangent are derived using a calculation like this:

 

http://www.terathon.com/code/tangent.html

another alternative is the transvoxel algorithm by E. Lengyel, though I am not sure if it's patented, it is iirc

 

The Transvoxel algorithm is not patented. More information here:

 

http://www.terathon.com/voxels/

 

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.

You could do this, but I don't recommend it:

void pushback_function()
{
    char storage[sizeof(some_class)];
    some_class *temp = new(storage) some_class;
    array.push_back(*temp);
}

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:

 

http://web.cs.wpi.edu/~gogo/courses/imgd3000_2011c/

http://web.cs.wpi.edu/~gogo/courses/imgd3000/projects/final/

 

You can see the feature list here:

 

http://www.terathon.com/c4engine/features.php

 

If you have any questions, please feel free to post in the C4 Engine forums:

 

http://www.terathon.com/forums/

The answer to the thread title can be found here:

 

http://www.terathon.com/code/tangent.html

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.

Aren't those both line-line tests and not line segment-line segment tests?

Yes, you're right. I must have been to sleepy to see the word "segment".

Calculate the following values, where x means cross product:

T1 = B - A
M1 = A x B
T2 = D - C
M2 = C x D

Then the two lines intersect if and only if

T1 * M2 + T2 * M1 = 0

where * means the dot product.

Of course, in floating-point calculations, you're unlikely to see a value of exactly zero, so you'd want to instead check for values very close to zero.

If you'd like to know more about where the above stuff comes from, look into Grassmann algebra and homogeneous coordinates. Here's a presentation:

http://www.terathon.com/gdc12_lengyel.pdf

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?

This diagram of the C4 Engine architecture might interest you:

http://www.terathon.com/c4engine/architecture.php

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:

http://www.terathon.com/voxels/

Another reason z-fail is more expensive is because you have to render a lot more triangles for the endcaps. You should you z-pass as much as possible, and use z-fail only when necessary. You can determine when z-fail is necessary as described here:

http://www.gamasutra.com/view/feature/2942/the_mechanics_of_robust_stencil_.php?page=4

The method described in GPG2 is very efficient and practical. I've been using it for over ten years (since the time I wrote the article), and I've been extremely happy with it. It's important to realize that the polygon clipping only happens once, when the decal is created, so it's not like you're spending time building the decal every frame. It does not cause a performance problem. Managing the decal on the CPU also has certain advantages that you can't get in a GPU-only method. For example, suppose a decal was created on an object that later moves, like a door opening or a barrel rolling down a hill. If the portions of the decal applied to those objects inherit the transform properly, then the decals move with the objects they are attached to. Even if the transforms were communicated to the GPU, a deferred rendering technique would have a serious problem trying to distinguish between the geometries to which the decal should be applied and those that may be near the decal now but shouldn't have the decal applied to them.

The dot product between a normalized plane and a point gives you the signed perpendicular distance from the point to the plane. The equation T * L = r means that the distance between the tangent plane T and the light position L is equal to the radius r of the light source. The equation Nx^2 + Nz^2 = 1 just means that the normal to the plane is unit length, where we left out the y coordinate because it is known to be zero.