The Size of ITexture is too big

[KevinLuo]

I noticed that the memory size of an ITexture object which loaded a 800KByte png image is about 32MByte.
That's too much for me! What if I want to load hundreds of images to show the dynamic animation.
Should I load the image frame by frame, and drop the memory frame by frame? What's the best solution?

Thanks!

[CuteAlien]

Use smaller resolution :-)
If you are using irrlicht trunk you can also try the dds loader (there is also one in Irrlicht 1.8, but that one had several problems and did not keep images compressed anyway). The DDS format allows keeping imaged compressed at least up to the graphic-card.

[KevinLuo]

Use smaller resolution
If you are using irrlicht trunk you can also try the dds loader (there is also one in Irrlicht 1.8, but that one had several problems and did not keep images compressed anyway). The DDS format allows keeping imaged compressed at least up to the graphic-card.

Thanks for your reply! I'm working on a 4k resolution project ,I have to use this size of image. How about the dynamic loading method? Does irrlicht support loading and drop textures frame by frame?

[CuteAlien]

Yeah - you can drop textures (IVideoDriver::removeTexture to get it out of the texture-cache). But you talk about a dynamic animation and I'm not sure if loading from disk each frame is fast enough for that. DDS should be faster (as it's smaller).

[kornwaretm]

correct me if i'm wrong, addition to texture resolution is the color format, like a simple alpha channel is 25% of the texture size (A8R8G8B8). these two determines the memory usage.

[Cube_]

If you want better than that you'd have to use DXT compressed textures or some other compression that the GPU can decode directly (there are a few different ones), I don't think irrlicht supports these directly - I know PNG will get you uncompressed image data in memory.

[KevinLuo]

Yeah - you can drop textures (IVideoDriver::removeTexture to get it out of the texture-cache). But you talk about a dynamic animation and I'm not sure if loading from disk each frame is fast enough for that. DDS should be faster (as it's smaller).

Thank you! I have tried that method. I remove the previous texture before I load the new Texture. And it doesn't make my system significantly slow.
I will also try DDS later.

[KevinLuo]

correct me if i'm wrong, addition to texture resolution is the color format, like a simple alpha channel is 25% of the texture size (A8R8G8B8). these two determines the memory usage.

I implemented image blending with alpha channel in Opencv once. The addition memory is far smaller than the memory of Irrlicht. That makes me confused most.

[KevinLuo]

If you want better than that you'd have to use DXT compressed textures or some other compression that the GPU can decode directly (there are a few different ones), I don't think irrlicht supports these directly - I know PNG will get you uncompressed image data in memory.

Thanks for you suggestion! That's a different viewport to this problem.

[CuteAlien]

The dds format is using dxt - and it's supported in the Irrlicht trunk version (I never worked with it myself - so not sure how well the support works with different drivers).

[Mel]

You can cut some memory consumption by disabling the mipmap generation if memory is a concern, the renders will slow a bit, but you will have more free memory. The older API used to "shadow" texture resources with system resources so updating them was easier, thus it is most likely the memory the texture is using is actually duplicated, that is API design, and there is no workaround.

When it comes to textures, the file size does not matter, what is important is the resolution and the format. Would be nice that Irrlicht could convert between texture formats, for instance, convert from a RGBA8 texture into a RGBA4 or the like. There is quality loss, i am aware of that, but to what extent? or perhaps, what if a dither pattern could be applied? Before generating a texture, an IImage is entirely in system memory, so it is easier to handle, the hard part would be to bring the texture back from the GPU memory, so it should be done before the texture upload

[Cube_]

RGB8 to DXT5 would be more interesting since GPU can take compressed DXT - for OGL 4.3+ ETC2 format is also available.

Another compression scheme that would be interesting to support would be ASTC, any of these with RGBA8 or SRGB (where applicable) is orders of magnitude smaller and supported directly on GPU so compressed texture data in VRAM.

the only problem with ASTC is it isn't mandated by standard so only some gpus support it (all recent mali, nvidia, and intel (skylake+) - AMD and ARM invented the thing so their gpus probably also support it)

[Mel]

It would be interesting if Irrlicht supported the KTX image files, they support a full range of block compression systems in hardware (i.e. the file is almost a "DDS" like but written by Khronos, although it also supports uncompressed and probably floating point formats, so eventhough the texture compression could remain GL only, there is no reason to not to support these files on DirectX as well )

https://www.khronos.org/opengles/sdk/to ... at_spec/#3

[Cube_]

The problem with the format is the compression is GL only so we get a feature disparity where the memory usage becomes unpredictable, unless it runtime rebuilds the texture to something supported like S3TC which is probably above and beyond the scope of any reasonable driver, and since it's technically a container (much like MKV for videos) the specific compression is not guaranteed - for OGL 4.3+ and GLES3+ it's pretty much guaranteed to be ETC2, or possibly (but unlikely) DXT5