About the usage of lock and unlock.

[Mel]

First of all, this is just a theoretical question, but involves the functionality of the engine.

It is noticeable that as time goes by, one of the largest bottlenecks of our applications will be the loading times, where resources that aren't directly streamed (some stream friendly support would be a great adition) will have to be loaded at once, meaning that the whole program will, in the best case, reduce its pace to load the assets, this becomes specially problematic when loading the textures, as they are larger files in comparison to the meshes, getting worse, as the size of the texture increases.

Obviously, for this, it is sensible to use a format which can be streamed somehow, and these are the questions.

When i ask Irrlicht to create a texture, to add a texture to the video driver, (not to load a texture nor to create a rendertarget texture) it does also create its mip levels, right?

If so, Then, the next step is to fill the levels, but filling the lower levels first would provide information for the later levels to display something? I mean, We have seen in many places how this works, First the objects have blurry textures, and as time goes by, the textures are progressively loaded. Is it possible using lock and unlock to do something the like in Irrlicht or the textures would appear black until the last mip level was loaded?

Obviously i wouldn't lock inside the render loop, but locking and unlocking outside it would upload the diferent mip levels to the video card properly or this can't happen if the texture is in use?

[hendu]

Yes, you could write the smaller mips manually, as long as you also use a lod offset for that mesh so it only uses the mips you loaded. Even if the texture is in use by the GPU, the write will just be added to a queue, no need to worry about that.

[Marthog]

I don't think that other games load the mipmaps first but instead have a low-detail texture which is displayed on far objects, so that the larger textures don't need to be loaded for far objects and only when used.

[Mel]

That is how the mip maps work. The video card may generate them so the far objects access always a smaller surface for the texture cache to optimize the usage of the texture, at the cost of using almost double the memory of the largest mip level, the same goes with the anisotropic filtering, with even larger memory needs.

The problem is to accelerate the load of resources so the response of the program is always the fastest. It is not the same waiting endless loading times than wait a bit shorter load, at the cost of delaying the reading of the resources for when the program is already running. Not to speak, for instance, of resources streamed via network. It gives a faster response.