godotengine / collada-exporter Goto Github PK

I think this should be a checkbox option among the other options: No nodes above top object

When importing the dae made with this exporter, the animation player is child of a spatial node, which is a child of the automatically created root node on import to godot.
root->spatial->armature,animationplayer

When importing dae made with blender's collada exporter, animation player is parented to the armature (like intuition tells me it should; it shortens each track's node path)
root->armature->animationplayer

I cant tell if this is because of how the exporter handles Armatures or Animations. I thought it might be an importer issue, but the blender exporter exports it so its less bloated, so it is probably an exporter issue.

I tried exporting the animation player separately from the armature+mesh, but the bone mapping/ animation is severely distorted

I just got this error and after much work in weigth paint of my gun no have any solution.I create model in makehuman then exported to blender and impot a free Gun model then create all rigs and animations.I know error with more of 1 object for export give error everytime.

I just export with sucess to .FBX and .OBJ default format of blender 2.75 without any error

please look a blender forum i posted but not answer cause is not a blender error is problem with better collada dae only http://blender.stackexchange.com/questions/65380/export-error-to-better-collada-object-has-unassigned-weights

please if anybody know how solve that please contact me to [email protected]

thank you

Currently the script uses both single and double quotes, with double quotes being more prevalent. For this reason, it would be better to be consistent and use always double quotes.

Blender developer Campbell Barton suggested a lot of changes. I created tickets for all of them (#3, #4, #5, #6, #7), but his code review should also be implemented.

It appears the collada exporter is inserting originally-non-existing keyframes and tracks for vertex group which don't appear in the action at all. I initially thought Godot was responsible for this but in
this issue, I believe reduz is saying that it is collada-exporter that is creating such keyframes, and nothing can be done on Godot side after the collada file created.

I'm using this exporter for Horde3D, and so far it's been doing better than the default DAE exporter, but I'm still having trouble with animations.
By animations I mean that one "Idle" animation.

Here's my export settings:

However my animations end up "empty" in the DAE file:

<library_animation_clips>
	<animation_clip name="Idle" start="0.0" end="1.0">
	</animation_clip>
</library_animation_clips>

(Continued from godotengine/godot#5457)

Alright, so last time the Better Collada Exporter was submitted to the Blender devs they rejected it and gave some changes to implement, but now after some work their suggestions have been implemented and now the plugin is in pretty good shape for a second round.

Anyone closely involved with Godot's development (pinging @reduz @vnen @akien-mga @Calinou) willing to submit it to the Blender devs? Preferably someone patient, as from what I've seen from @reduz's thread on the Blender mailing lists they can be picky, and it'd be the best for everyone involved (including other engines) if BCE got merged into Blender and their devs contributed to it.

I have a female character, the body is rigged with the blender default human rig, and the hair of her is rigged with another armature parented to the head bone.

azuka.new.zip

It works great on blender, but when I export to godot the hair doesn't become parented properly.

I already tried to test this on unity as well and the same problem appears, it seems is not just a godot issue.

This change is important, as the BCE should leave the user's Blender instance untouched.

        mesh = node.to_mesh(self.scene, apply_modifiers,
                            "RENDER")  # is this allright?

this mesh should be explicitly removed after use with:

bpy.data.meshes.remove(mesh)

Only affects meshes created in lines 428 and 538, so it should be an easy fix.

To recreate this bug:

1. Create a cube in blender
2. add a texture to it
3. delete the world node
4. export
   

Moved from godotengine/godot#1312, originally by @SuperUserNameMan:

The "Triangulate" option of the Better Collada Exporter is not really compatible with "Shape-Keys" (morph) animations.

If the "shape-key" animated mesh contains polygons other than triangles, and if it is exported with "triangulate" option set to ON, then, once imported into Godot, the vertices of each morph targets won't match. (I tried with a simple deformed cube)

If you re-export it with "triangulate" to OFF, then, Godot will warn you about "Primitive polygon not well supported (concave shape may fail)".

The only workaround i've found is to triangulate the mesh using a modifier into Blender, just before creating the Shape-keys.

I was working with this model from OpenGameArt:
https://opengameart.org/content/pinguin-low-poly

Using the better-collada exporter on the model outputs it with its plain grey material, but not the UV texture.

Blender's own collada exporter has the option to select either "Materials" or "UV Textures" in its texture options. Using the default exporter with "UV Textures" creates a png file of the texture, and gives the result I expect when imported to Godot.

I'm not very experienced with Blender, so I don't know if there's some unusual/anachronistic set up in that particular .blend file, but I've searched extensively without getting it to work with better-collada.

When i export the model,i receive the following error:
Traceback (most recent call last): File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\__init__.py", line 172, in execute return export_dae.save(self, context, **keywords) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 1966, in save exp.export() File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 1876, in export self.export_scene() File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 1522, in export_scene self.export_node(obj, 2) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 1467, in export_node self.export_mesh_node(node, il) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 1051, in export_mesh_node meshdata = self.export_mesh(node, armature) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 601, in export_mesh mat, mesh.show_double_sided) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 255, in export_material imgid = self.export_image(ts.texture.image) File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\addons\io_scene_dae\export_dae.py", line 189, in export_image if img_tmp_path.lower().endswith(bpy.path.extensions_image): TypeError: endswith first arg must be str or a tuple of str, not frozenset

Path separators are written as plain strings, such as this:

dstfile = basedir + "/" + os.path.basename(imgpath)

this is bad practice. They should be written as this:

dstfile = os.path.join(basedir, os.path.basename(imgpath))

First I would like to explain the reason I need this.
If I merge the whole scene in to one object I can just put -col, but for some reason Godot physics system will allow me to pass through the corners of the walls if I persist.
So the sollution was to have several separated models for each wall and of course separated collisions.
This created a furstated situation cause I had to manualy change the name of every object (walls, floors, etc) so I made a little change in the exporter to add the ability to export every model with -col.
Cause I am not sure how to participate in this commit, I genaraly do not know how to work with a team in github, I upload here a zip file with the changed addon.

The files changed are : init.py
lines: 93-97 contains my additions

and the file : export_day.py
lines: 1432-1434 other additions
and changed line 1437 from node.name to node_name

io_scene_dae_all_collisions.zip

In many case string concatenation is used where string formatting should be used.

For example:

        return "id-" + t + "-" + str(self.last_id)

should be:

        return "id-{}-{}".format(t, self.last_id)

Taken from https://github.com/godotengine/collada-exporter/blob/9e89ca5/io_scene_dae/export_dae.py#L30-L39

• Materials & Textures
• Optionally export Vertex Colors
• Morph Targets
• Control bone removal
• Copy textures
• Export Keyframe Optimization
• Blender native material? (?)

Hello,

When exporting a scene with images everything is fine, but when i export again the same scene over the previous .dae file it does not overrides the images. Instead the old images are kept. This behavior looks strange. It would be better if the new images are saved over the old ones.

If the cause of the current implementation is security reasons (to do not "accidentally" override some other important files) it is possible to rename the textures folder from images to {DAE filename}_images or something similar.

Right now none of the blender collada exporters support custom properties.

I'll be working on patching this exporter soon, is this a feature that would be upstreamed easily?

Moved from godotengine/godot#772

From @EngjellRraklli:

Parenting a mesh to a single bone of an armature in blender is not supported when exported in Godot,which means that the mesh doesen't move if the bone moves.

From @reduz:

I'm not really sure how to export this properly with collada. Tried a few ways but didn't have much success. I will wait until the OpenGEX exporter works, and try again with that.

As reported here (it's mostly about whitespace).

Software versions

OSX High Sierra.

2 day old master branch godot

better collada commit number 836241a

WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
WARNING: _parse_mesh_geometry: Primitive type "polygons" is not well supported (concave shapes may fail). To ensure that the geometry is properly imported, please re-export using "triangles" or "polylist".
   At: editor/collada/collada.cpp:1060.
ERROR: load: Condition ' !collada.state.visual_scene_map.has(collada.state.root_visual_scene) ' is true. returned: ERR_INVALID_DATA
   At: editor/import/editor_import_collada.cpp:1404.
ERROR: import_scene: Condition ' err != OK ' is true. returned: __null
   At: editor/import/editor_import_collada.cpp:1936.
ERROR: get_dependencies: Condition ' !f ' is true.
   At: core/io/resource_format_binary.cpp:1046.
ERROR: load_interactive: Condition ' err != OK ' is true. returned: Ref<ResourceInteractiveLoader>()
   At: core/io/resource_format_binary.cpp:996.
ERROR: _load: Failed loading resource: res://.import/walls_only.dae-2495f74eb8f5b57224687e700f224e50.scn
   At: core/io/resource_loader.cpp:185.
ERROR: _load: Failed loading resource: res://walls_only.dae
   At: core/io/resource_loader.cpp:185.
ERROR: remove_scene: Index p_idx=1 out of size (edited_scene.size()=1)
   At: editor/editor_data.cpp:491.

steps to reproduce

1 open .blend model
2 export with better collada
3. load scene into godot
4. error loading

expected result:

Scene is loaded like the official gltf 2.0 exporter

https://github.com/KhronosGroup/glTF-Blender-Exporter/tree/master/scripts

blender model.

gtlf2.0: created by the official khoronos exporter

scene models

walls_only.zip

I have a main Blender file which contains a rigged character. And if I create a separate Blender file which imports the rig from the main file and adds animations, Better Collada fails to export them, resulting in an AnimationPlayer without any tracks.

Currently, the option to exclude control bones works in such a way that any bone that is either set to non-deforming or its name begins with the prefix ctrl is not included in the export.

However, there can be certain cases where you want to include certain control (non-deforming) bones but not others. For this to work, we need to split the option into two different options that provides filtering based on bone names and deforming capabilities individually.

There are a lot of comments and docstrings which are either:

• Wondering if something works
• Redundant
• Commented out code

They are confusing and make the script look amateurish, so I think they should be removed.

Slots in Python can be used to optimize memory usage in class instancing. The Blender dev suggest using them for all classes, although I don't know if there is enough instancing to gain significant boosts in performance (and I read that if Python 3 is used, they are even fewer).

Hey there,

I'm one of 0 A.D.'s devs I might have met some of you in Lyon this year, and I have an issue with the script. I'm using a script I made there to generate game specific skeletons for my game, and when using the default exporter it works fine, but when doing so with yours it messes up every name by generic ones is it something I'm doing wrong ? (Since it messes up names I can't use it for the game)

https://github.com/StanleySweet/0AD-Skeleton-Generator

Gaia Clary, the OpenCollada maintainer, suggested that a Python-based importer is developed here.

This might be of little concern to Godot, of course, but now that BCE is its own thing and that a Blender dev implied that having an importer would improve the chance of BCE making it into Blender, I think it might be good to at least take into consideration the possibility and find out how many of us would be able to contribute to it.

I have no experience with the Blender API outside of my involvement with BCE but I have Python experience and can work with XML, so I would be willing to contribute. The problem is that I don't have much time to code, so unless someone else is willing to collaborate (especially on the Blender parts) I am afraid I won't be able to deliver soon enough.

Anybody willing to work on it?

The repository license states that it uses version 3, but in the files, it says version 2.

Blender often uses . character for a name.
But Godot does not allow . or / for node name.
So better collada should replace it with something another.

I have posted this issue on every place that I know in order to find an answer with no luck.
The problem is about custom collision shapes, I made a car and I made a collision shape for it, but when importing it in Godot, using the -colonly command (EDIT: I have found the official mentions about the commands, I am really sorry, but still that doesn't solve the issue) it creates a separate node for the collision shape that canot be accesed by the root(VehicleBody) node, so it asks me to give it another collision shape in order to work.

This is my Blender project setup:

I could't find any informations on how to solve this on the web and in the documentation.
Also Blender cannot export .res, .tres and .shape files so I cannot add it that way either, and there are no mentions on how we can actually make those type of files on the web or in the docs.

Moved from godotengine/godot#4074:

@Lamoot wrote:

Testing the Better Collada Exporter for Blender, I notice all of the bones in a rig get exported to Godot. A desired way would be to only export those bones that directly influence the mesh (i.e. deform bones). In Blender, bones can be flagged as being 'deform' bones and e.g. the FBX exporter has an option to only export those. It would be nice and very much needed for Better Collada to support this.

A rig is usually made from many bones. There are deform bones which directly deform the mesh, then there are control bones that are used to animate, and also helper bones. Together they make a rig comfortable to use and animate. However, for games, you only need the deform bones, the rest can and should be discarded.

Hi there.

I modified the script to get rid of the error about endswith() expecting str or tuple, not frozen set. Changing this if condition in line 189:
if img_tmp_path.lower().endswith(bpy.path.extensions_image):

To:
if img_tmp_path.lower().endswith(tuple(bpy.path.extensions_image)):

Solves the problem perfectly. It's too little of a change to clone and make a pull request, so I will leave this little fix as an issue here. I exported a couple of times with no problems, I can't tell for sure if it will ever present some undesired behavior, but so far it does the job.

Thanks.

When I create a model facing the negative Y axis which is the default 'forward' direction in Blender (can be seen by switching to the front view / NUM1), it is exported as having the Z axis as its foward vector.

This behavior can cause confusion, since Godot uses the negative Z axis as the forward vector for global and local coordinates.

We should change this to match Godot's convention, or add an option to let users to decide which coordinate system they want to use.

The blender better collada exporter is not correctly exporting mesh vertex normals. It has the same sort of incorrect shading result that the native blender collada exporter has. The image below illustrates the issue.

The far left model has been modelled in blender and shows the correct normals shading. Next to it in blender is the reimported .dae model that had been exported via the better collada exporter. Both the triangulate and tangent arrays options were used for the export. It clearly shows that there are normals issues.

On the right side are 2 collada imports into Godot3. On the far right is the incorrect result imported as .dae from the better collada export. On the left is the correct result, still as a dae import. However to achieve this I had to export an obj from blender, import this into Cinema4D, export as a collada(1.4) to then import into Godot3.

This does show that Godot is importing a .dae file and it normals correctly (actually doing a better job than Blender, which cannot import its own exported dae correctly! It even imports the cinema4d dae export incorrectly). The problem lies with the blender exporter, with both the default blender collada and better collada exhibiting the same issue.

The zip file contains the blender(2.78) file and godot3 file.

collada_normals_issue.tar.gz

Seems like this only supports one animation

My blender object is just a plane with a solidify modifier to give it thickness.

When I export it, the thickness information is not exported.
However if I apply the solidify modifier and then export, it works correctly.

Currently the Godot Export Manager only supports exporting Collada files. But since glTF 2.0 and Godot's exported scene are going to be more popular exports in the future, I think the Godot Export Manager should be separated from Better Collada and be made to support all 3 exports, allowing the user to select which export to use.

If the model is exported when it's not in base pose, the armature modifier gets applied to the model, leading to the model to be deformed in a not proper way. There should be a way, when exporting the model, to exclude the armature modifier from being applied to the geometry. Even in base pose, the armature modifier should not be applied because, depending on the type of rig, even the armature in complete rest position could differ from the original model due to bone constraints.

Blender:

Godot:

Demo:
AnimationBugs.zip

flake8 points out many unused variables. They should be removed (after testing making sure that they are indeed unused, in case they call functions with side effects).

Here they are:

• ./godot_export_manager.py:53:9: F841 local variable 'split' is assigned to but never used
• ./godot_export_manager.py:55:9: F841 local variable 'ob' is assigned to but never used
• ./godot_export_manager.py:68:9: F841 local variable 'op' is assigned to but never used
• ./godot_export_manager.py:130:9: F841 local variable 'ob' is assigned to but never used
• ./godot_export_manager.py:131:9: F841 local variable 'slot' is assigned to but never used
• ./godot_export_manager.py:313:9: F841 local variable 'scene' is assigned to but never used
• ./io_scene_dae/export_dae.py:561:9: F841 local variable 'has_uv' is assigned to but never used
• ./io_scene_dae/export_dae.py:562:9: F841 local variable 'has_uv2' is assigned to but never used
• ./io_scene_dae/export_dae.py:563:9: F841 local variable 'has_weights' is assigned to but never used
• ./io_scene_dae/export_dae.py:653:21: F841 local variable 'zero_bones' is assigned to but never used
• ./io_scene_dae/export_dae.py:1622:9: F841 local variable 'frame_total' is assigned to but never used

My blender object has key-frames every 4 frames,
but when i export a 33 frame animation, I get 33 key-frames, rather than 9.
I have tried blender version 2.78 and 2.79b.

Steps to reproduce

• Export a model with a material with any Specular Intensity value from Blender
• Import the model in Godot 3 beta 1

Expected behavior

The material will have metallic_specular value to be equal to Specular Intensity value from Blender

Actual behavior

The material metallic_specular value is 0.5

Hello!
There is a blender model with the character and simple walk animation
Vasya_2.zip
Here is the export settings:

That's how exported DAE file looks like in the Godot:

Mesh does not follow the bones, some parts of the mesh are floating in the air.
Resulting DAE file size is 861 Mb, but it is the less of all evils :)
Another problem with this model: if Shape Keys option is not checked, then the DAE can not be generated at all because of the script crash:

I've checked this with the HEAD version of the exporter in this repository and also in the exporter version that can be downloaded from https://downloads.tuxfamily.org/godotengine/collada-exporter/BetterColladaExporter-latest.zip
I've also tried to export this model to GLTF & escn too, but these attempts failed as well. This animation just can not be exported, and I've ran out of options :(

Hello,
I was testing the output of the Collada Exporter with an XML Schema validation tool and it turns out that there are small errors.

I was validating a simple scene with Suzane only (no materials, no images, just default suzane, camera and lamp). The command tool that I was using is xmllint which is part of libxml2-utils. To perform the validation you may use the command:

xmllint --noout --schema http://www.khronos.org/files/collada_schema_1_4_1.xsd untitled.dae

The output of this command is:

untitled.dae:13: element library_images: Schemas validity error : Element '{http://www.collada.org/2005/11/COLLADASchema}library_images': Missing child element(s). Expected is one of ( {http://www.collada.org/2005/11/COLLADASchema}asset, {http://www.collada.org/2005/11/COLLADASchema}image ).
untitled.dae:15: element library_effects: Schemas validity error : Element '{http://www.collada.org/2005/11/COLLADASchema}library_effects': Missing child element(s). Expected is one of ( {http://www.collada.org/2005/11/COLLADASchema}asset, {http://www.collada.org/2005/11/COLLADASchema}effect ).
untitled.dae:17: element library_materials: Schemas validity error : Element '{http://www.collada.org/2005/11/COLLADASchema}library_materials': Missing child element(s). Expected is one of ( {http://www.collada.org/2005/11/COLLADASchema}asset, {http://www.collada.org/2005/11/COLLADASchema}material ).
untitled.dae:552: element library_controllers: Schemas validity error : Element '{http://www.collada.org/2005/11/COLLADASchema}library_controllers': Missing child element(s). Expected is one of ( {http://www.collada.org/2005/11/COLLADASchema}asset, {http://www.collada.org/2005/11/COLLADASchema}controller ).
untitled.dae fails to validate

When opening the file with a text editor we can see that there are empty node in the corresponding lines like:

<library_images>
</library_images>
....
<library_effects>
</library_effects>
...
<library_materials>
</library_materials>
...
<library_controllers>
</library_controllers>

I guess there should be some kind of logic that if these elements does not have children - they should not be exported.

Someone may perform this validation with a more complex scene.

There is this script godot_export_manager.py however there is no mention of it in the README or how to use in Blender? Is it a one-off to run in the script window, or is it to be installed somewhere?

The README only mentions to install the io_scene_dae directory, not this script.

Let's take a look at this parrot model:
parrot.zip
load it and select the animation called "surprise" in the dope sheet. Take a look at the wings:

Now export it to dae format with the following settings enabled:

Place the resulting dae in the Godot, select the animation "surprise" in the AnimationPlayer node and take a look at the wings:

Tail motion isn't correct too, it seems that the skeleton does not follow the geometry well (somehow it outside the parrot body):

Currently the BCE uses raw string output to create XML elements:

self.writel(S_FX, 3, '<newparam sid="' + surface_sid + '">')

This is both hard to read and hard to write. The Blender team suggests using string formatting like they did here:

fw('%s<Coordinate USE=%s />\n' % (indent, mesh_id_coords))

I suggest something entirely different and in my opinion easier to both read and write (since it takes care of indentation automatically, and is also less error-prone) - using xml.etree.cElementTree to generate the XML (which is fast enough) and then use xml.dom.minidom to prettify/indent it (both are included in the standard library).

Hello Guys,

in Blender 2.8 you can create collections in a Scene and i wonder if those will be supported in the collada exporter.

https://code.blender.org/2017/09/view-layers-and-collections/ as you can see here the Scene structure was changed.

I assume that nested Layers should fit perfectly in Godot.

Best regards