Copy ITexture?

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!
Post Reply
no_response
Posts: 26
Joined: Fri Aug 20, 2010 11:07 am
Location: Bulgaria

Copy ITexture?

Post by no_response »

hi again,

I need to copy ITextures.
I need a way that is faster than creating a new RTT texture using addRenderTargetTexture. Creating ~500 RTTs takes about 3-4 seconds on my PC (which is old, I know) and this is unacceptable for my app.

So instead of creating new RTTs, I decided to have 1 RTT, render to it and then copy the RTT to a new ITexture, flush the RTT, render again, copy and so on....

Yet I can't find a way to copy ITextures.
What I tried was

Code: Select all

struct texsize{bool a[<ESTIMATED TEXTURE SIZE IN BYTES>];};
ITexture* sec = (ITexture*) malloc(sizeof(texsize));
*((texsize*)sec)=*((texsize*)RTT);
However, it seems the image data itself is stored in the ITexture as a pointer, so i'm just copying the pointer.


so... any way I can actually copy the whole ITexture?
Thanks!
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

No, not really. I didn't yet implement the texture blit operations. But I doubt that you can avoid the texture creation time. Usual textures will also take some time to arrange the memory on the GPU. Moreover, it's just one time, so a few seconds won't hurt. Maybe your scenarion requires a different type of usage for textures instead. What will you do with 500 textures (which are probably also very small each...)
no_response
Posts: 26
Joined: Fri Aug 20, 2010 11:07 am
Location: Bulgaria

Post by no_response »

I'm writing a file explorer.


The next lines may seem a dumb way of doing things, yet I am open for better ideas.

Once a user wants to open a folder, a function stores all the content's names and types (folder, device, file....) in an STL list<>.
Next up another function places rectangular scene nodes for each list<> member, poping it.
While placing, an RTT function is called, which draws the list<> member's icon and text under the icon. The return pointer (to an ITexture) is used as the rectangular scene node's material texture.


So when opening, for example, c:/windows/, in my case ~500 render target textures get created, taking about 4-5 seconds.
As you can understand, this defeats the whole idea of creating a better, faster and smarter file explorer than the explorer.exe itself. (not saying that explorer.exe opens the folder much faster, but yet it IS faster)


So my idea was instead of creating RTT for each file, only one RTT is created, rendered to it and then copied to another ITexture.


a screenshot can be found here


p.s.: it seems i'll have to dump the embed-text-on-the-icon idea and will have to place static text under each icon scene node, moving it with the slider.... that's what I was trying to avoid.
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Post by Mel »

I am understanding you are creating one rendertarget per each object in the list, to render the content of a directory, sending all the rendertargets to another rendertarget. Is that? Unless those rendertargets have the actual content of the images of a directory and change in realtime, it's an enormous effort for something that little.

Obviously, you are missing a feature of Irrlicht, or two. You don't need such amount of rendertargets. That's just crazy! not to speak the amount of ram needed to create and mantain them, or that you could just draw to one, and reuse it after. Just think that whatever is shown in the screen, won't appear until you put the "endScene()" call, so, what you do in the middle is just up to you. No one will see.

For example, think of this:

You have a texture (just one) with all the icons you need. All in their place. Also, you have an array or a list with the top left corner pixel of all of them, and their size. And you can access this list by type of file.

At this pont, you read the directory, and store the content inside a list.

According to the file type in the list, you may store the top left corner and the size of the corresponding icon on another 2 lists, and then, you can draw all these icons at once, using the drawBatches method of Irrlicht.

drawing 2D batches

You can do something similar with the text, I think irrlicht is capable of using rectangles to limit the area where the text is rendered, so you calculate an array of rectangles, and use the IGUIFont methods to render text.

IGUIFont method to draw text constrained to a rectangle.

The good thing is that you don't need extra rendertargets, You only need the ITextures for the fonts and the icons, and the rest you know how to do it, or you can investigate a bit more. It is not dificult. Read a bit more the documentation!
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Yeah, as I expected. Don't do such a thing. You will fragment your gfx card RAM, get serious problems about ressource handling in general, and rendering will slow down to a freeze almst immediately. You have to rethink your whole approach, the previous post should give you a lot of hints about how it could work far better.
no_response
Posts: 26
Joined: Fri Aug 20, 2010 11:07 am
Location: Bulgaria

Post by no_response »

first, thanks for the help.

the batch image rendering would be useful if the images were treated as a scene nodes (like when moving the camera, they get out of the view), yet it cant seem to come in handy in my case.

The text clipping, however, may be useful, but I can't get it to work. How exactly am I supposed to make a text clip to a scene node, for example?
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

What you should do can be found in the SpriteBank in Irrlicht, or generally in texture atlas techniques. You create a large texture, where you define regions into which you can add the icons you want to render. When rendering your list, you create quads (which should be batched into a large mesh btw) and define proper texture coords in order to get the correct icon. This will reduce the texture swapping upon rendering, you can send larger geometries for speedup, and you won't thrash the gpu memory with your hundreds of textures.
Post Reply