I have some conceptual questions about 3D textures and texture mapping in OpenGL that I am trying to wrap my head around. The questions pertain to the implementation of the code especially for 3D texturing in this tutorial: http://www.codeproject.com/Articles/352270/Getting-started-with-Volume-Rendering?fid=1807805&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Normal&spc=Relaxed&select=4729498&fr=1#xx4738025xx

The dimensions of the dataset used in the tutorial is 256 x 256 x 109 (109 2D slices)

1.

The code provides a way to map 2D images to a 3D texture by loading all the 2D slices into a single data array. Then, it proceeds to map the data to the 3D texture by incrementing fIndx from -1.0f to +1.0f in steps of 0.003f. Why is the increment in steps of 0.003f? There are ~666.667 increments which is roughly 6.11 times the total number of 2D slices (109 slices).

for ( float fIndx = -1.0f; fIndx <= 1.0f; fIndx+=0.003f )
{
    glBegin(GL_QUADS);
        MAP_3DTEXT( fIndx );
    glEnd();
}

2.

I am trying to figure out how to move through the rendered volume using 3D textures. What I am trying to do is similar to the video in this website: http://cvlab.epfl.ch/research/medical/em/synapses

The data in that website has to be, for sure, 2D images which are mapped to 2D textures. So, just making each layer in the volume vanish is apparently easy (but, I don't know how to do that!). My data looks like this though: http://ctrlv.in/292069

EDIT

There are 256 slices in my dataset, and I want to go through each slice one by one. How can I move through the slices one by one just as in the video?

1.

Why indeed... floating-point loop logic is evil. 0.003f cannot be represented in floating-point. After say 256 iterations of this, the loop counter is now ~= -0.231997 instead of -0.232. It would be better to do this loop using an integer control expression and then divide the end-result by 1000.0f inside the body of the loop. I would not trust the author of this tutorial to write any financial software. They will lose your money by doing things like this ;)

0.003f is actually ~ 0.003000000026077032089233398438... (it is a repeating number in floating-point because it cannot be expressed as division by a power-of-two). After enough rounding errors accumulate, the difference in value can be enough to throw off your loop counting logic. So much so, that even if that number incremented in steps large enough to address only 190 slices, the loop would run 1 less time and you would be missing a slice.

If you had 256 slices, and incremented ¹/₂₅₆ (which is expressed using a power-of-two denominator) per-iteration, floating-point loop control would work. Alas, ³/₁₀₀₀ has no such property. This is a bad floating-point value to use for looping. Since finding out whether a series of numbers can be represented precisely using floating-point is a nuisance, it is usually better to avoid floating-point loops altogether.

2.

If you want 256 unique values in the range [-1.0, 1.0] (NDC coordinate space), you should start at -1.0 and increment by exactly ¹/₁₂₈ (0.0078125) each iteration.