New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for compressed textures. #1522

Merged
merged 7 commits into from Sep 23, 2012

Conversation

Projects
None yet
5 participants
@fluffyfreak
Contributor

fluffyfreak commented Sep 18, 2012

Description:

Textures compressed using DXT1 or DXT5 take up less memory and are supported in hardware across almost all (any knwon exceptions?) graphics hardware. With the support of the GL_ARB_texture_compression standard graphics drivers are able to take an uncompressed texture and compress it in (near) realtime.

This patch adds support to for this realtime texture compression hopefully reducing the games video memory footprint and drastically reducing the bandwidth required for texturing during rendering.

Downsides:

In no particular order;

  • Loading time might be extended,
    • Not all drivers are equal in their compression performance.
  • Rendering performance might be impacted,
    • We texture our terrains in realtime and there might be negative performance from this though I haven't measured any yet,
  • Lack of support on some platforms or drivers,
  • Decrease in some texture quality,
    • DXTn formats are lossy and can cause "blocky" artefacts,
  • Potential rendering bugs caused by partial support of drivers,
  • Lack of control over which images/textures the effect is applied to,
    • It would be good avoid compressing GUI or other 2D textures but currently there is no support for this.

NB: I really am stretching to find all of these I don't think that they're as bad as I'm making them sound.

Results:

I've noticed no major rendering issues aside from the obvious decrease in the quality of textures across (laptop) ATi/AMD and (desktop) nVidia GPUs on Windows 7 64bit machines. These are however the only machines I have to test with currently.

Performance is hard to measure as is the actual decrease in memory consumption due to none standard GPU memory querying methods. Again unfortunately both of my platforms have more than enough memory for anything that Pioneer currently throws at them.

Cheers,

Andy

@Luomu

This comment has been minimized.

Show comment
Hide comment
@Luomu

Luomu Sep 18, 2012

Member

We texture our terrains in realtime

There are no textures on the terrains at all. It's all vertex colours.

Member

Luomu commented Sep 18, 2012

We texture our terrains in realtime

There are no textures on the terrains at all. It's all vertex colours.

Show outdated Hide outdated src/Pi.cpp
@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 18, 2012

Contributor

There are no textures on the terrains at all. It's all vertex colours.

I honestly hadn't checked that, we're not using texturing at all? What about the use terrain textures toggle?

All good points otherwise will make the changes now I'm back from food shopping :)

Contributor

fluffyfreak commented Sep 18, 2012

There are no textures on the terrains at all. It's all vertex colours.

I honestly hadn't checked that, we're not using texturing at all? What about the use terrain textures toggle?

All good points otherwise will make the changes now I'm back from food shopping :)

@Luomu

This comment has been minimized.

Show comment
Hide comment
@Luomu

Luomu Sep 18, 2012

Member

What about the use terrain textures toggle?

It uses some extra fractals to add more variation to the vtx colours.

Member

Luomu commented Sep 18, 2012

What about the use terrain textures toggle?

It uses some extra fractals to add more variation to the vtx colours.

@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 18, 2012

Contributor

Hmm, the perils of switching dev' machines. Seem to have mangled the line-endings (GameMenuView.h/.cpp) on one of my machines and committed it :(

Contributor

fluffyfreak commented Sep 18, 2012

Hmm, the perils of switching dev' machines. Seem to have mangled the line-endings (GameMenuView.h/.cpp) on one of my machines and committed it :(

@Luomu

This comment has been minimized.

Show comment
Hide comment
@Luomu

Luomu Sep 19, 2012

Member

Okay, this seems to work fine (latest gdebugger doesn't show compressed texture sizes but the saving should be sizable).

You still have wrong line endings src/LangStrings.inc.h, fix that and then this should be OK for merge.

Here's an example of noticeable compression artifacts (gradients compress especially badly):

So, maybe we want to add a compression hint to TextureDescriptor so UI textures can avoid this. Then they would be loaded uncompressed (I tried glHint(GL_TEXTURE_COMPRESSION_HINT, GL_NICEST), didn't help).

gl or glew functions in gameMenuView should be avoided, same deal as with #1385.

Member

Luomu commented Sep 19, 2012

Okay, this seems to work fine (latest gdebugger doesn't show compressed texture sizes but the saving should be sizable).

You still have wrong line endings src/LangStrings.inc.h, fix that and then this should be OK for merge.

Here's an example of noticeable compression artifacts (gradients compress especially badly):

So, maybe we want to add a compression hint to TextureDescriptor so UI textures can avoid this. Then they would be loaded uncompressed (I tried glHint(GL_TEXTURE_COMPRESSION_HINT, GL_NICEST), didn't help).

gl or glew functions in gameMenuView should be avoided, same deal as with #1385.

@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 19, 2012

Contributor

Yeah I knew about the artefacts, just taken a look at all of the texture builder and descriptor stuff now however I have an interview so it'll have to wait until this afternoon :)

Cheers.

Contributor

fluffyfreak commented Sep 19, 2012

Yeah I knew about the artefacts, just taken a look at all of the texture builder and descriptor stuff now however I have an interview so it'll have to wait until this afternoon :)

Cheers.

@s20dan

This comment has been minimized.

Show comment
Hide comment
@s20dan

s20dan Sep 19, 2012

Contributor

I'd rather this was an option like in other games, for those of us with enough VRAM for this to make no difference whatsoever ;)

Ok i guess I should have read it more thoroughly (It is an option). Nice work :)

Contributor

s20dan commented Sep 19, 2012

I'd rather this was an option like in other games, for those of us with enough VRAM for this to make no difference whatsoever ;)

Ok i guess I should have read it more thoroughly (It is an option). Nice work :)

@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 19, 2012

Contributor

@s20dan
Yeah don't worry it is optional, there's even a shiny new toggle button on the settings screen ;)
Performance improvements wouldn't be due to the amount of memory in many cases but the bandwidth used by texture access during pixel shaders. Either way, toggle-able.

Contributor

fluffyfreak commented Sep 19, 2012

@s20dan
Yeah don't worry it is optional, there's even a shiny new toggle button on the settings screen ;)
Performance improvements wouldn't be due to the amount of memory in many cases but the bandwidth used by texture access during pixel shaders. Either way, toggle-able.

fluffyfreak added some commits Sep 19, 2012

Remove the check that conditionally adds the texture compression.
Removes the dependency on Glew from GameMenuView.
Decided to do this rather than query the renderer as it is more consistent with the other toggle buttons.
Added support for texture compression to the texture descriptor and T…
…extureBuilder classes. This means that most textures will request their textures are compressed whilst UI textures won't be.
@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 19, 2012

Contributor

@Luomu
In the call glHint(GL_TEXTURE_COMPRESSION_HINT, GL_NICEST) the GL_NICEST will only affect the internal compression method chosen and it can only do so much. Blocking is almost inevitable on a lot of textures when compressed using the DXTn formats.

I think the nVidia compressor is based on libSquish, in fact they've contributed code back too it, I know that the SPURS based PS3 library is a cut down version of libSquish as well. Since it's open source I imagine they're all based on it or something similar... which means there's only a limited number of options to choose from (that are easy to implement on GPU/SPU) and some of the best quality ones are already blindingly quick so I doubt the hinting does very much, if anything.

Nevermind all that stuff I assume you already know anyway :D (I mention it more for others reference)

I've now implemented your suggestions, this mean storing another parameter in both the TextureDescriptor and TextureBuilder classes but appears to be the correct way of doing it.

I decided to remove entirely the conditional adding of the texture compression toggle and just always display it, just like the shader toggle is always present even on machines with only FFP support.

Contributor

fluffyfreak commented Sep 19, 2012

@Luomu
In the call glHint(GL_TEXTURE_COMPRESSION_HINT, GL_NICEST) the GL_NICEST will only affect the internal compression method chosen and it can only do so much. Blocking is almost inevitable on a lot of textures when compressed using the DXTn formats.

I think the nVidia compressor is based on libSquish, in fact they've contributed code back too it, I know that the SPURS based PS3 library is a cut down version of libSquish as well. Since it's open source I imagine they're all based on it or something similar... which means there's only a limited number of options to choose from (that are easy to implement on GPU/SPU) and some of the best quality ones are already blindingly quick so I doubt the hinting does very much, if anything.

Nevermind all that stuff I assume you already know anyway :D (I mention it more for others reference)

I've now implemented your suggestions, this mean storing another parameter in both the TextureDescriptor and TextureBuilder classes but appears to be the correct way of doing it.

I decided to remove entirely the conditional adding of the texture compression toggle and just always display it, just like the shader toggle is always present even on machines with only FFP support.

@Ae-2222

This comment has been minimized.

Show comment
Hide comment
@Ae-2222

Ae-2222 Sep 20, 2012

Contributor

hopefully reducing the games video memory footprint

There are probably a few other things that can be done, if you are concerned, such as sending normals as signed bytes/shorts instead of floats or packing 8 bit values into floats etc. It's something I had as a to do after the new terrain system is completed (on the other hand also queued are things like introducing new vertex attributes, for things like fractal city lights visible from space, so overall video memory use won't go down :) .. though we might have an option to disable features ).

I mention it more for others reference

Reasoning/links to papers are handy - especially in areas like graphics programming which is mostly only of use to game development, as Pioneer people tend to be from wildly different fields..including completely unrelated to IT like science/engineering, let alone graphics programming (you're the only professional game dev to work on Pioneer so far).

Even though Pioneer devs tend to have background/problem solving skills to do things like create an entirely new compression algorithm if needed, they tend to be often working from first principles. One of the main goals of the review system is to reduce the bus factor:)

Contributor

Ae-2222 commented Sep 20, 2012

hopefully reducing the games video memory footprint

There are probably a few other things that can be done, if you are concerned, such as sending normals as signed bytes/shorts instead of floats or packing 8 bit values into floats etc. It's something I had as a to do after the new terrain system is completed (on the other hand also queued are things like introducing new vertex attributes, for things like fractal city lights visible from space, so overall video memory use won't go down :) .. though we might have an option to disable features ).

I mention it more for others reference

Reasoning/links to papers are handy - especially in areas like graphics programming which is mostly only of use to game development, as Pioneer people tend to be from wildly different fields..including completely unrelated to IT like science/engineering, let alone graphics programming (you're the only professional game dev to work on Pioneer so far).

Even though Pioneer devs tend to have background/problem solving skills to do things like create an entirely new compression algorithm if needed, they tend to be often working from first principles. One of the main goals of the review system is to reduce the bus factor:)

@fluffyfreak

This comment has been minimized.

Show comment
Hide comment
@fluffyfreak

fluffyfreak Sep 20, 2012

Contributor

Luomo isn't a game developer? Thought that he was/is.

Ok well the reasons are pretty simple:

  1. Consume less video memory overall - less paging,
  2. Use a compressed format supported in GPU hardware - to use less GPU bandwidth during pixel shader,
  3. Better GPU texture cache utilisation and access.

Longer explanation here: Texture Compression

Since we're only supporting OpenGL it only makes sense to use the most common DXT1 and DXT5 formats which so far I'm just having the openGL driver build from RGB and RGBA respectively.

DXT1 does actually support RGBA but it's only 1 bit alpha so we'll be using DXT5 instead.

DXT1 textures should compress down to 1/8th of their original size and DXT5 to 1/4th with varying levels of minor visual artefacts.

There are other things that can be done, but they're dwarfed in my experience by textures. Now, we have a slightly crazy terrain system that produces huge amount of geometry, which is unusual, but even so my gut feeling is that textures will probably still dominate.

Contributor

fluffyfreak commented Sep 20, 2012

Luomo isn't a game developer? Thought that he was/is.

Ok well the reasons are pretty simple:

  1. Consume less video memory overall - less paging,
  2. Use a compressed format supported in GPU hardware - to use less GPU bandwidth during pixel shader,
  3. Better GPU texture cache utilisation and access.

Longer explanation here: Texture Compression

Since we're only supporting OpenGL it only makes sense to use the most common DXT1 and DXT5 formats which so far I'm just having the openGL driver build from RGB and RGBA respectively.

DXT1 does actually support RGBA but it's only 1 bit alpha so we'll be using DXT5 instead.

DXT1 textures should compress down to 1/8th of their original size and DXT5 to 1/4th with varying levels of minor visual artefacts.

There are other things that can be done, but they're dwarfed in my experience by textures. Now, we have a slightly crazy terrain system that produces huge amount of geometry, which is unusual, but even so my gut feeling is that textures will probably still dominate.

@johnbartholomew johnbartholomew merged commit 1c8d978 into pioneerspacesim:master Sep 23, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment