Horde3D

We plan to have dds support for Beta3, actually it is the final larger point that is still open for that release. So we will take care of it in the next time...


A question for discussion is if we should continue supporting the cross cubemap format or just use dds for cubemaps since they are actually a very special kind of texture (ATI CubeMapGen can be used to convert to dds cubemaps). Skyboxes do not have to be cubemaps so they can still use a cross (horizontal or vertical) as a regular 2D texture with the appropriate texture coordinates.


Either that or we just modify the existing texture upload function to be a bit more general (that's what I prefer). The dds loading code can be called before the other texture loading code, so dds will be the fastest path.

Sounds good!

There will always be people who don't want to use DDS, for one reason or another. Also remember that while vertical cross wastes no disk space with PNG files, it does waste a lot with DDS, as well as occasionally introducing compression artefacts at the edges.

My concern is that it will have to be made considerably more general. In particular, that function signature is already pretty complicated, and compressed textures require at least 3 other parameters (compression type, byte size, and number of mipmaps).

_________________
Tristam MacDonald - [swiftcoding]

Dark_Kilauea: I'm glad that my patch worked for you. I've already modified that condition too, because some texture used different flags.

I'm looking forward a more robust solution for this in the beta3. (and of course the optimization i've read of in other threads)

Marciano: I prefer using DDS for cubemaps. To be honest, I prefer using (precompressed)dds for every texture, except GUI.

for the function signature: compression type, byte size could be merged to format(eg.: RGBA8,DXT1, ...) as in d3d.

I'm still interested in how do you plan to handle the texture v flip with compressed DDS?

Not that sort of byte size - I mean the size of the compressed image in memory. For uncompressed textures this is trivially computed by width x height x bytes/pixel, but for textures with optional compression, mipmaps and cubemaps, it isn't quite as straightforward.

_________________
Tristam MacDonald - [swiftcoding]

Yeah, that is still an open issue. Flipping dds at load time without decompressing them is possible in many cases (http://users.telenet.be/tfautre/softdev/ddsload/explanation.htm) but it is not trivial and would take some of the performance advantage.
I would say we change Horde's convention so that the texture orientation is interpreted as in d3d. This means that texture v-coordinates need to be flipped in GLSL shaders (which is cheap). The not-so-nice thing is that render target textures will still follow the opengl orientation.

I had a discussion with Volker about some of the open issues related to the dds support. Here are the results in an OpenGL extension discussion-like style

Should we continue support for non-dds textures?
Yes. Limiting textures to solely dds would be too restrictive and unconvenient for most users, especially for small and quick projects.

Should we merge Texture2D and TextureCube to a single Texture resource type?
Yes. The type can be considered as an attribute like the texture format. This makes sense, since before loading a dds image, it is not clear which type (2D or cube map) it has. Furthermore, this makes it easier to support additional texture types like 3D or texture arrays in the future.

Should we keep POT conversion of NPOT textures?
No. It has several issues which make it hacky and elusive, e.g. dynamic texture update does not work with scaled textures. Conversion to power-of-two was implemented for older ATI cards for a specific legacy project. Horde has GL 2.0 as minimum requirement and so NPOT should be supported by the hardware. If non-standard conformant hardware is targeted users should be aware of the limitations of those. So they should create POT textures for old ATI hardware or have a preprocessing tool to do the POT conversion. For platforms that do not have guaranteed NPOT support (e.g. OGL ES 2.0) the texture upload function of the rendering backend can do the conversion transparently.

Should we continue support for cubemaps defined as vertical cross?
No. Cube maps are a very special and rather seldom used texture type. DDS offers a cleaner and more standardized way to store cubemaps. There are free tools available to create dds cubemaps (e.g. NV photoshop dds plugin and ATI cubemapgen) and it would be easy to write an external tool which converts a vertical cross to a dds cube map. This fits more to the Horde philosophy of having a single way of doing things in the core and adding more options through a utility/convenience layer. Furthermore, just having the dds cube map format encourages the use of a build process for converting source data to a platform-specific target format. This process is essential for larger professional productions and a good practice for small projects.

How should texture properties (like mip map generation and compression) be specified for non-dds textures?
Probably with naming conventions, possibly interpreted by the utility library. We don't like naming conventions so much but all other options are even worse. Storing the info in the materials is not clean because two materials could have different configurations for a single texture. Furthermore, it would be impossible to load a texture directly without a material. Having a separate text file which stores the meta-information for each texture is cleaner but makes things more complicated for artists.

That looks like a solid discussion - should make implementation a little clearer

_________________
Tristam MacDonald - [swiftcoding]

I don't think that this would be any more complicated than a naming convention.

At one of my old jobs, we used a similar system - artists would create a text file with the same name as their asset (but different extension) containing file properties.

e.g. MyAnimation000.tga is paired with MyAnimation000.php, which contains:

Obviously a Horde solution would use XML for these files instead of PHP though!

The DDS loading code is in the svn now.

Since there is no real agreement about the naming convention, we left it out for the moment. We keep the resource flags (NoTexCompreession, NoTexMipmaps) instead, so everyone can use whatever he likes for his project (naming convention implemented in loadResourcesFromDisk or additional description file). The texture configuration can also still be done in the material files as before.