search

bo3b / 3Dmigoto

Chiri's DX11 wrapper to enable fixing broken stereoscopic effects.
Other
688 stars 109 forks source link

Color Output Issue prevents Blender Import? #166

Open Arganom opened 1 year ago

Arganom commented 1 year ago

I am having an issue exporting Ib's to blender. I have tried multiple different branches of the 3dmigoto import plugin to no avail on multiple versions of blender. I believed it was a "multiple" vertext buffer issue when I first started geting acquainted with the main plugin for 3dmigoto but after talking to another use about a split/merge script I was informed that it might be a color output issue?

Down below I've posted the response from eArmada8 for reference:

Hi, the frame analysis you uploaded does not have multiple vertex buffers. My script will not be able to help you, since it is written for merging and splitting multiple buffers. You can tell if there are multiple buffers if there are multiple vb files per ib (.vb0, .vb1, .vb2, etc...) - your dump only has .vb0 for every .ib however.

I took a look at your frame dump, and there are invalid values; for example in 000061-vb0.txt:

vb0[1580]+000 POSITION: 19681, -76, 32767, 22104 vb0[1580]+024 NORMAL: 0.788628817, -0.00585955381, 0.60860014, 0 vb0[1580]+008 TEXCOORD: 190, 50, -1, -1 vb0[1580]+032 TANGENT: 0.0156254768, -0.497054964, -0.0273751039, 0 vb0[1580]+016 BLENDWEIGHT: 0.827450991, 0.172549024, 0, 0 vb0[1580]+020 BLENDINDICES: 8, 4, 0, 0 vb0[1580]+000 COLOR: -1.#QNAN

You can see the color value is not a number. You can try importing the raw buffers instead; when importing check the "Load .buf files instead" option. I was able to successfully load your frame dump when I checked that option, however it does not appear that any of the meshes that you provided are useable. (They will load successfully, but I don't see the model.)

You may want to ask the developers of 3DMigoto, or the developer of the import plugin. My script does not apply here though, since it is for merging. I'm going to close this issue for now."

So, Has this issue been answered before? I haven't seen any issues concerning the problem I've encountered. I've also tried testing another game " Road 96" and encountered the same issue so perhaps I have something in the frame dump that is configured wrong?

DarkStarSword commented 8 months ago

Hi, sorry I missed this issue when it came in and just saw it while going through the backlog now. Do you by any chance still have the frame analysis dumps for this case? I'm helping someone else at the moment with a similar issue (but in his case it's an indeterminate -1.#IND rather than a "quiet non a number" -1.#QNAN) and it would be handy to get a few more samples of real world occurrences of this issue.

In the meantime the easiest way to get past this and get the file imported to Blender would generally just be to do a find and replace over the text files to replace -1.#QNAN with 0, though I would kind of like to see the full file because usually a COLOR semantic would have 3 or 4 components rather than the 1 I can see in your snippet, so it might still have some problems with that. The "Load .buf files instead" option would certainly get past the parse error, but that option also loads the complete buffer, which isn't always what you want since it can include parts of the mesh from other draw calls (I added a switch last night to change it's behaviour internally so it can load the same partial buffer as the .txt files - I'll look at hooking that up to the UI soon).

The multiple vertex buffer limitation is now fixed in the latest version of the Blender addon, though as eArmada8 pointed out that isn't the issue you are encountering here.

DarkStarSword commented 8 months ago

Ahh, looking at your snippet again I see the offsets the COLOR semantic is invalid because it reuses the 0 offset from POSITION - that explains a few things, and just fixing adding support for parsing Microsoft's weird way of formatting NaNs should be enough to get past that specific issue.

The fact that it got interpreted as a QNAN is still rather surprising though... What are the DXGI formats of POSITION and COLOR?...

Is this by any chance using an INTEGER position rather than a float? I could see that scenario causing this if position is a DXGI_FORMAT_R16G16B16A16_SINT being interpreting as a DXGI_FORMAT_R32_FLOAT for the COLOR - the first two components of the position do indeed translate into a NAN interpreting them as a 32bit float:

In [21]: struct.unpack('f', struct.pack('hh', 19681, -76))
Out[21]: (nan,)

If that is the case, it might also explain why importing the buf files still didn't get a usable model in Blender. I'm not entirely sure if Integer positions will actually work off hand (I think they probably should in theory, but I've not tested that possibility), and it could also signify that the positions are actually using some game specific packing format which might then need a game specific version of the Blender script to decode - and figuring that out will probably need us to take a look at the vertex shader the game is using that decodes the position.