How to decrease texture loading time?

[ibax]

that's true. I have ONLY jpg texture files. this can be the problem?

[luthyr]

Are you building Irrlicht in Debug? Are you also building your program in Debug? Are you running the program direct from an IDE like Visual Studio?

How are the load times if you have Irrlicht release, program release, and run directly?

[ibax]

Are you building Irrlicht in Debug? Are you also building your program in Debug? Are you running the program direct from an IDE like Visual Studio?

How are the load times if you have Irrlicht release, program release, and run directly?

Hello. I'm working with VS2010. Building everything in Debug mode. The exe file after the build is running from windows, outside Visual Studio.
I will check the load time in Release mode today...

[Marthog]

As long as you don't need to debug the Engine but only your Application you normally don't need to compile it in Debug mode.
The Engine should have no bugs so that nearly always the problem is in your application. That means you can use the Release version of Irrlicht.dll.

[mongoose7]

As he mentions VS2010, I guess he is working on Windows. In which case, *all* DLLs have to be compiled for debug.

[ibax]

...in which case, *all* DLLs have to be compiled for debug.

sorry, I don't understand this now... I have all the necessary dlls: irrlicht.dll, irrklang.dll, sqlite.dll
I didn't recompiled these dll files.

And I have new .cpp and .h headers, which are compiling in debug now (currently).

That is the way I'm writing the code. Am I doing something wrong?

[luthyr]

Oh, if you are not rebuilding Irrlicht yourself (just using the prebuilt DLL in the SDK), then you are probably fine. Running your program in debug with Irrlicht release should not be causing massive slowdowns.

[CuteAlien]

that's true. I have ONLY jpg texture files. this can be the problem?

No, that's absolutely fine. What I don't get is then why profiling shows you that png_set_expand is using the most time - as it should then never be used at all (it's only called for png loading). That makes no sense so far. Maybe set a breakpoint in it and check the callstack to see from where that function is called.

[ibax]

Hi all!

My application starts with a menu. When you select every important thing, the .irr file (scene) starting to load and the play beging...

I rechecked everything once again, and I found the following on my console output:

Code: Select all

Loaded texture: C:/_irrlicht/Debug/myfont0.png
Loaded texture: C:/_irrlicht/Debug/myfont1.png

This can be seen in the console output in the first menu window, when the program starts. It is OK from this point of view, because I use special types also. So I solved this issue, now the font types are loaded as jpeg also. There is no png file in any of my directories now... But the png_set_expand call is still there and runs in 100%...

And I found some extra line in the console output also:

Code: Select all

Could not get lower surface level for mip map generation
Loaded texture: c:/program files (x86)/ambiera/coppercube-irredit 4.0.1/textures/~editor_defaults/default_white.png

I don't know the reason, why is this line between those lines, where the textures are loading and loading...

I made a jpg copy of this file, I rewrited the references (in the .irr file) from png to jpg, but nothing happens.

Texture load time is the same.
png_set_expand still exists and runs on almost 100%

[hybrid]

Make sure that you have all libraries properly updated and compiled with debug symbols. And do a proper profile, which shows how many percent are spent where. Otherwise you maybe see some functions calls which are not there in such a way.

[ibax]

I don't know, whether it counts, but irrEdit loads the .irr file 10x faster than my program (irrlicht)
(irrEdit also loads and uses all the textures of my mesh)

[hybrid]

Maybe you should compile Irrlicht and your app in release mode?

[ibax]

Maybe you should compile Irrlicht and your app in release mode?

I tried this also. App is compiled in release mode. I did not touched the irrlicht, so should I recompile it in release mode?

[luthyr]

You shouldn't need to. However, if you don't compile Irrlicht in debug, profilers like Very Sleepy are likely going to be inaccurate about what functions are actually slow (with regards to Irrlicht).

[devsh]

First off:

Compile everything in FAST MATH RELEASE


Secondly:

YOU CAN MULTITHREAD IMAGE LOADING!!!

but you have to do it in a clever way, you need to know that irrlicht loads textures in 2 steps:
1) Use a appropriate class to load, PNG, JPG etc. into an IImage* (which is a container class for an array on CPU)
2) Upload a texture to the GPU using the IImage*
3) delete (call drop() ) on the IImage to get rid of it

so you can multithread step 1, but not step 2 because it interacts with OpenGL

SO, if you want to have N threads:

have a main thread (one which spawned Irrlicht) which will:
--launch N-1 threads loading IImages from file into RAM and putting the IImages on a THREAD-SAFE-QUEUE
--read the queue and pop the item off, call createTextureFromImage() to upload to CPU and delete the IImage
if there is no item on the queue, do what the N-1 threads are doing and load an IImage and place on queue

THIS can cut down your FILE READ times by a lot


POINT NUMBER 3:

CHOOSE A LOSSLESS FORMAT (PNG) instead of JPG
CHOOSE A FASTER LOADING FORMAT (at the expense of disk space), in our game we actually go to the extremes of using DDS file format (no compression) to speed up the loading
(we put the DDS in a zip file)

DDS might not be an option for you cause 100 jpgs at high res would decompress into couple hundred megs


POINT NUMBER 4:

USE DDS, why?

Because you can pre-generate mip maps (with GIMP image editor), google mip mapping to know what I'm on about. Basically this saves Irrlicht from performing 100 mip map generations