Armature parenting fails

[Polynominal]

In a scene where armature has a parent of another armature creates a Unknown Location error.

like this: |-armature_face |-----face |-----armature eye ( parent: armature_face ) |--------eye

Error details:

Traceback (most recent call last):
  File "/home/avagrande/.config/blender/2.81/scripts/addons/Urho3D-Blender/__init__.py", line 1758, in invoke
    return self.execute(context)
  File "/home/avagrande/.config/blender/2.81/scripts/addons/Urho3D-Blender/__init__.py", line 1754, in execute
    ExecuteAddon(context, not bpy.context.scene.urho_exportsettings.showLog, self.ignore_geo_skel_anim )
  File "/home/avagrande/.config/blender/2.81/scripts/addons/Urho3D-Blender/__init__.py", line 3546, in ExecuteAddon
    ExecuteUrhoExport(context)
  File "/home/avagrande/.config/blender/2.81/scripts/addons/Urho3D-Blender/__init__.py", line 3508, in ExecuteUrhoExport
    UrhoExportScene(context, uScene, sOptions, fOptions)
  File "/home/avagrande/.config/blender/2.81/scripts/addons/Urho3D-Blender/export_scene.py", line 977, in UrhoExportScene
    a[modelNode] = ET.SubElement(a[usm.name], "node")
KeyError: 'Armature_face'

location: <unknown location>:-1

As a work around its possible to create a empty node and manipulate that instead of the armature itself. I hope this could be resolved by encoding a armature as a node with its own position which owns the model essentially automating the work around. I have tried implement this myself in the export scene code but its very messy so I wasn't able to comprehend enough code to do this myself, it would be very helpful to clean up the export scene code so its easier to contribute.

[dertom95]

Yes, when I recall right parenting on bones is not supported. It is a bit difficult because the skeleton in part of the mesh-mdl and the parenting part would be part of the scene/object.xml. For this I had a component ParentBone where you basically had to select the Bone at which the attached Node should be parented to. Didn't use it for quite a while. (I guess the exporter will endup working like this, doing this automatically. Not sure when I will find time for this)

Or maybe your workaround also works...maybe better. Can you explain a bit more in detail how your workaround worked? Or maybe send a test-blend so I can reproduce it?

2nd question, what is the reason the eye has an armature of its own? That is a quite unusual setup. Usually the eyes are part of the mesh and are manipulated by the master armature....

[Polynominal]

Well I am working on 2.5D which means that my eyes are a separate mesh to my main mesh. Essentially its just a series of planes cut down to fit their image so I can manipulate them using its own armature. I might try joining everything together but it felt inappropriate to do so as the mesh is mostly disconnected. I have used IK here and there so I am not very confident on the bone parenting method.

I am still working on it since it has many parts, but in short I need to create a new node which holds the transform and then manipulate that instead of the base model or the armature.

I made the meshes and armatures in 2.79 then tried to export them but ran into the "origin of the model should have the same origin as armature" using the original plugin which made me move to this new plugin and to 2.8 and it worked using a test shape even though origins were off so I was happy with it.

In the end this error got me to move back the old plugin and just resolve the original issue of misaligned origins as its the same as the work around and gives me the additional stability and exporting of materials without having to set it up using the node tree.

So it looks like: |- face <- token shape / empty |----- armature_face ( parent: face ) |----- face_base ( parent: face ) <- plane |----- eye ( parent: face ) <- token shape / empty |------- armature_eye ( parent: eye ) |------- eye_base ( parent: eye ) <- plane

I got quite a few images so its going to take me a while and I am not sure if it will work as intended so I will have to get back to you if it does work, although I don't see why it shouldn't. Individually it exports fine just haven't tested if it looks the same in game.

if the code was easier to read I could implement this but currently I can't do that. just naming your variables things other than "a" or "k" or "m" can be helpful. There are very many repetitions as-well including "{:d}".format(m) which makes it difficult to wrap my head around what its actually going on at each step like if the key is unique or not etc.

If you want to replicate this then create a square and then two armatures. parent the square to the armature and then that armature to the other one. eg:

|- armature_base |--- armature_sq |------ square test.zip

I also have the same error ( unknown location ) when moving from 2.79 to 2.8

[dertom95]

if the code was easier to read I could implement this but currently I can't do that. just naming your variables things other than "a" or "k" or "m" can be helpful. There are very many repetitions as-well including "{:d}".format(m) which makes it difficult to wrap my head around what its actually going on at each step like if the key is unique or not etc.

Haha,...yes. Took me also a while to understand that. a is basically something like a dict with all XML-Components

You usually have constructs like this a[something]=ET.SubElement(a[some_parent], "component") That creates an subelement "component" at the given parent, that you took out of that a-dict.

Now if you want to set values to this you need to access it, also via a[...]: a[something].set("name","componentName_something")

I know that "{:d}".format(m) looks strange I just went on using it as it was already in the code.

In the end this error got me to move back the old plugin and just resolve the original issue of misaligned origins as its the same as the work around and gives me the additional stability and exporting of materials without having to set it up using the node tree.

Are you using 2.79 again or how do you come around creating nodetrees? I'm quite sure even the exporter won't throw errors, parenting armature<->armature won't work...not 100% sure, though

[Polynominal]

Are you using 2.79 again or how do you come around creating nodetrees? I'm quite sure even the exporter won't throw errors, parenting armature<->armature won't work...not 100% sure, though

I reverted to 2.79 for now, the original model was made there so unless I run into issues later I will be using it for now. Well currently I am creating a duplicate of the shape of the base plane and transforming that with the children being the base plane and its armature. I think this work around works both for the old 2.79 plugin and this new one.

parenting armature<->armature won't work...not 100% sure, though

I think urho3d thinks of armature as a component of the mesh while Blender gives it a node. So you could probably convert the armature transforms into a parent node and clear the original armature transforms which would restructure the scene a bit but preserve the parenting rules.

Good luck and thanks for the effort.