Support for texture arrays

[hendu]

http://sourceforge.net/tracker/?func=de ... tid=540678

These patches add support for texture arrays. tl;dr q&a

- what?
Think texture atlas without any drawbacks. Uses only one slot, no mipmap bleeding.

- where?
>= dx10 hw, >= gles 3.0 hw, some lower hw via extensions (some high-end androids for example)

- dx?
GL only. See above, can't be done in dx9.

- usable for...?
Much greater batching, or texture variety (splatting etc). Just like an atlas but with less downsides.

- why via textures and not IImages?
Because it's very likely you use some of those textures elsewhere too, standalone. Forcing a re-read and re-decode from images makes no sense.

- drawbacks?
The current code doesn't support custom mip levels. There's also no check that the sent textures are in the same color format (they need to be).

Neither is a big issue, as very rarely anyone needs manual mip levels, and all loaded images default to 32-bit RGBA.



Picture of the attached demo app, showing off a two-layer array texture:

[hybrid]

That's really nice. I guess we can make the 1.9 release just from the contributions on the tracker. Which only means that we must get 1.8 out of the door...

[hendu]

Any chance you could implement instancing? It's likely the next thing I need, and lately it feels like I'm the only one hacking around

1.8 can wait, we need features

[hybrid]

IIRC, we have no final patch for instancing, so will need at least longer than this one. IMHO this one is pretty straight and almost done. I might extend the loading process just a little bit, in order to allow 3d texture loading and cube maps also with a similar API.

[Mel]

What diference is there with a 3D texture? Those already support mipmap filtering in all directions, use a single texture stage, and can be used with all DX8,9 and GL. Actually, the only drawback for 3D textures would be that they don't support the usage of the texture levels separately, but other than that, using the proper texture coordinates may equal the same utility as texture arrays.

[hendu]

Actually, the only drawback for 3D textures would be that they don't support the usage of the texture levels separately, but other than that, using the proper texture coordinates may equal the same utility as texture arrays.

You said it. The difference is that 2d arrays support blending in the 2d direction, while blocking blending in depth.

Playing with texcoords you _may_ be able to get exact results, on some particular hw. But you'll get bleeding on some other hw. It's not reliable, and if you go point filtering, it's point filtering for all three axes.

[Nadro]

Nice work. As I remember similar patch is available on a forum (but I'm not sure whether it's designed for OGL2 or custom OGL3 driver). Instancing is really nice feature, like eg. OGL3/4 driver, but currently my priority is finish iOS and Android ports. When these ports will be ready I'll help with an adding new features to an engine

[hendu]

The texture reloading is a must-have feature there, after having things draw properly. Otherwise things break on pausing etc.
Do you think adding that to the mobile branch will take long?

[Nadro]

I think that firstly we should implement PBO support. What about mobile branch? I think that in a first half of semptember it will be ready

[Simson]

Hello hendu,
I have tried this patch with Irrlicht SVN rev 4285 and that doesn't compile correctly with code::blocks under windows....
After I have declared glTexImage3D and glTexSubImage3D that compile fine but the sample doesn't compile with error :

screenquad.h|29|error: 'class irr::video::SMaterial' has no member named 'SkipArrays'|
screenquad.h|29|error: 'ESA_COLOR' was not declared in this scope|
screenquad.h|29|error: 'ESA_NORMAL' was not declared in this scope|
main.cpp|40|error: no matching function for call to 'irr::video::IVideoDriver::getTexture(irr::core::array<irr::core::string<char, irr::core::irrAllocator<char> >, irr::core::irrAllocator<irr::core::string<char, irr::core::irrAllocator<char> > > >&)'|
include\IVideoDriver.h|373|note: candidates are: virtual irr::video::ITexture* irr::video::IVideoDriver::getTexture(const irr::io::path&)|
include\IVideoDriver.h|385|note: virtual irr::video::ITexture* irr::video::IVideoDriver::getTexture(irr::io::IReadFile*)|

[hendu]

You can comment out the ESA/skiparrays lines. But the second error says you didn't patch your irrlicht, the patch is required for the demo to run.

[Simson]

I have patched my irrlicht svn version that why I wrote here
I think there's something missing in your patch....

[hendu]

The error is clear. Maybe you have an old library/headers somewhere.

[Simson]

I use the tortoise SVN apply patch function, maybe that doesn't work correctly, I'll try another tool.

the patched files are :
EDriverFeatures.h
CNUllDriver.cpp
CNUllDriver.h
COpenGLDriver.cpp
COpenGLDriver.h
COpenGLExtensionHandler.cpp
COpenGLTexture.cpp
COpenGLTexture.h

[hendu]

Doublechecked, one part was indeed missing. Please grab the added patch too.