Writing Collada files with baked animation (as FBX does) has been proven to work well, so am fine with this approach.

Though it would be good to get feedback from existing users of Blender's Collada support - for a time we would likely have to include both until one can replace the other.

Blocking Issues

Noticed some issues which should really be resolved before accepting this patch.

• Raw, un-escaped strings written to XML (Using " in object name will break export).
• Temporary mesh data created on every export and never removed.
• Unnecessary string concatenation used on potentially very large strings.
• Path separator written as "/", should be os.sep or use os.path.join(...)

Suggested Changes

Asside from minor issues mentioned inline,
other changes I would recommend (but aren't essential for inclusion in Blender).

• Replace string concatenation with string formatting, see: https://developer.blender.org/diffusion/BA/browse/master/io_scene_x3d/export_x3d.py
• Follow general conventions for writing XML that are used in the X3D exporter, see: https://developer.blender.org/diffusion/BA/browse/master/io_scene_x3d/export_x3d.py (how strings are formatted, indentation etc..).
• use __slots__ for all classes, saves memory and dynamically defining new attributes isn't used anywhere here (with added advantage typo's in assignment raise an error).
• Pep8 style.

Hi;

I have started to test the Godot Exporter by comparing with what the Blender exporter does. I do not say that any difference is a bug on either side, its just a difference for now. So there is no judgement here from my side.

For now i found 2 things with static Mesh Objects:

• I tested the default Cube but removed 5 of the 6 faces (and it has edges and verts which are not connected to faces)
  • Godot: exports only the face
  • Blender: exports the face, the edges, and the verts

• I tested the Second Life character
  • godot: adds duplicate verts along the seams
  • Blender: Exports the mesh as is

More to come (if i can find any)

@Gaia I never really made any effort optimizing individual indices for each type of components, as this feature of Collada is not portable between DCCs (which use different approaches to smoothing), and also unsupported on 3D hardware (thus, useless for game engines).

Also, no optimization at all is done for Blend Shapes (vertices are repeated), I'm not sure it's possible to do it better without confusing importers.

@juan ferrer (juan): I am sure you have a set of cases where the Blender exporter fails but your exporter does it correct. Is it possible to add some blend files here with such examples? That would be super cool and speed up testing a lot.

In D1787#40517, @Gaia Clary (gaiaclary) wrote:

@juan ferrer (juan): I am sure you have a set of cases where the Blender exporter fails but your exporter does it correct. Is it possible to add some blend files here with such examples? That would be super cool and speed up testing a lot.

Gaia, I'm sorry, I don't have the time or resources to do that

In D1787#40519, @Juan Linietsky (reduz) wrote:

In D1787#40517, @Gaia Clary (gaiaclary) wrote:

@juan ferrer (juan): I am sure you have a set of cases where the Blender exporter fails but your exporter does it correct. Is it possible to add some blend files here with such examples? That would be super cool and speed up testing a lot.

Gaia, I'm sorry, I don't have the time or resources to do that

To avoid misunderstandings, all I know about the current blender exporter is that it doesn't work so users keep switching to mine. I have no idea what the current problems are nor I have time to find what it doesn't work

May I ask why Collada and not OpenGEX ?

In D1787#40582, @Alexander Zubov (motorsep) wrote:

May I ask why Collada and not OpenGEX ?

My experience is in Collada, If OpenGEX is supported, the more the merrier.

@Alexander Zubov (motorsep), please keep comments about Collada, other formats may be interesting to investigate but are off topic here.

@Juan Linietsky (reduz), we need to know the pros and cons for the exporter, issues can be resolved or defined as known limitations.
We just need to be aware of compatibility issues that arise from including this exporter.
Failing that we can always include as "Godot Collada" exporter, but its worth to at least check if this really replaces existing Collada for existing users.

Some questions/comments...

• Does this work to replace our Collada exporter for second-life? (currently the main use-case, if not why not... how much work is needed to add support?).
• Does this work for Google Earth? (I didn't use this in a long time but at some point google earth supported zipped Collada files, IIRC we had some users use our existing Collada support for Google Earth).
• That it splits geometry by UV's, normals is typical when formats are used for real-time output and not necessarily bad, but will annoy users who want to use their meshes in other applications. Is this an acceptable limitation that people who use Collada have to remove doubles after import? Or is there any intention to make splitting vertices optional behavior?
• Feedback from users of other engines/apps is needed... (if that wasn't already clear).

Campbell, with all due respect, I think your way of thinking is too conservative and missing the point. All this situation is happening because Ton complained publicly that game engines all depend from Autodesk and closed formats (FBX). We already know all other engines use FBX and have limited (or if any) support for Collada.

The motivation between proposing this exporter is to make Blender able to export the same information using Collada, using as a starting point an exporter that is known to adhere to the standard and export every little bit of information supported by the spec. This way we can approach those who make popular tools, such as Unity, Unreal, etc. and tell them:

"Hey, Blender is now exporting Collada files properly, with every bit of information required to be imported by your engine. As Blender is popular open source tool and we now support an open format properly, we would like to make sure you can read our files properly (or support the format)"

If we find use cases where it doesn't work, we can talk to whoever makes the application that is failing and ask them to fix it. If this is not possible and only if users need it to work, we can hack the exporter to make it work in that application. If changes need to be done (ie, reusing vertices better to export to other 3D DCCs), we make those changes.

To make it short, I can fix what is broken if it makes sense, but if the intention is integrating this as an "Exporter for Godot", I have no intention of doing any further work.

I added 3 blend files with some tests in them. All blend files use

• layer 0 for the original
• layer 5 for the back import of the blender exporter
• layer 15 for the back import of the godot exporter

For now i can not tell if one is better than the other. I see issues with both systems.
But i do not yet see where the one is a total broken system where the other shines with perfection.
I also know that blender' exporter has a lot of issues but i do not see where it breaks the Collada specifications.

If anybody else is willing to add some comparison blend files here i am sure that will help a lot. But honestly i believe it is the author of this addon who should contribute as well.

Again to avoid misunderstandings, we can work together on fixing and changing whatever is needed, but I will only spend my time on this if:

1. It is certain that this exporter becomes the default exporter and current exporter gets removed.
2. We, by default, take a stance of doing the push to make other applications support it properly, if not well supported.
3. We let users drive the required use cases, I don't want to do unnecessary work because of speculation

Please understand that my only intention is promoting the use of the format as an open alternative to FBX, not dealing with Blender internal politics. Godot users already learn by themselves to install the plugin, so having it included is no incentive to me.

@juan ferrer (juan): From my tests yesterday and today i can not confirm that your exporter "exports every little bit of information supported by the spec". No offense intended here, just clarifying the statements based on experiments :) thanks

In D1787#40618, @Gaia Clary (gaiaclary) wrote:

I added 3 blend files with some tests in them. All blend files use

• layer 0 for the original
• layer 5 for the back import of the blender exporter
• layer 15 for the back import of the godot exporter

For now i can not tell if one is better than the other. I see issues with both systems.
But i do not yet see where the one is a total broken system where the other shines with perfection.
I also know that blender' exporter has a lot of issues but i do not see where it breaks the Collada specifications.

I never mentioned it broke Collada specification, I mention that it's likely broken due to mising pieces that are not exported. I don't know which of them are.
Also feature wise, Does it support morph targets, multiple UV layers, detecting when a bone affects a morph target, single or multiple actions?

Oh and on addition to that, does Blender exporter support proper triangulation of meshes so TBN is correct and shown like in Blender viweport?
I also added a lot of internal state checking to my exporter to warn users when something will not be exported as they expect.. in order for them to fix it instead of silently failing. Examples of this are more than one armature assigned, unassigned weights, empty animations, etc (check all the calls to report in the code).

In D1787#40616, @Juan Linietsky (reduz) wrote:

Campbell, with all due respect, I think your way of thinking is too conservative and missing the point. All this situation is happening because Ton complained publicly that game engines all depend from Autodesk and closed formats (FBX). We already know all other engines use FBX and have limited (or if any) support for Collada.

The motivation between proposing this exporter is to make Blender able to export the same information using Collada, using as a starting point an exporter that is known to adhere to the standard and export every little bit of information supported by the spec. This way we can approach those who make popular tools, such as Unity, Unreal, etc. and tell them:

"Hey, Blender is now exporting Collada files properly, with every bit of information required to be imported by your engine. As Blender is popular open source tool and we now support an open format properly, we would like to make sure you can read our files properly (or support the format)"

If we find use cases where it doesn't work, we can talk to whoever makes the application that is failing and ask them to fix it. If this is not possible and only if users need it to work, we can hack the exporter to make it work in that application. If changes need to be done (ie, reusing vertices better to export to other 3D DCCs), we make those changes.

To make it short, I can fix what is broken if it makes sense, but if the intention is integrating this as an "Exporter for Godot", I have no intention of doing any further work.

We can call it how we like "Collada (realtime)" or "Collada (game-engines)" ...
Fix obvious bugs and include it as an option.

I don't see this as being especially conservative, on the other hand if you propose this replaces the existing exporter.
Then it makes sense to take care that this doesnt break existing use cases (SecondLife for eg).

In D1787#40620, @Gaia Clary (gaiaclary) wrote:

@juan ferrer (juan): From my tests yesterday and today i can not confirm that your exporter "exports every little bit of information supported by the spec". No offense intended here, just clarifying the statements based on experiments :) thanks

Well, of course there is a lot of information in the spec that it doesn't make much sense to export, I meant that it exports as much as possible based on what the spec offers.

We can call it how we like "Collada (realtime)" or "Collada (game-engines)" ...
Fix obvious bugs and include it as an option.

I don't see this as being especially conservative, on the other hand if you propose this replaces the existing exporter.
Then it makes sense to take care that this doesnt break existing use cases (SecondLife for eg).

I mean by conservative that you are just making decisions based on speculation, when all we have to do is care about real use cases.
I propose that we make a single exporter and then fix it based on what users complain that they miss.
As an example, If it doesn't work for Second Life (using this as an example, can be anything):

1. If no one complains, the problems does not exist.
2. If someone complains, and our files are exported inncorrectly or missing information, we fix it.
3. If we believe our files are exported correctly, we ask Second Life developers to fix their importer.
4. If we have no success (we are ignored), then we hack the exporter to work with Second Life.

Well guys, let's do the following. Feel free to keep evaluating my importer, but after thinking this well I realized it's too early to submit it to you for adoption.
Even though I believe I have ample experience with this format, It's difficult for me to substance my claims so it only results in meaningless arguments.

I'm already in talks with Unity and Unreal developers about implementing proper Collada importers in their game engines. They are interested in this possibility (guess no one likes to depend only on FBX) so I will be working with them the following months to ensure they can import properly from Maya and 3DS Max using the fantastic OpenCollada plugin.

Once I'm done I'll yet again submit my exporter for consideration, ensuring that it works flawlessly in game engines. I'm sure that this will make it easier to convince Blender developers to drop the existing one, and avoid these discussions.

I profoundly apologize for wasting your time these past days.

@Juan Linietsky (reduz), no decisions have been made, and I only ask for evidence - to check code works before including it in releases is not speculation, its the bare minimum if you propose to replace existing code.

If many users are using this exporter successfully, where are they? can you point to projects where they document to use this? blog posts, tutorials recommending this?

I don't say the code needs to be perfect before its included, having both exporters for a while is low-risk and fine.

regarding:

Again to avoid misunderstandings, we can work together on fixing and changing whatever is needed, but I will only spend my time on this if:

1. If no one complains, the problems does not exist.
2. If someone complains, and our files are exported inncorrectly or missing information, we fix it.
3. If we believe our files are exported correctly, we ask Second Life developers to fix their importer.
4. If we have no success (we are ignored), then we hack the exporter to work with Second Life.

While in general what you say is probably fine - setting some specific rules under which you will maintain the script is not really helpful either...
Of course we don't want to maintain multiple code-bases, and will eventually default to this one if it works best, fixing errors users face etc... but to be so rigid here only makes it difficult for us - their can be exceptions to rules, requirements may change over time.

As for your last reply on this topic, you suggest the exporter isn't ready... this gives us real mixed messages.

There are some issues to address but this isn't really so much work... and incremental improvements can be made as we need as part of general development.

In D1787#40729, @Campbell Barton (campbellbarton) wrote:

@Juan Linietsky (reduz), no decisions have been made, and I only ask for evidence - to check code works before including it in releases is not speculation, its the bare minimum if you propose to replace existing code.

If many users are using this exporter successfully, where are they? can you point to projects where they document to use this? blog posts, tutorials recommending this?

Most users are using it to export to Godot, and a few others to other platforms. I think probably my original message wasn't clear. I want to have proven support of Collada exporting to game engines, and then work with Unreal and Unity so they fix their importers. I am in talks about helping them do this at the moment, which should hopefully be done by the middle of the year. I just want some cooperation from Blender..

If you want proof though, here' s proof:

You have posts int the Godot forum with users having issues:

http://www.godotengine.org/projects/godot-engine/search?utf8=%E2%9C%93&messages=1&q=collada

Tutorial:

http://www.gamefromscratch.com/post/2015/09/28/Godot-Engine-Tutorial-Part-16-Using-Animated-3D-Models.aspx

For cases unrelated to Godot:

Here's Torque 3D developers happy because BetterCollada works for them, unlike Blender built-in:

http://forums.torque3d.org/viewtopic.php?t=523

Here' s Panda 3D recommending Godot's BetterCollada because you get better results:

https://www.panda3d.org/forums/viewtopic.php?f=2&t=18031

Here' s DAZ3D users reporting having to use BetterCollada:

http://www.daz3d.com/forums/discussion/58442/question-about-weight-mapping-genesis-3

While in general what you say is probably fine - setting some specific rules under which you will maintain the script is not really helpful either...
Of course we don't want to maintain multiple code-bases, and will eventually default to this one if it works best, fixing errors users face etc... but to be so rigid here only makes it difficult for us - their can be exceptions to rules, requirements may change over time.

I guess things are done different on every open source project, what I mean by rules that I would prefer to be held responsible for it working than having to spend time justifying why it works or it should be used.

Regarding maintenance I also have no idea how do you deal with this, but if it helps as reference my current plugin gets considerable feedback and contributions from the community. It should work the same if it's integrated to Blender I hope (though no idea how much users contribute on a project not hosted on Github)

https://github.com/godotengine/godot/commits/master/tools/export/blender25/io_scene_dae

In D1787#40735, @Juan Linietsky (reduz) wrote:

Regarding maintenance I also have no idea how do you deal with this, but if it helps as reference my current plugin gets considerable feedback and contributions from the community. It should work the same if it's integrated to Blender I hope (though no idea how much users contribute on a project not hosted on Github)

https://github.com/godotengine/godot/commits/master/tools/export/blender25/io_scene_dae

Good to see the links showing that this is being used, already.

Are you able to address the Blocking Issues I've noted?

If you think they're unreasonable, let us know why.

if you don't have time right now thats fine - do you have an idea when you might have time for it?
Otherwise we have to find someone else to work on this, which brings us back to the question of who maintains.

Hello, I'm an animator and rigger using Blender to make animations for games. I use predominantly .fbx to get models from Blender to Unity, but would be happy to have an alternative, open format to use.

I exported a few models with this Collada exporter from Blender to Godot and it works well in general. The animations and the mesh show as they should in Godot. However, the exporter would need an extra option, where you can export only the deform bones. Currently all of the bones get exported, including control and helper bones. These bones don't deform the mesh and are not needed in the game engine, but are used in Blender for easier rig control. It's the same option you can find in the fbx exporter.

Importing the .dae files to Unity 5.3.1 gives me an imported model and rig with proper bone hierarchy, but the animations don't import at all. Exporting the same files with .fbx works without issues.

The files I'm using are for a project which I can't share, but I can prepare a rigged model to test in the following days which I can upload here for others to try as well.

Some facts:

• If we are kicking out the current Collada module now, then Blender has no Collada Importer any more.
• Juan's Importer is not ready for Blender yet (he said so himself, not my words)
• Juan's exporter does not work for Second Life and needs to get some changes for that (see my blend files from yesterday)
• Blender's current Collada module has issues, which mostly can be fixed if someone with blender internal knowledge would spend a bit of time to get things into shape.

Our requirements

Looking at what is needed from user perspective, here are our Secondlife requirements (which are very low requirements after all):

• export to Secondlife: static Mesh, Materials, Rigged Mesh: armature, restpose, bindpose(*)
• export to Maya (and possibly to Max as well)
• import collada files made by Blender
• import collada files from Maya (and possibly from Max as well)

Of course others have much more ambitious requirements. Please tell us what is needed!

(*) Bindpose has been added to the Exporter by means of Custom Properties attached to the Armature. This was the best we could do without modifying Blender itself. The current Collada Module works for us.

A suggestion

We (Jesterking, Ideasman42 and me) had a bit of irc talk yesterday about what a good import/export system should provide. Here is what i understand how it could be convenient:

• a base module that covers all common cases (mesh, armature, object grouping, materials, light, etc...) This module is maintained by Blender developers and shipped with Blender out of the Box
• a mechanism for adding target specific modifications (using callbacks maybe). These modifications can be shipped with blender or they can be made by third parties and added as needed.

Such a system should be easy to maintain and easy to modify, so having this built in python sounds about right to us (for importer and exporter). I guess it is feasible to use Blender's addon system for providing the basic import/export Addon, and allow target specific addons which talk to the basic module.

Final Remark

I am fine with replacing the current system with something new. But then this new system must support import and export and should allow target system specific modifications (users must be able to add their changes independent from Blender e.g. by callback hooks).

As long as we do not have such a system i propose that we just keep with what we have and do a bit of effort to get the most apparent issues solved. Blindly replacing what we have with something new and then fixing afterwards whatever shows up as bug or missing feature is imho not a feasible option.

@Matjaž Lamut (lamoot) The Blender collada exporter has this feature (export only deform bones) and it is a for sure super easy to add this feature to whichever future exporter as well. So no worries :)

In D1787#40761, @Gaia Clary (gaiaclary) wrote:

Some facts:

• If we are kicking out the current Collada module now, then Blender has no Collada Importer any more.
• Juan's Importer is not ready for Blender yet (he said so himself, not my words)

I never mentioned kicking out the Collada importer module now, mine will need some work until it can be integrated and will definitely need help.

• Juan's exporter does not work for Second Life and needs to get some changes for that (see my blend files from yesterday)

I don't really have a clue about second life, so contributions to fix that are welcome. I would instead focus on contacting Second Life developers to fix their importer.

• Blender's current Collada module has issues, which mostly can be fixed if someone with blender internal knowledge would spend a bit of time to get things into shape.

That didn't happen in years, because there haven't been enough demand. Users want an exporter that works for game engines right now, and the current priority (using Collada for exchange between DCCs or Second Life) seems low. As you guys don't have much experience in this area (game engines) it is understandable that the exporter never really appealed to developers.

Our requirements

Looking at what is needed from user perspective, here are our Secondlife requirements (which are very low requirements after all):

• export to Secondlife: static Mesh, Materials, Rigged Mesh: armature, restpose, bindpose(*)
• export to Maya (and possibly to Max as well)
• import collada files made by Blender
• import collada files from Maya (and possibly from Max as well)

Of course others have much more ambitious requirements. Please tell us what is needed!

(*) Bindpose has been added to the Exporter by means of Custom Properties attached to the Armature. This was the best we could do without modifying Blender itself. The current Collada Module works for us.

Let's be honest for a second, Collada is a terrible format for exchanging data between 3D DCCs. Aren't there efforts to work on best suited formats for this such as Alembic, USD, etc? Even a plugin that reads .blend files in Maya would be a lot more appreciated than using Collada.
From the bottom of my heart I believe any effort towards this goal is time wasted, and that this energy should be used for implementing better formats to achieve this goal.

Collada is a format designed to export to game engines, period. The high usage, maintenance and volume of contributions to my exporter is proof of that. As such, the largest part of the effort should be pointed towards that goal. I understand that importing Collada might be desired, but this should be by far the lower priority.

A suggestion

We (Jesterking, Ideasman42 and me) had a bit of irc talk yesterday about what a good import/export system should provide. Here is what i understand how it could be convenient:

• a base module that covers all common cases (mesh, armature, object grouping, materials, light, etc...) This module is maintained by Blender developers and shipped with Blender out of the Box
• a mechanism for adding target specific modifications (using callbacks maybe). These modifications can be shipped with blender or they can be made by third parties and added as needed.

Such a system should be easy to maintain and easy to modify, so having this built in python sounds about right to us (for importer and exporter). I guess it is feasible to use Blender's addon system for providing the basic import/export Addon, and allow target specific addons which talk to the basic module.

Sorry, I don't believe in this kind of software design. I think one size fits all abstractions for unknown use cases are always doomed to fail. Let blender just expose the API and writing import/export is easy.

Blindly replacing what we have with something new and then fixing afterwards whatever shows up as bug or missing feature is imho not a feasible option.

I think this is the best way to develop software, use case derived. It keeps your feet in the ground and saves you unnecessary work in both design and implementation.

Hi, mind if I offer a little feedback, because I too have used Juan's addon to an extent to export meshes to Godot.

Right now, there's not a whole lot of issues I see with it from the perspective of a user, but I wouldn't mind seeing it optimized where possible and the code more organized where possible.

Also to note, do people care enough about Second Life these days to expect the exporter to work with it? For one thing, its development seems to have been largely abandoned for a while and you barely even hear of it now.

In D1787#40761, @Gaia Clary (gaiaclary) wrote:

Final Remark

I am fine with replacing the current system with something new. But then this new system must support import and export and should allow target system specific modifications (users must be able to add their changes independent from Blender e.g. by callback hooks).

We can of course generalize basics - calculating tangents, triangulating a mesh... splitting off vertex based on UV's.... etc.
But further not sure how this is relevant to patch review here.

As long as we do not have such a system i propose that we just keep with what we have and do a bit of effort to get the most apparent issues solved. Blindly replacing what we have with something new and then fixing afterwards whatever shows up as bug or missing feature is imho not a feasible option.

Agree, and for this reason I think its not sensible to make replacing existing collada export an initial target for including this add-on.

As long as we do not have such a system i propose that we just keep with what we have and do a bit of effort to get the most apparent issues solved. Blindly replacing what we have with something new and then fixing afterwards whatever shows up as bug or missing feature is imho not a feasible option.

Agree, and for this reason I think its not sensible to make replacing existing collada export an initial target for including this add-on.

Then it will simply never be replaced. What's the point of having two? People will use the one that works best for their needs instead of reporting the issues.

Did you see anyone reporting issues to the existing Collada exporter? No, they just went and downloaded mine and forgot that the built-in one exists.

I think a more sensible solution is to simply do away with the current Collada exporter. If an user has an export problem and, on this specific situation the previous one worked better, we will:

1. Make sure to know that there is a problem with the new one and fix it
2. Ask said user to use the previous Blender version (with the previous exporter) and export with that in the meantime.

It's not like content meant to be exporterd with Collada uses bleeding edge Blender features..

@Juan Linietsky (reduz), please respond to https://developer.blender.org/D1787#40736

In D1787#40777, @Campbell Barton (campbellbarton) wrote:

@Juan Linietsky (reduz), please respond to https://developer.blender.org/D1787#40736

Apologies. Currently working on finishing the 2.0 Godot release (likely by some time this week), will work on this afterwards

Greetings,

According to this document, OpenCollada implementation will be removed for 2.8 and replaced with a python solution.
https://docs.google.com/spreadsheets/d/1NjuEd3Dw7chJ9OyViyJn3MWQPcc6-zQM4yGFxuVFEfo/edit#gid=0

As I understand this removes the major concern/roadblock to further develop Better Collada exporter. One thing still missing for my use case (animation) is having an option to only export deform bones of a rig. Would it be possible to include such an option?

I'm attaching a simple rigged mesh with animations for testing. It shows a basic organization of a rig with deform, control and helper bones and how it's then exported to collada.