Weird Bones Naming causing errors

[enzyme69]

weird_bone_names.zip

From Blender default, bones often named: bone.000, bone.001, bone.002 and this GLTF to USDA converter seems to dislike this idea.

Perhaps there should be a checker that can modify bone.000 to bone_000? Thanks 👍

[kcoley]

@enzyme69 thanks for filing this, since it relates to the Armature/ workaround as well. I'll look into handling bone names.

[enzyme69]

Just to add to this, I got this Rig in Blender with name "Beefy Rig" -> this causing error also... only I figure out, there is a space there so I removed it and it does not complaint about name.

Next weird thing is this error, which I can't decipher:

Traceback (most recent call last):
  File "gltf2usd.py", line 1105, in <module>
    convert_to_usd(args.gltf_file, args.usd_file, args.fps, args.verbose)
  File "gltf2usd.py", line 1094, in convert_to_usd
    GLTF2USD(gltf_file=gltf_file, usd_file=usd_file, fps=fps, verbose=verbose)
  File "gltf2usd.py", line 63, in __init__
    self.convert()
  File "gltf2usd.py", line 1080, in convert
    self.convert_nodes_to_xform()
  File "gltf2usd.py", line 101, in convert_nodes_to_xform
    self._convert_animations_to_usd()
  File "gltf2usd.py", line 511, in _convert_animations_to_usd
    self._convert_skin_animations_to_usd()
  File "gltf2usd.py", line 616, in _convert_skin_animations_to_usd
    usd_skeleton = joints[0]['skeleton']
IndexError: list index out of range

[enzyme69]

If you want to check it out... beefyPose.zip

[wave-electron]

I'm having a stab here. But looking inside beefyPose.gltf under "skins": "joints": the joint numbering starts at 12 and the numbering is not entirely sequential either. Its failing at line 616 usd_skeleton = joints[0]['skeleton']

joint[0]['skeleton'] is null? But Kacey will have a better idea. I have the same error in another gltf model... the joint numbering starts at 7. If you change usd_skeleton=joints[7]['skeleton'] it no longer crashes on that line in crashes at line 698. So Kacey will be able to tell us whether he's assuming that joints start at 0 and go up sequentially???

On Thu, 23 Aug 2018 at 22:22, Jimmy Gunawan notifications@github.com wrote:

If you want to check it out... beefyPose.zip https://github.com/kcoley/gltf2usd/files/2314343/beefyPose.zip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kcoley/gltf2usd/issues/11#issuecomment-415395144, or mute the thread https://github.com/notifications/unsubscribe-auth/APhRdGyzwHr41qqpYFM6hMfUm0usypa-ks5uTp5wgaJpZM4WI060 .

-- Kind Regards,

Mr Ashley Joyce

Company Director

Bowin Service Pty Ltd

T: 0404481375 F: 02 8080 4393 E: admin@bowin.com.au

[kcoley]

@enzyme69 @wave-electron thanks for the info. I'll try to take a look at this later today. I may need to refactor the way I am handling the bone names to handle this case better.

[kcoley]

@enzyme69 @wave-electron Digging further into this, I believe it is a bug in how I am detecting joints with animations. I think I have a way to fix it, so will give it a try

[wave-electron]

Looking at the monster.gltf from KhronosGroup, I noticed the file generator was COLLADA2GLTF a command line tool on github. I might use this tool to create some more glTF 2 files that have animated bones and see if successfully convert to usda using gltf2usd.py . I was then going to use the same source DAE files and see what differences I can find between the glTF2 files generated by Blender & COLLADA2GLTF. We already no the issue with naming bones with .001 exists with the Blender exporter.

[kcoley]

@enzyme69 does the beefyPose model look as expected when you load it into other glTF viewers? I am getting weird results when I look at it using Babylon.js's sandbox, Three.js's viewer and on Windows Mixed Reality.

Babylon.js

Three.js

Windows Mixed Reality Viewer

[wave-electron]

@kcoley If you get a chance take a look at this example. t-rex.zip I created the collada file from Blender -> COLLADA2GLTF -> GLTF file. The file works properly in the Babylon sandbox. It also processes via the gltf2usd.py without error to creae the usda file. The usda file opens up in xcode ok, and looks fine. However, after converting into usdz and viewed in safari it won't load. I stripped the animation out to see if the images or meshes are causing the crash and it opens as usdz in safari without the animation. Would love to see if you can pinpoint the issue.

[kcoley]

@wave-electron sure thing, I'll play with it sometime this weekend to see if I can get it to work.

[wave-electron]

@kcoley Just something else... gltf2usdz.py - usd doesn't like bone names with hyphen - If you remove the - between T-Rex_Pelvis it doesn't throw an error

 Error in 'pxrInternal_v0_18__pxrReserved__::SdfPrimSpec::_New' at line 108 in file /tmp/USD/pxr/usd/lib/sdf/primSpec.cpp : 'Cannot create prim '' because 'T-Rex_Pelvis' is not a valid name

another issue worth mentioning... is making sure the PBR images meet the file type spec. For example a normal_map file with an alpha channel was crashing as a usdz archive.

[kcoley]

@wave-electron Thanks for the findings! I’m creating a regex to try to catch these naming edge-cases during name conversion to USD.

[wave-electron]

@kcoley great... the command tool needs to deal with naming issues, otherwise it will be manually intensive to correct the naming in third party 3D authoring tools.

Over the weekend I was using the command tool FBX2gtLF.... again similar problem with the t-rex file. The glTF is working as expected in the bablyon sandbox. It converts to usda & usdz without errors. But in this case appears as a static pose in usdz iOS12 beta 10. WalkingLady.zip

[kcoley]

@wave-electron I didn't have as much time this weekend, though I did create a branch where I am using regex to handle node names. After the change, I was able to see some animation for WalkingLady, though the animation was corrupted. However, I didn't see anything for the t-rex model. I hope to find some time this week to take a deep dive and investigate

[wave-electron]

@kcoley Cool, I'm using that branch now for my testing. You need to add colon : to symbols (boss:RightHandPinky3) that USD rejects.

Warning: in _InitWithString at line 106 of /tmp/USD/pxr/usd/lib/sdf/path.cpp -- Ill-formed SdfPath </root/node0/node77/node78/boss:RightHandPinky3>: syntax error

[wave-electron]

@kcoley

to deal with the naming crashes when encountering colon. I updated your regex code to the following to include the ':'

    `return` re.sub(r'\.|\b \b|-\b|:', '_', name) # replace '.' and ' ' and '-' and ':' with '_' 

then around line 730

 # name = self._get_joint_name(node)
    name = self._convert_to_usd_friendly_node_name(self._get_joint_name(node))

[kcoley]

@wave-electron thanks for the regex update! I'll add that to the branch shortly

[kcoley]

@wave-electron revisiting the t-rex model, I was not able to get the usda file to load in my copy of XCode-Beta (I'm currently on 5), though I was able to at least view the model in usdview. I will try testing it out in Maya when I get a chance, but for now I will merge the regex naming branch to master

[enzyme69]

@kcoley Sometimes, I am not 100% sure whether Khronos Group animation export works properly. I tested using Clay and also getting weird animation...

Will try exporting again...

Thanks for checking this!