Animation/rigging tools seem particularly lacking to me. For example, a "set driven key" in maya is simple, very common action. You can do the same thing in blender, but it takes more steps and seems kind of obscure.
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.
There are actually better apps than Maya for modelling / UVing, but for animation / rigging / skinning / techanim it's the benchmark.
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.
Blender has made a lot of strides in the past few years. Have you tried it recently? My last encounter with blender was in 2008 and it was rather painful. I gave it another try several months ago and got my socks blown off. I've since rebuilt my workflow around blender and there's no going back.
Yeah, I regularly try it (both with its native keybindings and with it's Maya emulation mode), and it has got better.
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.
Blender is pretty good. I've only used it a few times but I agree that the UI seems to have improved quite a bit. I did find the interface modes a bit confusing at first (and I say that as someone whos primary text editor has been Vim for the last 5-6 years).
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.
> With so much functionality, where to find the things you are looking for can be a bit difficult.
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!).
The most honest answer is that studios can't extend the software without violating the GPL.
Maya is outrageously extensible in a variety of ways and really set the standard for being "open" in this way. A lot of the big studios have toolsets that radically transform parts of Maya, shaping it into the tool needed for the work.
Maya is also pretty crusty, plenty of other applications do a better job at it's core competency, but they simply aren't dug into studio pipelines like a tick in the way that Maya is.
Blender has to limit itself to Python, or at least, I'm not aware of the ability to create native plugins. I'm all for Python, but a lot of interesting work is done in C++ building native operators for the application or embedding custom viewports for gamedev which I don't think is remotely possible in Blender yet.
Additionally, licensing prevents many integrations from getting off the ground.
So what you are saying is that there is no benefit of using Maya if you are not specifically a commercial software company who want to sell derivative tool-kits made from open source projects.
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?
Being one of the industry standards for 3D modeling. OK, and having a file format that can at least in theory be read by other programs (.blend files are simply undocumented memory dumps).
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.
Just curious, have you tried using blender at a more or less advanced level? It's like comparing Windows and a Unix system and saying that Unix doesn't have a decent user interface. I mean, once you start using blender extensively, you realize that blender makes your workflow faster than the mainstream CG packages.
Of the big CG packages, I've used both 3DS Max, Maya, and Blender--Max most of all.
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.
Blender's a bit like a tiling window manager. If you don't get on with your keyboard you're not going to have much to say. It is however extremely efficient for those that do.
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.
Maya has its dependency graph architecture, while Houdini has its many layers of networks. They both make explicit their pipelines of data transformation, using a common building block, and that allows the system and the artist to reason about what gets done and when. You might create some geometry (a grid), then apply some noise to it to create a landscape, then use it as part of a physics simulation as a static object, then also use it as part of the rendering of the final image. You expect to be able to change the parameters of each of those stages and reason about the result.
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.
Oh yes, I see now. Actually, that was one of the few things I missed in Blender coming from Softimage. Not too much, though, but I do appreciate the power of a unified editable operation stack/pipeline for bigger projects.
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".
I was scared away from Blender for years by people like you. Last week, I learned Blender. I was astonished to find it way more intuitive than every other 3D program I've used heavily. That includes: 3DS Max, Polyworks, Cyclone, Meshlab, CloudCompare, RiScan, Moray, Photoscan, VisualSFM. You can do everything 100% with the mouse, or 100% with the keyboard. I'm at about 60% keyboard, 40% mouse, which is just how I like it. If you can't remember how to do something, and can't find it in the clicky menus (even though it IS there), just press space and type what you want to do.
I haven't used 3D modelling software, but I presume that you would look up things as you need them as in any other software, and not memorize everything in the beginning.
Things that are commonly used will be memorized automatically.
