3D等效位图（bmp）

Question

In the same way that a bitmap (bmp) is just a 2 dimensional array of values representing white/black or color - is anyone aware of a similar type of "structure" for a simple 3 dimensional bitmap? In other words, a 3 dimensional array of values representing black/white or color?

It seems like there are a variety of problems that potentially be solved relatively easily with such a "point cloud" type of structure.

In other words, without getting into the whole 3d rendering world, some problems seems solvable with a much simpler data structure, and far less math than is usually involved with managing 3d objects effeciently (using OpenGL, DirectX, Axiom, GDI+, etc).

I understand that this structure would not be "efficient" along a variety of vectors - but... it seems like there may be certain problems that would seem to lend themselves to such a "model" of a 3d object.

It would also be helpful to have an algorithm to generate such a point cloud from other 3d file types such as STL, Mesh, POV, BLEND, etc). Maybe one of these is already such a structure? (newbie) :)

Any suggestions or information greatly appreciated. Thanks in Advance.

Answer 1

There is nothing preventing you from using a 3D array of numbers to store pixel data except the memory to store it. Like this:

struct Pixel {
    int Red;
    int Green;
    int Blue;
}

public Pixel[,,] myPix3D = new Pixel[300, 300, 300];

That is the "3D equivalent of Bitmap"

OR, you could store each pixel and its location, to save memory. This way you don't store anything for empty spaces in your object.

struct Pixel {
    int Red;
    int Green;
    int Blue;
    double X;
    double Y;
    double Z;
}

If you had a very detailed 3D scan from something like an MRI or CAT scanner, these structures would be useful, and in fact a collection of 'slices' from such a scan is basically the same thing. Most of the time, we are only concerned with putting the visible pixels on the screen as fast as possible, and better structures exist for that, such as vector models, collections of triangles, etc.

Another way to store a 3D image, which is actually used quite often, is the depth-map. With each pixel, you store a value indicating how close it is to the "screen" or whatever your projection surface is, and in subsequent drawing operations, you skip any pixels that have greater depth than the current pixel, because it won't be visible. (also called Z-buffering)

Also please note, when we go through the process of actually rendering 3D objects, we DO create them in 3D space first - but we usually do not texture map those objects, so the "in memory" representation is temporarily the type of object you are talking about but a bitmap always contains all the pixels, and we don't always need that, so we don't render the solid object into 3D space, only the wire-frame. Most graphics engines apply textures AFTER that temporary 3D space has been projected to 2D, and many optimizations have been applied.

You could use that middle step to create your points in 3D space, but it isn't efficient to do that when all we are interested in is rendering the 2D image. If you had some use for the 3D bitmap, it could easily be created from wireframe models which have been projected into 3D space.

Answer 2

3D textures are supported natively by standard rasterization hardware and API's. Note that "point cloud" doesn't refer to any kind of 3D raster -- instead, a point cloud is just an unstructured collection of points.

The most common problem with using a 3D data array is that it takes an awful lot of memory -- so much that the sheer size can make it slow to compute with, even if the data fits in available memory. There are ways to improve on this: I believe MIP maps are supported for 3D textures, and on the main processor side, octrees can be used to take advantage of sparse 3D data.

However, there are many applications where 3D arrays make sense and nothing else does. For example, MRI data is naturally dense 3D information.

Answer 3

AFAIK there is no such a thing as a well-stablished raster 3D structural format. While raster data is often used in modern graphics, it is limited to texture, bump maps and height fields; structure is always defined in vector terms.

My bet is that the reason for this scenario is the data volume x model ratio, sometimes questionable in 2D, but clearly at a disadvantage in 3D.