Sign in to follow this  
Geometrian

OpenGL 3D Textures

Recommended Posts

Hi, I recently got 3D textures working in my OpenGL application. It would be nice to have some 3D textures to work with, though. Presently, I'm just taking a 2D image and using it (depth=1), but I know greater things are possible. On a slight tangent, how are 3D textures stored? I had the idea to use a 2D image. Suppose you have a 512x512 image, that can hold the data for a 64x64x64 texture. Is this the way 3D textures are typically stored? I'm hoping for a metallic 3D texture, as that fits nicely into my new game, but really any sort of 3D texture would be good right now. Any decent free resources? I couldn't find any... Thanks, Ian

Share this post


Link to post
Share on other sites
Yeh 3d textures are amazing, they are just a bunch of 2d textures on top of each other.

Did you know, you can actually create a high detail 3d voxel surface on top of your triangle models, and you can render any kind of advanced 3d voxel pattern.

And you can probably draw 10 flat sprites on top of each other and you could make things like grass on the surface of a landscape.

Its just a matter of making the grass model in 3dsmax, convert it to 3d textures, then displaying in game, 256 flats ontop of each other restoring the grass in 3d.

Theres almost no difference in just storing 10 normal textures as aposed to loading a single 3d texture with 10 layers... its just you get special 3d retrieves from a 3d texture, when you Tex2DLod()

Share this post


Link to post
Share on other sites
Quote:
Original post by rouncED
Yeh 3d textures are amazing, they are just a bunch of 2d textures on top of each other.

They're a bit more than that. Texture arrays are essentially just 'a bunch of 2D textures', but even they have some very significant differences.

Quote:
Original post by rouncED
Theres almost no difference in just storing 10 normal textures as aposed to loading a single 3d texture with 10 layers...

There are a lot of differences. First off, a 3D texture allows quad-linear interpolation, instead of the trilinear 2D texture interpolation. The hardware will also interpolate on the depth axis. Second, mipmap sizes are defined by a cubic function, instead of a quadratic one. Third, a 3D texture is a monolithic structure, from the point of view of the GPU. It cannot be partially swapped out of VRAM, even if you only use a small subset of it. This is very different from a set of 2D textures, which can be partially swapped. And last, most importantly, you can sample a 3D texture by using a single texture lookup with a three component vector. This is totally impossible with a bunch of 2D texture, where each texture requires a separate image unit, a separate lookup and complicated logical to actually select the right images and interpolants.

Quote:

On a slight tangent, how are 3D textures stored? I had the idea to use a 2D image. Suppose you have a 512x512 image, that can hold the data for a 64x64x64 texture. Is this the way 3D textures are typically stored?

Depends on the GPU architecture. Most GPUs don't even store 2D textures in the straightforward way, due to texture cache issues. From the host application point of view, 3D textures are stored per slice.

3D textures are very useful, but don't get too excited about using them everywhere. They take up a lot of memory. A simple RGBA 512³ texture will eat up 512 MB VRAM ! In fact, the best usage scenarios for 3D textures involve very asymmetric texture sizes, for example 512*512*4. They're used to store more information per pixel then a typical RGBA texture can provide (16 components instead of the usual 4, in this example). This can be used to store spherical harmonic coefficients in a lightmap, for example.

Share this post


Link to post
Share on other sites
Here's a rather cool paper about generating 3D (solid) textures from 2D examples:

Solid Texture Synthesis from 2D Exemplars

Unfortunatly I've asked the author for source code/executable but haven't got anywhere.

One advantage of 3D textures is that you don't need to specify UV texture coordinates for you models. Instead, you can just use the vertex positions as texture coordinates (possibly scaled, rotated, etc). This makes then useful for texturing proceduraly generated geometry, or geometry which changes dynamically.

Disadvantages include the memory required, and the fact that they are hard to generate. You could generate them procedurally, but you might also want to look at exporting them from 3D modelling packages. Such packages typically have a 3D material editor. If you rendered this material onto a bunch of adjacent slices you could take the resultig images and rebuild the 3D texture. Scripting could make this automatic...

Share this post


Link to post
Share on other sites
Quote:
Original post by Geometrian
I'm hoping for a metallic 3D texture, as that fits nicely into my new game, but really any sort of 3D texture would be good right now. Any decent free resources? I couldn't find any...

3D-textures consist from layers,but has more specific mipmaping-in their mipmaps neighbouring layers are also mixed.And the sampling time from 3D-textures takes more time than usual. One of their advantages is possibility of sampling "between" layers,but if you will try to interpolate 1st and 3rd layers for example,you can't skip 2nd. And so on.

Share this post


Link to post
Share on other sites
I'm thinking something small (like 643) will be entirely sufficient for my purposes. That amount of data should be about as much as a single 5122 texture.

I think the point about using it for extra color channels is awesome.

Likewise, PolyVox, that link is great! Something like that is perfect--but I need something to work from; that paper is pretty impassible...

-G

Share this post


Link to post
Share on other sites
I should have pointed out that he does have some example textures for download here: http://johanneskopf.de/publications/solid/textures/index.html

However, you will need to decode the file format (doubt if it's complex). But after some examination I noticed that the textures lack high frequency detail - that is, they look blurred compared to the 2D examples. Guess the algorithm needs more work but it's still pretty impressive.

Share this post


Link to post
Share on other sites
I thought those were 2D textures, so I missed them...

Alright, so decoding the file system. They give this spec on the matter. I'm trying to translate this to Python. Any clues--or would this be better in the Scripting Languages forum...? (I'm working with "corral.vol" which I presume is a misspelling of "coral"...)

So far, I've got:
file = open("coral.vol", "r")
header = file.read(4096)
The header data is apparently turned into a struct (class) VolumeHeader. The rest of the file is then read. Should be simple enough to convert--if I were more familiar with C languages...

-G

[Edited by - Geometrian on June 20, 2009 6:30:37 PM]

Share this post


Link to post
Share on other sites
I'm not familiar with Python, but I agree it should be simple to convert. It looks like a pretty basic format - no compression etc. But yes, a Python forum might be able to help more...

Share this post


Link to post
Share on other sites
Translation thread here:
http://www.gamedev.net/community/forums/topic.asp?topic_id=538657

Getting back to the main topic, is there some standard for storing volumetric textures? As I understand it, they're mostly procedural, but not every 3D texture I've seen is that way.

It would be cool to make sense of that article sometime :D

Share this post


Link to post
Share on other sites
Quote:
Original post by Geometrian
Getting back to the main topic, is there some standard for storing volumetric textures?


The most widely used format for volume data is DICOM, but this is heavily oriented towards storing medical data. It's not partcularly suitable for games.

Microsofts DDS texture format has support for volume textures, as described here. They also have some more general information here. This is probably the easiest approach.

For a more 'open source' solution, I've wondered whether the .mng file format could be used to hold volume data. It's essentially a series of .png images, designed for animation but I don't see why it couldn't be a series of slices in a volume. Read more here.

Quote:
Original post by GeometrianAs I understand it, they're mostly procedural, but not every 3D texture I've seen is that way.


The way in which textures (both 2D and 3D) are created is usually independant of the way in which they are stored. So you could create the texture procedurally, and then save it using one of the formats above.

Share this post


Link to post
Share on other sites
DICOM sounds interesting, especially as there must be a lot of textures for it (Wikipedia, for instance, seems to make exclusive use of medical volume textures to explain the concept). However, it looks like an overkill for procedure...

DDS might work--I found this describing how to load it. Especially if other applications use DDS, it would be good to have code to use it. On the other hand, at the link at least, 3D textures don't seem to be supported...

I have used MNG with Jasc Animation Shop (Version 2.02, mind you, quite old) and I can easily see how that idea would work. I think it best if it were done automatically, however.

I think the best approach for my code for maximum compatibility is to be able to load as many types as possible--in this case, starting with .dds, .vol, and .mng in that order.

Then, someone needs to make a REALLY AWESOME 3D texture creator and create a standard...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this