Jump to content
Posted 09 July 2012 - 11:43 AM
Posted 09 July 2012 - 01:44 PM
Posted 09 July 2012 - 02:21 PM
In this page http://www.opengl.org/wiki/Array_Texture it describes that texture2DArray is used for this purpose, but isn't the same z = (1.0f/texDepth*index) without to break the compatibility with OpenGL < 3.0? And the problem about the texture3D with at least 2px of depth remains...
If you're using OpenGL 3.0 or above, 'texture arrays' (search for them) are designed specifically to do this. They're a bit like 3D textures, except that filtering only occurs on the layer you are using.
Posted 09 July 2012 - 02:38 PM
Edited by mark ds, 09 July 2012 - 02:42 PM.
Posted 09 July 2012 - 02:54 PM
Don't forget that you can't mipmap your 2D textures if stored in 3D.
Edit - unless you want to manually calculate the correct mipmap by interpolating across two 3D textures, that is.
Also, you can have one layer in a 3D texture, but depending on your hardware, it may require a power of 2.
What hardware are you running on?
Posted 09 July 2012 - 06:21 PM
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
Posted 11 July 2012 - 04:43 AM
Texture arrays would be the preferred route, yes, but even if you can't use them on account of your minimum specs, it's not all bad news.
Firstly, older hardware isn't that crap - really. The last desktop video card that could only handle 256x256 textures was a 3dfx back in the 1990s - I'm reasonably certain that you don't want to aim that low!
A more reasonable starting point would be somewhere in the GL 1.5 to 2.x class, which more or less guarantees you a minimum of 2048x2048 (there's one Intel in this class that only does 1024x1024, but I don't know of any other). You say that you're using shaders so that puts you in the guaranteed 2048x2048 bracket.
If you're still in doubt, a good place to jump off from might be this OpenGL capabilities database: http://feedback.wild.../report/opengl/ - here's the page for GL_MAX_TEXTURE_SIZE: http://feedback.wild...AX_TEXTURE_SIZE.
You'll see that ~2% of their listed hardware supports less than 2048x2048. Jumping down to the actual cards (http://feedback.wild...XTURE_SIZE#1024) you'll see that a huge majority (495 out of 553) of this 2% are "Microsoft GDI Generic" - in other words they don't even have an OpenGL driver installed. Not supporting 2048x2048 textures is going to be the least of their problems. So you can quite confidently set that as a minimum requirement, and be certain to have 100% coverage of the end-users you care about.
For mobile platforms I'm not sure how things work out, so you can probably run with a hybrid solution. Instead of restricting yourself to a choice between a single 2048x2048 texture or 64 256x256 textures, why not create 4 1024x1024 textures? You'll still get much of the benefit of reduced draw calls, but still also fit within the texture budget of the hardware. Likewise, if you've determined that the hardware only supports 512x512 textures then create 16 textures at this resolution.
Specifically for 3D textures as a solution to this, there are some things to watch out for. The max 3D texture size may be smaller than the max 2D size - I don't think that OpenGL specifies this, but it can and does happen. Also, you need to be careful of your filtering modes - basically, set up any kind of linear filter and you'll be filtering between different slices in the 3D texture, which is not what you want in this case (a texture array wouldn't have this problem) - it's GL_NEAREST all the way here. Finally, and only if you're really being ultra-conservative, 3D textures are an OpenGL 1.2 feature, so they're not going be available on some of the more prehistoric hardware (which nobody really has any more so it's a non-issue; just mentioning for info). Are 3D textures available on mobile platforms? Don't know - someone else will have to tell you that.