March 28, 2024, 20:40
bigger smaller reset     1020px Wide width Full width Reset   * *

Gildor's Forums

  Homepage Facebook Read news on Twitter Youtube channel Github page
Welcome, Guest. Please login or register.
Did you miss your activation email?

« previous next »
Print
Author Topic: DDS Texture export with color smudges and incorrect header (Injustice Android)  (Read 6627 times)
North
Newbie
*
Posts: 4


View Profile
« on: September 10, 2014, 00:36 »

I exported this files from the android cooked data files. I had to fix the headers first to get the correct texture (wrong texture size, bits per pixel and RGBA masks). The java code that fixed it is below.

Anyhow, the problem is that the textures have smudges of color on places that should have no color. Also, this smudges seem to be in the same color palete as the correct part of the texture. What I wanted to know is if the files are like this in the original or something went wrong.

Thank you.



Code:
       RandomAccessFile rFile = new RandomAccessFile(file, "rw");

        byte[] value = new byte[1];

        value[0] = 0x10;
        rFile.seek(0x50);
        rFile.write(value);

        value[0] = 0x20;
        rFile.seek(0x58);
        rFile.write(value);

        value[0] = (byte) 0xFF;
        rFile.seek(0x5C);
        rFile.write(value);
        rFile.seek(0x61);
        rFile.write(value);
        rFile.seek(0x66);
        rFile.write(value);
        rFile.seek(0x6B);
        rFile.write(value);
« Last Edit: September 10, 2014, 09:49 by North » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #1 on: September 10, 2014, 10:55 »

Thanks, I fixed that. By the way I think you filled wrong "flags" value (at offset 0x50) - value 0x10 means
Code:
/*
 * The surface is indexed into a palette which stores indices
 * into the destination surface's 8-bit palette.
 */
#define DDPF_PALETTEINDEXEDTO8                  0x00000010l

Could you tell me, what happened when you used DDS files with all these fields unset?

I think that color patterns in completely transparent areas created by DDS encoder program. I think these are used for better mipmap generation.
Logged
North
Newbie
*
Posts: 4


View Profile
« Reply #2 on: September 10, 2014, 12:12 »

The value at 0x50 is to fix the size.  Previously it was 512 * 512 (one byte per pixel). I changed it to 512 * 512 * 4 (4 bytes per pixel).

At 0x58 I've set the bitsPerPixel to 32.

The next 4 values are the masks for R, G, B and A: 0xFF000000, 0x00FF0000, 0x0000FF00, 0x000000FF

Before fixing the header, the image displayed only used 1/4 from the image data and it was all corrupted. It used 8 bits per pixel to display it (instead of 32).

Here is how the image is originally exported.

If you want, I can upload the data files I used to export this images from.

Is there anything I can do to remove the smudges programatically?
« Last Edit: September 10, 2014, 12:17 by North » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #3 on: September 10, 2014, 12:29 »

The value at 0x50 is to fix the size.  Previously it was 512 * 512 (one byte per pixel). I changed it to 512 * 512 * 4 (4 bytes per pixel).
Isn't 'size' at offset 0x4C? (I double-checked nvtt code before write this). Offset 0x50 contains DDSPixelFormat::size, which always should contain value 32.
Quote
Is there anything I can do to remove the smudges programatically?
You may check alpha channel, and set color to 0,0,0 when alpha is 0.
Logged
North
Newbie
*
Posts: 4


View Profile
« Reply #4 on: September 10, 2014, 13:24 »

You are right about the 0x50 value. It should be 32(0x20). In the original it was set to 04. I don't know why but changing it to 0x10 fixed the image for me. Now I changed it in my code to 0x20. Thank you for pointing this out to me.

Regarding the smudges, I'll try it out and let you know how it works. Thank you for your help.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #5 on: September 10, 2014, 13:30 »

If you didn't notice, I've updated umodel 2-3 hours ago (probably there's no reason to use a program for DDS header postprocessing now?)
Logged
North
Newbie
*
Posts: 4


View Profile
« Reply #6 on: September 10, 2014, 14:49 »

I just tried it and the export is perfect now. Even the smudges are no longer there. Thank you.

LE:  If I skip the -dds flag the tga images look just like the dds before the fix (only using 8 bits per pixel instead of 32).
« Last Edit: September 10, 2014, 14:51 by North » Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #7 on: October 29, 2014, 17:37 »

I checked non-Android DDS files exported by UModel and found that all DDS viewers which I have now crashed with all .dds files! I did some research and found that changes to UModel which I made during this discussion caused exporting incorrect DDS files: DDS header will never contain both fourcc and color masks - at least those which produced with NVIDIA and Microsoft DXT tools. So, I decided to revert these changes. By the way I'm going to do extra research - I'm downloading Android "Injustice" now, so I'll check why Android textures are exported as DXT, while they're most likely not in compressed format.
Logged
Gildor
Administrator
Hero Member
*****
Posts: 7978



View Profile WWW
« Reply #8 on: October 31, 2014, 21:01 »

I've improved Android support. Algorithm of saving textures to file wasn't changed, by the way I performed a number of tests with PVRTC, DXT and ETC cooked games, and everything works well
https://www.facebook.com/media/set/?set=a.813543672022768.1073741827.176350295742112&type=1
Logged
Print 
« previous next »
Jump to:  

Powered by SMF | SMF © 2006-2009, Simple Machines LLC
Leviathan design by Bloc | XHTML | CSS