EpicGamesExt / BlenderTools

Blender addons that improve the game development workflow between Blender and Unreal.
https://epicgamesext.github.io/BlenderTools/
MIT License
2.7k stars 26 forks source link

Send to Unreal - "Skeleton does not exist in the project" error when texture name matches object name #665

Closed joric closed 7 months ago

joric commented 9 months ago

Prefixes help, also, enabling prefixes somehow fixes this bug on import so there's no error dialog in Unreal:

The following bones exist in the imported animation, but not in the Skeleton asset hero_Skeleton.  Any animation on these bones will not be imported: 
HERO
Imported bone transform is different from original. Please check Output Log to see detail of error.  

I've spent a considerable amount of time debugging this issue, and it's been quite frustrating. You can easily reproduce the problem by examining the console output and importing the problematic FBX file from the temporary folder.

In my case, when I imported the faulty FBX file into Unreal Engine after importing the texture, I received an error message that said, 'cannot delete referenced object.' It turned out that the object (skeletal mesh) had the same name as the texture file without the extension. Specifically, the skeletal object was named 'hero,' and the texture file was named 'hero.jpg.' To resolve this, you can either rename the skeletal mesh object in Blender or rename and reimport the texture in Blender. Just renaming the texture in Blender didn't work for me, probably because the texture was packed.

I'm not entirely sure how to address this naming conflict, but one possible solution is to ensure that all asset names are unique and rename assets if necessary. It's worth noting that texture names matching object names is a common occurrence. Using prefixes in the Pipeline - Export - Settings Dialog - Extensions (for example, T_ for textures) can be helpful, but they are often disabled by default. Perhaps enabling them by default would be a good idea.

Additionally, the error message from Unreal Engine is not very informative. It would be more helpful if it could print out the Unreal error message to help locate the problem more easily.

Moreover, if we decide to change defaults, it might be a good idea to use more meaningful default paths instead of /Game/untitled_category/untitled_asset/ - perhaps something like /Game/ImportedAssets would be more intuitive. Setting this up in all files can be quite tedious. Additionally, enabling subfolders by default, either based on collection name or asset name, could streamline the workflow.

Lastly, it's worth noting that the 'Use collections as folders' feature appears to have a bug. It's producing an error message that says in get_skeleton_asset_path import_path = get_path_function(properties, UnrealTypes.SKELETAL_MESH) TypeError: UseCollectionsAsFoldersExtension.get_full_import_path() missing 1 required positional argument: scene_object. Unfortunately, I'm not sure how to fix this issue; it may be related to a scripting error.

TL:DR: the problem arises when the texture name matches the object name, and using prefixes can help alleviate this issue.

Upd. Sometimes it's not name clash, it's a revision-related error, like "Failed to revert package which was marked for delete" (can be fixed by commiting changes), all those errors result in "Skeleton does not exist in the project" (can be reproduced if you delete resources and then import bad fbx from Temp).

Also mesh and material names add .00x each time the item is exported (if remove/add affixes is enabled in settings). E.g. after a few exports mesh or material names like "test.001" become "test.001.001.001.001.001.001.001.001.001".

jamesbaber1 commented 8 months ago

The missing parameter should be fixed in the latest release. Also a validation was added here to check the asset type provided for the skeleton path, which should make something like this more clear if somehow it got set to the path of a texture or any asset other than a skeleton.

Re-open if you experience these issues again. Thanks!