Texture Loading Speed

[Kaiser]

In one project I'm working on I load about 500 textures in all. Most of them are just parts of various animations I have, and so for a while I thought to combine them into gifs and just be done with it. Of course after poking around the forums I now know that just ain't gonna happen.

So, is there possibly any way to accelerate the loading times of the textures? I do recognize the fact that by cutting every other frame I could probably speed things up, well, about twice as much, but I'm still in the hopeful "Surely there's another way!" stage of my frustration.

Thanks
-Kaiser

[hybrid]

You could put them all into larger textures and access them via texture coord manipulation. Creating a hardware texture always consumes a decent amount of time for setting up the strctures etc, hence loading only a few large textures should speed up your app.

[rogerborg]

In one project I'm working on I load about 500 textures in all. Most of them are just parts of various animations I have, and so for a while I thought to combine them into gifs and just be done with it. Of course after poking around the forums I now know that just ain't gonna happen.

Umm... why not?

[Kaiser]

The primary obstacle in using gifs is that Irrlicht does not support them. (so I think, if I'm wrong please disillusion me)

Also, does anyone know how to go about doing this coordinate manipulation? The forums, API, and just fooling around in the editor have shown to be rather vague on the subject.

[rogerborg]

We could guess at whether you're talking about animated gifs, and whether your problem is texturing 3d objects or drawing 2d sprites, or you could tell us what requirements you're trying to satisfy. It'll go faster if we do the latter.

[Kaiser]

Incidentally I am referring to both. One set of images is applied to a sphere in such a manner that the mesh looks as though it is appearing in segments of consistent latitude. The other set forms the illusion of a circle being drawn in segments of consistent theta. As to your other question, at the moment the images I use are naught but humble png's.

Also, since it may have some impact upon the answer, I must confess that I have taken the dark path and am using C# in this project. Nonetheless the answer to this question interests me beyond this one application and doubtless when I graduate into C I will run into it again. Thus I will be grateful for an answer irrespective of whether or not it is limited to C.

[rogerborg]

Sorry, I was unclear. I'm basically having trouble understanding why you'd want to switch to gifs rather than stick with pngs. What's the thinking behind that?

Again, I still don't actually know what your requirements are, or why they are causing a problem. I'm now guessing that what you need to do is to dynamically re-texture 3d objects, by applying a new texture to an already loaded model. If that's not what you're doing, can you please explain what it is that you are doing, and why it involves loading 500 textures.

[Kaiser]

I suppose I'm being unclear myself.

I really would rather stick with png's. The reason why I was considering gifs is because I believe the reason for why it took so long for my program to load, which ranges between 5 and 7 seconds, is because of the vast number of times that I load textures. This is not in itself an abominable amount of time to wait, but loading that many images just feels inefficient. If I was able to use three gifs for the three animations I would be able to reduce the number of calls from 502 to 35. However, I found on the forums that Irrlicht does not support gifs.

The purpose of the textures is varied. Two sets of them are applied to meshes that are really nothing more than .3DS spheres. One set, which is comprised of 50 individual 64x64 png files, begins as a transparent image with only a hundred or so pixels colored in, and as the set is traversed more pixels at seemingly random locations are filled as well, until in the final file the field is solid.

The second mesh which I apply to a sphere is the one that vexes me the most for what would seem inefficiency. It is 60 more 64x64 png's, and the series begins as a single row of pixels, which expand in the +y direction over the course of the set until image 50, where the field is full. In images 51-60 pixels begin to disappear irrespective of their rows until the implied image 61 in which the entire texture is transparent (here I simply stop displaying the scene node).

At each step of these animations I reapply them to the mesh, which may itself be another point of inefficiency.

The final animation is a set of 360 112x112 png's that I use to demonstrate how near a given event is to completion. Each image represents another angle filled in on a circle. The area outside the circle is transparent.

Thank you for your patience in dealing with my rather nebulous posts.

[Frosty Topaz]

I believe there's a material type that may help. IIRC one of the alpha channel material types allows for a reference value to be set and draws pixels with an alpha value greater than the reference. By changing the reference you should be able to achieve the effects you're talking about with a single image each.

Now that that's said I'm going to add a caveat. I've not done this personally, don't have the api open right now, and will leave it to you to confirm. I hope I'm remembering right and this helps.

[Virion]

I thought loading speed is depending on your system spec?

[Kaiser]

So it is. I admit, I don't really care about the loading speed anymore. It's not really all that bad. It's the possibility of there being a better way that intrigues me now.

[hybrid]

At least the second case can be easily done using a texture matrix (unless you need exact pixel lines). Simply set the texture wrap to clamp and let the y texture coord range from 0 to 50. Then scale it down each animation frame such that the last coord meets 1 in the final frame. Then start to set the alpha value and let the sphere dissolve.
Both situations could also be handled with larger textures and a texture animation using texture matrices. Simply change the translation of the matrix in such a way that always the next subtexture is shown.

[rogerborg]

^^^
What he said.

If I was able to use three gifs for the three animations I would be able to reduce the number of calls from 502 to 35.

MY HEAD ASSPLODID!!!

Sorry, I am completely unable to fathom the thinking here. What is it about gifs that would allow you reduce 502 textures down to 35?

[hybrid]

It would work if animated gifs would be supported by some kind of texture animator.

[christianclavet]

One simple trick that could help (Not sure you'd like it 100%), is to put all your PNG's in a single .ZIP archive. Then retrieve them from the archive.

This should load a little faster, but CPU usage will increase also.

Also if you're willing to have also a faster loading speed, is to put your images as JPEG (Do you need the ALPHA channel in your images?)

JPEG filesizes are much smaller than PNG, but they can't contain alpha informations.

So the idea: batch convert all your PNG into JPEG's and put them in an archive, then load them from the archive. You should see a difference.