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"
Of course, I'm giving you advice on Slashdot, so what do I know? :-P
Wait 3 months [and] Purchase 3D Studio Max
If you can't get your software from 0 to at least barely usable in nine days, then wait for blender.org to go live on October 13. My $10 helped; did yours?
Will I retire or break 10K?
Now that the Blender Foundation have collected all the money (100k.. wow) to buy the blender source from NaN, they will be releasing the source under the GPL very soon (paid members pre-release due tomorrow).
Blender is a full fledged 3d program with some animation capabilities. Maybe looking at their design will give you some good ideas.
You can read more about it at http://www.blender3d.com/. Here's a brief synopsis of their goals:
Goal 1
Make the sources free
Goal 2
Establish artist/coder services
Goal 3
Make Blender a better product, and promote free access to 3D technology in general
So, not to totally discourage you, but perhaps you could simply learn how the code works for this project (which is very mature and powerful) and then contribute to it.
Good luck regardless of whether you start your own project or learn about Blender and help those folks out. Most importantly, have fun!
If you celebrate Xmas, befriend me (538
Steve Streeting had a similar concept in mind when he implemented his OGRE 3D Engine. He also has designed his engine so that it is written in C++, has a modular plug-in architecture that enables extensibility without recompilation (for certain portions of it, obviously), offers multiple 3D API support and builds both with MSVC++ 6 & 7 and also gcc 3+. The MS builds require STLport, an open-source replacement STL that's more compliant than Microsoft's -- ha, imagine that ... -- but that's along the lines of what you're talking about.
He's got a number of interesting design ideas and, from what I understand, is fairly accessible.
Also, and let me offer this, I have no idea about your programming skill and knowledge other than what you've claimed, but please ignore whatever posts come up that try to tell you how incredibly difficult this all is and how you're just better off joining an open source project or buying a package and saving yourself the hassle. If you want to do it, can really do it, and enjoy doing it then, not meaning to quote Nike's marketing department or anything, but: Just do it.
Regardless to what your general goal is, I would suggest you to look
at some of designs behind Visualization Toolkit (VTK). Some important
aspects include: unified API to all classes, reference couted object
management, platform independent build system, and nightly checking if
code compiles, regression tests, etc.
Another thing you need is to design with scripting in mind. For
example, almost every class in VTK can be accessed from Tcl, Python,
and Java, with (almost) no work on developers side. Classes are
wrapped with a fairly straightforward wrapping code, so it is
relatively easy to add scripting language support. The fact that
scripting is important you can see from a great success of AW Maya.
GUI is probably the most important part of such a tool. Make sure for
GUI to be easy to use, clean, and make sure it is scriptable. In AW
Maya and Paraview you can modify every aspect of GUI through scripts.
Good luck. Here are some url's:
http://www.vtk.org
http://www.paraview.org
Take a look at this website.
L -Man-Pages/index.html
It has plenty of tutorials and downloads on OpenGL.
There's also a large message forum.
http://nehe.gamedev.net/
This one is a reference to the OpenGL Commands
http://www.eecs.tulane.edu/www/graphics/doc/OpenG
First, get every animation package you can get your hands on and use them (don't forget Blender, Alice under squeak). Try building animations with programming - and use several backends (POV, BMRT, OpenGL, java3d and so on).
.net etc)? (Hint: Yes)
First (plus). Decide if you really want to do this, or would be willing to (say) modify Blender.
Second. This is a fairly large project so finding assistance would be a Good Thing. Get your assistance to criticize, add, delete and so on.
Third. Plan it out beforehand. Building a prototype (use a RAD tool if you can) can be valuable. Plan for staged completion (static first, backend done here, UI there, animation...).
Fourth. High level design decisions. Would you want a low level api so that it could be programmed from other languages (ie guile, perl, python,
Fifth. Sketch (at least) your goals (see above), it helps here to build scenarios from the user level (things like "I want the user to be able to do this with this kind of actions") Write them down as formally as possible. Differentiate between UI and lower level support routines and API's
Sixth. Write down your api as formally (use scenarios here too) as you can. Preconditions/postconditions will help a lot.
Seventh. Iterate First through Sixth till you're satisfied things wont change too much.
Finally. Code.
Have fun
I've used a couple of the big-name packages in this area (Maya, Lightwave, Renderman(prman & bmrt)), but i'm primarilly a programmer. Being a programmer of 3d applications at that, i have a few suggestions as to how you do it:
...). This doesn't mean you won't also want some simple command-language as well, but for the heavier-duty stuff, i think Python's your language, but then, it's really personal preference. I suggest you go with something that's clean and robust and has good, easy C or C++ language bindings.
First, encapsulate the system-specific stuff, preferably through pre-existing libraries where available. You can encapsulate the 3D renderer as well, though i'd suggest just picking one (*cough* OpenGL *cough*) and doing it well, at least at first, not worrying about wrapping it up. Next, i'd design the entire interface in said 3D rendering context or other windows popped up from it, both so that you don't have to worry about gui consistency across platforms, and so that it goes fast with fewer big library dependencies. There are a couple cross-platform libraries that do GUIs for OpenGL out there.
Now, if you've used Maya much, you'll know that it's basically a big programming enviroment with a few graphics hooks. The rest is scripted. It's truly amazing, but i think that this is quite vital. I'd suggest using SWIG or Boost::Python to do Python interfacing to your compiled code, and use Python to build the interface and implement a lot of the details (some tools, basic relationships,
Don't worry about a rendering engine, just get it to work with Renderman (prman, entropy, bmrt, etc.). Most renderers in comercial software fall short of those anyway.
Oh, and try to get the groundwork in there quickly, then do RAD with Python, replacing stuff as needed for performance.
So, to recap: incremental development, scriptabiliy, OpenGL everything for display, scriptability, Renderman export, and above all, scripability. Especially scriptability that's easy for artist-types to use.
Despite the multitude of responses you've already received, I'll throw my two cents in.
A while back I wrote a raytracer. After I had it doing primitives, texture mapping, etc. It occurred to me maybe I should just go whole hog and write a 3D modeller. Well I changed my mind due to time considerations, but maybe I can help you a little:-
If you know the mathematics behind it, implement the different rendering engines you want: raytracing, radiosity, photon mapping, NPR, etc with the primitives you want to support (spheres, planes, triangles, nurbs, etc). Doing this lets you do what has already been mapped out for you by mathematics. Just implement them, the things I listed above really don't take that long if you have some solid time to dedicate, and a firm understanding of the math.
Also make sure you have good reference to backup that firm understanding. If you haven't already,
check out:
I found this book useful for basic CG related math.
This is a good one on radiosity.
And this one photon mapping.
Here, and here are useful as well.
For particle streams and the such, see the papers residing somewhere in Pixar's servers.
The problem comes when choosing APIs, GUIs, etc. I would suggest going with something like OpenGL with GLUT. Most of the 3D modellers out there use OpenGL and it has good cross-platform support. You can then use OGL not only to display scenes rendered (I wrote mine out to png - I was lazy), but you can use the wonderful main loop of GLUT to
write your UI. Mind you this can be a pain, but it means you can make your interface fully scriptable and skinnable on-the-fly using discrete objects to make up the whole. The other choice is to rely on any of the many well-supported UIs out there with OGL support. Just watch the platform (in)dependence if that matters to you.
Overall, take the project in stages, ideally from the best defined (math) to the least (UI). Make sure each chunk is highly modular so it's easy to alter or replace.
I'm not sure if this will help, but I wish the best of luck to you. Remember to start a sourceforge project. You might find you can get some help.
Ok, I thought I would try to make this stand out a bit, since I specialize in 3D graphics for a living. I am by no means the top guy at my company, but do have experience in design implementation, as well as reading the Open GL reference guide several times. Let's start with general advice:
1. Keep all your rendering loops tight. Avoid doing any extraneous operations such as caching. Use arrays instead of linked lists(this keeps the data inside your cache). Avoid recursion unless you can be sure that your complier is not pushing and popping the function stack(some compilers are smart and will not create a stack unless you pass data as a parameter).
2. Try to perform as much work as possible at startup or while the user is editing. Remember you want to make as many operations as possible a once only thing. The last thing you want to do is put a bunch of crap in your rendering loop.
3. Take advantage of caching on your graphics card by using display lists and vertex buffers. On nvidia cards this alone can speed up your application by 3x. Only use immediate mode rendering when necessary. Keep in mind that most graphics cards use extra memory when you put the data inside a display list, so there are times when display lists can be slower.
4. Perform depth sorting for proper rendering of alpha blended objects. (this is something we failed to do in the initial design of our application, which was written in 1992 before alpha blending was a widely used feature).
5. Try to keep interface code generic, and try to make rendering code specific. It's always a tradeoff between readability and performance.
6. Learn assembly, not because you're going to use it that much, but so that you can spot areas of slowdown. Learning which operations are expensive is crucial. Function calls, random memory access, pointer deferences can all slow your program down.
7. As mentioned in six, optimize your access to memory, pay attention to byte alignment, which will allow you to pack more data into the cache. Also look into AMD and Intel's articles on optimizing for performance. The most crucial aspect is how you access memory. There are new instructions which allow you to load data from memory into cache before it's used. This can often speed computations up significantly in real-time applications. There are also many other tips, but I'll leave up to you to go to AMD and Intel's websites and download the white papers.
You mention animation, the project that I worked on for the last year tackled this problem:
The project was to integrate animation into an application that was not designed to do this, and to make it generic enough so that the user could animate anything. Here are some simple concepts to get you started in designing an app that allows users to animate in an intuitive manner:
1. Timelines - A timeline is a graphical way of representing time. You can use something that looks similar to a ruler, with time marked in units of usually every second.
2. Keyframes - These are points on this timeline that are specificed by the user. Keyframes always have a time associated with them. If I want to animate positional data, then that keyframe will have a time as well as data about the X,Y,Z position of that object. When the user hits play, the application will interpolate between points on the timeline.
Here's where C++ comes in handy. You can make both timelines and keyframes a class. Then, let's say I want to animate clouds, I can simply create a class called cloud timeline that contains cloudkeyframes. When the user clicks a keyframe, an interface opens up that allows him to edit that data, which in the case of a cloud might be both transparency and position. Then when the user hits play both position and transparency are animated according to the values of the keyframes given. The neat thing is, that a cloud timeline can be derived from positiontimeline, which means that you only have to do the work of creating an interface for animating position and orientation once.
Next, it is important to remember that timelines are a property of some object within the scene. I would say that it you can also keep object data organized in a generic manner. I would recommend using a scene graph. So, what the user would see is a scene represented by a tree, with the root node being the terrain and child nodes being objects on that terrain. You can also pull some neat tricks with scene graphs, such as nested transforms. This would allow you to have an object such as a car, with four wheels, to have wheels that are child nodes of that car. In this way, you could create a timeline for the entire car, and then the wheels could have their own timelines which would animate their rotation. The wheels would not know anything about the fact that they are moving along with the car. There are of course other ways of animation, such as writing your own scripting language, which I have never done. I have written a VRML parser, however, and I can tell you that learning both Bison and Lexx is important if you want to implement a language. There are other types of parsers, but using these compiler tools tends to be more straightforward. In the least it would be good to pick up a book on language designed and construction. The book I studied in College was "Compiler Construction: Principles and Practice" by Kenneth C Louden, but there are others that may be better. Anyway, that's enough rambling, and since most on slashdot are pedantic, please forgive any technical erros, it's Friday night and I wrote this in about 20 minutes.
The biggest problem with most 3d software is the
developers are absolutely clueless about their
target audience. Look at Lightwave, amazingly
powerful renderer, most modern 3d features, but
the interface is a joke. They improved it
exceptionally with the release of 6.0, but it
was mainly a Maya rip. The consequence of that
is that the software is basically dead, in terms
of future. Some really killer plugins are being
released for it, but my point isn't to bash
lightwave.
A few ideas I would recommend to keep in mind.
1. Most of your audience is not hard core, they
dont want to script, they are smart, but
want it to work out of the box. A button
solution if you will.
Now, the caveat of that is the power user.
They will want the flexibility that i talk
about later
2. Dont go off and use obscure methods, the
3d graphics industry is finally coming to
using standard techniques for basic applications
and Visual/Graphical concepts. Use those,
it will make your program user friendly and
successful.
3. Flexibility
One of the key things that make programs like
maya and XSI (I guess 3ds but i havent used it
seriously in years) is that the software is
extremely frexible. The entire GUI of maya
is manifested from script, this is a terrific
feature that is one of the manly reasons it is
so successful in the character animation
industry.
And finally, a personal request, allow usage of
hdr images for textures/lighting/rendering!
Thanks
-div
To be fair, maya was written pretty much from scratch about five years ago. It borrowed heavily from PowerAnimator and Wavefront Advanced Visualizer (and whatever that wavefront dynamics software was) but it was still revolutionary. It was also written by a very small team. I think its worth a shot at any rate, I always encourage innovation.
Why anyone thinks they got a deal by spending 2k less on max rather then maya is beyond me, by the way. But the maya vs max thread is a flamewar for another time...
Sig removed because it was obnoxious
Linux an untouched market? Hardly. Most of the big name large and powerful animation packages already run on Linux. For rendering, there's POV and BMRT, and Renderman for those with the $$. Then there's blender, scheduled to be opensource soon; not to mention the counteless modeling and animation projects that have already been started (ok, this is a stretch, most of them scarcely compile correctly, but someone's already working on it).
What I'd really like to see is a Linux port of Rhinoceros. This is a really great modeling program. It's loads more useful than AutoCad for designing (IMO), and it does solid modeling for a mere $800. In fact, this and a few games are the only thing that ties me to Windows at all. I'd be willing to fork out up to 500$ more to pay for the privlidge to use it on Linux, and I know there is demand for a port. So far they have shown no intrest at all...