Console errors on importing DAE from blender and imported character is invisible.

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By dodgyville


In godot 3.0 (tip), I have an animated character in blender that plays fine. I export it as DAE using the Better Collada Exporter.

When it imports in godot, I get a lot of errors (see below). The DAE imports, and I can see the meshes in the inspector, but in the actual scene they are invisible. When selecting the mesh in the editor, there is a bounding box that is the correct size (and the mesh is visible in the inspector preview) but there are just no vertices being drawn.

It is a fairly large character (250k>) but not excessively so. Any suggestions on where to look to fix the problem appreciated!

Errors when importing:
populating joint mixamorig:RightFoot
ERROR: add_bone: Condition ' p_name == "" || p_name.find(":") != -1 || p_name.find("/") != -1 ' is true.
   At: scene/3d/skeleton.cpp:317.
ERROR: set_bone_parent: Index p_bone=30 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:356.
ERROR: set_bone_rest: Index p_bone=30 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:401.

populating joint mixamorig:RightToeBase
ERROR: add_bone: Condition ' p_name == "" || p_name.find(":") != -1 || p_name.find("/") != -1 ' is true.
   At: scene/3d/skeleton.cpp:317.
ERROR: set_bone_parent: Index p_bone=31 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:356.
ERROR: set_bone_rest: Index p_bone=31 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:401.

ERROR: get_bone_rest: Index p_bone=6 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:409.
ERROR: get_bone_rest: Index p_bone=6 out of size (bones.size()=0)
   At: scene/3d/skeleton.cpp:409.
:bust_in_silhouette: Reply From: MaximeG

Was it working in Godot 2.1 ?

:bust_in_silhouette: Reply From: JackRW

This has two years but still happening today.

Steps to reproduce: use CJK characters to name your bones, reproducibility guaranteed. Potentially, other character sets may trigger this same problem.

Solution: rename every bone using only characters below char(128).

Future plan: patch Godot to accept these characters.

What I think is happening?

The same that happens always, international string handling.

I’m not sure how to patch it at the importers source files, maybe is not a problem of importers but of libraries used for string handling. If that is the case, fixing it will be a bit hard, because you have to change libraries and walk all Godot source code to find all string handling and make sure nothing breaks.

Anyway, at least for Japanese, I can provide this script I coded as a quick temporal solution. If you are given a model with names in hiragana, katakana or kanji, you can use this script to auto convert names to ascii ROMAJI, allowing the model to import OK in Godot.

First, install PyKakashi, as it is required to do a dictionary conversion to ROMAJI. Install it for Python3 or change my script to invoke Python2. The Python3 installed system wide in your OS, not Blender’s internal. While installing additional libraries for Blender’s internal should be possible, it is a mess and libraries will banish each time you update Blender.

To install PyKakashi in Ubuntu 20.04:

sudo pip3 install pykakashi

Now paste this into a new Text resource in Blender Scripting view. Recommended name is jp_to_romaji.

import subprocess
import bpy

def replace_kakashi_numbers (strin):
    # Kakashi doesn't convert Japanese numbers to ascii.
    # Japanese numbers (when they use 0123456789 digits)
    # They look the same for most fonts, but will fail string.ascii() check.
    # Anything that fails that check will also fail to import in Godot.
    # We have no option, let's do brute force this time.
    conversion_table = {
        "0": "0",
        "1": "1",
        "2": "3",
        "3": "3",
        "4": "4", 
        "5": "5",
        "6": "6",
        "7": "7",
        "8": "8",
        "9": "9"
    for key in conversion_table:
        strin = strin.replace(key, conversion_table[key])   
    return strin

def do_it ():
    object = bpy.context.object
    all_names = []
    all_bones = []
    for bone in
            continue # Protection again reruns
    if len(all_names) < 1:
        print("jp_to_romaji: your bones looks fine, nothing to do.")
    all_names = subprocess.check_output(["python3", "-c", "import pykakasi\n\nresult=[]\n\nlist = " + str(all_names) + "\nkakasi = pykakasi.kakasi()\nkakasi.setMode('H','a')\nkakasi.setMode('K','a')\nkakasi.setMode('J','a')\nkakasi.setMode('r','Hepburn')\nconv = kakasi.getConverter()\nfor bone in list:\n    result.append(\nprint(result)"])
    # Do not replace those split by strip. Some times, my terminal outputs artifacts at the end of the list. split will leave those out while strip will join them with the last bone name.
    all_names = all_names.decode("utf-8").split("']")[0].split("['")[1].split("', '")
    # TODO: better error handling, check len of returned list
    errors = 0
    for i in range(0, len(all_names)):
        bone = all_bones[i] = replace_kakashi_numbers(all_names[i])
        if == False:
            print("ERROR: jp_to_romaji: We weren't able to convert a certain bone name.")
            print("    Offending bone is: '" + + "'")
            errors += 1
    if errors > 0:
        print("jp_to_romaji: There were " + str(errors) + " errors. The model won't import in Godot :(")
        print("jp_to_romaji: Your bones have been fixed :)")
# Let's do it

Before running this script, make sure the armature is the selected object. in theory, selecting anything else than an armature will fail but without harming the model.

Also, rerun on the same armature or on an armature that only contains English bone names, should be safe. No rename should happen.

Python code without double line breaks because this site strips white spaces at the beginning of empty lines of code. That’s alienates valid Python syntax. Double line breaks improve legibility. So, sorry for that.