My point is that physical orientation is meaningless until you map data existing in an abstract coordinate space (such as window space or texture space) to an output device, because physical orientation (top/bottom, left/right) can only be interpreted relative to an observer.
When rendering to a texture there is no output device involved and thus no physical orientation.
The only (slight) exception from that is the concept of front- and back-facing based on “clockwise” and “counterclockwise” winding order of vertices. However, even those terms can be defined purely mathematically without reference to physical orientation of window space.
From: Florian Bösch [mailto:firstname.lastname@example.org]
Nevertheless bottom/left is 0,0 on FBOs not top/left.
On Fri, Dec 7, 2012 at 5:52 PM, Georg Kolling <Georg.Kolling@imgtec.com> wrote:
When you render to a texture the origin is the origin.
That is, the origin in window space is mapped to the origin in texture space, and the positive X and Y directions are aligned with the positive S and T directions.
There is a single set of (texture coordinates, window coordinates), or if you want to take a step back, a single set of (texture coordinates, normalized device coordinates) to map the texture space origin to the window space origin.
On Fri, Dec 7, 2012 at 4:31 PM, Georg Kolling <Georg.Kolling@imgtec.com> wrote:
When you render to a texture the origin is bottm/left not top/left. If you're serious about origin preservation such as not to end up with cases where there is no right UV set anymore or you render things upside down variably, you upload with origin bottom/left not top/left. Alternatively you fix glViewport, glScissors, FBOs, to have origin top/left such that you'll not have to render things upside down and can apply one set of UV coords regardless.