Maybe there's a lack of vertex data about 3dmigoto HOT 10 OPEN

What game is this from? I'm guessing from some of the quirks I'm seeing here that it's probably Unreal Engine, which has a bunch of problems that complicate matters working with the blender addon:

• Unreal often uses the generic name "ATTRIBUTE" (instead of "POSITION", "NORMAL", "TEXCOORD", etc), so the script cannot tell what inputs are what and doesn't know what to do with any of the data. I guess you already dealt with this - it looks like you renamed the semantics in your vb0 file?
• Unreal is known to proclaim that it has semantics in vertex buffers that don't actually exist (the script should ignore these if the corresponding vb file is missing).
• Unreal may pass some additional semantics in structured buffers bound to texture slots rather than in the vertex buffers. 3DMigoto can be configured to dump these out, but the script doesn't know how to deal with them (and this is a tricky one to attempt to find a general solution, since there is no equivalent of an input layout for these, so if we do find we need the data they contain it may require a game and potentially material specific version of the script).

And when I merged the buffer files and imported them into blender.

What did you use to merge them? This should not be necessary in the latest version of the blender addon as it now has support for loading from multiple vertex buffers natively. If the tool is specifically designed for Unreal games it might still be necessary to use it to deal with some of the other quirks I mentioned above, but it shouldn't be necessary to merge vertex buffers any more.

I guess this also explains why the headers in the vb0 and vb5 files you provided don't match. That was about to send me on a wild goose chase looking for a possible bug in our dumping or file de-duplication code as the input layout in every vb file dumped in the same draw call should be identical, but if you have altered vb0 that would explain it.

it showed
keyerror:TEXCOORD8.

This could definitely be from a failed attempt to merge the buffers - I see vb0 header claims that TEXCOORD8 should be at vb0 offset 28, but there is no corresponding data at that offset in the body of the file (or any offset after 24 for that matter). If I work on the assumption that the header in vb5 is the original unmodified header (and trust that your renamed semantics in vb0 are accurate), then I guess that TEXCOORD8 should have originally been located in vb4 offset 4.

It looks like whatever you used to merge the buffers may have miscalculated the offsets - it appears it incremented the offset by 8 after TEXCOORD7, but a R16G16_FLOAT is only 4 bytes. But again, the most recent version of the addon should not require the buffers to be merged. I may have made a mistake here while trying to work out how the offsets had been adjusted when merging that led to me misinterpreting what I was looking at. Looking at vb5 header again it appears TEXCOORD7, TEXCOORD8 and TEXCOORD6 are all listed as being located in the same vertex buffer (vb2) and offset (4) as each other, so they will all share the same data. The script will only take the first of these as valid and discard the rest, but it still expects to find the data for the invalid semantics to be in the txt file. They probably shouldn't have had distinct offsets assigned in the vb0 merge though, as that would mean the script will treat them as valid semantics.

As for vb5, it does indeed appear that it doesn't contain any data - it's stride is 0 (as noted in its header, as well as the error in the log file when it was dumped out), so I'd consider the two semantics that it is supposed to contain (ATTRIBUTE12 and ATTRIBUTE11, that you appear to have renamed to SKINPOSITION12 and SKINPOSITION11) would be invalid. When I've seen this in UE games that I've looked at in the past there was just no buffer bound in these cases so I had the addon skip them if the vb file they were supposed to be in didn't exist - in your case that file does exist, but doesn't contain any data. You might just need to delete the file to get the script to skip those.

OTOH you (or the tool you used to merge the buffers) renamed them to SKINPOSITION, which might signify that they are important? This isn't an official DirectX semantic so the script won't be able to interpret them even if they were present, but perhaps it might turn out that they correspond to semantics in a structured buffer and we might need to import + preserve their values... Can you point me at the tool you used to merge these?

Also, would you mind attaching the original unmodified files from the frame analysis dump? I'm trying to collect some real world samples from different games/engines that I can use to improve the script. Unreal is probably going to be a good candidate for adding a semantic rename feature on import/export to deal with the "ATTRIBUTE" names, though I have my doubts that it will be consistent enough between different titles to be able to add a preset for this (I believe this is somewhat dependent on the material, so may not even be consistent within a single game).

from 3dmigoto.

Spotted an unrelated bug in that log file that's trying to use a deduplication filename with a "?" (from FrameAnalysis.cpp line 1779) to signify a generic buffer, which of course fails on Windows as that's a reserved character:

000001 3DMigoto Dumping Buffer C:\Users\abc\Snow\data\game\Game\Binaries\Win64\FrameAnalysis-2023-10-20-130744\000001-vs-t2=28cbf62a-vs=fcb563178a854b78-ps=663e4037492f1919.txt -> 
000001 3DMigoto Unable to create C:\Users\abc\Snow\data\game\Game\Binaries\Win64\FrameAnalysis-2023-10-20-130744\deduped\f875dacd-?b2.txt: 5

from 3dmigoto.

It looks like whatever you used to merge the buffers may have miscalculated the offsets - it appears it incremented the offset by 8 after TEXCOORD7, but a R16G16_FLOAT is only 4 bytes. But again, the most recent version of the addon should not require the buffers to be merged.

I may have made a mistake here while trying to work out how the offsets had been adjusted when merging that led to me misinterpreting what I was looking at. Looking at vb5 header again it appears TEXCOORD7, TEXCOORD8 and TEXCOORD6 are all listed as being located in the same vertex buffer (vb2) and offset (4) as each other, so they will all share the same data. The script will only take the first of these as valid and discard the rest, but it still expects to find the data for the invalid semantics to be in the txt file. They probably shouldn't have had distinct offsets assigned in the vb0 merge though, as that would mean the script will treat them as valid semantics and won't discard them.

from 3dmigoto.

What game is this from?

This game is snowbreak containment zone

It should be made with Unreal Engine 4 version 4.26

I did try to use the latest blender import script directly, but I found that there were no models after importing, only a lot of vertices overlapping each other, so I tried to modify the semantic attributes, because all file headers have only the semantic attribute ATTRIBUTE

The picture is from https://github.com/eArmada8/vbuffer_merge_split/issues/5 Although I imported the unmerged buffer file, I also had this problem

Can you point me at the tool you used to merge these?

https://github.com/eArmada8/vbuffer_merge_split/blob/main/kuro/kuro_vb_merge.py

I've slightly modified its matching rules, but apparently I'm doing it wrong

buf.zip

from 3dmigoto.

Thanks, I'll take a look at that game.

I did try to use the latest blender import script directly, but I found that there were no models after importing, only a lot of vertices overlapping each other.

Yes, the issue where all vertices were overlapping will be because it couldn't find a POSITION semantic, and it looks like @eArmada8's script has a feature that tries to guess the semantic names that might help with that, but I can't say whether all the semantics it guessed would be correct for Unreal (two TANGENT semantics in your vb0 seems a bit sus).

so I tried to modify the semantic attributes, because all file headers have only the semantic attribute ATTRIBUTE

So in theory you should only need to modify the semantic names, and no longer have to worry about merging the buffers together into one file. I think the script will complain if there are any differences between the headers of the various vb files, so at least for now you would have to rename them consistently in each file (that feels like something I could tweak in the script so it just uses the header in vb0 and ignore the rest, though it would probably be better if I expose some options in the import dialog to allow the semantic names to be remapped at import time without altering the file headers at all).

I don't know how much further that will get you - we might still have some more issues to solve if the game is passing any semantics in structured buffers, but one step at a time :)

from 3dmigoto.

buf.zip

Thanks for the samples, but it looks like this only contains the .buf files from the dump - I do need the .txt files as well because they contain the buffer info (stride/format), draw call info and input assembler layout, whereas the buf files are just the raw binary buffers the game passed to DirectX (all body no header).

from 3dmigoto.

Sorry, I've given a new zip file
This should be a model of the face
buf.zip

from 3dmigoto.

Try out the new semantic remapping feature - for these meshes I think it should be configured something like this:

I recommend saving an operator preset in the import dialog so you don't have to reconfigure those every time.

Vertex positions, normals, UV coordinates, vertex groups all Imported:

When you export it will now save the before/after names in the .fmt file so that it can re-apply the same semantic remap if you re-import it again (the semantic remap UI is currently only in the frame analysis import dialog, not the raw buffer import dialog):

element[0]:
  SemanticName: ATTRIBUTE
  SemanticIndex: 0
  RemappedSemanticName: POSITION
  RemappedSemanticIndex: 0
  Format: R32G32B32_FLOAT
...

Note that this is a very bleeding edge feature that was required quite a significant amount of code changes and has only been lightly tested, so... there could be problems/regressions - please do let me know if you encounter any. I'll also look at adding some quality of life features to help fill out the semantic remap table from file and perhaps guess what they should be remapped to (at least for Unreal), but given I've been up to 5AM the last two nights getting it this far that can wait for another day ;-)

I haven't tried exporting a modified mesh back to Unreal yet, so I don't know whether this will be enough for a complete workflow - the structured buffer quirk is still a significant concern since if we don't deal with that any data Unreal reads from it could be applied to the wrong vertices after modifying a mesh.

from 3dmigoto.

Thank you for your work,

I’m sorry for the late reply.

I successfully imported a new buffer file.

But when I tried to replace the content in the game, new problems came one after another.

There was no error message, and nothing changed.

I thought I did something wrong in blender at first, but when I tried to skip the index buffer or vertex buffer directly, nothing happened, and there was no error message either.

So I added ShaderOverride. It worked, and the body was skipped.

But I don’t know how to solve the problem of not being able to replace it.

Attached configuration file

[TextureOverridebody]
hash = 974f8a86
vb0 = ResourceVB0
vb1 = ResourceVB1
vb2 = ResourceVB2
vb3 = ResourceVB3
vb4 = ResourceVB4
ib = ResourceIB
handling = skip
drawindexed = auto
[ResourceVB0]
type = Buffer
stride = 12
filename = fenni.vb0
[ResourceVB1]
type = Buffer
stride = 8
filename = fenni.vb1
[ResourceVB2]
type = Buffer
stride = 8
filename = fenni.vb2
[ResourceVB3]
type = Buffer
stride = 4
filename = fenni.vb3
[ResourceVB4]
type = Buffer
stride = 8
filename = fenni.vb4
[ResourceIB]
type = Buffer
format = DXGI_FORMAT_R16_UINT
filename = fenni.ib
[ShaderOverridePS]
;Green skirt
hash = dd7f66b40ce9235c
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS1]
;Black ornaments and green ornaments
hash = d8b7399081c3911e
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS2]
;Front half of hair
hash = a59e6dac066cc4f0
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS3]
;Black skirt
hash = a5381b4fbb83fb36
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS4]
;Shadow of the front half of the hair
hash = 9c0323a15a9f0633
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS5]
;Half of the hair
hash = 8e40872248749c8f
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS6]
;body
hash = 29aeb2fa0cf15c62
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS7]
;Partial shadows
hash = 74bc48a966c8a734
checktextureoverride = ps-t0
checktextureoverride = ib
[ShaderOverridePS8]
hash = a35fb6f88e3209ed
handling = skip
[ShaderOverridePS9]
hash = 3648dcc654fd7063
handling = skip
;[ShaderOverridePS0]
;hash = fcb563178a854b78
;checktextureoverride = ResourceVB0
;checktextureoverride = ResourceIB
;checktextureoverride = ResourceVB1
;checktextureoverride = ResourceVB2
;checktextureoverride = ResourceVB3
;checktextureoverride = ResourceVB4
;allow_duplicate_hash = true

from 3dmigoto.

addendum

After importing the character model into Blender, it is reversed, just like importing the model from a mirror image of the character, however, this can be recovered by mirroring the y-axis.

When re-import a vb/ib file after exporting it, the number of vertex groups are all zeroed out, and I'm not sure if this is normal.

from 3dmigoto.