Textures, upside-down, backing-store? Non-power-2?

[m-7761]

I've noticed Qt and wxWidgets both store their images opposite of how MM3D loads them.

Since MM3D doesn't edit images, does it need to keep a copy of the image in Texture? And if not, it would be better to send the data directly to OpenGL without making a copy and flipping it upside-down in memory.

I don't see an option in OpenGL to flip the texture while it's loading. That would be a simple option. It has a lot of other options in this area. Maybe I'm missing something.

In that case I think the only option is to change the sense of the UV coordinates. That could be a preference I suppose. Artists may prefer one way or the other after all.

Also, I disabled some code that resampled textures to be power-2. I think non-power-2 is pretty well supported, but even if a platform can't render it, then the artist should change the texture. MM3D is a art tool and not a model viewer. Resampling the texture makes it look different. So I think that should be taken off the table.

EDITED: This makes me wonder if glDrawPixels draws upside down by Qt and wxWidget's convention.

[m-7761]

FWIW I ended up flipping the images in my UI framework module. (The wxWidgets image API is very unaccommodating (and unwieldy) so for RGBA images it wasn't even possible to avoid manually interleaving the alpha pixels, so it was simpler to always copy. glDrawPixels was upside-down. The API I set up for this is called glutCreateImageList (extension) so it should probably conform to OpenGL conventions, even when they are at maximum wrongheadedness.)

[zturtleman]

[Oppose NPOT resampling removal in MM3D / don't care to change texture UV. Generally agree in a non-legacy world.]

Image up direction is handled by texture coordinates. MM3D uses the 'conventional' OpenGL method of 0,0 being the bottom left of image / viewport and yes, the image being upside-down in memory (a feature of typical BMP and TGA images as well). I personally prefer 0,0 in top left like most other software though I can see how having +Y be up in 3D space and 2D space has some appeal for consistency.

but even if a platform can't render [non-power of two], then the artist should change the texture.

It really all depends what software you're using the model with (unless it's a model you aren't planning to export and use elsewhere). For example Quake 3 always resamples NPOT textures and MM3D can make MD3 models for Quake 3. It seems like if NPOT is not support then issuing a warning and resampling would be better than refusing to load. (Do image editors refuse to load 16-bit per-channel images on 8-bit or 10-bit per-channel displays? No.) I don't personally care as I wouldn't use NPOT for model textures.

[m-7761]

What platforms can't render NPOT? I mean, I guess OpenGL must have an API for detecting if the system can render NPOT. So if I felt strongly, I would start by figuring out how to do that first. If Quake 3 models should have their textures corrupted to appear identical to in-game, that's another matter, but seems very specific.

[zturtleman]

Full support may only be available in OpenGL 3 and OpenGL ES 3. OpenGL ES 2 doesn't support mipmaps and repeat wrap for NPOT textures without an extension and apparently some OpenGL 2 drivers fall back to software rendering for those. https://aras-p.info/blog/2012/10/17/non-power-of-two-textures/

[m-7761]

Given OpenGL's sketchiness, I think the only practical solution is to add a user preference. MM3D is sorely lacking an interactive user preference system. I think that should be a top priority to develop. I think this is worrying about nothing though, and I certainly would not want my NPOT textures resampled unless I know my system is unable to render them. IOW: It should be a preference that is off by default.