Textures compression tool (BINARY RELEASED)

[hybrid]

The interface seems pretty simple, but the use of the rest of the methods is not easily possible with compressed images anymore. How would you implement the pixel access? Should this decompress the content, or should we return a compressed component of the image? What ybout scaling compressed images, and how do you integrate this into the drivers which don't support compressed images? Do you really want to put all compression and decompression implementations into one huge CImage implementation? No way, that is unmaintainable. So we need to clear up on all those exisitng methods first, before adding new methods to the API which might become non-implementable in the end. Look at what I've done with the append methods in the meshbuffers...

[REDDemon]

what about addin a IImageManipulator? this will be used for filling with colors, scaling, copying etc. (the mesh manipulator is already present).

Anyway for compressed textures there 's no need for a IImage counterpart. Just need to implement that in the IVideoDrivers methods wich just load textures:

Methods for loading from a KTX file

Code: Select all

 
                //! Get access to a named texture.
                /** Loads the texture from disk if it is not
                already loaded and generates mipmap levels if desired.
                Texture loading can be influenced using the
                setTextureCreationFlag() method. The texture can be in several
                imageformats, such as BMP, JPG, TGA, PCX, PNG, and PSD.
                It can load also KTX files.
                \param filename Filename of the texture to be loaded.
                \return Pointer to the texture, or 0 if the texture
                could not be loaded. This pointer should not be dropped. See
                IReferenceCounted::drop() for more information. */
                virtual ITexture* getTexture(const io::path& filename) = 0;
 
                //! Get access to a named texture.
                /** Loads the texture from disk if it is not
                already loaded and generates mipmap levels if desired.
                Texture loading can be influenced using the
                setTextureCreationFlag() method. The texture can be in several
                imageformats, such as BMP, JPG, TGA, PCX, PNG, and PSD.
                Also KTX textures can be loaded.
                \param file Pointer to an already opened file.
                \return Pointer to the texture, or 0 if the texture
                could not be loaded. This pointer should not be dropped. See
                IReferenceCounted::drop() for more information. */
                virtual ITexture* getTexture(io::IReadFile* file) =0;
 

I can also improve those methods

Code: Select all

 
                //! Creates an empty texture of specified size.
                /** \param size: Size of the texture.
                \param name A name for the texture. Later calls to
                getTexture() with this name will return this texture
                \param format Desired color format of the texture. Please note
                that the driver may choose to create the texture in another
                color format. If you specify a compressed internal format
                your texture can be used as compressed texture
                and edited as any other texture.
                \return Pointer to the newly created texture. This pointer
                should not be dropped. See IReferenceCounted::drop() for more
                information. */
                virtual ITexture* addTexture(const core::dimension2d<u32>& size,
                        const io::path& name, ECOLOR_FORMAT format = ECF_A8R8G8B8) = 0;
 
                //! Creates a software image from a part of a texture.
                /**
                \param texture Texture to copy to the new image in part.
                the texture can also be compressed. In that case you obtain uncompressed data.
                \param pos Position of rectangle to copy.
                \param size Extents of rectangle to copy.
                \return The created image.
                If you no longer need the image, you should call IImage::drop().
                See IReferenceCounted::drop() for more information. */
                virtual IImage* createImage(ITexture* texture,
                                const core::position2d<s32>& pos,
                                const core::dimension2d<u32>& size) =0;
 

that would need internally a CCompressedProxyTexture. It will be easy for me making that. The proxy texture just keep in RAM a copy of an ITexture in a uncompressed format (the color format of the image is directly implied by wich compression is choosen since DXT1 only accept R8G8B8 and DXT and DXT 5 only R8G8B8A8.
So if the user specify DXT1 compression it will gain control over a ITexture that the user can freely modify by calling "lock()" as aR8G8B8 texture. When the user calls "unlock" the new data is sent to GPU for compression.
Then putting that ITexture into a material layer will automatically use the last compressed data found in the GPU by default a black (or other noticeable color) texture is used if user did'nt specify anything with a lock call().
this way even when user try to lock a compressed image it is deconpressed and a Proxy texture is created. This is much less invasive API change and need just to add few new color formats (DXT). I already have Idea on how to implement that if you give me white paper and wich parts of Irrlicht needs to be edited (really just few methods + 2 extra classes used only internally)

maybe IImage can be added with few methods. but no IImage with Compressed formats can be created (so no need to change pre-existing methods).

Code: Select all

 
static bool isCompressedColorFormat() //just a superfluos detail
{
    swich(colorformat)
    {
    case DXT1: case DXT3: case DXT5: return true;
    }
    return false;
 
}
 

what about that? it seems nice to me.

Since i'm working with streaming for my terrain manager I can also add the chance to stream a texture by updating only parts of it and its mipmap levels (and not only with KTX textures if you like. Almost same difficulty for me. (but probably not really needed for now).

In conclusion:
1)KTX files support in the methods wich can returns a texture specifin only a source KTX file => internally a CKhronosTexture is created
2)Methods wich returns an empty texture => internally creates a CCompressedProxyImage already linked with a CKhronosTexture. Data is sent from Proxy to KhronosTexture
3)Users can require to lock a CKhronosTexture => in that case a CCompressedProxyImage is created. Data is de-compressed only once. After that the users have only to specify new data with (lock) and those data will be sended immediatly to GPU in compressed form when calling (unlock).

Issues. Still need a way to remove CCompressedProxyImage by detaching it from the CKhronosTexture (for savin RAM memory).. probably can be done just specifying the correct LOCK MODE. as parameter in lock method. Can't remove that automatically because in case 3) many de-compression/re-compression can reduce image quality.. Probably better to add a new LOCK MODE (FREE_RAM) wich only effect is to destroy the ProxyTexture. So that users can still use all other lock modes without warry about them.

If it seems ok to you I'll start implementing the CCompressedProxyTexture.

After I get all working I'll take a deeper look into GL extension handler to see If I can remove glew dependences easily. :*

[Nadro]

The interface seems pretty simple, but the use of the rest of the methods is not easily possible with compressed images anymore. How would you implement the pixel access? Should this decompress the content, or should we return a compressed component of the image? What ybout scaling compressed images, and how do you integrate this into the drivers which don't support compressed images? Do you really want to put all compression and decompression implementations into one huge CImage implementation? No way, that is unmaintainable. So we need to clear up on all those exisitng methods first, before adding new methods to the API which might become non-implementable in the end. Look at what I've done with the append methods in the meshbuffers...

bool IsCompressed; // if true, many CImage methods aren't active, we can manipulate only uncompressed images.

If we try get an access to a compressed image data, our methods eg. scaling, pixel access etc. should return false flag, empty - black pixel etc. User should first check value returned by isCompressed() method and operate on an image data only when value is true. Decompression will be not automatic, so we have to manually call this method to create uncompressed image from a compressed. What about a huge part of code in a CImage class required for a implementation a compress and decompress methods? Like REDDemon said we can create something like a IImageManipulator and move some CImage methods to it or we can use function callbacks for each compression type.

@CuteAlien
From what I know You're right about a patent.

[CuteAlien]

Compression/Decompression would be the patent-covered part anyway. Basically compressed textures should only be used for being passed on to the graphic-card and nothing else.

[Nadro]

Compression/Decompression would be the patent-covered part anyway. Basically compressed textures should only be used for being passed on to the graphic-card and nothing else.

I agree with You in 100%, thats why manipulation on compressed images will be not avaiable (I think that less than 1-5% users will be use compress/decompress methods, but in a free time we will be allowed to implement them).

[REDDemon]

What about a huge part of code in a CImage class required for a implementation a compress and decompress methods? Like REDDemon said we can create something like a IImageManipulator and move some CImage methods to it or we can use function callbacks for each compression type.

The image manipulator part was the less relevant ^^ but can be good Idea. It can be extended with a interface for add user's defined manipulation (exactly as scene nodes permitt to users to define new functionalities).

I thinked long about that:

And I don't think add Image compression to IImage is good idea. It makes users really confused.
First of all Image compression is driver specific that's mean writing driver/specific code in a class that should not depend in any way from drivers (just my opinion). writing those methods means that Irrlicht have to expose internal classes to other internal classes making hard to maintain on the long run (can be done but is hugly)

My solution was to use a ProxyTexture wich is used only from another texture. So no one know about the proxy texture except for the new texture class (wich is ready and working).

I think that's the ideal solution from a design point of view:

1) no API changes required (just 3/4 new enumerations.. and that's also not necessary)
2) great performance (use of Proxies means also that if something is not required is not used nor allocated saving time)
3) also simpler in internal implementation (few methods to be changed slightly) and only 2 extra classes wich have the same dependencies of already existing textures.
4) all other internal changes are just related to the CKhronosTexture and not to the ProxyTexture.
5) consistent with existing code/API. a DXT1 texture will be always threated by Irrlicht as a RGB image. a DXT5 texture as a RGBA image. Also all other internal classes of the engine can forget about texture compression.

[CuteAlien]

Compression/Decompression would be the patent-covered part anyway. Basically compressed textures should only be used for being passed on to the graphic-card and nothing else.

I agree with You in 100%, thats why manipulation on compressed images will be not avaiable (I think that less than 1-5% users will be use compress/decompress methods, but in a free time we will be allowed to implement them).

Oh, we have implemented decompression already. It's in the engine. Just defined out.

[REDDemon]

Oh, we have implemented decompression already. It's in the engine. Just defined out.

^^ I still can't see it in the latest trunk. where's the submit on sourceforge?

Now that I've implemented compressed textures would be nice to see your API changes so that I can send the correct patch to the SVN

have you used my solution of a proxytexture or just added to the API the hooks that I needed?

Just a bit curious about why now you added texture compression when users asked for that from long time ^^

Compression/Decompression would be the patent-covered part anyway. Basically compressed textures should only be used for being passed on to the graphic-card and nothing else.

I don't see the problem. Manipulation will be done on decompressed data anyway. after manipulation is done the video card's driver will do the rest^^

[CuteAlien]

Oh, we have implemented decompression already. It's in the engine. Just defined out.

^^ I still can't see it in the latest trunk. where's the submit on sourceforge?

Decompression of dds-files - not KTX - and before putting them into textures. It's in CImageLoaderDDS.
And I have no idea why it was added like that, as it was coded by Thomas who is working rather independently of the rest of the team and just drops a patch into svn every few months. I guess he just needed that...

[REDDemon]

ah ok now i understand. Sorry I thought bad .. well that's a tricky way to read a image file I think. I never thinked that Irrlicht already had a DDS loader (probably just didn't looked into depth)

what do you think about using proxytextures so? have I just to send a Patch that you can freely look at? (probably better I go to PM you next time)

[CuteAlien]

Please don't PM me, Hybrid knows 10x as much about texture management than me, I'm definitely the wrong guy to discuss this with :-) (I just accidentally know a little bit about that stuff, because I had installed a patch for DDS once 3-4 years ago in one of my projects).

[REDDemon]

ah ok well. When patch is ready I'll tell him so. Thanks.

[hybrid]

Still, what about non-supported compressed image formats? We need to handle that transparently, which means that we need a decompression feature, a transparent on-the-fly image format conversion mechanism, etc. And also, the "proxy texture" is already used in COpenGL, where we store an image in RAM. But this needs to be improved and manageable from the outside, which takes more effort. The problem is always the quite monolithic CImage implementation with an interface in IImage which resembles CImage exactly. This needs to be improved first, before we can extend any of the image or texture parts.

[REDDemon]

Subject: Optimized/Compressed Textures - KTX Loader (v.0.0.1 READY!!)

Still, what about non-supported compressed image formats? We need to handle that transparently, which means that we need a decompression feature, a transparent on-the-fly image format conversion mechanism, etc. And also, the "proxy texture" is already used in COpenGL, where we store an image in RAM. But this needs to be improved and manageable from the outside, which takes more effort. The problem is always the quite monolithic CImage implementation with an interface in IImage which resembles CImage exactly. This needs to be improved first, before we can extend any of the image or texture parts.

That's exactly the problem I intended to solve.

There can't be a transparent Image Implementation for handle compressed formats without huge API change. (or wihout a monolothic CImage)
Instead I create an ITexture wich returns only uncompressed data when locked. And is able to compress data the users put in it on the fly. No edits are required in the Image class this way. the Itexture (CKhronosTexture) internally use a proxy just for better incapsulation of the code (I know Irrlicht already used Proxy textures.. so why no using them again?)

The user don't have to warry if image is compressed or not. It will be edited as uncompressed RGB image. Only on the GPU the texture wil be compressed. So there will not be compressed images. Just textures wich can take images and compress them.

If the users want to create an empty texture for compress his own content it can do that with "addTexture".

Code: Select all

 
virtual ITexture* addTexture(const core::dimension2d<u32>& size,
                        const io::path& name, ECOLOR_FORMAT format = ECF_A8R8G8B8) = 0;
 

he has only to specify as color format a compressed format,it can be ECF_A8R8G8B8_compressed. Wich works for him exactly as ECF_A8R8G8B8 execpt that the same texture will occupy 1/4 of the size in the GPU and will be probably faster in rendering. The new color format is valid only for that method. Only textures can return that color format their IImage counterpart will continue to be a standard uncompressed Image.

So if you want to improve the Image class you can still do that without to warry about compressed textures implementation wich will be trasparent and NON-invasive.

Probably is better to show directly the patch. I'm not sure i'm explaining it well.

[Nadro]

Why we need a handling of a compressed image formats now? I think that this isn't important, because only minor percent of users will be need manipulation of compressed images. We need only allocation, deallocation and access to a compressed data and these methods are ready. At texture loading stage we should also add a possibility to an automatic drop an image after loading process (extend an interface with a boolean flag which will tell a device dependent textures about keep an image). Proxy textures isn't required, because unified interface with locked methods on compressed images (CImage->DeviceDependentTexture) will be better than many solutions eg. (ProxyTexture->DeviceDependentTexture, CImage->DeviceDependentTexture etc).