Ttexture-origin selection.

Hi

I have made my engine support OpenGL and Direct3D 11. From my experience, most problems can be fixed or worked around with some effort, but there is ONE major problem where an engine cannot be made entirely API agnostic.

And that is the fact that OpenGL has its texture-coordinate origin (0,0) in the lower left corner, and D3D in the upper left corner.

The problem with this is, that it totally messes up all texture-coordinates in your data.

My work-around so far is, that i load all textures up-side-down in D3D, that fixes all texture-coordinate problems. However, now all render-to-texture operations create up-side-down results, because you just messed up D3Ds conventions.

So i added something to my engine, where the modelview-matrix is silently “patched”, whenever one renders to textures, so that the geometry is rendered up-side-down into the texture, fixing nearly all problems.

The remaining issue is, whenever people do unexpected things in shaders, where they don’t use the engine-provided modelview-matrix and thus don’t flip the image.

And finally, the OUTPUT, that means the image that is rendered to the backbuffer, must not be flipped, or your result ends up wrong. People have to be absolutely aware of that, i can’t magically fix this entirely.

Since the graphics-hardware obviously is able to do both and MS has no intentions in making D3D more portable to OpenGL, it would be great, if at least OpenGL would allow to set a state, to set the texture coordinate origin to the upper-left corner.

That would remove the one big obstacle that currently exists, if one wants to port an engine between OpenGL and D3D.

The switch MIGHT but does not really need to, also influence the window-origin, used for setting the viewport, scissor-rect and possibly some other functions. But those are actually very easy to fix in an engine, so that’s not important. The really important thing is only, that a given texture coordinate samples the same location in a texture.

Jan.

How about using ARB_fragment_coord_conventions?

Regards
elFarto

How about using a texture matrix which defines a -ve scale.
Just a thought.

There is nothing like texture matrix in shader. It can be implemented but it requires “patching” that is not trivial.

This extension addresses “only” window fragment coordinates in fragment shader. Not the texel in texture.

So it looks like Jan needs hypothetical ARB_texture_coord_conventions extension.

I was thinking about the built-in gl_TextureMatrix[n] or supply your own uniform 4*4 matrix to do the same.

I think the point he was making is that it would require extensive manual changes in the shaders, whereas a built-in feature would work automatically.

Then again, the built-in feature would probably have to be a per-program switch that would be set before programs are linked.

ARB_fragment_coord_conventions is a good start. It fixes the biggest problem between D3D and OpenGL.

However, it would be nice if there were an additional extension, which would allow to switch the texture-origin from lower-left to upper-left, then the behavior would be (mostly) identical to D3D and porting would be very easy.

A texture-matrix would be one solution, but you always have to make sure it is applied. Same thing for window-coordinates. It always requires the shader authors to be aware of the problems and not forget to apply the fixes.

I wouldn’t want to apply such state per shader program, but just as a global state in the application. Either you sample using OpenGL conventions or with D3D conventions. Of course one COULD make it shader state (or sampler state?), i wouldn’t really care for that extra flexibility.

Anyway, just some idea for the ARB to consider.

Jan.

I wouldn’t want to apply such state per shader program, but just as a global state in the application. Either you sample using OpenGL conventions or with D3D conventions. Of course one COULD make it shader state (or sampler state?), i wouldn’t really care for that extra flexibility.

I didn’t suggest it because of flexibility. I suggested it on the assumption that texture units don’t actually have an origin switch on them. Which means that the origin would be built into the shaders. So if the state were global, every time you change the state, every shader would need a recompile.

Jan> You could use a blit right after glTexImage to flip the texture upside-down. It’s probably the easiest and fastest solution.

Any idea why Microsoft uses the upper left as their {0, 0}? GL already existed and they should have used the same conventions and I’m sure there isn’t any copyright on this silly thing.

V-man : probably just to keep the same standard as GDI and numerous other 2D API.

Wonder if that’s what RenderMorphics RealityLab did (which Microsoft bought and which became DirectX, IIRC).

http://www.gamedev.net/reference/articles/article1775.asp