Xith3D compressed texture support

Engines, Libraries and Tools Xith3D Forums
#1

I’ve added support for DXT1, DXT3 and DXT5 compressed texture support based on Xith3D_2005-02-08_cvs. Currently only for the JOGL renderer (LWJGL still works but doesn’t support these formats).

For this I’ve made some changes in ImageComponent (new FORMAT_xxx flags) and many changes in TextureShaderPeer for JOGL (changed half of defineTexture() to make it easier to maintain).

I also think that TextureLoader needs a major overhaul. Java doesn’t like custom BufferedImage formats. I get “Unable to transform image” on some file formats. The best way would be to move from BufferedImage to byte[]. This will need a bit of code to handle the common formats (R8G8B8, R8G8B8A8, R5G6B5, …) and a generic code path that handles the other formats.

We still need entrypoints for BufferedImage but we should not base our internal processing (atleast for static textures) on it. With this I mean MipMap generation. My idea: Convert the BufferedImage to a BufferedImage with a 2^x size and a processable internal format (only when needed), then do simple box scaling for mip maps.

Also ImageComponentXX should only hold references to the passed byte[] or BufferedImage for dynamic textures.

TextureLoader should be changed so that one can add his own image loaders (e.g. DDS importer) or file sources (e.g. URL handling or custom archive files). It also should not quit the application when a texture could not be found (may be replace it with a hardcoded “404” image ?)

How is currently maintaining the texture handling stuff ?

Ciao Matthias Mann

#2

that all sounds great Matthias- roll it all in mate :slight_smile:

#3

I know how to post patches and bugs - should I post it there ?

I think someone needs to check my changes to the texture code before it is checked in. I have run all tests and they still work, but they don’t use all code paths.

#4

This all sounds really good.

I am worried about massive changed being made to the current TextureLoader as it is pretty hard to test all the different code paths as there are so many.

How about you start with a clean slate, perhaps call it “TextureLoader2”. That way there’s no legacy crap you need to worry about. Once it is up and running, we can provide migration advise and deprecate the entire old TextureLoader class. This gives you far more freedom to do what you like and beta testers can then try out your class with their code at their lesure. What do you think?

If you did go this way, we should open a discussion to find out what other people didn’t like / did like about the current TextureLoader.

Please post your patches to Xith3D though IssueZilla. If you want to provide testing builds and need somewhere to upload them, email me.

Thank you :),

Will.

#5

I’ve filled a issue to track the compressed texture support part: https://xith3d.dev.java.net/issues/show_bug.cgi?id=92

I’ve not yet started with the TextureLoader stuff. The main goal that I have for TextureLoader2 are:
[]Does not depend on BufferedImage to do mip mapping
[]A TextureLocator interface that is responsible to get an Texture for an given texture name. This allows complete loading done by the application.
[]A TextureStreamLocator interface that is responsible to get an InputStream for a given texture name.
[]A TextureStreamLoader interface that is responsible to create a complete texture from an InputStream.
[]An ImageLoader interface that is responsible to create a single ImageComponent from an InputStream.
[]The above interfaces are tried in the order as listed.
[]If an InputStream was found, but could not be read from the above interfaces then ImageIO is tried.
[]An error handling mode that defines if null, an build in error texture (“404”) or an exception should be returned when the texture name could not be resolved / loaded.

#6

Hi All,

Finally I got some time again to work on Xith3D.

I will review the changes to check if everything is OK.

I have already played with compressed textures, and in my case I changed only few lines to make it working - I did not use external texture compression (if you specify compressed format, OpenGL driver compresses the texture for you). Massive changes only needed when textures have to be stored in compressed format also in main memory…

Yuri

#7

According to many papers (also some from NVidia) compressing textures while loading is very slow. Also there are many tools that can create DDS files (from NVidia, DirectX Texture Tool). One can even create a small program that uses OGL to compress the textures and stores them as DDS file.

While DDS is a M$ file format it is heavly used in PC games and reading it is very simple (a fixed size header directly followed by the compressed texture mipmaps). A standard java application has only 64MB (in the default settings of the JVM) memory, so loading compressed and mip-mapped textures saves a lot of processing time (for mip-mapping) and a lot of memory - about 170kb compared to 1M.

Maybe I’ll include my very simple DDS loader with the new TextureLoader2 (this would be a TextureStreamLoader).

#8

It’s not an amazing article, but re: TL2, could you read this month’s Game Developer, which has an article on writing texture locaters and loaders to be more intelligent, and roll in any good ideas from there? It’s a C-perspective, but 90% applicable to java.

Personally, I wasn’t impressed by the article. Seemed pretty mundane ideas that anyoen could come up with. However, its’ about 3-4 pages IIRC and quite convenient as a reference point to read descriptions of approaches as a starting point. Also goes into some of the pros and cons. I suspect there’s nothing that hasn’t been mentioned at one time or another for X3D, but why not check? :slight_smile:

PS: may not be this month’s GD…I’ve left my copy in someone’s house, so can’t check, but I think this was in the issue that came out for free at GDC. If not, it’s probably the previous month’s issue (I read them both at the same time during GDC).

#9

I don’t have access to gamasutra or the GD magazine. I also didn’t find the article on their homepage.

Can you post a link to the article somewhere ?

#10

Hello,

I’ve started with the implementation of TextureLoader2. For this I’ve created a set of classes that does low-level pixel processing (currently only mip-mapping and BufferedImage conversation). The ImageComponentXX will also need these classes because you can specify BufferedImage for byReference ImageComponents.

These classes are currently called PixelProcessorXXXX where XXXX is the pixel format (e.g. R8G8B8A8)

Should I add these to com.xith3d.utility.image ? Or should I add a new package (like com.xith3d.utility.pixelpipe) ?

I’ve changed the ImageComponent partially immutable (format, width, height, byRef, yUp) this will simplify the new implementation of update(). The new process of update() will be Image->byte[]->ByteBuffer->OGL. So the fastest dynamic textures will be updates to byte[] because a DirectByteBuffer has a native call for each put() call.

Maybe we can find a way to also remove the java copy of static images (these not byReference) ? I’ve already removed the byte[] and BufferedImage copies if byRef is false. This will cause getByteData() and getImage() throw an IllegalStateException.

Ciao Matthias Mann

#11

I’ve only read it in the paper mag. You’ll either have to find a newsagent and see if the copy they’ve got has it in or wait a month and see if it appears on GS.com