Jones Wrote:No, I am using 3D texturing. This means I am stacking the two images and choosing which depth value to use when drawing. In the end it means you can do something like this:

You should _really_ be doing this via multitexturing, and not with 3D textures. Performance is likely to be significantly better, it'll expand to further effects easier, and you won't run into mipmapping issues.

Furthermore, multitexturing is has much wider hardware support than 3D texturing.

Frogblast Wrote:You should _really_ be doing this via multitexturing, and not with 3D textures. Performance is likely to be significantly better, it'll expand to further effects easier, and you won't run into mipmapping issues.

Furthermore, multitexturing is has much wider hardware support than 3D texturing.

Multi-texturing, you say? Hmm. I'll look into it. I've never really done any of it before, but it sounds like it'll be fun to learn. I'll sift through some of the references at NeHe.

Multitexturing in this case is only really easy to do with 2 textures, and you can only reliably get up to 3 or 4 if you're creative. (4 max, though, unless you don't want to support any NVidia cards. ) However, with terrain, you can use 3D textures for almost any number of layers. If you have 8 different terrain layers, for instance, it would be impossible to do with multitexturing on anything but on the Radeon 9600 or later. (and no NVidia cards) However, it would be a simple matter with 3D textures. I can't say anything on performance, though, especially since there doesn't seem to be much information in general on the internet about 3D textures.

No success yet, my Construct3DTexture builds texture units that I can't even get to work on simple 4-vertex quads, let alone my massive terrain.

I'm gonna post the source code here. I hate doing this because it makes me feel like I'm giving up and asking you guys to solve my problems for me (), but I'm stumped. Perhaps you can spot something.

I'll try to help here by explaining how stuff works. Each 'TEXTURE' item has OpenGL compatible values that could be used at any time to re-bind the texture to another GL unit. The pixels item is a pointer to the array of data. (Which *is* kept around inside the 'TEXTURE'.

The arguments of the function are fairly self-explanatory. Depth is number of textures being passed in. '*target' is the destined GLuint. (For the texture.)

The TEX_RESULT_COMP3D struct has only two items. 'tex_used_count' which is the number of textures that were successfully bound. 'tex_used' is an array of fixed size (128 ints). It works like this:

Joe-Bloe passes in three textures. The middle one is bad, so the struct contents would be sorta like this:

tex_used_count = 2
tex_used = {1, 0, 1, 0, 0, 0, 0, 0, ... etc }

A one indicates that the texture item <place of n> *was* used. I know, they could be shorts or chars to save memory but I stuck with ints, and frankly, it's no important right now.

If you are reading this code and you get to the part where there is an if loop that checks to branch *with* mipmapping or *without* you can ignore the option that confirms mipmapping. It is not being used to test right now. (If you *do* spot something wrong with it though, please, speak out.)

RAYNE_ITL_TEX_FILTER_GL_TRANS is quite simply an array to convert Rayne (which is what I nicknamed the engine) texture filter values to OpenGL ones. I hope the rest is reasonably clear, I commented a lot, but I know some of my comments are less than useful.

I also know the code is not very efficient, but I'll fix that once the rest is actually working. Thanks for any insight you can offer.

// At this point we have a list of all the textures which can be combined to form the stack.
// Let's alloc some memory.
tex_dat = (GLubyte*)new GLubyte[numberToUse * t1_width * t1_height * t1_components];

// These are variable.
// The second is not, because it has a limit of detail.
glTexParameterf(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, RAYNE_ITL_TEX_FILTER_GL_TRANS[t_filt]);
glTexParameterf(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, RAYNE_ITL_TEX_FILTER_GL_TRANS[1]);

EDIT: (Thought I'd add...) The 3D texture looks fine in the profiler, but the app can't use it. I remember TommorowPlusX having some trouble with the profiler showing something working when it wasn't. If I remember correctly it had to do with 3D texturing too. Is something like happening now?

OneSadCookie Wrote:Kinda misleading -- NVidia only exposes four texture units through the fixed-function pipeline, but they support many more via shaders.

That is true, but if you were looking for compatibility, you wouldn't want to rely on pixel shaders.

BTW, according to the man page of glTexImage3D, it's available since OpenGL 1.2. Multitexturing was introduced as an extension in as early as 1.1, but then rolled into the core in 1.3.

Edit: oh, and before you consider bump mapping, you're going to have to learn about shaders. (it's not just some magical setting you can turn on) As to your current problem, what does it look like when it breaks?

akb825 Wrote:Edit: oh, and before you consider bump mapping, you're going to have to learn about shaders. (it's not just some magical setting you can turn on) As to your current problem, what does it look like when it breaks?

I know about the difficulties of bump-mapping. Over at NeHe they use something like 6 different texture units to accomplish it. Can't wait!