Sure, .blend files are basically useless outside of Blender, and that's why there's an export command that lets you export what you made into other format like .X3D (xml based) for example or even Wavefront .obj file.
But can you guarantee that no information is lost by exporting? I personally have my doubts (and I had bad experience with the Blender exporters in the past on this point; perhaps the bugs are fixed now).
In my opinion Blender should introduce two file formats:
- .blend: The existing format; fast to load, save etc., but not for reading from external programs
- .blend_external: A format that presents exactly the same information as a .blend file, but can be read easily by external software and is thus completely documented in all details. Perhaps more slow to load/save (which should not matter for the purposes of .blend_external).
> But can you guarantee that no information is lost by exporting?
You practically never can when exporting in any format, from any program, since few formats are subsets of any others. The important thing is to be able to export the information you need. Most formats cover the same things, so chances are you can export what you need.
FWIW, I've seen a few projects that import blend files. Serialized memory dumps are not a bad thing and are easy to write loaders for (as long as they're documented sufficiently and/or have libraries available.)
I don't see why you would need to have a separate format. As long as .blend is fully documented up to the point of being able to recover all the application-agnostic data I don't see a benefit to splitting off another format. It might make sense to omit the Blender-specific UI data and so on, but I don't think that really needs a separate format to accomplish.
> and I had bad experience with the Blender exporters in the past on this point
Bad experiences with Blender exporters will probably never cease. Many of them are written by a single person to scratch an itch and do the minimum they need from it. That isn't to say you won't find quality ones, but unless and until all formats have exporters in-tree and are dutifully maintained, there will be occasional breakage. The good news is the quality tends upward, so exporters for common formats are probably a lot less disappointing today than when you last tried them.
This is pretty much the same dilemma as all content creation packages - whether 3D software, audio, CAD, video editing etc. Internal formats need to be fast and robust to frequent revisions, and will inevitably support procedural transformations on data that are unique to that software (eg a particular mesh modifier, particle system, audio compressor or video effect).
So external formats become quite difficult to specify, and generally require that everything gets baked/bounced down to the lowest common denominator - eg per-frame animation channels, or EDL-level edits in a video.
The .blend format isn't actually that bad, if you really need to access it. I've seen a number of external libraries written in C or Python that do this, and it's one of those formats where you can skip over the unknowns (as indeed Blender itself does when loading files from the future).
If you want to do 3D interchange, this will depend much on your particular application. We have FBX for mesh, scene and animation data which is pretty good. OBJ is always there for the simplest of things. ABC (Alembic) support is coming to Blender for more complex geometry, and there's talk of OpenVDB for voxel data.
Other roads out include numerous exporters for various game platforms - THREE.js, the new Khronos gITF format or OpenGEX.
