akb825 Wrote:What's wrong with mipmapping? I though TomorrowPusX was able to get it working.

Me too, actually. He didn't use gluBuild3DMipmaps though, I bet. (I'm a wee bit lazy. )

I fixed my problem with the lines. This is actually a useful bit of info for you guys (incase you didn't already know).


Is the solution.

You probably could build your own, scaling down the width and height and not depth. I will probably try that whenever I get the chance, since I really don't want to handle interpolating between 6-8 textures. (all I have to do, though, is find an algorithm to downscale an image... )

Edit: never mind, you can't do that. You must reduce the r as well. So, TomorrowPlusX, how did you do it? Meanwhile, I'll look up solutions to get massive multitexture interpolation implemented...

Editx2: messing around with the LOD bias might prove useful, too

Jones Wrote:And it would seem that multitexturing is an extension, whereas 3D textures have been in the core since 1.3 (or was it .4? ).

Whether it's an extension or not is completely irrelevant. What matters is hardware support. Multitexturing is supported by everything Mac OS X supports; 3D textures are not.

In any case, everything we've discussed was once an extension --
ARB_multitexture and ARB_texture_env_combine, promoted to core in 1.3
EXT_texture_3D, promoted to core in 1.2
ARB_shading_language_100 & friends, promoted to core in 2.0

akb825 Wrote:You probably could build your own, scaling down the width and height and not depth.

No, you can't. All dimensions are halved at each mipmap level, no matter what you want. That is what the spec says. Go read the other thread.

Read my edit, I corrected myself.

Yes, I remember TommorowPlusX's thread on the subject.

Well my code works sorta. With 3 textures it throws a 1280 and a 1281 (gl errors) which are the equivalents of GL_INVALID_ENUM and GL_INVALID_VALUE, respectively.

I'm trying to track them down but it's tough, when I call glGetError at various places sometimes I get 0's where they weren't before. Does calling glGetError automatically clear the error value?

Yes, GetError pops one error bit. There can be multiple bits set simultaneously though.

I suggest declaring a static (or global) variable so that you only cal glGetError once in your drawing function. (aka: only cal glGetError if it's TRUE, and have it originally FALSE and set it to TRUE when you call glGetError) Then, move the call around until you get the exact place (or places) where the error occurs.

... or you could just use the OpenGL profiler's "break on error" to go to exactly the call that generated the error, rather than using a tedious, time-consuming and error-prone process like that...

Well, I tracked that error down, but now I've got more.

It seems that whenever I enable GL_TEXTURE_3D, standard 2D textures stop working. I can't bind them, load data into them or draw them.

Hmm, unpleasant surprise. I'm gonna have to write some methods in that dynamically switch between 2D and 3D so I can use both.

Annoying.

EDIT: I've just had a thought. That's not possible, I think. Because I was just loading 2D textures and then making 3D textures... or was I? *runs off to test*

Were you sure to call glDisable(GL_TEXTURE_3D) after being finished with 3D textures, and call glDisable(GL_TEXTURE_2D) after being finished with 2D textures? (aka: do you ever have more than one enabled at once?) You should only have 1 texture type enabled for each texture unit enabled at 1 time.

OSC: Thanks for the info on OpenGL profiler, I didn't know that. (of course, almost all of my debugging is done through print statements coupled with stack backtraces... )

For textures, there is a precedence order for which one "wins" if you have multiple kinds glEnable'd at the same time. TEXTURE_3D is quite high on that hierarchy.

You shouldn't ever care though -- only enable one texture target at once!

[edit]Beaten by akb825![/edit]

It sort of works now, but for some reason adding more textures screws up the GL_TEXTURE_2D/3D thing. I guess I'll just keep changing targets. So it might look like this:

You don't need to call glEnable with a texture type when you're loading, only drawing.

akb825 Wrote:You don't need to call glEnable with a texture type when you're loading, only drawing.

Ah, even better. Thanks for the tip.