Slashdot Mirror
Designing Computer Animation Software?
"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"
I think the first thing you should do is getting/recruiting yourself some programmers and designers and having a good team.
For your builtin scripting language, may I suggest you *not* invent your own, especially for a small project. If it were me, I'd create a Perl module (probably a class of them) and use those for the scripting. That way your program has much greater power than it would with a custom language (think web-based 3D apps) plus it reduces learning curves. Think AutoCad/Lisp.
If you're going to enter the big, bad world of 3D, the only way you're going to get noticed is if you can offer something really special. And not having to retrain all your programmers in a new language is something special. Being able to give an artist a copy of "Learnig Perl" and having them go to town is a lot better than trying to give them some documentation written by a programmer at the last minute.
My email is real.
Here are some suggestions:
-- SIGFPE
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.
.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.
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
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.
Everyone knows that damage is done to the soul by bad motion pictures. -Pope Pius XI
- Is your intent commercial software, free software or other?
- If your intent is free software then are you thinking Open Source?
- If your intent is commercial software, then why do you think this product would be any better than the other commercial packages out there?
- What is the overall goal for this - professional quality animation? Movie or TV quality work? Video Game design?
- Are you working alone?
- How is it that you will have the time to devote to this? What makes you think you will finish?
- 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.Schnapple
As much as FSF advocates are pained to admit it, C# is going to become the de facto programming language in the next few years. By writing your program in C#, you'll be the first 3D animation package to use this, and take advantage of the power of .NET. Since there are already several packages similiar to yours, you have to do things like this to make your project stand out.
Good luck!
C - A language that combines the speed of assembly with the ease of use of assembly.
fucking excellent idea.
no better way to get started then to look at how someone else has gone before you.
one look at blender code, and you might go "holy shit forget it"....or maybe "man this is some elementary shit"
mod parent up
I think this is one of those situations where if you have to ask slashdot, you're not up to the challenge ;)
Looking for a computer support specialist for your small business? Check out
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.
That area is chock full of software patents to unknowingly violate.
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.
I disagree.
Only the top level design should be completed in order to start working. There is no way in hell a programmer can think of every single detail of a large software project, even after writing it, let alone prior to writing it.
Perhaps you mean that he shouldn't start if he doesn't have any idea of what interaction and what modules he has, and what the interfaces between those modules should at all look like.
In that, I agree. But I've made The Last Detail mistake in the past, and it has prevented the success of some of my attempted software projects. I have done much better in projects where I jumped right into the water. Usually got it right, when I didn't, I had a much better clue how to get it right the second time. The time it takes to spawn two attempts at a software problem is much quicker than trying to think of all of those details in the abstract.
Professional programmers generally work as part of larger teams with lots of division of labor. Many such teams have dedicated designers. I seriously doubt that a professional programmer would attempt a project of this magnitude on his own. That doesn't mean it can't be done, but you are asking the wrong question.
Another question to ask is: who is this software for? Is it for your own edification? Do you want to write a book about it? Do you want it to become a larger project with more participants? Answers to those questions should determine how you structure the project, how you design it, etc.
My general advice would be: break the problem up into lots of smaller, independently useful programs. That way, you'll have something to motivate you and to show for your work. Don't create ambitious, general class hierarchies--that is the best way of killing even a large project, let alone a one person project.
The lobsters represent, in general, the human condition: People see life as a zero sum gain, and any gain of anyone else is a loss of theirs. That sort of mentality is far too common.
Mind you I think this ask slashdot is insane: That would be an absolutely massive project.
Today I have a nifty little directed-graph editor with cut/copy/paste, a palette of nodes to be drag-dropped onto the graph, a property window for selected objects, and multi-level undo/redo. I've written 4-5 such things in the past using C++ (I have this digraph fetish, you see) but I never got near as much done in three weeks. The timeline really impressed me.
Other environments may be just as effective, of course. I've only dabbled with java and smalltalk, so I'm not in a position to compare. I just know C# and .Net make for a pretty productive platform.
And no, I don't work for MS. In fact I've loathed them since bundled their email application to their (monopoly-holding) operating system, thus both tying and dumping, and thus putting a previous employer of mine out of business. That's a pervasive rant though, so I'll stop here. :-)
Anyhow, in spite of its birthplace, C# and .Net will be the foundation for my next couple of personal projects, and possible for many more, until something better comes along. I really like what I've seen so far.
The lack of multiple inheritance bugs me, but it's less of a problem than I'd expected, and it also presents an interesting challenge.
Build stuff. Stuff that walks, stuff that rolls, whatever.
Pfff. What are you? A professional.
Real developers jump in and just write.
Then when you're done, you write it from scratch again after seeing all the mistakes you made the first time.
Then you write it a third time and add comments since you can't remember what the hell you were thinking at 3:00AM on the last rewrite.
You think I'm wrong? Look at Windows CE.
True, but if he's willing to separate wheat and chaff, there's probably enough people here who know what they're talking about that asking here will not have been a waste of his time.
Especially if he's not discouraged by the e-holes ridiculing him for thinking big. While it's true that he probably won't realize all of his goals, before he's done he will have learned a lot and had a lot of fun. What else matters?
Anyhow, I have a bit of experience (and some of it with a not-completely-unrelated project), so I thought I'd chime in.
First, not coding yet is a good idea, and one that's lost on a lot of people. Think first, design, plan, write down your designs and plans (the very act of writing forces you to think about them more), and re-read them to think about them some more. Better yet, find some like-minded people to critique your designs and plans. They'll see things you won't.
Changing designs is easy and painless when you've only invested a couple paragraphs. It's a huge pain in the ass when you've invested hours or weeks or months.
I used to work for a manager who believed that with a good design document, you could hire a semi-talented high school student to do the coding. I think that's design documentation beyond the point where diminishing returns sets in, but on the other hand, you I also believe that if you know what it is you're going to create, you can't write too much design documentation. XP and "agile programming" are great for situations in which the client changes the requirements regularly, but if you have a clear picture of what you're creating, it's worth spending lots of time on documentation. In my experience it saves far more time than it costs.
Design the user interface, and write that down, in detail.
Do a high-level design of the whole system - what are the objects, what are their responsibilities, and how to they communicate?
For each class, do a detailed design. How does it carry out its responsibilities?
Then re-read the whole thing and look for issues that you didn't see when you started. Have a teammate reread the whole thing and look for issues. Look for assumptions you didn't know you had. Look for objects that have been tasked with doing things that they can't do with the information or interfaces they have available.
Then figure out a game plan, a timeline, that will get you a minimal application with at least some usable functionality. That gives you a gratifying achievable goal to shoot for, and it gives you something functional to (hopefully) help keep you inspired.
Good luck.
Build stuff. Stuff that walks, stuff that rolls, whatever.
That's my approach to the piano. So many other people already play, why bother reinventing the wheel by starting with chopsticks? I'm not playing a note until I get I get a record deal.
I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.
If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.
OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...
Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.
For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.
As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.
Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.
Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)
When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.
I have only just barely scratched the surface here. This is a truly vast question you have asked.
Good luck with the project.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Unless I'm greatly mistaken, OGRE is nothing like a 3D modeller. It is a 3D realtime (ie. game) rendering engine.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
If you can find a completely new way of representing a 3D object that is both more flexible to model and animate than current techniques, then you've got something really worth doing. I'm not smart enough to think of a totally new way to represent a 3D object, but if some one could it would change the 3D application world.
So few Ask Slashdot questions can really be truly answered based just on the posted question,
- by-giving-half-assed-legal-advice.com, so these questions can never be answered.
There are only a few types of Ask Slashdot questions:
1. Ones where the question is answered in the first 5 posts, it's usually something a quick Google or Freshmeat search would have answered. These are also known as Cliffisms(tm).
2. One that asks for specific legal advice. Obviously this isn't free-lawyers-who-like-to-accept-tons-of-liability
3. One that asks something like this. Usually the scope is too broad to give a meaningful answer, but sometimes some good ideas get thrown about. This is probably the most interesting, but still not too effective usually, unless the scope of the question is just right, which is rare.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I cannot believe that this was modded as Funny. I think insightful, or Informative would be better. I cannot begin to think of the number of times I have gone back and rewrote something over just because it was just not right enough.
But then again I am not a professional software developer and don't have a due date to meet.
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
There are things you sometimes don't or can't see until you try to code it. Often, it's the case that it's difficult or impossible to do something a certain way due to constraints of the language.
Iterative design and prototyping are, IMHO, much better than the old "design, then code" method.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
1. Think of the most important feature that you can describe in one sentence and that you estimate will take a small amount of time (say, 4 hours).
2. Write a test for it.
3. Write the code to make the test pass.
4. Refactor.
Repeat steps 1-4 until finished.
I decided that I was going to create a viewer for CAD models using OpenGL. Take my home page link to see what the end result was.
:)
./ you likely do not have the ability to complete the project." --Ignore these. If you have the time and interest, you will have a lot of fun and learn things that would be hard to do otherwise. This is worth doing IMHO.
You should set some realistic goals early on. I have read some good comments about planning. --Do this, they are telling you the right thing to do!
I wrote the core of what I thought would be capable of becoming the viewer. Turns out that I was right, but I ended up with a viewer that will need heavy rework before it can be built upon. It actually works well and does the job it needs to do, but not in an elegant and extendable way. Better planning and research, on my part, would have helped out a lot. Of course, now I can comment on such things because I see the value --even if it was the hard way
Take that plan and break it into a couple of realistic initial projects that both accomplish something and contribute to your end goal.
I also read a couple of comments to the effect of "If you are asking on
After putting my early revision of the viewer up on sourceforge, I have recieved comments and e-mail from people wanting to help me code better (thanks Thierry!) and from people letting me know how they use the program. One person, after some conversation, went through the code line by line with suggestions and advice that helped me improve the program quite a bit. This whole experience was good for me.
I have some general comments about this sort of program as well based on a few years AE experience with them. (I have worked with MAYA, ProEngineer, I-DEAS, StudioTools.) Watching users learn and use these tools has shown me a lot. Spend some time with these users and watch them work. Consider what is done well and what could use improvement. This will help your planning more than you know.
Go with OpenGL as the foundation for your display. It will keep your project cross platform. OpenGL is mature and very well documented so leverage that.
Think long and hard about your interface. What actions will one need to accomplish at a particular time? Think about different workflows and allow for them. Some users like to free form draw, others draw then size then draw --that sort of thing is important. Consider MAYA, it presents both methods at all times.
Part of the overall success of MAYA also lies in the fact that it is as much of a platform as it is an authoring tool. I believe this is key for this type of application. Since you really do not know how people will create with your tool, allow for that in the core design.
Think about the command structure as well. Lets say you have a function that will sweep a curve along a path. (Which is a very common function.) Instead of creating many sweep commands, build one that handles sweeps in general. Every package gets feature creep, make sure yours puts it off as long as possible.
Most of the programs I mentioned above have good workflow built in that is ruined by lots of odd commands that fill gaps in the feature set that a well developed core command set would have addressed if they better understood how people would be doing things.
Get copies of these and learn them enough to understand how things are accomplished and build from there. Many of the common mistakes have already been made for you, take advantage of that.
Build upon some of the more documented file formats out there. Your project will be used more if it is data friendly. While you are at it, make your file format a smart one. Document it well and be sure it can grow with your project in a sensable way. Given all the inexpensive storage today, do not be afraid to store lots of smart data that is easy to work from.
The most difficult part of this project is likely to be the geometry kernel. There are kernels out there that you can build upon. Most of these have many man years invested in them. You would be wise to do your homework here and take advantage of one of these. This will also help greatly with the data elements I mentioned earlier. ACIS, Parasolid, Hoops and others like them are what you should be looking for.
Invest a lot of time in good graphical feedback to the user when you get to that point. If things are modal, indicate that mode onscreen in a way that does not distract from the task at hand. Things like direction, spatial location, surface normals, control points and such should all be distinct and clear for easy manupulation.
Go have a bunch of fun, learn stuff, live to tell the tale. --Remember to go outside once in a while though!
Blogging because I can...
Linux already has good tools for modelling, rendering, and reasonable tools for output.
Also, trying to reinvent the wheel is a waste of time, there are a jillion different frameworks, engines, modellers, renderers out there for Linux, none of them complete enough to produce professional, day to day 3D animation work.
Blender is the most complete of the free packages, and it really is an extremely good piece of software, despite the annoying lack of 'Undo'.
Blender has some good animation facilities, but I really think it would be worthwhile to write a separate module that specialises in character animation. This would be a godsend to people who are trying to do complex animation with Linux, without paying for Maya etc.
I suggest, you take Blender and build a module into/around Blender's workflow to bring professional-level character animation tools to Linux. Use Blender as a modeller, as a 3D format, and a scene-integration tool, and build us a set of professional non-linear character animation tools, that integrates well with the best (soon-to-be) open-source 3D package in the world.
Look at Project:Messiah, a character-animation addon for Lightwave3D for a good example of how a great character animation tool works, and also at Hash's Animation Master, as those tools are really, really good too.
This would fill an existing hole in the toolset available on Linux, reuse work already done by the community, stand a better chance of getting to a usable stage quickly, and probably give you a chance to think about doing a 'ground-up-rebuild' from the perpspective of the most 'demanding' end users of your software - the character animators.
With Blender, you also have a huge community of artists who will thoroughly test your package, and provide suggestions and help to make it the best it can be.
I gots ta ding a ding dang my dang a long ling long
Yeah, I second that. I added lua as a scripting language to my 3D molecular modeling program and it totally rocks. Small, fast, easy to use and works as advertised.
For me, one of the greatest benefits is that it allows for lots of design exploration and customization without having to muck up the core C++ code.
mhack
Building a better ribosome since 1997
Yes, waterfall-style planning (actually, it's "Vattenfall"-style planning, as in the company "Vattenfall", but that's another story) has been abandoned for being too inflexible. When new requirements pop up, that kind of planning requires you to rewind to the requirements phase, which is Bad and not very much in line with how reality works.
However, your arguing is equally out of touch with reality, but from the other side. Have you ever written a spec? Have you ever made a design? I have, on some projects, and I have not, on others. I have been a professional designer-coder for 18 years, and I've seen projects without management crash and burn. I think the best way to sum it up is the old military adage;
"No battle is ever won according to plan, but no battle was ever won without a plan, either."
Let's begin from the top. Code is emotional. You don't throw away code. You rewrite it, you re-encapsulate it, you tweak it. But you never throw away perfectly working code. It's your baby, damnit, and you're proud of it.
So what if it doesn't solve the right problem? Well, that's what you find out after you've coded for some two weeks and start to see how things fit together. You're now stuck with two weeks' worth of coding that WILL make it into your final product, relevant or not.
OR... you could plan for two days and discover that already. And you could make classes that fit better together from the start.
It's true that you get started quicker if you don't plan ahead. It's pretty much like orienteering and running away in some direction (hey, it's about running, right?) without looking at the map and planning your route first.
Wrong. Coding is not about programming. It is about solving a specific problem. Unless you understand the problem before you start coding, you are going to solve a different one.
The statement "you'll be much smarter after just [one] week of codewriting" smells of elitism and being so out of touch that I don't know where to begin. Yes, you will know more about your product. You know why? Because YOU THINK ABOUT THE DESIGN as you code!
Only you're producing code that you wrote before you knew which problem you're solving. Back to square 1.