I just put some stuff in Kolf to display the objects with different colors. It uses QColor::setNamedColor which gives course designers an easy way to use either RGB or CSS colors.
Obviously this is a nice feature 
. But that is not the real point of this post.
The real point of this post is the usage of certain OpenGL extensions we are planning to use. As posted by Stefan Majewsky during last wee there is work being done on a texture-creation application. That application now has a scale option which allows you to use more sizes of textures.
The good thing about this is a better resolution for the terrain (we use 1000×1000 for the grid and 256×256 for the texture at the moment). We could now start using 1000×1000 resolution textures which should make the terrain look nicer.
The problem here is the GL_ARB_texture_non_power_of_two OpenGL extension, which was approved by the OpenGL ARB in 2004. This extension works for Intel 945+, NVIDIA GF2+ and Radeon 7k+ cards. But not on the older Intel cards, S3/VIA chipsets and mobile hardware (it is not an OpenGL ES extension, so buh-bye N810/OpenMoko/Pandora etc.)
Is this still acceptable? Or does this go against the ideas of KDE Everywhere and should it work on hardware? (in this case: force the texture to be a power of 2 one, so max. 1024×1024)
The hardware has gotten so many new features over the last few years which can cause problems for KDE in the next few years. For instance: will we improve Marble for people with OpenCL enabled cards so that it runs and renders up to 50x faster, or do we not start to use these features because most of the people still have old hardware?
As most of use know this is a problem in the whole it world where the fruit company and the really small software company force people to buy new computers, but we cannot really do it. So what is a general support lifetime we should use? (at GCDS I’ve seen people with 6 year old hardware)
It makes the workload heavier but using the new functionalities with a decent fallback in case it is not supported would be the best of both worlds imho. See how kwin for instance handles this gracefully (as far as possible).
You should look at the GL_(NV|ARB|EXT)_texture_rectangle extension. It’s supported on more cards, because it doesn’t require that all texture filters to be supported.
As we use OpenGL a lot in Avogadro we have hit this question a few times. We do our best to always fall back tom something that should work for everyone. If your hardware is newer then Avogadro will often use newer features, but we try and maintain a fall back. I think this is the ideal approach, but agree with Med – it increases developer workload and the number of code paths.
In this particular case, why not force the texture to be a power of 2 (1024 instead of 1000), as you proposed? Is there a drawback to it?
I believe we should go for newer features if they are absolutely required or will make a big difference in ease of coding. But requiring it to use 1000 instead of 1024 seems not critical. But maybe I am missing something?
Well, obviously this is a solution. But then you limit the options for the designers, because we also want textures for the other objects, and maybe a designer wants to use a 125×100 pixel texture. In the past I did this by scaling it to 128×128 without maintaining aspect (then it looks the same) but that is not something you want to force your designers to do.
You just have to allocate a texture that is big enough (i.e. 2^n-1 < width <= 2^n).
Just calculate the texture coordinate appropriately – this way only memory on the video card is lost but you have the same effect as using non power of two textures. No need to scale anything.
Also an option, indeed, but every card that does not support the GL_ARB_texture_non_power_of_two has no video memory (only shared)….
Sure. But it’s the only proper way I know of to support arbitrary sized textures on hardware that does not support NPOT textures. It only gets a real problem on big textures (i.e. 1025×1025).
Other than that you can look for algorithms to efficiently map multiple bitmaps in a single texture.
So a 1025×1025 bitmap on a 2048×2048 texture you would have a 1023×2048 and a 1023×1023 block that could be used by other bitmaps.
Here is an example:
http://blackpawn.com/texts/lightmaps/default.html
I think the proper way is to have multiple render-path i.e. a fall back if the extension is not available on the platform. This way the more efficient/better looking way will be used if possible.
I know this is more work to do but in the end it’s what you have to deal with when using OpenGL directly and want to maintain compatibility.
Another option is to pack multiple odd-sized textures into one 2^n texture, a la Quake-style UV-mapped textures.