Mass Effect Andromeda

[warrantyvoider]

https://pastebin.com/t3Ux7quQ dumped from memory, full texture format list! rick was right, ah well

[Hairless_Wookiee]

Didn't Rick post that info a couple of weeks back?

viewtopic.php?f=9&t=3971&p=22134#p22125

[warrantyvoider]

Didn't Rick post that info a couple of weeks back?

viewtopic.php?f=9&t=3971&p=22134#p22125

well then no one saw it, including me, because there are many format lists out there...


anyway, as im continue to research dds I had a simple idea: why not create a dds in the (now known) target format and size, and replace the pixel data? that lead me to the idea to make a GUI frontend for texconv, as it already supports many many formats and can read and write them, so heres my new tool hopefully it will help me to make correct headers for export





Somehow you can not use quotes in the output folder name, so you can not use folders with spaces in the path!

now on github: https://github.com/zeroKilo/DDSCreatorWV

greetz WV

[AnonBaiter]

Well, I've never thought of this before but...

Do you plan on implementing an header generator for your "DDS" tool? I say this because I have a lot of headerless files lying around, and I don't kow the resolution of them. For that end, I could experiment on trying to figure out exactly the correct image of these headerless DDS files.

[warrantyvoider]

it creates dds files, so it also creates dds headers, essentially click create, enter your target size, select target format and maybe force dx10 header, then replace the pixeldata in the created dds or just use the header for whatever

[AnonBaiter]

So I should just import raw data just fine?

[warrantyvoider]

not in my tool. I dunno what is so confusing:
1.you can load an image, bmp or dds
2.you can save that image to, again, bmp or dds
3.you can create a white bitmap with size X;Y as input

if you use option 3 and you know the format and size of your raw pixel data, you can create an empty, white bmp with that size, export is as dds in your prefered format. it creates a dds with a valid header, and you can use that header to add before your raw pixel data, to make a dds file out of that. ok sofar? if you dont know the size and just wanna test a bunch of bytes, you can replace the same amount of bytes of pixel data in that white dds you just created, with your test data. the result will look lineshifted, but you could see if color and co are ok, also guess the width of an image by the repeating pattern length

greetz

[AnonBaiter]

I think I get it now. Sorry I wasn't clear.

[warrantyvoider]

yay, seems I can finally make valid headers^^

[warrantyvoider]

wohoo, this actually works! added 4 more common dx10 format types to support! still far from done, but with the previous tool this should be solvable now



now on github

greetz WV

[BottonK]

yay, seems I can finally tried the Wealthy Affiliate make valid headers^^

Awesome, I'm gonna give this a try now then.

[Hairless_Wookiee]

It seems like format 66/BC7_UNORM textures are not extracting at full resolution, but rather the 4th mip. For instance, a 2048x2048 texture is extracting as 256x256, a 1024x1024 texture is extracting at 128x128. Format 67/BC7_SRGB textures are working properly, extracting at the full resolution.

[warrantyvoider]

It seems like format 66/BC7_UNORM textures are not extracting at full resolution, but rather the 4th mip. For instance, a 2048x2048 texture is extracting as 256x256, a 1024x1024 texture is extracting at 128x128. Format 67/BC7_SRGB textures are working properly, extracting at the full resolution.

well you can use my tool above to make me a better header if you think I set some flags wrong and tell me where it differs, also the code is open source. then currently the real first mip is calculated this way: sum the mip sizes from small to biggest until the sum matches the actual data length and take that last mip as new start. the firstMip variable in the res data is not always true, so should not be used.

greetz WV

[Hairless_Wookiee]

Here's the header results from the version exported by the MEA Tools vs resizing and re-exporting it from Photoshop and creating a dummy image in TexTools:

http://i.imgur.com/xaHYdxW.jpg

[warrantyvoider]

Here's the header results from the version exported by the MEA Tools vs resizing and re-exporting it from Photoshop and creating a dummy image in TexTools:

http://i.imgur.com/xaHYdxW.jpg

ah man, thats useful and I will look into it, but I also made a tool to display those infos... https://github.com/zeroKilo/DDSCheckerWV could you pls redo this with that tool? thanks

greetz

PS:am at work, so can only make testreleases here before I can commit it to git later

EDIT: comparing your hex by hand, my tool still exports fine, it doesnt matter that you create a 2048x2048 texture, if there is only data for a 256x256 texture available, I can not export more, its as simple as that. simply check DDS_header here

[Hairless_Wookiee]

I'm just going by the info panel in the Texture Plugin. It says a particular texture is 2k or 1K, but only exports a lower resolution, unlike the other formats. For instance:

Type : Texture2D
Format : 66 - 0x42 (supported) (BC7_UNORM)
Size X : 1024 (128)
Size Y : 1024 (128)
Depth : 1
Slice Count : 1
Mip Count : 11
Mip Start : 3
Mip 1 Offset : 0x000AE4F4
Mip 2 Offset : 0x000DA015
Mip Sizes :
-> 1024x1024 = 0x100000 bytes
-> 512x512 = 0x40000 bytes
-> 256x256 = 0x10000 bytes
-> 128x128 = 0x4000 bytes
-> 64x64 = 0x1000 bytes
-> 32x32 = 0x400 bytes
-> 16x16 = 0x100 bytes
-> 8x8 = 0x40 bytes
-> 4x4 = 0x10 bytes
-> 2x2 = 0x10 bytes
-> 1x1 = 0x10 bytes
= 0x155570 bytes

So I gather for whatever reason that it can't find the data for the higher resolutions.

[warrantyvoider]

you really dont like to read my posts, do you? that info you see there, is what is STORED in the res data, I just display whats stored as META DATA. it has a variable called firstMip which already shows you in the brackets the real size it would expect (because it may start with mip 1,2,3... and so on, instead of 0) and I additionally check for the real size before exporting. just sum the mip sizes up and compare at which level you would reach the amount of data in the chunk. also mip = resolution. if the original size was 2048x2048, it makes a 2048x2048mip, a 1024x1024mip, a 512x512mip, a 256x256mip AND SO ON. now they stored not the biggest mip plus all smaller ones, but started with a smaller one instead. so even if the meta data SAYS its a 2048x2048 texture and it SAYS it starts with mip 2 (which would be 512x512), doesnt mean there is that much data in the chunk! if there is only data for 256x256 and smaller, I can not magically find data that does not exist! Games are cooked! That means resolutions get downgraded to allow portability and what not, so on compiling of the resulting game, the engine decided which sizes it actually wants to store (no need for a 2048er texture, when the ingame object at best gets a handful rendered pixels on screen)

greetz

PS: take your own example:

...
Size X : 1024 (128)
Size Y : 1024 (128)
...
Mip Start : 3
...
Mip Sizes :
(0) -> 1024x1024 = 0x100000 bytes
(1) -> 512x512 = 0x40000 bytes
(2) -> 256x256 = 0x10000 bytes
(3) -> 128x128 = 0x4000 bytes
(4) -> 64x64 = 0x1000 bytes
(5) -> 32x32 = 0x400 bytes
(6) -> 16x16 = 0x100 bytes
(7) -> 8x8 = 0x40 bytes
(8) -> 4x4 = 0x10 bytes
(9) -> 2x2 = 0x10 bytes
(10) -> 1x1 = 0x10 bytes
= 0x155570 bytes

officially its a 1024x1024 texture, but it starts officially at mip 3, from the list below you can see, thats actually 128x128. now if you add all sizes from 10 to including 3, it >should< match the amount of data in the chunk, but it doesnt has to. it can have all mips, then the size would have to match 0x155570, it could also only have data for 64x64 and smaller, thats why you only know the real size after export. I could display the guessed mip start, but you can already see if from the preview, which is always the biggest resolution available

[warrantyvoider]

added BC5_UNORM support (format 63 - 0x3F), this was a bit tricky as you can not directly convert between that format and bmp (it only needs 2 bytes per pixel, bmp has 3 or 4) so I had to add a mid step in conversion and now it works^^


I also updated my DDSCreator tool, because you could surely create BC5 from bmp and save it to dds, but you couldnt directly load it back in until I added the midstep. it also has alot more options now


now on github!

greetz WV

PS: source

[warrantyvoider]

well I guess youve been waiting for this...

texture import and mod support! now on github

for now it only accepts a dds as input, which also has to match in data size and format, but with the ddscreator tool this should be no problem.
Happy Modding!




also added my first mod for testing here

greetz WV

[epyonx3]

This is really cool! Any chance this tool can extract audio from the game as well? Specifically conversational audio?