Import Error：AssertionError

[53nemu]

Happy New Year Please accept my apologies for disturbing you at the beginning of the year. I'm a novice modder with no programming experience. This is my first time using 3Dmigoto to create a mod. I've installed the 3Dmigoto plugin in Blender version 3.33. When attempting to import the ib and vb model, I encountered the following error message.

Python: Traceback (most recent call last): File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 2516, in execute import_3dmigoto_raw_buffers(self, context, fmt_path, fmt_path, vb_path=vb_path, ib_path=ib_path, vgmap_path=vgmap_path, migoto_raw_import_options) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 2441, in import_3dmigoto_raw_buffers obj = import_3dmigoto(operator, context, paths, merge_meshes=False, kwargs) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 1305, in import_3dmigoto obj.append(import_3dmigoto_vb_ib(operator, context, [p], **kwargs)) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 1323, in import_3dmigoto_vb_ib vb, ib, name, pose_path = load_3dmigoto_mesh(operator, paths) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 928, in load_3dmigoto_mesh return load_3dmigoto_mesh_bin(operator, vb_paths, ib_paths, pose_path) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 910, in load_3dmigoto_mesh_bin vb.parse_vb_bin(vb_paths[0], use_drawcall_range) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 618, in parse_vb_bin self.merge_vbs(self.vbs) File "C:\Users\ROG\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\blender_3dmigoto.py", line 670, in merge_vbs assert(len(vb.vertices) == self.vertex_count) AssertionError

The model is known to function properly within 3Dmigoto (game: The Legend of Heroes: Trails into Reverie), so I'm hoping you can assist in determining whether the issue lies with my computer's environment or with the model itself. Once again, thank you very much for your plugin. AlisaKimono.zip

[DarkStarSword]

Looks like this mod might have been created with a fork of an older version of this script before it had official support for multiple vertex buffers (i.e. could only load .vb, not .vb0 + .vb1 + .vb2, etc), and the workarounds they used to make it work with the older version is now confusing the newer version of the script that supports multiple vertex buffers directly.

You might be better off using the fork of this script that was tailored for that specific game, especially if it has any other game specific workarounds that aren't in the generic version (I don't know if there are any, just mentioning it as something to consider).

But if you want to use it with the new version of the script I've converted it so that it should work: AlisaKimonoConverted.zip

Essentially I undid the workarounds they put in the .fmt file and updated how stride is recorded to match the new version:

• Changed InputSlot from 0 to the correct vertex buffer containing each element (in this case one element / vertex buffer, so is the trivial case of 0-5)
• Changed AlignedByteOffset back to 0 for each element (again, one element/buffer, so it's the trivial case where every element starts at the start of their buffer)
• Replaced the single 'stride: 64' at the top with the stride of each individual vertex buffer, which I determined from their formats and verified still adds up to 64
• I also deleted the .vb file - that was a combination of all vertex buffers in one file for the workaround, but the new script would get confused and think it's another vertex buffer 0 with too much data

Alternatively, the new script can still load the mod without these changes if you remove the numbered vertex buffer files before importing (the old script would have ignored those files, the new script is seeing them and assuming they must be additional vertex buffers that it needs to load), however that would still require the use of their game specific workaround to split the exported .vb back out to the numbered files afterwards - the new script can export the numbered files directly.

[53nemu]

Looks like this mod might have been created with a fork of an older version of this script before it had official support for multiple vertex buffers (i.e. could only load .vb, not .vb0 + .vb1 + .vb2, etc), and the workarounds they used to make it work with the older version is now confusing the newer version of the script that supports multiple vertex buffers directly.

You might be better off using the fork of this script that was tailored for that specific game, especially if it has any other game specific workarounds that aren't in the generic version (I don't know if there are any, just mentioning it as something to consider).

But if you want to use it with the new version of the script I've converted it so that it should work: AlisaKimonoConverted.zip

Essentially I undid the workarounds they put in the .fmt file and updated how stride is recorded to match the new version:

• Changed InputSlot from 0 to the correct vertex buffer containing each element (in this case one element / vertex buffer, so is the trivial case of 0-5)
• Changed AlignedByteOffset back to 0 for each element (again, one element/buffer, so it's the trivial case where every element starts at the start of their buffer)
• Replaced the single 'stride: 64' at the top with the stride of each individual vertex buffer, which I determined from their formats and verified still adds up to 64
• I also deleted the .vb file - that was a combination of all vertex buffers in one file for the workaround, but the new script would get confused and think it's another vertex buffer 0 with too much data

Alternatively, the new script can still load the mod without these changes if you remove the numbered vertex buffer files before importing (the old script would have ignored those files, the new script is seeing them and assuming they must be additional vertex buffers that it needs to load), however that would still require the use of their game specific workaround to split the exported .vb back out to the numbered files afterwards - the new script can export the numbered files directly.

I am deeply grateful for your assistance and truly appreciate your explanations regarding the matter. I am also immensely thankful for your plugin, as it has reignited my interest in gaming. Wishing you a Happy New Year!

[eArmada8]

I'm encountering the same issue. It does not seem to be directly a problem with using older versions of the plugin. The current commit seems to have issues overwriting older plugins (and maintaining fidelity somehow as well).

For example, with this mesh, there are 6755 vertices. When I export it again, it has 7154 vertices for some reason.

If I export to a new file name, I can re-import it. If I export and overwrite the original, then I am left with .fmt, .ib, .vb (old) and .vb0 (new) files. Then the plugin seems to try to read both the .vb and .vb0 file, and the assertion error occurs. This happens even if I rename 4.vb to 4.vb.bak, but not if I rename to 33.vb. So I suspect that the plugin is searching using ".vb" and reading both the old 4.vb and the new 4.vb0.

Correcting this behavior should fix the assertion error. I still don't know how 6755 vertices becomes 7154 vertices though.

[DarkStarSword]

I've pushed a change to filter out the .vb file if a .vb0 file also exists.

[eArmada8]

Thank you very much! Tested, working great. :)