Designing Computer Animation Software?

reversedNormal asks: "I would like to write a full fledged 3d-Animation Software package from scratch. Yes, I know, a VERY daunting and time consuming task. But I have a very good understanding of 3D mathematics, physics, and computer graphics in general, plus a solid foundation in computer programming. To give you an idea, this package will be similar to Maya, 3DS Max, etc... in many respects. The question is, what is the best programming paradigm to use for such a project? I have all of the major concepts, and relationships in mind, but refuse to write one line of code until I have a good design plan. How does a professional programmer approach this design task? Ultimately I would like to be able to tie it into any number of different operating systems, graphics API's (OpenGL, DirectX, etc..), and so on. What are some good ways to do this?"

"Essentially I want the core of the software to be written in Standard C++, and then be able to tie into the Win32 API, or X, or QuickDraw (etc.) for display and input. The main concepts, such as procedural 2D and 3D geometry, 3D geometric transformation, polygon modeling, NURBS modeling, subdivision modeling, keyframe based animation of parameters, motion capture control of parameters, physics-based animation, sound synthesis, texture-mapping, lighthing, rendering, and so on are generally abstract ideas that do not need to depend on (but can certainly take advantage of) any particular API or environment. Of course, the idea is to eventually visualize the abstraction onto the screen, allowing the user to interact via the 2D pointer and keyboard input, and ultimately rasterize it, which will mean turning to various operating system standards. It will also be open as a plugin host and have a built in scripting language. Any design suggestions? I know that this is probably the most intelligent audience to communicate with, and any feedback would certainly be appreciated"

Comments

First things first.

[shufler]

You might want to write pseudocode before you do touch that one line of code. For something this large, jumping right in will leave you frustrated and you will surely abandon this project.

This is something that cannot be stressed enough. Every single detail should be planned out before you begin to code.

The SDLC is your friend.

Re:First things first.

[Codifex Maximus]

SDLC or Systems Development Life Cycle.

Decide first if it is worth your while to write it.
Get someone to fund it.
Find out what your intended users need.
Use IPO or input, process, output charts to help you get an idea of what the main program process must do. Break it down then into logical component parts and do IPOs for them too. When you get down to the simplest level that can be broken down, then you are ready to begin designing your datastructures and relationships - use DFD and ERDs. Use top down hierarchichal DFD to define the scope of your system. Don't try to do too much or you will kill your project. A tight refined scope is better than an ambiguous... It's gonna do everything!

After datastructures are done, then do the pseudocode for manipulating the data. About this time, you want to begin work on defining an easy to use user interface - let the user's mull it over while you pseudocode.

Review, refine, tighten the scope if neccessary. Reevaluate feasibility. Get some help but not too much. Use Ghant, Pert charts to plan phases of implementation. Make sure you have adequate hardware and software to support the system. Don't lock yourself into any proprietary toolkit that may carry license fees or limit your potential userbase.

Chose a platform, coding model, naming convention, and language that best suits the apps purpose. Use a code control system such as CVS. Create a working prototype of the user interface the user's agreed on. Let them play with it and give you feed back.

Review, refine, tighten the scope etc... etc... etc..

Fill out the prototype with some real code and throw it at the users again.

Review, refine... you get the picture.

Somewhere along the line, you will begin to get a working system. Now you must support it or find/train someone to. Remember your documentation. Did you fully comment your code?

Was it all worth it?

Re:First things first.

[Peaker]

I believe this method of software creation is good for the Cathedral model, and with well-funded programmers who program for money, it can get done. But keep in mind, that since its not incremental, its not exciting. DFD's on paper, ERD's, are all boring, when you get down to them. Unless you finish it all very quickly, you're going to be stuck in very long design phases. Unless you're an extremely good designer, you're likely to hit some problems in the actual implementation that may require refining the design.

Code is getting cheaper and cheaper to write. A rapid prototype of how even a large program should generally work or look like can be created in a very-high-level language in just hours. So if you're one of those who can do the designing while coding, its probably most efficient to do it that way, as you can easily throw away the code if seeing the design sucks (Much easier to see with your head on the ground and code written).

Also, I don't see how multiple contributors can't fit into this well-framed process. I would also like to disagree with the requirement of pseudo-code, as today's high-level languages, such as Python, are pretty much as high-level as pseudo code and correctly described sometimes as "Running Pseudo Code". This also means that their code, written correctly, is _truly_ self-documenting, truly. Rarely is there a weird piece of code that requires extra documentation. I'm talking about the what and the how, and not the general software architecture, which should be documented separately.

In summary, I think that your software creation model is too "formal" in the sense that it will not excite programmers, and will be very difficult to get contributors from all around. Excited programmers are better programmers. Also, I think its a bit presumptious of you to think you can know, to detail, the exact best way for the program to be designed, and thus its probably best to write it piece by piece, and see where usability's taking you. An assumption of mine, is that most useful features of a program are suggested at its usage stage, and not its design stage - This means you better minimize the design stage, and get to the usage stage as soon as possible. Do you disagree with this assumption?

Consider writing plugings

[youBastrd]

3DS MAX and Maya pretty much do everything under the sun. If they can't do it natively, third-party plugins are a good way to go. If you need some functionality that's not there, write the plugin, surely you've got the skills to do that. These products are very mature already, nevermind their popularity and the amount of training users have invested in them.

You've got an uphill climb if you want to write this thing from scratch.

Mauybe you've already done this but...

[TheAwfulTruth]

The first thing to do is define your target audience. There are already so many 3d modeling/animation programs out there, what is it you are trying to do by making a new one?

There is a reason why people are willing to pay hundreds and thousands for Maya and 3ds. They are THE standard and they work great. And if that doesn't matter to you then Martin Hash's Animation Master is an amazingly powerful set of programs for dirt cheap.

So if it isn't to be either of those then what? The first 3d program with a truly easy to use interface? (That may not even be possible, but it would be a godsend)

Before thinking about programming "para-dig-ums", I'd concentrate on what the "product" (Free or not) really is. Believe it or not, desighning the code framework for the internals and drawing the 3d elements on screen is the EASY part. Getting a good, no make that excellent, "User Interaction" going on what is likely the most difficult thing anyone does on a computer is far more work.

Re:Scripting Language - try Lua

[null-und-eins]

Lua (http://www.lua.org/) is a small, fast, extensible language that is designed to be embedded into an application. It has already become a favourite among game designers. The idea is, that you extend it with new datatypes in C, such that the objects in your application become scriptable. Think TCL, just better. For a performance comparison, see http://www.bagley.org/~doug/shootout/craps.shtml. It beats both Perl and Python.

Learn from the best

[Prof. F�HL]

Before I took my first hang gliding lesson in the late 70's I went down to the beach and watched seagulls soar along the cliffs for several hours.

When I went to my first lesson, the instructor asked the group if anyone had prepared for it. I told them what I had done. The other students laughed out loud. The instructor gave me his best 'you are the only chucklehead here who even has a clue' look.

Hope this helps

Opportunity for a rethink

[oquigley]

I'm not a programmer, but I am a professional user of 3D tools.
I've noticed that the huge advances in 3D modeling & animation packages that we saw in the late '90's, with the release of Maya, Max 1-3, Lightwave, Soft and the like seem to have come to a stop.
The most recent releases of all of these seem to be converging on the same feature sets. They're all making dull, incremental progress. At the moment, I'm wondering whether it's even worth the hassle to upgrade from Max 4 to Max 5. The only thing it really seems to offer is built in global illumination rendering, which has been available as a plugin for a while.

I'm wondering what the next revolution in 3D authoring tools is going to be. I can't imagine that we'll be going down this path of diminishing returns forever.

One possibility seems to be true WYSIWYG realtime rendering using the coming generation of floating point accurate 3D cards. Another seems to be automation of character animation (embedding simple AI into the skeletons)...

I'd question if it's worth the bother to simply replicate the existing functionality of mature, static programs. If it's a new project, you could rethink what a 3D package is supposed to do and make a real leap.
What do you all think it would take to refresh the 3D tools world.

Common Lisp

[voodoo1man]

Before you mod me down, check out what these guys have done. (The site hasn't been updated in a while, due to company problems and one of the main coders being on hiatus or something (fyi, his name is Larry Malone, he has been doing this ever since he modelled the sailing ships in Tron using custom-developed software at III, and has been writing graphics Lisp software at Symbolics and since afterwards)). Well, enough of the history lesson.

Common Lisp has a lot of benefits for this type of work. Since it is completely dynamic (ie - everything runs in an image with which you can interact, add code/compile and debug, all at run-time), the plug-in/scripting is taken care of from the start, and can have the full syntax of CL and access to any of the main program's features you choose to give it. CL will probably give you the most results per line/minute of code because of this dynamism.

Most CL implementations have pretty good foreign function interfaces for C and C++ libraries (Franz's Allegro CL even provides support for run-time Java objects.)

CL's performance is on par with C++ in general, and lags only in one major area - FP operations require "boxing" overhead when the symbol pointing to the numbers is dynamically typed (most compilers optimize statically typed declarations pretty well - which makes most of the overhead go away.)

Of course, before you go off on your great quest, you should probably read what some of the other posters have suggested. Writing graphics software like the type you describe is an incredible amount of work (I gave up my uber-Scheme system after 100 lines and settled for writing smaller utilities and plugins), and many have tried and miserably failed before.

Re:advice backed by practical experience

[Anonymous Coward]

How about skipping that part entirely, realising that you're not going to get the architecture right upfront anyway. The architecture is going to evolve through a number of refactorings, not through some superhuman designprocess.

I think that's a matter of personal experience, ability, and taste. I, for example, code exactly like that. Back when I was 'programming' (creating code that was compiled to a binary executable), that was how I worked. I started with a basic idea of what ends I wanted to realize, jotted a few notes in the header(s) of my source code, and away I went. After a few days, I jotted down some additional goals. I coded some aspects to perfection while tinkering with others. Slowly, my interface evolved, usually a complete re-write of the user interface occurred about ten times with any given project. When you have four principal features, the interface has to showcase them. When you grow to ten, you have to allot the space more evenly and logically for the other six, etc. Through this process, I had slowly more and more people using my program(s), and suggesting feature additions and changes. (Beta testers, friends cleverly disguised as beta testers, and even the general population)

Now that I'm involved primarily in scripting (Shell scripting on Linux back-ends, web scripting the U.I.) I code pretty much the same way. One project I'm working on would never have been started if I'd waited until I had a solid, complete vision of the project's future. Instead, I got a few ideas and plowed ahead, roughshod. As the project developed I slowly got more and more ideas for feature additions, and eventually decided on a rough versioning system (ie; features A, B, and C will be complete for v0.1, D, E, and F, for 0.2 ... )

I know, and have collaborated with people who can't STAND to work on a project with that design course, and it's perfectly understandable. I learn by doing, some people meticulously plan every detail. I doubt I'll change very radically in forseeabl future, and likewise doubt that a planner will change much either.

I only hope that the submitter doesn't fall into the trap of planning for so long that the project gets forgotten, or that he loses interest. It would be excellent to see a 3D rendering app for Linux.