Page MenuHome

2.8: Proposal: Remove OpenCollada
Closed, InvalidPublicDESIGN

Description

This proposal is to drop OpenCollada (C++ API), replacing it with an export only add-on.

The main reason behind this is Collada has not proven to be a very reliable interchange format and OpenCollada is quite a heavy dependency.
Effort can be better spent on glTF format which seems to better fit for us.

For reference:

Event Timeline

Campbell Barton (campbellbarton) renamed this task from T52776 Proposal: Remove OpenCollada to 2.8: Proposal: Remove OpenCollada.Jan 31 2018, 1:46 AM
Campbell Barton (campbellbarton) lowered the priority of this task from 90 to Normal.

Not really related to the task itself but the spreadsheet is in the recycle bin so it will be removed if left there, you might want to move it out if you don't want it deleted.

This keeps coming up, and i don't think this ever got decided on? I remember people wanting to kill it in the past, but afaik there have never been any consensus on actually removing it.

of all our dependencies i admit its one of the larger binaries, but

  1. it's easy to build/maintain for platform devs
  2. It has a very active maintainer on the blender side of things.
  3. afaik any issues the format has, are due to the format not due to the integration (ie vendors are allowed to define custom extensions , any py based exporter will have the same issues)
  4. The people that'll work on glTF are most likely not the people working on collada.

so why are we hellbend on getting rid of an integration that has a very active maintainer while other parts of the code are withering away and are allowed to stay (*cough*bge*cough*) ?

First of all I would dispute that Blender's Collada import/export is well maintained.
It is maintained in the sense that it is kept from being entirely broken.
But there remains quite a few issues especially with animation import/export which nobody has the time/interest/ability to solve:

From what I can tell Blender's Collada support is basically second-life-collada support, at least when it comes to animation (@Gaia Clary (gaiaclary) correct me if I'm wrong).
Godot ended up writing their own add-on instead of trying to fix the current C++ code. See link. While this doesn't prove Blender's Collada support is bad - it's an example where others weren't able to use it, coupled with all the open issues and questions/TODO's in the code (see P601), this doesn't give me confidence that this is a code-base worth supporting.

The accumulated time of:

  • Checking reports in the bug tracker.
  • Making sure changes to Blender don't break Collada.
  • Keeping the library building/up to date on all platforms.

... adds overhead. 2.8x is a good time to consider dropping support for features that aren't worth keeping - hence this proposal.

I stand corrected, that's a lot more tickets than i was expecting, i was under the impression that @Gaia Clary (gaiaclary) dealt with most tickets coming in within a couple of days.

Should this decision be postponed until the IO C/C++ library system is in place and evaluated to work at an acceptable level?
We have D2835 and a GSoC 2018 idea for now. No libraries have been implemented yet.

@Vuk Gardašević (lijenstina) don't think there is any reason for C/C++ Python modules to make a difference here.
They are more of a way to optimize existing scripts.

hi;

First of all: Yes, i am getting active with Collada mostly when it comes to Second Life support. But that is so, because i know most about the parts of Blender and Collada which are needed for this.

Second: I see where Collada has flaws. But my impression always was that the root cause of most issues was with the Blender integration and not with flaws in the Collada format. Extensions are not so worrying (and IMHO are only relevant for the importer part).

Third: I have been getting much less active in the past year because i was told many months to wait a while until 2.8 is stable enough to step in. I know i could have worked in master but i had the impression that i would end up with duplicate work, which may be a wrong impression though after all :(

Fourth: I have often mentioned that i can not solve some of the problems because i either do not understand the problem, or i do not understand the blender part of the integration. Asking for help is often tedious, especially IRC is more of a frustration than a help for this, i know there are more important things to do, but still.

Fifth: It is funny to see that this pops up again just one week after i have started to take care of the module again :) Its a bit like whenever i start working on it someone steps up and wants to remove it. That was the case since ever :(

So, i continue working on the module until you guys delete it. I only ask you to be fair and tell me a bit in advance when you decide to drop it.

cheers,
gaia

Thanks for sharing your perspective, I realize this is quite some work for you and it's not like our collada integration is completely useless, I just opened this task to try come to some resolution as to weather the C++ OpenCollada support is worth keeping.

So, i continue working on the module until you guys delete it. I only ask you to be fair and tell me a bit in advance when you decide to drop it.

This isn't a nice way to handle things - while I've made a case for removing OpenCollada - this isn't decided,
as maintainer I'd like to hear you make the case to keep OpenCollada integration or you're suggestions for what a good way forward might look like.

We could include the Collada add-on and drop OpenCollada once you can confirm the add-on works for second-life for e.g.

Hi, Campbell;

Ok, ...

  • here are my opinions for why keeping OpenCollada in Blender is a good thing:
    1. OpenDollada is rather stable and rather complete.
    2. OpenCollada supports import and export.
    3. The integration in Blender works basically, though it could need some rework for improving.
    4. The support for Secondlife is almost complete, so from my side it works almost well.
  • Here is what i think needs to be checked before any decision is made. Maybe some others could help me doing this:
    1. Reworking the open issues to check which of them are still relevant (I am already working on this actually)
    2. Check which issues would take a lot of time to get fixed
    3. Check which missing features are worse to be implemented

If the result is that its about impossible or it takes a lot of time to fix things then this is one reason for dropping Collada. However if it can't be done with OpenCollada, why would it be easier to solve with Python?

  • And here is what i believe we need to do in the case where the Collada module remains in Blender:
    1. Cleaning up the Blender integration to make it better maintainable
    2. Finding the right people for help with relevant open issues
    3. Getting the relevant issues fixed
  • And here is what any python addon needs to provide to us if it shall replace the Collada module:
    1. The exporter of course
    2. An importer that is capable to read the exporter's data back into Blender
    3. The Importer must be capable to accept any valid collada file (it can drop data that it can not import though)
    4. The exporter should be capable to export for Maya at least.
    5. The exporter must be capable to export for Secondlife as well.

I meanwhile believe that i know what the special secondlife code in the current exporter really does. So adding this to a Python exporter should be not such a big issue.

I would be much faster if i would know whom i could ask for help. It was Jesterking long time ago. But nowadays i do not know whom to ask.

@Vuk Gardašević (lijenstina) don't think there is any reason for C/C++ Python modules to make a difference here.
They are more of a way to optimize existing scripts.

As that would be a way of overcoming one substantial limitation of the Import / Export system in Blender (speed, memory usage), i would like it to see how it works out first. The devil is in the details and the bug tracker never sleeps :)
In some cases, Collada is the best option currently available (like in T53236). From a user standpoint until the comparable alternatives are in place, that would count as a regression.

  • As @Vuk Gardašević (lijenstina) said, I would keep OpenCollada in any way until another exporter allows to get the same speed for heavy meshes/scenes and are as memory efficient (see https://developer.blender.org/T53236#469082).
  • Second, it saved my day many times when the FBX exporter fails.
  • Last but not least, regarding the workflow I see the most (archviz), it's a must have to communicate with Sketchup.

@Vuk Gardašević (lijenstina) don't think there is any reason for C/C++ Python modules to make a difference here.
They are more of a way to optimize existing scripts.

As that would be a way of overcoming one substantial limitation of the Import / Export system in Blender (speed, memory usage), i would like it to see how it works out first. The devil is in the details and the bug tracker never sleeps :)
In some cases, Collada is the best option currently available (like in T53236). From a user standpoint until the comparable alternatives are in place, that would count as a regression.

Fair points which should be taken into consideration, but I'll push back on the notion that any kind of regression is blocking.

Gaia listed quite a reasonable set of features a replacement should support.

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.Sep 28 2018, 4:40 PM
Brecht Van Lommel (brecht) claimed this task.

OpenCollada is not being removed in Blender 2.8.

Gaia Clary (gaiaclary) changed the task status from Unknown Status to Unknown Status.Nov 27 2019, 12:49 PM

reopened temporary for organizational purpose

Gaia Clary (gaiaclary) changed the task status from Unknown Status to Unknown Status.Nov 27 2019, 12:50 PM
Gaia Clary (gaiaclary) moved this task from Backlog to archived on the Collada board.