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”.
3 Likes
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.
2 Likes
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
6 Likes
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! 
@aidan-j-rhoden for reference, could you mention the software names & versions that only support Collada?
Sure! The two I’m aware of right now are Chief Architect and Studio.
Studio is a tool used for designing Lego sets, and it can export to .stl and Collada. However, that’s not critical at all, because there is an addon to import their own format.
Chief Architect is the more important one to me, as it can only export to .stl and Collada, and there is (currently) no I/O options for its own format.
However, neither of these are super critical for me, it’s more of a convenience. For Studio, I don’t even use Collada, except in the case of importing custom Legos, which I’d be apt to design in Blender anyway.
It’s an inconvenience, but if Collada I/O is removed, users could have a older version of Blender installed specifically for importing .dae files, saving the .blend file, then opening it in the newer Blender version of their choice, or re-export into a different format.
Although, that only properly handles the input part of Collada. Which may not be enough for some use cases.
3 Likes
The lego people have violated our license for years on end. Personally I think they should be disqualified from being taken into consideration how dropping collada may affect them for that reason alone.
1 Like
Oh, I hadn’t thought of that for some reason! That would work just fine for me, thanks!
Export is not a worry; I don’t ever use Collada for that.
Hi, another problem of removing this in the future is games like BeamNG.drive use the Collada file format for all of their 3D content in the game.
1 Like
Our studio use DAE Collada daily because of a direct compatibility with Sketchup.
There are no that much file formats this software can handle relatively properly.
As far as I can see Sketchup also support export for FBX, OBJ, 3DS, STL, VRML. What makes you use Collada instead?
1 Like
Export from Blender to Sketchup requires Collada.
The best way to import from Sketchup to Blender is an addon because native Sketchup exporters (FBX, 3DS, etc) are also far away from being good.
Also, AFAIK, the addon is windows only.
1 Like
@LazyDodo @mont29 wrt OpenCollada security issues, I have remembered that a year ago I did not only “think about it”, but actually played around with removing stale/unused/pointless dependencies from the OpenCollada project, and fixed it up to build with modern compilers. It was here: Comparing KhronosGroup:main...aras-p:master · KhronosGroup/OpenCOLLADA · GitHub and from what I remember I did these things:
- Fix VS2022 build,
- Removed things not needed for Blender (3dsmax/maya plugins, validator, Ogre3D converters, G3D browser, etc.)
- Remove usages of PCRE completely (it was only ever used for trivial string splitting),
- Remove embedded expat, Cg, lib3ds, zlib, zziplib libraries,
- Some other cleanup.
So if someone strongly still needs Collada, and/or the fact that upstream has known security issues in the libraries it embeds is a problem (particularly for Blender LTS), we could consider switching to “my fork”. The upstream project is dead for all practical purposes.
14 Likes
I’d happily switch over to your fork as it alleviates all my concerns!
2 Likes
@LazyDodo ok let’s do this! I just updated embedded libxml2 in there from the one of year 2008 to the latest version too. Blender build does not use the embedded version anyway, so not directly relevant.
3 Likes
downside: we seemingly have no test coverage at all for this IO format, did some manual fiddling with it by manually exporting / importing the default cube, it seems unhappy with every file i try to feed it so looks like something broke along the way (but haven’t looked with a debugger yet)
+-- Collada Import parameters------
| input file : C:\Users\ray\Documents\untitled.dae
| use units : no
| custom normals : yes
| autoconnect : no
+-- Armature Import parameters ----
| find bone chains: no
| min chain len : 0
| fix orientation : no
| keep bind info : no
Warning: Call `save()` to make sure that changes persist in all cases.
I/O warning : failed to load external entity "//C:Users/ray/Documents/untitled.dae"
File access (Error): Critical error: ERROR_COULD_NOT_OPEN_FILE Additional: \\C:Users\ray\Documents\untitled.dae
The Collada import has been forced to stop.
Please fix the reported error and then try again.COLLADAFW::Root::loadDocument() returned false on 1st pass
+----------------------------------
| Collada Import : FAIL
+----------------------------------