Models/textures

[emoose]

Does anyone know the status of model/texture modding? I haven't really kept up to date on those, IIRC the original DQXI used some strange maybe-Criware format that UModel didn't support, has that changed since then?

I did see some talk on the UModel forum about it, but it wasn't clear if there's actually any support for either OG or S now... and also didn't see anything about replacements there neither.

Would really like to find some way to get OG models/textures in here, I've never been good at working on 3D-graphics related stuff though, but usually pretty good at figuring out file-formats, maybe that's the main thing that's changed here? (and the changed texture packing/resolution decrease ofc, but I think if OG models could somehow be used that shouldn't be a problem)

[mike9k1]

That's a pretty lengthy topic, haha.

UModel supports both DQXI's. OG uses Tekken 7 settings in vanilla umodel (4.13 w/ Event Driven Loader backported from 4.14, so most tools can pretty much treat it like 4.14 IIRC) -- late in OG's life, we could manage to cook native textures, etc using a source-build of 4.14 (as binary builds in that version still did not support Event Driven Loader), we still have it hosted here

For Definitive Edition, a custom version of UModel was commissioned for the Switch version. Cooks can be done in vanilla Unreal Editor 4.18 this time. However, this time a script was needed to adjust the offsets in the cooked files to make them compatible with the game. More details on all that here: https://sites.google.com/view/dqxi-commands/tutorials/creating-mods

We have not yet managed to get custom models into the game (nor OG models for that matter). It almost looks like we could use a script similar to the one we use to adjust the offsets in cooked textures, but I haven't had the time to work on making that script compatible with model files. It does look like there was some change in formatting between the two versions, but I suspect it to be a situation similar to the texture files. In DE, they changed the texture formatting to PF_BC7 for most everything, whereas in OG the texture formatting they used was PF_DXT5. Definitive Edition still supports PF_DXT5 cooked textures, however. (Although I will say that the format change threw me off when I was first researching the offset change).

For anything else, we have a specific channel dedicated to all this on the Modding Community Discord (linked in modding tutorial above).

[emoose]

Hmm, offset changes remind me of what UnrealFinderTool needed for DQXIS to work, for that the UE 4.18 UObject class that almost everything in UE4 derives from had 0x10 bytes added to the end of it for some reason (haven't checked what those are for yet though)

I doubt raw UObjects are stored in the uasset files so probably isn't the cause of it, but I guess the actual issue is related, they probably added some extra field to a class somewhere that ends up being serialized into the uasset, think the uasset should have enough info inside it to work out what class/struct was edited that way though, could probably add that to the UE4.18 src and make another custom build for DQXIS (hopefully models might be something similar too, or could be a case of 4.13->4.18 differences maybe...)

Neat about Umodel working, do you know if normal UE ever worked with models using those settings too? If not I think most/all of UModel code is at https://github.com/gildor2/UEViewer, maybe could be merged into UE with some work.

I'll have to download the OG edition again and try comparing some things, just waiting on a new drive to get here first (2 weeks and still waiting >.>)

E: hm, looked into the 0x10 bytes in UObject, seems to hold an FName that has stuff like :C010IE_C786T1W0P1S000 or :C010IE_C793T0W0P1S010, any ideas what those are for? Seems like a kind of ID or serial number of some sort Ah might not be an FName actually, nvm

[mike9k1]

Gonna go ahead and drop this here: https://www.nexusmods.com/dragonquestxisdefinitiveedition/mods/22

[emoose]

Gonna go ahead and drop this here: https://www.nexusmods.com/dragonquestxisdefinitiveedition/mods/22

Nice! Glad to see some progress is being made with it. It's too bad about the outlines, maybe merging some of the SDK stuff with UE4.18.3 could help with that, I'm not really sure how much work it'd need though.

Finally got a new drive so I can start experimenting with the UE4 src, will probably host a DQXI-fork of it on github if I'm able to.

Speaking of forks, do you know if the UModel-dq11 fork is required for viewing DQXIS models, or was that just for switch? I couldn't find where it was posted originally, not sure if the source is available for it anywhere neither :/

[mike9k1]

Speaking of forks, do you know if the UModel-dq11 fork is required for viewing DQXIS models, or was that just for switch? I couldn't find where it was posted originally, not sure if the source is available for it anywhere neither :/

It's required for the PC port of DE as well. It was originally posted here: https://www.gildor.org/smf/index.php?topic=6325.45

( At least, i'm fairly certain that the version we use is basically identical: https://cdn.discordapp.com/attachments/736008414639161403/788424940944490496/dq11s_tools_pack_1.zip )

I don't think there was any source provided (aside from some explanation from Gildor).

[emoose]

Well I made a start on the UE4 fork: https://github.com/emoose/DQXIS-UE4

So far it includes the added USkeletalMesh properties, the FTexturePlatformData change that Gildor mentioned, and the pak file obfuscation (also added code to UnrealPak which should let it create obfuscated paks that DQXIS works with, but haven't tested it yet)

There's also a change to UObject so that classes/structs created by this should mostly match the size of DQXIS versions, should make it easier to compare structs in the PDBs from this against the DQXIS-SDK structs.

Of course there's still a lot of other things that need to be added, eg. SkeletalMeshes from DQXIS don't seem to load currently (SK_P001.uasset seems to break inside USkeletalMesh::Serialize - couldn't see any difference in DQXIS's Serialize func though...), it did seem to load the files that SK_P001.uasset depended on fine at least.

I'm not sure if DQXIS textures/materials are working yet neither (really not that experienced with UE4's editor...), would appreciate anyone trying it out or adding any improvements.

(also for working with DQXIS files, you might need to change the UE4 version fields at uasset 0x8 to 60 03 00 00 02 02 00 00, otherwise I think editor refuses to try loading it - maybe this can be edited in our fork, hm)

[emoose]

BTW @mike9k1 I was wondering if you know what the cook-fix-uasset/uexp scripts are changing, it seems like uasset one is updating 0xA9 in the uasset header (BulkDataStartOffset?), and [length - 92], but do you know what they're changing them for? The uexp one seems to be changing any PF_ string in the uexp to be nulled out instead, is that right?

Also is there any chance you could upload a uasset/uexp that works with/needs to be fixed with those scripts?

(I'm wondering if the FTexturePlatformData change Gildor mentioned is related to these at all, adding the field he mentions should shift the uasset bytes over, doesn't look like the cook-fix scripts are moving any bytes though so maybe this isn't related... would be nice if we can find what UE4 code needs fixing though)

E: oh I think I might understand now, the cook-fix-uexp is adding 4 0x00 bytes after any PF string, and then cook-fix-uasset is updating sizes inside uasset header, that right? The field before the one added in FTexturePlatformData is an EPixelFormat field, so maybe it does change the same thing the cook-fix scripts are fixing... wish I knew how to use UE4's editor so I could actually try it out ;;

[mike9k1]

BTW @mike9k1 I was wondering if you know what the cook-fix-uasset/uexp scripts are changing, it seems like uasset one is updating 0xA9 in the uasset header (BulkDataStartOffset?), and [length - 92], but do you know what they're changing them for? The uexp one seems to be changing any PF_ string in the uexp ~to be nulled out instead~, is that right?

Also is there any chance you could upload a uasset/uexp that works with/needs to be fixed with those scripts?

(I'm wondering if the FTexturePlatformData change Gildor mentioned is related to these at all, adding the field he mentions should shift the uasset bytes over, ~doesn't look like the cook-fix scripts are moving any bytes though~ so maybe this isn't related... would be nice if we can find what UE4 code needs fixing though)

E: oh I think I might understand now, the cook-fix-uexp is adding 4 0x00 bytes after any PF string, and then cook-fix-uasset is updating sizes inside uasset header, that right? The field before the one added in FTexturePlatformData is an EPixelFormat field, so maybe it does change the same thing the cook-fix scripts are fixing... wish I knew how to use UE4's editor so I could actually try it out ;;

You are pretty much spot-on with what the cook fixer scripts do :)

I'll attach a couple sample sets of files- one from before and one from after (and i'll go ahead and throw the source file in as well).

This one is a purple variant of Hero's hair (just the one I have immediately on hand, meant for use with Project Rebuild):

After cook, pre-fixer: T_P001_Hair_E001_CS01_C_pre-fixer.zip

After cook + fixer: T_P001_Hair_E001_CS01_C_post-fixer.zip