Moving Collada I/O to Legacy Status

Starting from Blender 4.2LTS release, Collada file format support will be marked as legacy. This means that only minimal maintenance effort will be spent on it from now on, and that it will be removed in a later release (either 4.5 LTS, or 5.0).


The main reason for this decision is that the third-party library used by Blender (OpenCollada) has been fully inactive for 6 years now. This is becomming a serious issue for both security and compatibility with modern codebase (e.g. the library cannot be built anymore against the recent versions of some of its dependencies).

Further more, the Blender implementation has also seen no significant activity for several years now.


Last time this subject came up, it was decided to wait until linden labs (the only known user of this functionality) transitioned to a different format (think it was gltf, but don’t pin me down on that) does anyone know where they are at these days? if they have a functional pipeline with a different format already i wouldn’t mind dropping support sooner

1 Like

A significant portion of glTF seemed to land last November for Second Life’s material system: PBR Materials Are Here - Tools and Technology - Second Life Community

Ongoing work for the remainder of the glTF spec is progressing and they seem to be making continued progress in the area so they’re active for sure.

I think the discussion last time was about a full removal. Here we will just be marking the UI entry and Documentation as β€œ(legacy)”[1] where it will remain on life-support until 2026 when 4.2 goes out of support.

[1] And maybe a CLOG warning printed to the console further indicating removal at a later date?

I get that, but my argument is, if check if the last core user has moved on already, could we perhaps, accelerate the removal so we don’t have to support it till 2026?

If we keep shipping it at one point we’re gonna have to make the choice between shipping with known vulnerabilities or porting some 3rd party abandoned code to newer library versions, neither option is very appealing to me. Especially if not shipping it is on the table since all core users of it moved on


Ah, I see where you’re coming from. I don’t know just how good the glTF support is there for sure. As far as policy it would be β€œpoor form” to just remove with no heads up. We should have marked this legacy at the time of the last discussion…

But yes, we are carrying security risk. I think we know of, at least, 2 linux distros who have chosen to drop Collada (both OpenCollada and Blender’s support for it) on their own because of this – and it’s not like they gave any prior warning either.

The inactivity of a repository for a project’s source code implying that the project is obsolete does not make sense to me.

(I remember it coming-up for MLDonkey in Pkgsrc.)

To me, it is the exact opposite: The project is complete.
Please do keep it! :smiley:

Complete? It doesn’t compile with any modern compilers without code changes, there are several known high security vulnerabilities, this is not complete, this is abandoned and we kept it alive for 6 years now after the original authors gave up on it. enough is enough


OK, It sounds bizarre being the Khronos group standard and prime citizen at PlayStation
Now it’s as I have been in a time capsule. I may have missed a few episodes (such as what’s the replacement for it :stuck_out_tongue_winking_eye:.)

Mmh: GitHub - RemiArnaud/OpenCOLLADA
(From Does OpenCOLLADA not maintenance? · Issue #654 · KhronosGroup/OpenCOLLADA · GitHub)

This is the original author. Perhaps he lost the keys to the repository ?

1 Like

ok, lets take a look at the new repo then, random picking (i picked 4, but there’s many more used, 4 will make the point though) from the various deps it sticks into /Externals

libexpat 2.0.1 (2007)
zlib 1.2.3 (2005)
libxml 2.6.32 (2008)
pcre 8.12 (2011)

Surely these are also β€œcomplete” libraries, with no issues what so ever, no? just to be sure lets check the outstanding CVE’s on just those 4 then

┃                ┃          ┃         ┃ Latest         ┃                ┃                 ┃                ┃                ┃                 ┃                ┃
┃                ┃          ┃         ┃ Upstream       ┃ CRITICAL CVEs  ┃                 ┃ MEDIUM CVEs    ┃                ┃ UNKNOWN CVEs    ┃ TOTAL CVEs     ┃
┃ Vendor         ┃ Product  ┃ Version ┃ Stable Version ┃ Count          ┃ HIGH CVEs Count ┃ Count          ┃ LOW CVEs Count ┃ Count           ┃ Count          ┃
β”‚ libexpat_proj… β”‚ libexpat β”‚ 2.0.1   β”‚ 2.6.2          β”‚ 7              β”‚ 13              β”‚ 7              β”‚ 0              β”‚ 6               β”‚ 33             β”‚
β”‚ xmlsoft        β”‚ libxml2  β”‚ 2.6.32  β”‚ 2.12.7         β”‚ 6              β”‚ 25              β”‚ 33             β”‚ 0              β”‚ 2               β”‚ 66             β”‚
β”‚ pcre           β”‚ pcre     β”‚ 8.12    β”‚ 8.45           β”‚ 3              β”‚ 4               β”‚ 3              β”‚ 0              β”‚ 0               β”‚ 10             β”‚
β”‚ zlib           β”‚ zlib     β”‚ 1.2.3   β”‚ 1.3.1          β”‚ 2              β”‚ 0               β”‚ 0              β”‚ 0              β”‚ 4               β”‚ 6              β”‚

so yeah, new repo or not, it’s still pretty much abandoned, just letting it be, would be very irresponsible


Fair point and I generally agree with the sentiment. The lack of maintenance prompted the topic of removal but I wouldn’t consider this a reason for removal on its own.

I’d argue that the format has not become the universal interchange format it set out to be, with (all?) major users moving to other formats. Over time it’s becoming less and less relevant.
Coupled with this using a large unmaintained library makes continued support difficult to justify.

It’s great if Blender can support a wide range of formats (historic formats too) however I think it makes more sense to handle this using add-ons.


The only recent activity there seems to be to keep compatibility with recent versions of Max and Maya. That’s a… very exclusive type of maintenance. BTW, here are all the differences between the official Khronos repository, and the β€˜maintained’ fork.

And stating that some piece of software can be β€˜finished’ and never need any further work does not sound even remotely realistic to me. At the very least, I would expect such piece of software to have no bug reports open, no known issues, no todo’s, no open PR’s, not be affected by any CVE, etc. That is definitively not the case of OpenCOLLADA.

1 Like

I also think that just dropping in at this point would be the best course of action. Especially for an LTS release.

People can still use older versions of Blender or write a stand alone plugin for newer Blender versions if they really need to use it.


Agreed. I’m not sure the last time I used a collada file format… 15 years ago? Never?

Sometime last year I have looked into what it would take to remove dependencies from collada that have known CVEs (pcre, lixexpat etc.), and it is not very hard if the only thing you need is a collada I/O library, and not everything that the OpenCollada project has. But on the other hand, it is a bit of β€œis there even a point in doing all that work?” question, and with each passing month the answer is more and more of a β€œnope, there’s no point”.


To be clear regarding complete removal of Collada I/O support, the current suggested removal releases are here to give time to the potential users (including studios or other businesses) that would still rely on that format to transition to another one.

Should maintenance become suddenly a much bigger issue, we could then consider removing it sooner. But I would keep it at the very least in 4.2 LTS (unless extremely compelling reasons to remove it appear). In general, we try to avoid disruptive changes without giving a decent period (at least one or two releases) of warning and transition. And ideally, disruptive changes should only happen when switching to a new major release number…

Regarding having python extension for Collada support, I vaguely remember a discussion about this idea several years ago already… It could be a good alternative to complete removal of support for this format. But that would imply that there is still enough interest in this format to motivate people in the community to work on and maintain it.


If 115 CVE’s, of which 18 are Critical (including a perfect 10.0 full score) in just 4 of its deps, don’t count as extremely compelling I’m not sure any argument will be convincing enough to warrant immediate removal. I know i initially argued β€œlets check with the core users” but in my defence that was before i pulled up the numbers. We can’t ship this for another 4 years in good conscience


I don’t know what CVE’s or compiling is, so I can’t speak to the security of an I/O feature.
However, I do know, there are a few proprietary softwares whos’ only open export formats are .dae and .stl. I really don’t want to be working with .stls. Is there any chance this functionality could remain as an addon, but maybe disabled by default, if it has some issues?

1 Like

Having a Collada I/O add-on on our new extension platform would definitely be a possibility.

However, the current built-in code is not an add-on, but a part of Blender’s C++ source code, so it cannot be moved into its own independent add-on.

Found this project, but it has not been active for three years, so even if it may be a start-up point, getting it to work and be acceptable as an extension would certainly require some work.

PS: A CVE is a normalized way to reference and track security issues in libraries and software.

1 Like

Hmmm… I see. That’s unfortunately a more complicated problem than I thought.
Well, maybe those other softwares will get better export options! :joy: