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).
Rationale
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
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.
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 .)
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
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
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.
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?
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.
.)