   Render to texture
  Hi allI'm using rendering to texture to store the RGB values in a texture (obviously). I need to do several steps and in each step render in a diferent texture. The problem is that I need to do, maybe, 300 steps, and I can't store 300 texture on GPU. I thought a solution. My render to texture is 1024x1024 resolution, so I can create a texture, for instance 4096x4096 and in each step render my 1024x1024 screen in a portion of my big texture. That way I can store more than 300 steps in textures.That idea I implemented (two month ago) rendering in framebuffer and using glCopyTexSubImage2d. The parameters xoffset and yoffset let me control where the pixels are drawn. I think the idea is clear.My question is: Can I do the same with FBO? I'm telling, can I specify, someway, attaching the 4096x4096 texture, draw the result in a portion of my texture. (My viewport is 1024x1024).Thanks.   
  hi, i wasn't implemented fbo yet so i don't know much about gl's fbo,  but i think you should reduce these 300 count. 300 texture 1024x1024 with rgb makes nearly 1 gigs of video memory. so if you dont use them often you can move some of these (less used ones) to system memory or even worse write to hd. sorry maybe not helped much but, if you really need these textures someone who used fbo before may help you.   ;  That's not a solution because I need all them. Pass the texture to CPU memory is a very high price. Anyway thanks for you reply.   ;  You can use a technique called ping-pong rendering, with 2 textures, A and B, render to A, read from B, then read from A, render to B, then render to A and read from B. You can do that as much as you want, and all data stays inside the GPU.   ;  I use ping pong technique for depth but for colors I need to store all them in order to calc come values in each layer after rendering. During rendering is impossible because I don't have the necessary info until render ends.Thanks anyway.   ;  Basically, you won't get the right answers if you do not ask the right questions. I suppose your aim is not to store 300 rendered images and use all of them together as input for some kind of postprocessing step just for the sake of it. I assume you have some real problem at hand you need to fix. Telling us what you are doing out of what purpose helps not just to optimize storing 300 render images but to come up with another solution whatsoever if possible. It could be an option to reduce (read: pack) the information or to accumulate the results somehow to reduce the texture usage.4096 x 4096 x 32 bit x 300= 1,2 GBThen you also have several MB for your back buffer, depth buffer, render data plus some "overhead". Even with a quality graphics card you only have 768 MB vram available. This forces your driver to swap large chunks of data in and out of the vram which could easily stall your system more than copying the back buffer as you do at the moment.One solution might be to have a somewhat optimized ping pong chain with several dozens of textures you render to with an FBO and then accumulate their content. I also don't see without further explanation how you can use 300 textures at once as input to whatever post processing step. If you into more detail how you using all those 300 results at once right now and what you are actually trying to do there might be some better answers we can give.   ;  You are wrong. I'm doing the rigth question, but judging by your reply my explanation is awful. Let me try again...I need to store 300 (more or less) textures of 1024x1024 (not 4096x4096). The problem is complex and there's no other way to do but this. If I explain why I need to store all them the post will be unreadeable, so please believe me, has long been working on it.Now let me show you and simplified example. I want to store 4 textures (1,2,3 and 4) of 10x10. Results that the max number of textures I can store (hardware limitation) is 2, but the max size of a texture is 20x20. Solution: I create 2 textures of 20x20 (t1 and t2), and place 1,2,3 and 4 that way: 1 in the boottom of t1. 2 in the up of t1. 3 in the bottom of t2 and 4 in up of t2. That way I can store the 4 textures where initially seams that the limitation of max number of textures makes it impossible.In order to do this (as I explained before) I use glCopyTexSubImage2d. Once I render the image (that is what I want to store in texture) via glCopyTexSubImage2d I store the result in a region the "big" texture (in the example t1 or t2).Now I think the idea is so clear (I hope).I would like to do the same but using FBO instead of glCopyTexSubImage2d (because is faster). So I should be able to specify (once I attached the "big" texture in the FBO) which region of the texture I would like to write the result.So my question (and I'll try to be as "rigth" as possible): It is possible to specify someway, wich region of the texture I would like to draw on?I've implementing some test and the way opengl manage the FBO I think what I'm asking is impossible, but I never loss my faith.Thanks.;  I still think I am not wrong [smile]Rendering to an FBO is very much like rendering to the back buffer. You can set the viewport and a corresponding projection matrix to render only to a portion of the render target. It doesn't matter if it is the back buffer or a texture. Now you don't need to explain hardware limits to me. I understood your idea of a texture atlas and I also understand why you want to go this way. Still I believe the true answer lies in what you are actually trying to do. As pointed out even with advanced hardware with 768 MB of vram your approach with 300 / 4 textures is likely to stall your pipeline more than copying the back buffer as you seem to be doing at the moment.So take your time and the space (we have plenty of the latter here) and explain why you think you need to store the result of all 300 passes until the end? I think this will produce more solid answers.If you stick to what you have already explained then the answer is: Yes it does work with FBO but no it won't help your overall performance - it might even make things worse.   ;  You can set a smaller viewport (glViewport) and that will render only to a part of the texture.   ;Quote:Original post by HuntsManYou can set a smaller viewport (glViewport) and that will render only to a part of the texture.That way seems to work fine. I have to be carefull, but I'll try it. Thank you.Waterwalker I really appreciate you help, and I promise next post I will explain all my problem. Today I'm out of time. Thanks anyway.   