Closed Cyp closed 5 years ago
Let's see, if dublicating the nodes can be avoided ...
A refactored exporter is now enabled by default. It now creates one animation per node, possibly fixing your issue. @Cyp, could you verify that the parent inverses are now correct?
Sorry for the late response.
Seemed to still be getting the issue, but actually it's completely failing to save anything, so I'm not sure…
Doesn't seem to be working, after trying to reset the settings, when saving I'm getting this:
Traceback (most recent call last):
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/__init__.py", line 376, in execute
return gltf2_export.save(self, context, export_settings)
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/gltf2_export.py", line 85, in save
generate_glTF(operator, context, export_settings, glTF)
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/gltf2_generate.py", line 2872, in generate_glTF
generate_animations(operator, context, export_settings, glTF)
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/gltf2_generate.py", line 802, in generate_animations
process_object_animations(blender_object, action)
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/gltf2_generate.py", line 628, in process_object_animations
if blender_action.name not in animations:
AttributeError: 'NoneType' object has no attribute 'name'
location: <unknown location>:-1
And (not really related, I think), I couldn't even get back in to the export menu after selecting export indices to UNSIGNED SHORT
.
Traceback (most recent call last):
File "~/.config/blender/2.79/scripts/addons/io_scene_gltf2/__init__.py", line 291, in invoke
setattr(self, k, v)
File "/usr/share/blender/2.79/scripts/modules/bpy_types.py", line 611, in __setattr__
return setattr(properties, attr, value)
TypeError: bpy_struct: item.attr = val: expected a string enum, not int
location: <unknown location>:-1
In def process_object_animations(blender_object, blender_action):
, I'm getting blender_action
is None
, for one of the two objects I was testing with. Not sure if something weird happened to the object, I had one animation set, and somehow when searching in the outliner for an old animation that isn't used, blender was incorrectly saying that the object had it. I then manually deleted it in the outliner, and it finally disappeared. Before that, it seemed to be applying a combination of the animations when exporting.
For the weird object, the down-arrow for "Switch to editing action in animation layer below the current action in the NLA stack" is permanently enabled (clicking has no effect), while the up-arrow is permanently disabled. For a normal object, both arrow buttons are disabled. I don't know what a NLA stack is, and have never used one.
Finally managed to un-weirdify the object by deleting an "Action stash" in an "NLA Editor", and now it can again export animations for the object.
Now that I can actually test the issue, it seems to still be exporting the same animation for both objects, not taking the different parent_inverse
s into account.
Here's a workaround for thrown exceptions I encountered while trying to export — don't know whether it's appropriate to push to master, since the animation with the [Action stash] ends up not being exported, adding here in case it's useful: https://github.com/KhronosGroup/glTF-Blender-Exporter/commit/02fad15f41d56933455f4f44e5e1a13c6e5de4d5
The mesh of two objects with the same mesh but different sets of modifiers seems to not get duplicated either.
Not sure if this ticket was migrated from glTF-Blender-Exporter to glTF-Blender-IO, or if I reported there directly after reading something about that new tickets should be reported there instead, but this bug report was based on glTF-Blender-Exporter.
Testing again after switching from glTF-Blender-Exporter to glTF-Blender-IO, it seems to be the opposite problem — the animation sampler inputs and outputs are duplicated, even with the same parent inverse, and meshes with modifiers are duplicated, even if the modifiers and auto-smooth angles are the same. What remains is then a performance and file-size issue, rather than a correctness issue.
Thanks for following up on this @Cyp – when testing with glTF-Blender-IO now, are you using Blender 2.8 or 2.79? And could you share a model that reproduces the issue?
Using 2.79b. Haven't tried 2.8.
test.blend.gz → test.gltf (had to rename the .gltf to .gltf.txt to be allowed to upload)
Note that SphereA
and SphereB
have duplicated mesh data, even though they have the same modifiers.
Note that Cube
and SphereA
have duplicated animation data, even though they have the same animation and same parent inverse.
Since modifiers can depend on vertex sets, which seem to be per object instead of per mesh, I think testing modifiers for equality might be complicated. But if possible, it's probably better to.
I think #280 and #281 may improve things, if you're able to check.
Tested — those didn't affect my test case. They seem to be to do with skinning, which I'm not currently using.
Note that SphereA and SphereB have duplicated mesh data, even though they have the same modifiers.
The two spheres have no logical connection to us. They both use the mesh data of the cube, but they both have modifiers so we have to create (modified) mesh data for them. That they both have the same modifier setup, is unknown to us.
Note that Cube and SphereA have duplicated animation data, even though they have the same animation and same parent inverse.
They need separate animation data in glTF because they have the same parent inverse. If they would share the same animation data, their resulting world space translation would be identical.
Edit: Oh, you are talking about sphere A! In that case, sharing animation data would work indeed, but to know that two objects can share animation data, we would have to check that their original transform is completely identical which doesn't work for the same reasons as above with the modifiers.
Sharing animation data should be possible. See #340 for a partial solution which at least shares the sampler inputs/outputs.
That looks pretty cool!
Is there still an issue here, or can I close this ticket?
If multiple nodes use the same animation, and the nodes have different parent inverses, the animations are wrong for nodes with a different parent inverse to the first node.
I'm not sure what a sane solution is that doesn't involve duplicating the animation (with different parent inverses applied to it), but reporting in case there is a possible solution.