glCompressedTexImage2D

[system]

Hi,

I’m trying to load pre-compressed textures from disk using the GL_COMPRESSED_RGBA_S3TC_DXT3_EXT format for the texture. Building a PEF executable (linking against the OpenGLLibrary lib), my code works fine, however the identical code, when linked against the equivalent Mach-o framework (AGL) doesn’t work, it just produces a white rectangle when I draw the texture (no other compressed formats work either as far as I can see).

Everything else works fine (all other functions, including extensions, produce the expected results). Is there a bug in the Mach-o implementation of this function? If so, is there any other way I can link to this function in Mach-o, since presumably some people manage to use it ok, without being forced to build PEF apps.

[arekkusu]

glCompressedTexImage2DARB(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA_S3TC_DXT5_EXT, width, height, 0, size, pixels);

works for me in a Mach-O executable built under Xcode 1.5, using NSGL. AGL should be the same, though.

Does glGetError() indicate any reason why the texture upload failed?

[arekkusu]

See also this thread .

[system]

Thanks for the suggestions, but I’m not getting any error from glGetError.

I know the image format is ok because it works in PEF builds. It just seems as if the glCompressedTexImage2D function doesn’t do anything in Mach-o.

The problem may be unrelated to the function itself though. I’ve tried dynamically loading the function at runtime from both PEF and Mach-o builds, including loading the Mach-o framework from within the PEF build, using appropriate glue code, and loading the PEF version of the library from the Mach-o build. Regardless of what I do, the PEF build works, and the Mach-o build produces a white square - the same effect as if I don’t call the function at all.

[OneSadCookie]

random question – you setting TEXTURE_MIN_FILTER appropriately?

[system]

Holy crap, you’re a genius!

I think MIN_FILTER must default to GL_LINEAR on PEF and not on Mach-o. I’ve set it explicitly and it now works perfectly.

Thanks you

[OneSadCookie]

Versions of Mac OS below 10.3.0, including 8.6 and 9, incorrectly treat the default min filter as “NEAREST_MIPMAP_LINEAR if mipmaps are specified, LINEAR if they aren’t”. Mac OS X 10.3 fixed this bug, but I guess they put a special case in to let old CFM apps continue working.

[imported_execom_rt]

First, you should use

glGetTexLevelParamteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_COMPRESSED_ARB, &compressed);

In order to check that the texture has been compressed.

Also you should use the Generic Compressed Internal Types GL_COMPRESSED_RGB_ARB or GL_COMPRESSED_RGB_ARB, - Although it seems to not works correctly on my Powerbook -

Finally, GL_COMPRESSED_RGB_S3TC_DXT5_EXT should be used only if GL_ext_compression_s3tc exposed, although this extension is NOT defined on my machine, but seems to works as well … Go figure …

And also,

Doing

GLint dwNumCompressedTextureFormats;
glGetIntegerv( GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB, &dwNumCompressedTextureFormats);
pCompressedTexFmt = new GLint[dwNumCompressedTextureFormats];
glGetIntegerv( GL_COMPRESSED_TEXTURE_FORMATS_ARB, pCompressedTexFmt);

Returns a very strange list of supported compression type. I guess the GL_ARB_compression_texture is very badly implemented here.

Try to follow this document : http://developer.nvidia.com/attach/6585

[arekkusu]

execom, what hardware are you describing? EXT_texture_compression_s3tc is exported on all hardware renderers except for the Rage128.

[imported_execom_rt]

Yes, sorry, the GL_EXT_texture_compression_s3tc is supported in fact.

The hardware used is a Powerbook G4 ‘NVIDIA GeForce4 MX OpenGL Engine’

Extensions supported are
GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_fragment_shader GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 GL_ARB_texture_env_combine GL_ARB_texture_compression GL_ARB_texture_mirrored_repeat GL_ARB_vertex_buffer_object GL_EXT_compiled_vertex_array GL_EXT_texture_rectangle GL_EXT_texture_env_add GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color GL_EXT_secondary_color GL_EXT_texture_compression_s3tc GL_APPLE_ycbcr_422 GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_pixel_buffer GL_NV_register_combiners GL_NV_blend_square GL_NV_fog_distance GL_NV_multisample_filter_hint GL_ATI_texture_env_combine3 GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

Here the values of the ‘texture formats’
83f3
533bac
bffffb10

The two last are just plain wrong.

I was expecting:

83f0
83f2
83f3

I think it’s a bug in the glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS_ARB, …) function.

[imported_execom_rt]

Your web page with extensions on MacOS X is quite interesting - I’ve done a similar tool for extracting extensions - I’ve done a OSX version, but an updated version should come soon. I have also a Cocoa version, with the same user interface, but lacking some time to finish it, but if someone is interested …)

Could be fine if you can test the glGetIntegerv with the list of supported texture format, just to be sure that it works.

[arekkusu]

I think that OSC has sufficiently answered the original question, so the rest of this is going off-topic.

However, you are correct! I get similar results on Radeon9600: 83f3, 90001054, 0. This is definitely wrong, I’ve logged #3806869 about it.

This doesn’t prevent you from using compressed textures though; since all of the current OS X renders that support compressed textures only support one specific compression extension (s3tc) and that extension defines DXT1, DXT3, DXT5. So if you’ve got the ARB_texture_compression extension, those are the only formats you can use. Of course, this might change in the future…

[arekkusu]

In 10.3.6, I now get correct values on my Radeon 9600:
83f0
83f2
83f3

However, the bug is still open, so maybe not all renderers are fixed?

[imported_execom_rt]

Yes I noticed that, this was fixed as well on my Geforce4MX.

There is still some others bugs in 10.3.6, but things gets better.

A bit off topic, but remaining bugs I’ve noticed in 10.3.6:

• Still some issues with ARB_vertex_program:

  1. Rendering random coordinates polygons under some circumstances - very scary and annoying. Easily reproducible and no workaround I could find.

  2. having several problems with fog + ARB_vertex_program, Especially if you have multiple object sharing the same vertex program, the other objects are rendered ‘white’, like the front color what initialized with the fog coordinate only. Else the fog + vertex program seems to work fine.

  3. if you have a vertex program that computes texture coordinates (like env mapping or other), you HAVE to write 1.0 into the .w texture component - This is not required in an hardware implementation, however It can be workarounded.

• Some problems when handling ‘nested’ pbuffers. like:
  PBuffer1: rendering a scene into it
  PBuffer2: rendering a quad with the texture from PBuffer1
  Rendering a quad with texture from PBuffer2 on screen. : It does nothing.

Hope it will be fixed in 10.3.7