Maybe there's a lack of vertex data #181
Comments
|
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:
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.
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.
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). |
|
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: |
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. |
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
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 |
|
Thanks, I'll take a look at that game.
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 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 :) |
|
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). |
|
Sorry, I've given a new zip file |
This gives the script a native way to deal with games that don't follow standard DirectX semantic names, by allowing the user to override how the script will interpret each semantic. This is particularly useful for Unreal Engine games that name every semantic "ATTRIBUTE". At the moment the user must still deduce which attributes are what, but there's enough clues that we can probably add a guessing feature later (e.g. POSITION is usually 1st, UE seems to group NORMAL and TANGENT in the same buffer, TEXCOORDs are 2 component formats, also grouped in the same buffer, blend indices and weights always come in pairs with the indices being integers, etc). The translations are applied at import/export time, and the before/after renaming is added to the input layout description so that exported files can be reimported and the same remapping will be applied. This is a fairly substantial change, so it comes with a moderate risk of regressions. Allows the meshes from Unreal on this ticket to be imported without needing to modify the headers first: bo3b/3Dmigoto#181
|
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): 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. |
|
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
|
|
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. |
Hi, I’m a beginner.
I used 3dmigoto to dump frame analysis files and got multiple buffer files.
But when I opened vb5, I found only semantic attributes and no vertex data.
Is this normal?
And when I merged the buffer files and imported them into blender, it showed
keyerror:TEXCOORD8.
Is this also caused by the lack of vertex data in vb5?
ShaderUsage.txt
log.txt
000004-vb5=ddd690a8-vs=fcb563178a854b78-ps=663e4037492f1919.txt
000004-vb0=af9cb6e7-vs=fcb563178a854b78-ps=663e4037492f1919.txt
The text was updated successfully, but these errors were encountered: