2019-12-12 02:50 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006044Spring engineGeneralpublic2018-11-08 20:23
Assigned ToKloot 
Product Version104.0 +git 
Target VersionFixed in Version104.0 +git 
Summary0006044: .DDS file using 3dc compression doesn't load
DescriptionA DDS texture exported with the .3dc compression format isn't loaded correctly by the engine, resulting in mangled output.

Normal maps are very sensitive to compression, thus using a DDS with the common DXT5 compression results in multiple artifacts (check attached screenshots).

.3dc compression is the best standard for normal maps in DXTs (source: http://wiki.polycount.com/wiki/Normal_Map_Compression), it would be great having support for it in the engine to keep loading times as low as possible.
Steps To Reproduce1. Define any model with a normal map texture in .dds format with 3dc compression.
2. Load in game
3. Watch mangled normals in the resulting texture
Additional Informationhttp://wiki.polycount.com/wiki/Normal_Map_Compression
Checked infolog.txt for Errors
Attached Files




Kloot (developer)

Spring's DDS loader predates the BC5 (ATI2N/3DC) format by several years, but I don't know of a recent open-source (and compatibly licensed) library that supports it. suggestions welcome if you have any.


lhog (reporter)

https://github.com/g-truc/gli perhaps?


Kloot (developer)

gli builds are available at https://springrts.com/dl/buildbot/default/gli_dds/ , please test them extensively.


lhog (reporter)

Hi Kloot!

Thanks for putting stuff together. I've run basic tests on the new branch engine (104.0.1-872-gfd30f2e) and it seems like 3Dc textures are not loaded correctly (I observe pitch black normal map), while uncompressed DDS texture is loaded ok.

For the reference I'm attaching both files. I intend to test other DDS encoding as well, once they are made available to me.


lhog (reporter)

Uncompressed one.


lhog (reporter)

DXT1 and DXT5 encodings seem to get loaded fine.

Unsure if it's related but I see a few other issues:
1) I see a red square instead of commander picture. Commander buildpic is stored in PNG AFAIK, so I'm not sure why it happens. It's also the only unit type there this glitch is observed. Latest maintenance (104.0.1-868-g8294eeb) works fine. See screenshots.
2) Striderhub, for example, look dull, probably something to do with misread Texture2 for this unit. My DDS viewer says it's format is BC1_TYPELESS. https://github.com/ZeroK-RTS/Zero-K/blob/master/unittextures/striderhub2.dds


Kloot (developer)

Last edited: 2018-11-07 19:38

View 5 revisions

1) is trivial to fix
2) according to gli, the formats are



Jeffy_NormalHeight_1k_3dc_mips.dds: FORMAT_RG_ATI2N_UNORM_BLOCK16 / GL_COMPRESSED_RG_RGTC2

3) Jeffy_NormalHeight_1k_3dc_mips.dds substituted for striderhub's texture 1 and rendered with just fragColor = diffuseColor also ends up pitch-black for me; seemingly gli can not (yet?) vertically flip 3DC-compressed textures which Spring does by default for all non-buildpic dds files

try build 874-g3d52735 when it gets here.


lhog (reporter)

There are couple good news:
1) Red icon is gone
2) 3Dc DDS loads up and I can see normals, although it requires flip, like you outlined. Normal "colors" look weird (see pic), though it likely has something to do with swizzles done during compression.

I'll open up a ticket on gli github page to see what they have to say about 3Dc flip-ability.

P.S. Striderhub's look was caused by an extremely peculiar stuff, I spent last couple of hours on. My PBR framework created debug definitions for shaders automatically like below (here TANGENTNORMALS debug was flagged in Lua).

Next I had #if switch to determine which info to draw

  gl_FragColor = vec4(baseColor.rgb, 1.0);
  gl_FragColor = bla;
  gl_FragColor = blabla;

Apparently(!), if stuff defined like that, then it works for this shader (tangent normals are drawn correctly), but somehow it totally knocks out default lighting shader, which was used to shade striderhub and other models. It's 100% reproducible and I have absolutely no idea why it was happening. After it became apparent that something was wrong with #defines I changed the Lua code, so the output has become:
I didn't check all debugs, but change of #define order apparently fixed the issue with striderhub rendering.

Thanks a lot!


lhog (reporter)

Just to illustrate my P.S.
screen00055.png - normal PBR rendering of Jeffy
screen00056.png - debug output of tangent space normals is active. As you can see somehow default model lighting is affected. In the same time commander rendering, which is performed with another shader from CUS framework, is not affected.


Kloot (developer)

unfortunately there is no way to inspect a shader after the GLSL preprocessor has gone over it, but striderhub definitely also uses a custom normalmapping shader (because /luarules disable changes its appearance) which may be relevant.

I'll give this a few weeks before merging into develop/maintenance, happy testing itmt.

-Issue History
Date Modified Username Field Change
2018-09-19 01:49 MaDDoX New Issue
2018-09-19 01:49 MaDDoX File Added: dds_issue.zip
2018-09-19 01:49 MaDDoX Tag Attached: texture
2018-09-19 13:11 Kloot Note Added: 0019359
2018-09-19 18:23 abma Status new => feedback
2018-11-06 11:51 lhog Note Added: 0019478
2018-11-06 20:47 Kloot Assigned To => Kloot
2018-11-06 20:47 Kloot Status feedback => assigned
2018-11-07 02:15 Kloot Status assigned => feedback
2018-11-07 02:15 Kloot Note Added: 0019479
2018-11-07 13:03 lhog File Added: Jeffy_NormalHeight_1k_3dc_mips.dds
2018-11-07 13:03 lhog Note Added: 0019481
2018-11-07 13:03 lhog File Added: Jeffy_NormalHeight_1k_uc_mips.dds
2018-11-07 13:04 lhog File Added: Jeffy_NormalHeight_1k_uc_mips-2.dds
2018-11-07 13:04 lhog Note Added: 0019482
2018-11-07 15:19 lhog Note Added: 0019483
2018-11-07 15:23 lhog File Added: screen00045_.png
2018-11-07 17:34 Kloot Note Added: 0019485
2018-11-07 17:49 Kloot Note Edited: 0019485 View Revisions
2018-11-07 18:19 Kloot Note Edited: 0019485 View Revisions
2018-11-07 18:22 Kloot Note Edited: 0019485 View Revisions
2018-11-07 19:38 Kloot Note Edited: 0019485 View Revisions
2018-11-08 00:38 lhog File Added: screen00054.png
2018-11-08 00:38 lhog Note Added: 0019487
2018-11-08 00:54 lhog Note Added: 0019488
2018-11-08 00:54 lhog File Added: screen00055.png
2018-11-08 00:54 lhog File Added: screen00056.png
2018-11-08 20:23 Kloot Note Added: 0019500
2018-11-08 20:23 Kloot Status feedback => resolved
2018-11-08 20:23 Kloot Resolution open => fixed
2018-11-08 20:23 Kloot Fixed in Version => 104.0 +git
+Issue History