You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While writing the löve importer I noticed some potential issues with the export.
The biggest is probably the problem already described in Some problems whith exported sample #67 , where changing images in an animation are not possible, since there are no multiple "display"-elements exported and the displayIndex is always exported as -1 for each keyframe.
Is the edges field actually part of the DragonBones file format? Even if it is, why not just export (way more interesting and closer to the implementation) vertex indices?
(optional) I think it would be nice to export slot attachments of type "image" instead of mesh per default, if the image is only weighed to a single bone. Because now either you have to detect that case yourself and convert subsequently or you have to implement skinning, when in most cases it is not needed. This would also imply that you would have to parent the attachments to the bones they are actually parented to (because at the moment all are parented to the armature itself, which is also kind of weird btw.) and also that you export a file that contains information about the atlas (preferably the format DragonBones also uses). This is a not so minor change, but I thinkt it would provide more similar exports and easier implementation of runtimes.
(this is probably my fault) It seems like the bone transformations (in the animation/keyframes) are only partially relative to the bind pose. The position seems to be in world space. This was very weird to debug but, I only got it to work like this:
Where bone.bindTransform:compose() multiples the bindTransform from the left with the bone transforms. I have to overwrite the positions then, because otherwise the translations are all wrong (rotated and such). I think this is my problem because the files work fine in DragonBones too, I think. It might even be, that it is a fault of the format and you discovered this yourself. But I would love to know what this is about.
The text was updated successfully, but these errors were encountered:
While writing the löve importer I noticed some potential issues with the export.
"triangles":[1,0,3,0,2,3]
). In fact just for the COA export (because I don't want to deal with the edges) I had to add something like this:Is the edges field actually part of the DragonBones file format? Even if it is, why not just export (way more interesting and closer to the implementation) vertex indices?
(optional) I think it would be nice to export slot attachments of type "image" instead of mesh per default, if the image is only weighed to a single bone. Because now either you have to detect that case yourself and convert subsequently or you have to implement skinning, when in most cases it is not needed. This would also imply that you would have to parent the attachments to the bones they are actually parented to (because at the moment all are parented to the armature itself, which is also kind of weird btw.) and also that you export a file that contains information about the atlas (preferably the format DragonBones also uses). This is a not so minor change, but I thinkt it would provide more similar exports and easier implementation of runtimes.
(this is probably my fault) It seems like the bone transformations (in the animation/keyframes) are only partially relative to the bind pose. The position seems to be in world space. This was very weird to debug but, I only got it to work like this:
Where bone.bindTransform:compose() multiples the bindTransform from the left with the bone transforms. I have to overwrite the positions then, because otherwise the translations are all wrong (rotated and such). I think this is my problem because the files work fine in DragonBones too, I think. It might even be, that it is a fault of the format and you discovered this yourself. But I would love to know what this is about.
The text was updated successfully, but these errors were encountered: