RTT regression between 1.7 and 1.8

[hendu]

RTT texcoords got more broken sometime between 1.7 and 1.8.

In 1.7, RTT texcoords were always correct, but occasionally caused 2d drawing to be upside down.
In 1.8 and current trunk, 2d drawing is always correct, but RTT texcoords occasionally get upside down.

Since of the two functions I mostly use RTT, this regression hits me fairly badly.

Test app attached to this bug:
https://sourceforge.net/p/irrlicht/bugs/419/

As the comment in the test app says, by switching the commented line with the one right below it you can observe this behavior. In 1.7, one option will have everything correct, and the other will have the A's upside down.
In 1.8, one option has everything correct, while the other has RTTs upside down.

[Nadro]

Thanks for test demo. I'll fix some bugs for Irrlicht tomorrow, so I'll look at this problem too.

[hendu]

Note that this is not the main bug, I failed to make a small demo that shows the main issue.

The main issue is that chaining RTTs flips every other of them; that should not happen. But curiously a small demo does not show that flipping issue.

e.g. Render the scene to rtt1. Blit rtt1 to rtt2, maybe doing some color transformation. rtt1 and rtt2 should be the same way up, but they are not.

[Nadro]

I looked at the example from the tracker and flipping works properly in my opinion (I think that may be hard to do better system for flipping than existing, it's problematic that OpenGL has the origin in the lower left corner), just ensure that in shader pass you doesn't use RTT texture in the material from last run loop, because if RTT texture is use texcoords are flipped. If you simply put "sq.setTexture(0);" or other non RTT tex at line 48 in rttbug.cpp all works correct. Flipping is done in line 1013 in COpenGLDriver.cpp. As I remember in older Irrlicht versions flipping was broken, so image was inversed in each odd RT.

[hendu]

As I remember in older Irrlicht versions flipping was broken, so image was inversed in each odd RT.

That's exactly what I'm seeing in 1.8 and trunk, and not on 1.7. It was correct before, now it's broken.

[hendu]

Very curiously, changing the check from "if (isRTT)" to "if (isRTT && CurrentTarget == ERT_FRAME_BUFFER)" fixes it for the complex app, but it breaks the simple app.

[Nadro]

Maybe is it good idea to enable flipping only for fixed pipeline renderers (when standart EMT is used + 2D operations) and for programmable pipeline (when shader material is applied) left original flipping. In current solution mixing RT and standard texture when only one texcoord is in use we will see issues (depend on which texture standard or RT is assign to TextureLayer no. 0).

[hendu]

I use EMT_SOLID for simple blitting?

[Nadro]

EMT_SOLID should work properly for blitting, because it'll flip RT and left standard textures without modifications. In shader you have to care about flipping UV on your own hand. As I wrote in previous post mixing standard textures and RT may cause artifacts, but I was unprecised before, it's related for situations when TextureMatrix is used for multiply texcoord and one set of multiplied texcoord is used for both RT and standard textures.

BTW. Simple shader should be more efficient than built-in fixed pipeline EMT_SOLID for blitting.

[CuteAlien]

Copy pasting my answer here from the bug-report:

1.7: green increases toward bottom in both cases. A's get flipped when changing texture.
1.8: colors flip when changing code-line, A's don't get flipped
trunk: green decreases toward bottom in both. A's don't get flipped

What it means is: In OpenGL textures have their origin in left-bottom corner of images.
Irrlicht uses the D3D style with origin on left-top corner (and also a texture matrix which looks a bit different). To make this work Irrlicht converts all texture matrices from D3D to OpenGL (note: other engines sometimes solve this by flipping all textures instead on loading, but Irrlicht wanted texture-data and texture-matrices both to be the same independent of the used driver).

Now the problem is in OpenGL RTT's do always get rendered upside-down (aka left-bottom origin). Which would be nice for pure OpenGL, but not with our texture matrix changes which expect textures to have left-top origin. So if we have RTT's in the fixed function pipeline we assume it's upside down and use another matrix to flip it on it's head.

But when exactly we flip/not flip RTT's has changed a bit over the versions.

With shaders we run into a problem. For Irrlicht 1.9 we no longer pass the texture-matrix always to shaders. Instead shaders have to do this themselves. Reason probably for speed and to get rid of OpenGL compatibility profile and because on other OpenGL variants like ES2 this probably must be done anyway.

So all is fine if you use fixed function pipeline. But if you use shaders you now have 2 options with Irrlicht 1.9:
1. When rendering RTT's do render them upside-down in your shader (so they end up with left-top origin).
2. When using RTT's in a shader do something like Irrlicht does for fixed function matrices and tell your shader in some way that RTT's need to be handled upside-down. So in check if texture return true for isRenderTarget and send that info as uniform to your shader and then handle it there.

I'm not sure if there is a better option than what we have right now for Irrlicht (there are different options obviously... but all come with their own pains).

As for the 1.8 behavior - it always did send the flipped matrix even with shader pipeline (it didn't handle shader pipeline different back then). It was possible somehow to get that information in shaders with OpenGL compatibility profile functions I think. I didn't dig too deep into that. 1.7 looks the same - I don't really know where the difference between those 2 is.

And sorry for this getting not answered for a decade.