Seriously though, what can Maya do that Blender can't?
Blender often has trouble dealing with scenes at production scale. Not that it can't do it (as the blender movie projects prove) but generally you have to know the strengths and weakness of it well to set up a scene at production scale. And to be honest, the scale of the blender shorts is pretty small compared to a typical maya production scene.
It's getting better with every release though. A lot of the tools, for example the texture painting and matchmoving tools, are already better than maya. Render layers have recently caught up.
I think maya still has an edge in production use, but we're starting to see blender being used in real production situations. If you look at the trajectories of development of both programs, blender is moving fast and maya is more or less sitting still.
Blender's got most of the functionality in theory, but it's really not well architected / designed in terms of workflow - a bit like old Nokia Nxx phones - they had all the features, but they weren't user-friendly for many things.
But it's still painful doing many things in a fluid / connected way, and generally it just doesn't scale for assets.
E.g. I tried to import the .obj (because the FBX support is pretty crap and there's no .abc support) of a fairly small model I had of a voxellated (shape made out of cubes) shape, which consisted of around 300,000 primitives (all cubes), and blender took over 6 hours to import it. Maya, Houdini (and 3D apps I've written) opened it in seconds.
With so much functionality, where to find the things you are looking for can be a bit difficult. I think doing as you did and rebuilding your workflow around the tool is probably the best way to get productive.
I've yet to see a 3D program where it's easy (except, maybe Google Sketchup). They are complicated beasts, so new users should expect a learning curve. In my experience, though, Blender gets easier once you master the basics (while most other packages let you do a "hello world" type project easily, but mire you down with their "friendly" UI for more advanced stuff).
Another important thing that sets Blender apart WRT learning curve, is the abundance of good tutorials and help (it's even got its own stack exchange site[1] - incredibly helpful!).
Or... should I sum it up as Maya is used by studios who already has c++ experience, and Blender is used by studios that has python experience?
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).
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.
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.
The gold standard for UI for me, though, is still Wings3D (based on Nendo). It has way better UV unwrapping support than anything else I've tried. It is as good as it is specifically because the functionality it aims at is quite limited.
Sketchup gets an honorable mention for UI, but the scripting and geometry it makes is such garbage I can't recommend it.
What it's missing really is some of the universal, underlying data flow architecture that the likes of Maya and Houdini had from the start. But it's getting there.
Could you elaborate on that? I'm not sure I understand what you mean by "data flow" in the context of a CGI package.
You'll generally see these pipelines depicted as editable, directed graphs (DAGs) in the application. Blender uses DAGs for a number of things - eg an image compositor, and for shading networks. It also provides modifier layers (like 3DS MAX) for geometry transformation. But it doesn't go down to the core of the application which is why you can get some problems when it comes to certain tasks in animation for instance. But they are working on this.
It's a bit like all these various architectures for the web - Flux, RxJS etc. They're making explicit the transformations and dependencies that happen, by means of a data flow graph (even if it is not visualised). This usually means less surprises and more opportunity for optimization.
Here's a hotkey chart for Blender.[1] You must memorize this. "Note that charts and references relate to common or frequently used actions in Blender so should not be regarded as a comprehensive list of shortcuts. Note also that triggers are context sensitive, the same key may function differently depending upon the Editor open or operation performed".
[1] http://www.katsbits.com/tutorials/blender/useful-keyboard-sh...
Things that are commonly used will be memorized automatically.