Important: Changes to Xith3Ds texture loading functionality and API

divzero · June 3, 2005, 2:17am

Matthias Mann has been hard at working improving the texture loading abilities of Xith3D in several ways.

He has created an alternative texture loader named TextureLoader2. The TextureLoader2 is a better documented, faster and cleaner way of loading textures. He has also fixed some bugs and added support for compressed textures. If the TextureLoader2 class is well recieved, the old TextureLoader class will be deprecated and support fased out. The changes are well documented in both the code, and javadoc and have been made for both supported renderers of Xith3D (JOGL and LWJGL), and I thank Matthais for doing this.

He submited the changes as Issue 92

In fixing the bugs and cleaning up the code, several API changes were necessary which is why I have not yet committed the changes in.

Please download and test out (with your code), this experimental build:
http://xith.org/download/builds/2005-06-01_experimental-textureloader2/Xith3D_2005-06-01_experimental-textureloader2.tar.gz
I have also uploaded the TexutreLoader2 Javadoc

There is a new test case: Xith3DBumpMappingTest which shows off some of the new functionality.

Matthais will be checking this thread regularly to answer any of your questions.

In two weeks from now, on the 17th of June, 2005, unless there are any vetos to the changes in this forum, I will commit this patch to the core, so please test it prior to that day.

Thanks Matthais for your valuable contribution to Xith3D!

Cheers,

Will.

arne · June 3, 2005, 10:50am

Hi

I tested, if the old loader works still - It does.
I tested also a mixture of the old and the new loader, because the new loader hasn’t got functionalities like getting a BufferedImage from a Image-file (ofcourse, I could have used ImageIO). - This works also.
I tested also the examples. They are all very nice!! But I think the Bumpmapping doesn’t work. Here it is:

http://www.wi-bw.tfh-wildau.de/~_amueller/screenshots/bumpmapping.jpg

Conclusion: The new loader works super ;D - Well done!!, but we should keep the old loader - they don’t seem to interfere.

Arne

arne · June 3, 2005, 11:16am

Uhh-ohhh - One important thing I forgot to mention - the texture’s orientation is not the same as in the old Textureloader. (It’s rotated or mirrored, not sure what exactly) So it would become a nasty business, when we all had to change our texture coordinates.

Arne

divzero · June 3, 2005, 1:40pm

Hi Arne,

Thanks for testing it.

What setup are you running there? Bumpmapping works for me (I think, to be honest I don’t know what I am looking for, it certainly looks better than your Screeen Shot) on my Apple PowerBook G4, but not on my PC which has a fairly dated GeForce2 MX 400 card (in the latter case, it just dies and displays nothing). I have attached (love the new forums!) my screen shot.

You’re right, the new and old loaders should in theory be usable together as they both return the same objects. I am not proposing we remove the old Loader any time soon, if ever, but assuming the new loader is well recieved we may recommend people don’t use the old one.

Regarding the mirrored textures, I am not noticing this. I ran my game on it, and everything looked OK (granted, I’m not doing any fancy textureing, but I certainly do load a lot of textures). The com.xith3d.test.tcm.CubicEnvironmentMap demo also looked fine.

I agree, it is unacceptable to ask people to change texture coordinates! Be assured we would not let this happen. Can you post any more info on this problem?

Cheers,

Will.

matthiasmann · June 3, 2005, 4:55pm

Hello,

I want to point out the basic way to use TextureLoader2.

First you get the TextureLoader2 instance:
TextureLoader2 tl = TextureLoader2.getInstance();

Then you need to register aleast one locator. A locator is responible to resolve the texture name to either an InputStream (a TextureStreamLocator) or directly to a Texture (a TextureLocator). Mostly you want to use a TextureStreamLocator.
We will add 2 locators one for our current java resources (JAR files etc…) and the current directory:
tl.addTextureStreamLocator(new TextureStreamLocatorURL(getClass().getResource(".")));
tl.addTextureStreamLocator(new TextureStreamLocatorFile(new File(".")));

Then we can register additional decoders (called TextureStreamLoader), they parse the content of a file and produces textures. Included is a TextureStreamLoader that can load compressed DDS files (which are now directly supported by Xith3d !):
tl.addTextureStreamLoader(new TextureStreamLoaderDDS());

After all that (hard) work we can finally load a texture. We will load the file “lena.dds” as an RGB file (without alpha) and we want mipmaps (note: DDS needs to contain mipmaps - automatic generation not supported(
tl.getTexture(“lena.dds”, TextureLoader2.RGB, true)

We can also load a bmp file. Here mipmap generation is supported but for a normalmap (bumpmapping) it’s not good to generate mipmaps because the texture stores normal vectors and not colors.
tl.getTexture(“normalmap.bmp”, TextureLoader2.RGB, false)

A additional note: If a texture was not found a black/white check-board with 2x2 pixels is returned.

PS: The bumpmapping demo requires vertex and pixel shaders. It works on a GeForce FX 5700 (tested) or a Radeon 8500 (untested). Don’t try it with a Radeon 7500 or Geforce 3 !

That’s it. - happy coding.

arne · June 3, 2005, 6:51pm

For the Bumpmapping:
I’ve got a Radeon 9000 Series.
I used the BumpmappingTest from your demo directory, so there shouldn’t be any coding errors.

About the textures:
I made two screenshots one with the old-loader and one with the new loader.

using TextureLoader

http://www.wi-bw.tfh-wildau.de/~_amueller/screenshots/textureOld.jpg

using TextureLoader2

http://www.wi-bw.tfh-wildau.de/~_amueller/screenshots/textureNew.jpg

I simply changed these lines


Texture tiles = texloader.loadTexture(tilePath,"RGB",true,Texture.BASE_LEVEL,Texture.BASE_LEVEL_LINEAR,Texture.WRAP);
Texture alphamap = texloader.getMinMapAlphaTexture(alphaPath);

to


Texture tiles = texloader2.getTexture(tilePath,true);
Texture alphamap = texloader2.getTexture(alphaPath,true);

I don’t post the TextureLoader creations here, because I create both Loaders in both cases, so nothing chenges there. It’s really only those two lines!!

In the Xith3DColorComponentTest there is a similiar result, but I don’t know if it is just coded badly there. (The red squares are not there, where the Texture is blending into red)

Arne

matthiasmann · June 3, 2005, 9:42pm

Hi Arne,

Maybe it helps if you mirror all textures verticaly. For this you need to change the last boolean argument from ‘false’ to ‘true’ in line 384 of TextureLoader2.java

    byte[] data = new byte[lineSize * height];
    
    pp.createFromBufferedImage(
            data, 0, lineSize,
            img, 0, 0, width, height, false);   <===== make false to true !
    
    Texture2D tex = new Texture2D(

This will then mirror the texture on the y-axis. If this helps I will add it as an additional parameter to the various getTexture(…) functions.

About the bump-mapping:
Do you use the newest ATI driver ? I discovered that their drivers for new cards are not very good.
Did it print any errors or warnings while starting / running ?
Can you tell me the exact type of your ATI card ?

Ciao Matthias Mann

arne · June 4, 2005, 10:21am

Yes, mirroring the texture vertically did the job, so you should add a flag to the loader for that. (this option would be really good to have, because I had to mirror the textures before to let them show correctly with the old loader -so you can say I’m mirroring them twice now )

I installed a new driver, but nothing changed.
The exact type of the card is: SAPPHIRE RADEON 9000 ATLANTIS PRO (Windows doesn’t show it, when you’re only logged in as a user)

Here’s my output:
`
Available 0: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ] MS: false 2 Score: 1312

Available 1: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 1376

Available 2: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ] MS: false 2 Score: 312

Available 3: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 376

Available 4: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false, DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ] MS: false 2 Score: 1120

Available 5: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false, DepthBits: 16, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ] MS: false 2 Score: 1120

Available 6: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: false, DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ] MS: false 2 Score: 120

Available 7: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: false, DepthBits: 16, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 0 ] MS: false 2 Score: 120

Available 8: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false, DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 1424

Available 9: GLCapabilities [DoubleBuffered: false, Stereo: false, HardwareAccelerated: false, DepthBits: 16, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 1424

Available 10: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: false, DepthBits: 32, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 424

Available 11: GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: false, DepthBits: 16, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha:8, Red Accum: 16, Green Accum: 16, Blue Accum: 16, Alpha Accum: 16 ] MS: false 2 Score: 424
Chosen index: 2
Chosen capabilities:
GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true,DepthBits: 24, StencilBits: 8, Red: 8, Green: 8, Blue: 8, Alpha: 8, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ] MS: false 2
Init GL is net.java.games.jogl.impl.windows.WindowsGLImpl
OpenGL Renderer = RADEON 9000 DDR x86/MMX/3DNow!/SSE
OpenGL Version = 1.3.1006 WinXP Release
OpenGL Vendor = ATI Technologies Inc.
OpenGL Extensions = GL_ARB_multitexture GL_EXT_texture_env_add GL_EXT_compiled_vertex_array GL_S3_s3tc GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_ATI_element_array GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_map_object_buffer GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_attrib_array_object GL_ATI_vertex_streams GL_ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output_point_size GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays L_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_EXT_vertex_shader GL_HP_occlusion_test GL_NV_blend_square GL_NV_occlusion_query GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_extensions_string WGL_EXT_swap_control
No Fragment Program support, skipping
`

Arne

matthiasmann · June 4, 2005, 7:11pm

Hello,

you driver has support for GL_ARB_fragment_shader but not for GL_ARB_fragment_program (which is used by Xith3D) - so you need to get a better card like a Radeon 9600+ or a Geforce FX 5200+

You can check that with the OpenGL Extension Viewer from http://www.realtech-vr.com/glview

Ok, I will submit a patch that adds the mirroring as an option.

Ciao Matthias Mann

arne · June 5, 2005, 1:35pm

Hmmm too bad - but couldn’t we do something, so that the guys with bad Graphics cards simply don’t show the bumpmapping, so the textures look ok. We would then have to print a message, that the bumpmapping was ignored.
Is this possible?

What is this fragment program doing anyways? (sorry if i’m polluting this thread, but could you use the internal messaging service, or you icq, to answer me (if you want), so this thread doesn’t get that much polluted)

Arne

croft · June 7, 2005, 7:09pm

I’m getting the following exception using the experimental JAR xith3d.jar from the tar file:

java.lang.ClassFormatError: Illegal field name "
" in class com/xith3d/scenegraph/Node
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)

Is anybody else getting this problem? If not, I’ll check to see if I need to update my other JARs or compile from the source.

divzero · June 8, 2005, 12:04am

That’s pretty strange ???

The source is included, can you try compiling it yourself (just ‘ant’)? You’ll need to copy in a “third-party” directory from another Xith3D installation, or downloaded here: http://xith.org/download/third-party.tar.gz

Will.

divzero · June 13, 2005, 3:19am

5 days to go before integration. Please check this experimental build out.

So far there are no vetos and the code will be added as planned.

Will.

croft · June 13, 2005, 9:17pm

OK, I compiled using the experimental source instead of the experimental JAR and it did not crash. TextureLoader2 is working OK. One of my texture coordinates is flipped but I think that is a problem with my code and not TextureLoader2.

divzero · June 14, 2005, 6:44am

That’s the second report on flipped texture’s we’ve had.

Matthias,

Should the default setting be flipped? Are there any disadvantages of htis?

Will.

croft · June 14, 2005, 6:09pm

In TextureLoader, it would happen when I would pass in a BufferedImage, but not when I would load from a resource JAR. I dug around in the code trying to figure it out. My guess is that it has something to do with textures being stored upside down in graphics memory but that is just a hunch. Maybe something similar is going on in TextureLoader2?

It could be that the COLLADA exporter I used flipped the texture coordinates. Not sure. I’ll dig into it.

croft · June 14, 2005, 9:26pm

I dug into it. I created a test case of a simple square polygon with a 512x512 texture. The T coordinate is flipped when you use code that looks something like this:
`
textureLoader2.addTextureStreamLocator ( new TextureStreamLocatorURL ( baseURL ) );

texture = textureLoader2.getTexture ( imageName, false );
`
I’m using TextureStreamLocatorURL because I am pulling the texture image file off of the Web. I would not be surprised if it is not flipped when loading from a File but is flipped when loading from BufferedImage or URL. I haven’t tested this theory, though.

matthiasmann · June 14, 2005, 11:31pm

Hello,

It’s not a problem to flip the image by default. I suggest to change the line that I pointed out in an erlier post for the cvs checkin.

After the changes have been checked in I will submit a new RFE with adds the option to choose if the image should be fliped (default) or not.

Cioa Matthias Mann

croft · June 15, 2005, 6:11pm

I’m not sure I understand. Should the image be flipped by default? If so, is this because textures are traditionally flipped by default?

matthiasmann · June 15, 2005, 7:03pm

Hello,

it has to do with how OpenGL handles textures: In OpenGL the coordinate (0,0) is the lower left, while in an (standard) image file it’s the top left.

In the message http://192.18.37.44/forums/index.php?topic=9771.msg77922#msg77922 I descriped what must be changed to flip BufferedImage based textures.

Ciao Matthias Mann