Slashdot Mirror
Open Source On the Big Screen
An anonymous reader writes "Following the success of Elephants Dream, the Blender Foundation is developing a follow-on open movie called Peach, set for completion later this year. Computerworld has up an interesting interview with Matt Ebb, lead artist from Elephants Dream (the interview is split over 5 pages). Ebb talks about the making of the world's first open movie and offers some advice to others wanting to start such a project."
As a blender/crystal space user I'm more interested in the development of Apricot, the open game based on the movie. It'll be great to see improvements in the area of 3d Linux game development, and certainly make it a more attractive platform for developers in the future.
That's partly because they try to combine modelling - with two or three different paradigms: polygons, NURBS and subdivision surfaces - texturing, rigging, animating, physics, particles, hair, etc. into a single program. Of course the end result is a horrible mess where it's impossible to find what you want. Which, I suppose, is a long-winded way to say that they're kitchen sinks ;).
Ultimately, the problem is that 2D modeling - drawing - has traditionally been the domain of artists, while 3D modeling has been the domain of engineers and architechts. Artists don't have to know or care about mathemathics, while engineers and architechts have to. Their tools reflect this: brushes vs. millimeter paper. This division has been carried to the computer realm. It is straightforward to paint with Gimp - point and click a place in the screen, and color is added there - but the very first thing any 3D program manual starts talking about is polygons, and then goes on to explain the mathemathical foundation of NURBS. The limits of 2D screens and pointing devices don't exactly help, either.
To top it all off, the popular OBJ format used to exchange 3D models completely fails to retain any of the all-important rigging or animation loop information. As a result, these models are fine if you want to do an image of Lot's wife but not otherwise. We desperately need a higher-level file format which captures rigging, animation cycles (such as walk cycle) and automatic things like blinking and breathing, as well as unconscious gestures, body language and such. In short, a file format to describe a digital actor. The current stuff is the equivalent of assembly, and about as efficient for large projects: good for the CPU, horrible to anyone who has to do anything with it.
And, of course, all this is completely ignoring all the stupid little things like polygons caving into the model like the empty shells they are, NURBS models breaking at seams, the utter masslessness of any model unless the animator specifically goes over each frame and figures out how inertia and gravity affect things, inverse kinetics chains flip-flopping in certain situations, etc.
I wonder when we'll get even the abstraction level equivalent of ANSI C for 3D; compared to the current stuff, it seems pure sci-fi.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
3d modeling tools are seen as technical products for a technical audience.. as such the UI is given no serious consideration. Your first statement is partly true, but not entirely. First, each app has a different philosophy behind its work flow. In that sense, no, understanding 3d modelling doesn't guarantee a '0 time to learn' by any stretch of the imagination. For example: Lightwave has a modeler app. You build your model in that app, then load it in Layout and animate it. The benefit is that the tools are designed around direct vertex manipulation. It's very easy to get a nice clean model with no extra invisible points etc. The added bonus is since LW's scene has to load the object in, then modify it, you can easily modify an object later and it won't rock the boat of what's going on in layout. (In other words, you can easily update a character's model after it has been animated. Though not impossible in other apps, it's typically less elegant.) Maya, however, has a different approach. Its idea of modeling involves piling on a series of modifiers/nodes onto some geometry. If you want to slice along the polys of a cube, for example, a 'split node' is attached to the object that modifies the geometry for that result. You can then go back and modify it.
On the surface, you end up with a similar toolset. Both Maya and Lightwave have the split/slice polygon tools. However, the philosophies behind them really make that common toolset problematic. For example, Lightwave doesn't have a modifier based operation. It's like Photoshop in that respect. You mess with the vertices, blammo, you're done. This gives you tools like "Dragnet". That tool allows you to grab an area of verticies and pull, just like working with clay. Maya, however, can't do any operations on geometry without creating a modifier. So if you want to do a tool like I described, you have to create a 'dragnet' node, place its start point, then move it to the destination. That's a good deal slower than how Lightwave handles it.
This is an over-simplification of what's involved, but it more or less illustrates the problem with your statement. I'd liken it to watercolors vs. oil paints. They both require paint and a paint brush, but the techniques involved are nearly inverses of each other. With Lightwave, you model by cutting a lot of pieces away. With Maya, you model bending pieces into shape since its work flow lends itself to doing lots of deformations. To put it another over-simplified way: Lightwave would be better suited to modeling something vehicular with rigid pieces. Maya, however, would totally kick Lightwave's ass when modelling something with a lot of hoses and other bendable things, like the Sentinels from the Matrix. The difference is in the workflow philosophies of these apps, not their toolsets. It's a lot harder to cross-train modelers between apps than you'd expect. 3d modeling tools are seen as technical products for a technical audience.. as such the UI is given no serious consideration. I'm not sure how to read this statement. Either you're saying that the UI isn't developed for the mass audience (which is true, and I have no argument at all with) or you're saying that UI's are just tacked on and the artsts just deal with it, which does happen, but isn't generally true. UIs for 3D apps are developed around the philosophy of the app. If that philosophy isn't understood, then the UI makes no sense. Give a Photoshop guru a copy of Illustrator and tell him to do work in it, and he'll tell you the UI's bad. Different philosophy. A lot of work actually does go into the UI of 3D apps. The problem is you cannot take something as vast as '3D' and slim it down to a UI philosophy like you can with something like Photoshop. Yes, 3D apps aren't unituitive or psychic, but no, it isn't for lack of trying.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)