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

Needs a lot of experience

[coljac]

My intuition says that there is years of work in this project. And, you ask, how does a professional programmer approach such a task? This kind of project is difficult and expensive even for teams of professionals with a lot of money behind them. They start with whiteboards, and use cases, and specs, etc.

If I were you, the first thing I would do is identify a very small subset of the functionality - say, the ability to parse and view a .mdl file - and try that first. Perhaps there's a need out there for a model viewer. A project of the scope has a chance of completion, and if you're still enthusiastic at that point you can expand the scope of your app, building on the code you already have.

Again, I'm sure you're smart and understand coding and the right physics, but the one thing the experience of a professional programmer would give you is a sense of the scope of this task.

A Few questions for you...

[Schnapple]

Although your question was very specific in some respects, it was vague in others. Possibly purposely. Still, I have a few questions of my own for the original poster:

1. Is your intent commercial software, free software or other?
2. If your intent is free software then are you thinking Open Source?
3. If your intent is commercial software, then why do you think this product would be any better than the other commercial packages out there?
4. What is the overall goal for this - professional quality animation? Movie or TV quality work? Video Game design?
5. Are you working alone?
6. How is it that you will have the time to devote to this? What makes you think you will finish?
7. And finally, if it turns out that you are an individual from a commercial organization willing to undertake such a tremendous task in a crowded field with such strong players, why do you think Slashdot will be a good place to get meaningful advice?

Don;t get me wrong - I'm not trying to slam you or your idea or anything but these are the questions that popped into my head when I read this. I know history is filled with projects like this but for every Linus Torvalds who sits down and makes his own OS (and yes I have read the GNU/Linux FAQ) there are thousands that get 10% in and say screw it.

if you have to ask slashdot...

[yorgasor]

I think this is one of those situations where if you have to ask slashdot, you're not up to the challenge ;)

For what purpose?

[tc]

A fully-featured 3D animation package is pretty damn huge. What is your intended purpose in building your own, rather than using an existing package? I assume that it is simply for fun, or perhaps you have a more ambitious goal of creating an open source 3D modelling package that might be a replacement for Max, Maya et al?

If you are intending a serious replacement for professional packages, perhaps you need to talk to some of the users of those packages. I'm sure some game developers (just as myself) and animation folks lurk on Slashdot, but to get really great feedback you really ought to go to a more special purpose forum.

That said, some things I'd consider if you're planning a truly professional quality package are:

- Support and documentation. Especially really great documentation and samples. Plan a lot of time on this. Getting this piece right will pay for a lot of fuckups on the rest of the design.

- Extensibility. Every pro user I know uses an array of in-house extensions, for everything from custom data format importers and exporters to plugins for procedural geometry, custom shaders, special lighting models, and a whole slew of other things. Make everything scriptable, overrideable, and customisable. Consider writing the bulk of your standard features using the same toolkit people will use to write plugins, because then they serve as sample apps.

- Consider providing compatibility modes for people migrating from other pro packages. Artists get very set in their ways. Unless you have a truly revolutionary and more productive UI, follow some of the existing conventions, or at least make it an option.

- Provide a batch processing mode, so that offline tools can invoke the power of your package without firing up the whole damn UI. In the games business, we have a lot of build process running on our artwork from assorted batch files, Perl scripts, and whathaveyou. I'm sure the same is true in other pro environments too.

Incremental work.

[Peaker]

An important thing to remmember, especially for motivational projects (projects that require a lot of motivation to keep going), is to write code incrementally.

One of the best methods I know to write code incrementally is to rapidly model it in a Rapid Development language such as Python.

Since I get excited by seeing results quickly, I'd probably start by deciding on a GUI toolkit, and find some Python bindings for it. Perhaps an OpenGL GUI of my own, in any case, that's where I'd start. Whatever excites you the most (Perhaps rendering ray-traced images of simple objects excites you, and you can start there), is where you should start. As long as you're excited about what you're doing, you can easily keep on going.

Then, when you have a GUI (Or a simple renderer for that matter), you need to generate "stubs" for other components. There are various meanings of the word "stub" flying around, so I'll explain mine: A simple replacement of the interface a software component, that is trivial to implement, lacks any of the functionality, and is intended to later be re-written.

This enables you to work on an exciting Skeleton of your program, that lacks almost all of the functionality, but there is already a bit of something very exciting to you, and perhaps to others who share your interests, to work with.

Notice this is the same method used in the early development of Linux.

Linus provided a very simple Skeleton of a Kernel, with either stubs or extremely naive implementations of almost all kernel subsystems. This is much better than the alternative, of trying to create the 2.4.19 kernel, component by component, from scratch.
Linux 2.4.19 shares very little in design and in code with Linux 0.1, and the actual implementation decisions of Linux 0.1 don't really matter at all now.

This is why I emphasize that you should start before you know exactly where its going, because there's a good chance you'll be stuck planning it forever, if you try to get it all right in the first time. If you don't bind yourself to backwards compatability, it doesn't really make a difference what kind of design error you make now, it can be corrected with time and with rewrites. Don't worry - rewrites are much shorter than the original designs and writes, as they come after a lot of experience, and can often reuse most of the code.

Keep excited, start coding. Whenever there are tidbits of work you don't like doing, but must, keep in mind how the great cool exciting things that depend on it will look like.
Don't code without design, but do code what little parts you know the design of already.

Sorry Mr. Linus, writing an OS is a stupid idea...

[Brian_Ellenberger]

Mr. Linus, it is my understanding that you intend to write your own operating system from scratch. I just want you to know your "Linux" kernel is a stupid idea. Why don't you just buy Unix from one of the many vendors out there? It is a waste of your time and resources to try and reinvent the wheel.

There are many things I have written that have been "reinventing the wheel", from a merge sort to converting a Windows BMP to JPEG. But I learned a ton from doing it. Heck if he just wants to write something just to learn more about 3D modeling, more power to him. And you never know if in 5 years we will be raving about a new open source 3D modeler giving 3DSMax a run for its money...

Brian Ellenberger