RenderTargetTexture on OpenGL Return 0 for lock() and pitch

[thomascheah]

Hi,

As some guys over here might noticed from my recent postings in this forum, I had been struggling with some issues with Render Target Texture on Direct3D drivers. After much thought, I decided to give OpenGL a try. (I can hear Hybrid chuckling. )

But I bump into walls as soon as I tried OpenGL driver.

1. It seems that the lock method of a render target texture always return 0 (null) on OpenGL driver? It does not make sense to me, and I can't believe this is a bug, given that the driver has been matured quite a bit.

2. The pitch of a render target texture always return 0 as well. Is this the same problem as what Direct3D driver encountered previously?

3. Since this is my first attempt to make a transition from Direct3D world to OpenGL, I know Irrlicht did a very good job abstracting the difference between these two drivers, but I certainly still believe there are some differences between these two under Irrlicht. For example, one of them that I learnt from this forum is that OpenGL render target texture is upside down. Aside from that, can anybody give me a quick summary on what other differences that I should be aware of?

Any help is much appreciated. Thanks!

[BlindSide]

The upside down render target in OpenGL has been fixed. (Unless you are reading from a shader).

The ->lock() returning 0 issue is a known bug and hybrid has been wanting to get it fixed for some time now.

[thomascheah]

Dang! I guess there is no workaround for that at the moment. My objective is to save render target texture to an image file. I thought if lock works, I can just retrieve the pixels and save them according to the pixel format.

Arghh... I guess I am really stucked.

[vitek]

You might be able to use the screenshot functionality for this. Set the render target, render, then use the drivers createScreenShot() method to copy the pixel data to an image.

Travis

[hybrid]

The thing is that we need to copy the RTT from GPU into an IImage, adjust for the flipping (because right now the RTT assumes that it is internally flipped, but on access we have to change this, too), and probably upload afterwards (flipping back for correct internal flipping). This is pretty expensive and I did not want to introduce this in the late stage of 1.4. I'll add some bugfixes for the development version, though, which should give access to RTTs under OpenGL, too. Maybe we will also get some less expensive texture access methods (e.g. read only access methods, which also avoid mipmap updates on access), we'll see. If there is a cheaper solution for the access we might even see this fix in a later bugfix release of the 1.4.x series.

[thomascheah]

Yeah, I guess my only choice right now is using createScreenShot method. The reason I am so reluctant to use that solution initially as createScreenShot only create a screenshot image that is the same size of the window size. My objective is to create a screenshot of any arbitrary size at high-res. (No pixelation result of stretching, etc.) I guess I will have to use this method until there is some way to fix this RTT with OnResize problem.

Anyway, thanks everyone for the feedback and input! You guys are the greatest!

[thomascheah]

Aside from that, I also noticed createScreenShot will capture any windows that are on top of the main window where Irrlicht renders. This might not be a problem in fullscreen mode, but I believe it is ill-suited for programs in windowed mode, where there is always dialog boxes (of the same application), or windows of other application obscuring the current main application window.