Texture system redesign

[gecko0307]

Dagon's current texture system is cumbersome. From the beginning it was based on dlib.image, so texture loader (dagon.resource.texture) first creates an image object, then Texture object from it. Because usual SuperImage by itself isn't quite suited to store GPU-specific data, specialized image interfaces are used in some cases: ContainerImage for DDS and SuperHDRImage for Radiance HDR. This makes texture initialization code very complicated and hard to maintain.

Some observations and design decisions:

• OpenGL supports a wide variety of specialized image formats, including floating-point and compressed ones. Same is true for popular texture containers, DDS and KTX. dlib.image, on the contrary, is best suited for working with 8-bit RGB and RGBA that are used in standard image formats such as PNG and JPEG. This suggests that SuperImage generally shouldn't be used to load textures. There should be universal Texture class to store texture data directly without additional layers of abstraction. Pixel access interface, like in SuperImage, is not needed for textures - they are only for intermediate storage, so they should keep only metadata and raw bytes of the image.
  • For sampling / pixel access, shader-based function can be used
• Image decoding will be based on stb_image and dlib.image.io.hdr. DDS loader should be rewritten to load directly to Texture object.
• Texture class should support what OpenGL supports, not what image containers support. Container loader is responsible to adapt its input to the engine, not the other way around, like in current implementation.
• Texture class should support cubemaps and 1D/2D/3D image data. Currently cubemaps are handled separately from ordinary textures, and the engine doesn't support 1D and 3D textures, while DDS, for example, supports them.
• Textures decoded from standard formats can be cached to disk for faster loading.

This issue is addressed in texture branch.