Horde3D

Next-Generation Graphics Engine
It is currently 29.03.2024, 14:50

All times are UTC + 1 hour




Post new topic Reply to topic  [ 69 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject: Re: Texture Compression
PostPosted: 27.01.2009, 09:20 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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...

swiftcoder wrote:
My gut feeling is that we should strip the power-of-two conversion out of the engine, as it is a required part of the GL 2.0 spec, and the engine already specifies GL 2.0 as a requirement. Failing that, power-of-two conversion should be disabled for DDS, as it would require decompression. Additionally, DDS files should use their native cubemap support, while other textures continue to use the vertical cross.

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.

swiftcoder wrote:
The simplest way I see to implement this is to add an extra texture upload hook to the renderer, to support compressed textures. This way the DDS loader can be implemented without making huge changes to the existing hooks and loaders.

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 27.01.2009, 12:44 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
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...
Sounds good!

Quote:
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.
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.

Quote:
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.
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]


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 27.01.2009, 23:57 
Offline

Joined: 26.08.2008, 18:48
Posts: 120
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 28.01.2009, 02:15 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
attila wrote:
for the function signature: compression type, byte size could be merged to format(eg.: RGBA8,DXT1, ...) as in d3d.
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]


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 29.01.2009, 00:07 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
attila wrote:
I'm still interested in how do you plan to handle the texture v flip with compressed DDS?

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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 17.02.2009, 00:25 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 17.02.2009, 01:14 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
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 ;)

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

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 17.02.2009, 02:52 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
marciano wrote:
Having a separate text file which stores the meta-information for each texture is cleaner but makes things more complicated for artists.
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:
Code:
$startFrame = '000';
$endFrame = '009';
$hasAlpha = true;

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Texture Compression
PostPosted: 22.02.2009, 14:07 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 69 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 46 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group