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
Step 1: Create Sourceforge account.
Step 2: Place project into "Planning" phase.
Step 3: Wait 3 months.
Step 4: Purchase 3D Studio Max using the money you've been saving for 3 months.
Seems to me you need some sort of mechanical device, perhaps one useful for motion. You should try a roundish shape, some research has proven useful in this area. However, you should not take advantage of this research, rather, reinvent it.
No one has ever fired for blaming Microsoft.
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.
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?
I know that this is probably the most intelligent audience to communicate with, and any feedback would certainly be appreciated.
You're new around here, aren't you?
I think the first thing you should do is getting/recruiting yourself some programmers and designers and having a good team.
you need some sort of mechanical device, perhaps one useful for motion. You should try a roundish shape
That's called a wheel, and it's been patented (PDF).
Will I retire or break 10K?
Step 5: ???
:-)
Step 6: Profit!
(Ahh, the oldies are still the goodies
-- I have monkeys in my pants.
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.
was not this recently purchased from the people and GPLd? rip them off. it's cheep and easy. or better yet, forget it and just help them?
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.
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.
No one has ever fired for blaming Microsoft.
Figure out what file format you are going to use and what information you need to maintain to display a 3d object. Also remember tha current versions of Max and Maya were not written from scratch rather, there have been several incantations. Maybe you should target the feature set of early modelers and then revision up to current standards.
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
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
Anyone who had the drive to complete something like this would already be coding.
Silly.
-Kevin
- 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
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.
Why?
Looking to break into the animation software market?
Hire a team of programers - that's a start.
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
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.
You may want to take a look at using Trolltech's QT for the GUI; it is very portable and already has nice support for OpenGL.
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.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
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.
The person asking this question will not be able to complete this programming task if he has to ask questions like this one.
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
That area is chock full of software patents to unknowingly violate.
Why not list DirectX first, weenies?
if your personal temperament allows working with other people, design the core well and bask in the ensuing community effort. if you are more the lone wolf, rapid prototyping (currently incarnated under fad name "extreme programming") is even more indicated (in the medical sense) because you can (re- re- re-) design everything w/o undue discomfort. you could probably post a complete app in a few days, why not?
(do it right and we'll hook it up to emacs, oh yes.)
good luck!
thi
What you want to do will probably take more time that you will have available over the next 10 years.
Projects like 3D Studio Max and Maya are designed by developers who have had years of experience developing previous versions of similar software. Then it takes a fairly large and experienced team to create a program such as 3DSMax or Maya.
How would a _professional_ approach it?
He would use the existing tools because he would be too busy being a professional to fuck around reinventing the wheel.
What does this have to do with _you_?
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.
Doesn't Emacs already have this functionality built-in?
The posts here remind me of a story I once heard. There was a bucket full of lobsters. The lobsters hated being in the bucket, and were all trying to get out. Every time it looked like one lobster was about to pull itself over the edge, the others would grab ahold of it in the hopes of being dragged out too. Instead of being finding their freedom, they would pull the lobster back down and they would all be back where they started.
Why are you being a bunch of lobsters, Slashdotters? Why can't you support this guy and move him along towards his dream? Trolling and cynicism: is that what we have all come to?
On the other hand, the guy does sound like a fucking idiot.
The middle mind speaks!
Fags - Faggots Architect Great Software
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.
At the beginning was at.
I would like to write a full fledged 3d-Animation Software package from scratch. ... The question is, what is the best programming paradigm to use for such a project?
Ask Larry Wall nicely. Maybe he'll squeeze some NURBS and Inverse Kinematics support into Perl 6.
I just read the article, it's a total scam.
This person needs a life perhaps, but not money.
fucker.
Worst.. "Ask Slashdot"... Ever! - CBG
so why not write a front end that generates files for rendering? Writing a front end for renderman would be pretty interesting and wouldn't take you 65 years.
love is just extroverted narcissism
to be honest this story looks like a troll. but on the serious side of things take things step by step... why not write a few 3d demos, with a rotating torus or cube for example ;)
Open Source developers innovate in hundreds of little ways but not often in major ways. What I mean is, create a framework.
If you can do the high level design very well and document it just as clearly, then it can be useful and effective to garner a team of other interested OSS developers. Once a minimally functional application is built to wow people on a point or two, others may very well take interest. When they do, you have to have available componants of the system to immediately delegate to them. These componants must be easy to understand--such as, "it inputs this and must output that." If you've engineered the framework to be modular, then others might be able to understand how to contribute prior to loosing interest because they're lost in your code.
Matthew
In addition to all the solid advice given here, I offer this little bit: Get in touch with actual animators, modelers, lighting and texture artists. Get as many as possible, from as many different 3d packages as possible to put the program through its paces. Remember, a lot of these people are not very technically minded and will appreciate a clean and intuitive interface. For a prime example of a great UI look at Softimage|XSI It is easily the most intuitive of many 3d packages I've used.
My patience is infinite, my time is not.
Just some suggestions off the top of my head: It seems like that's what you're going to do by writing it in C++ so maybe I'm just repeating what you know, but it lends itself naturally for such things... abstract object/shape class and then go from there.
You should have some sort of independent 3-D rendering layer, if you want API independence. Make it extensible, and don't forget about hardware shaders for quick visualization of textures, etc... even something that many commercial modellers don't support yet. Have some sort of translation layer to translate from your own material model to whatever hardware shading language is in vogue now.
Use embedded Tcl/Tk for UI scripting, to allow maximum flexibility
There's 10 types of people in this world, those who understand binary and those who don't.
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.
Essentially there are two ways to make sure your ap is portable, either write yourself a graphics library that your program uses exclusively and then port it. Or just use api's that can be cross compiled anyways. If you use opengl than you can compile on anything, but it you want to find a way to use direxctx or opengl you are essentially just going to have piles of wrapper code to slow it down and twice the work. I would recommend using something like gtk for your interface as it has been ported to windows and has opengl widgets to make the whole thing quite easy. It is fast looks pretty and makes sense, at least to me.
Moonlight 3D, the modeller that was declared dead so often on /. (just search for "moonlight" in the /. internal search function) is under open development again, not yet functional - not quite functional, mostly due to OpenGL bugs but we'll get those bugs tracked down eventually
not as featureful as blender, but when working, usually said to have a much nicer GUI...
oxygene
I started working on a project similar to this but gave it up in order to devote more time to my 'main project'. I'm attempting to create some sort of electronic device that will do great numbers of calculations in a fraction of the time it would take humans. suggestions????
A circle-snot is a Taco-snotting circle-jerk, another practice common among the Slashdot crew.
The first way is the "easy way out" and will give you almost immediate results if you have a lot of skill: Locate a bunch of free software math, physics, graphics and database libraries and programs. Try to sift the quality ones from the flaky and crappy ones. Then, write your main program, basically hacking out all the necessary features and modifying all the code you've obtained to suit your needs. It'll probably be flaky at first, but after hunting down some big bugs, it'll be relatively stable. Just make the program BITCHEN by giving it the most innovative user interface in the world and giving it all the features people need, many of the ones they want, and few relatively unused and unimportant features. People will love it, and they'll start submitting patches. By the time you're at version 2 (about three to four years down the road), you'll have a development team and can start doing rewrites of certain sections. In 20 years, you will probably have the most awesome graphics package around, and you'll be setting standards. The risks here are that you may not make it stable enough, and people won't be interested.
The other way is to design and write everything from scratch. It is EXTREMELY difficult to raise a from-scratch piece of software so it actually works and is used by people. I'm out of time. Sorry. Gotta go.
Look carefully at Maya. It is going to be difficult to improve on THAT interface. Bill Buxton really knows his stuff, and has created the interface that is propelling Maya towards ubiquity. Are you going to write the renderer too? One step at a time! Make your modeller/key framer output renderman and then you can use BMRT until you've written your own. By all means, look at Blender, but don't even consider C#. QT is an excellent suggestion - many many graphics people prefer the mac (for good reason) and Linux is making great inroads in this arena, displacing SGI. QT will guaranteed crossplatform capbility. Fake it all in Python first, then code the critial stuff in C++. Use Python as a scripting language - there's already a ton of 3D and image support and you won't be alone. Many of the large houses use Python to tie things together. Also of great interest should be the Lightflow renderer. Gorgeous imagery and a (albeit limited) Python wrapper for scripted scene generation. And if you're going to do MOCAP, for heaven's sake avoid Euler angles. Quaternions applied early on will save you a lot of grief later.
if i remember right, though, STLport was necessary even for older versions of gcc that hadn't quite finished up templating the iostream stuff, etc.
...
...
computer labs at school had an old borland c++ compiler that -thought- it knew what the STL was, and Visual C 6 with no pathces installed -- just enough to start compiling and croak. At least the borland compiler finished compiling, then trailed off when iterating through certain containers
and we were learning 'data structures' on these, and couldn't convince anyone to just grab a copy of gcc on our Unix box. grrr.
so yes, STLport is not a bad idea -- at least you know you've got a good STL available if your local compiler comes with stupid libraries
The best 3d package I have seen is Houdini, from sidefx software. www.sidefx.com
/ houdini/hou dini_apprentice_download.html
If I were to write my own it would be like this program and its procedural approach.
they have a full demo you can download, and CD's in several of this months magazines (CGI is one).
Along with video tutorials which help out alot.
heres a mirror with the download.
http://www.techimage.co.uk/tc/products
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.
There are a great variety of cross-platform libraries and frameworks that you would find useful. For example, for a humble JPEG coded, the Independent JPEG Group's JPEG library works really well and runs on everything from DOS to a Cray. It is portable beyond belief. For a lossless graphics format there is libtiff. (I don't know what's available for cross-platform video format software, but I'm sure there is some.)
If you're going to write in in C++, my favorite framework for GUI, file API's, TCP networking, multithreading and database is ZooLib. (But note that presently the best code to use is what's in CVS because it hasn't had a release in a long time (Real Soon Now, really!).
I've started writing a book about ZooLib that is released under the GNU Free Documentation License.
But if you don't like ZooLib, it's important to use some cross-platform framework. There are many to choose from.
Another important framework is the Simple DirectMedia Layer. You will want this for your rendered scenes and for sound (ZooLib does 2-D graphics, it's not a 3-D API).
If you write in C++, do as much as you can with the Standard Template Library. There are some excellent books that teach how to use it.
For a long time, the STL has got a bad rap, in part because the template definitions in the header files are hard to read, and in part because of poor compiler implementations of the C++ ISO standard, or poor implementations of the library itself. But by now there are excellent implementations for every OS that is in common use. For example, on Windows, don't bother with Visual C++ - use Metrowerks CodeWarrior or Comeau C/C++.
Even if you choose to work with a broken compiler, the STLPort library provides a compliant standard library that will work almost anywhere.
I was rather intimidated by the STL when I first encountered it but once I got a good book and learned how to use it, I thought it was the best thing since sliced bread.
Boost has many portable C++ libraries that are of excellent quality.
Finally, I am (slowly) building a website devoted to educating developers in cross-platform and portable programming called ByteSwap.net. Read my first article there Writing Cross-Platform Software - Getting Started. More articles will appear when I get more free time!
Request your free CD of my piano music.
with the design phase. just open up an editor and start coding. the build and fix model of development is under-rated.
Boy, you sound pretty damn arrogant.
The realities are that you are never going to get it right the first time, stupid. Which means that you will probably never even start this "project" of yours other than jerking off to how intelligent you are because you have a very good understanding of 3D mathematics, etc.
What you need to do is get version 1.0 out. Do what YOU think is the best design and just fucking program it. WHILE you are doing it, YOU will realize what you want to do. This is called evolution, and unless your project evolves and undergoes several layers of modifications, it will probably be pretty shitty.
Getting the project up and running is the part of the project that has the greatest inertia, and by saying that you refuse to consider doing anything until you get it perfect really indicates that you are quite young and don't have any practical real-world experience.
Go away and build something (or multiple things) small, but related, using technologies and methodologies that might be useful. Learn what works for you and what doesn't. Repeat a few times, until you know what's going to work for your project.
To give an analogy, look at what John Carmack is doing at Armadillo Aerospace. When he started out, he and his team didn't know enough about rocketry to decide what technologies they were going to use in their ultimate goal (a vehicle to win the X Prize for a private space shot). What did they do? They've experimented with a variety of things on test rigs and as part of complete craft, and discovered what works and what doesn't.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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.
The first thing is to ask yourself whether you want this to actually exist as a product that works. I'm sure you do. But it's possible your knowledge of physics and 3D math may be outweighed by your (in)ability to create a realistic development plan. You have grand aspirations. But if you can't make progress, let alone produce something useful, nothing else matters.
So you need a design that will allow you to be productive, probably in small increments. You need the Unix shell model, in which the big stuff happens in a dynamic scripting type of environment, and the heavy lifting happens in a high performance environment, with a well-defined and straightforward interface. Go find the Unix Magic poster right now and hang it on your wall.
In other words, you need a framework. I suggest this be your central design philosophy - code your high performance stuff in C++, keeping them small and self-contained. Do your higher level design in an interpreted, dynamic language that invokes/manipulates your low-level hiperf routines. You can migrate code to or from C++ to find the right balance between flexibility and performance. You will be able to change things all around and do significant experimentation quickly.
But more importantly, with the right framework in place, it will be easy for anyone, such as you, to contribute in small increments.
must... stay... awake...
Hi.
I have just decided to re-invent the wheel. Also, I'm going to re-discover fire.
Do any of you guys know the best shape to make my new "wheel"? Also, what will make "fire" burn?
Any help?
Taking on a project of this scale by yourself requires a monumental amount of arrogance. Now, that's not a bad thing necessarily (especially if you pull it off), however the fact that you asked other people for their advice shows you don't have enough arrogance to bring this thing to fruition. Either do it, or don't do it. If you're so smart that you know all about 3D mathematics and physics and computer graphics and have a solid background in programming (doesn't knowing all about computer graphics kind of require this?) then you should have done the design work for this kind of project in the past.
Write it in Python. Python is a beautiful language! It is easy to learn, and it will cut your development time by an order of magnitude.
Ridiculous waste of fukkin time! I don't think John Carmack would have posted anything close to such a wasteful interrogation (as an example!). If you want to do something you get off yer ass ans fukin do it, without waiting for a pat on the back and stupid advice from half-drunken moronz like us....
I - D - I - O - T!!!
Make an ASCII art renderer plugin! and save us the pain of Yet Another Unfinished Project!!!!!
heh :)
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.
Something like:
Software Engineering 201 - Large Project Design. Fall 2002
McMartin/Dhawan, T-Th 1-3pm, Rm A104.
Students will produce a detailed project plan for a large graphical software package, with emphasis on design, resource requirements and critical path.
I will advice you on the things your 3D Experiment Project should have:
1. A plug-in architecture, based on a very simple to use API. This way you concentrate on the basics, and hopefully then allow everyone else to develop plug-ins to extend the functionality. This will save you a lot of time.
2. Provide a tutorial to show how simple it is to develop a plug-in for it.
3. Use XML-based formats for your files.
4. Plan from the start for the program to be distributable, so one can render on multiple nodes on a network.
5. Check out the TrueSpace user interface. TrueSpace's output is not as refined as the big guys, but the 3D interface is bar-none the easiest to use (and it also support traditional 4-screen views). You can download a demo from there to check it out yourself.
6. Make it run on Linux, Mac OS/X, and Windows 2000/XP.
7. This is a long shot if you don't use Java, but if you program to the Java 3D API you automatically support OpenGL, Direct 3D, QuickDraw, etc, saving yourself a step in the process.
8. Include a scripting language for ALL internal functions and user interface commands and menus. That way a hard-core programmer has access to the low-level stuff, and a casual programmer can create simple scripts to automate a series of keystrokes and menu commands. Javascript could be great for this, or maybe some XML-based language?
9. Plan to include support for 3D glasses. They trully make modelling and animating a lot easier.
10. Include a utility to import/export to at least one well-known format, so people can get started right away experimenting with their 3D objects and scenes (Lightwave, 3DS MAX, Maya, etc).
It's easy to get caught up in all the features you need to have in 3d graphics, but the truth of the matter is that when creating 3d animation or models, there are not very many tools that are used often. Every software has some sort of bells and whistles to show what you can do in 5 seconds at a trade show, but building and animating is almost always a matter of pulling vertices, moving and rotating. If you can come up with an elegant way of doing these things, you have a very important basis for a software package. Some of the high end 3d tools of today have forgotten that artist spend a lot of time hitting the same buttons over and over again. The easier these few important areas are to navigate, the faster you can get the model or animation done. And everyone wants to go home and sleep at some point. Well, I'm assuming that's true of some people out there.
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....
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
A more doable approach to getting into 3D animation software design would be to design something to complement an existing program.
For example Weta designed an AI program to create the hordes of characters in the battle scenes of LOTR. Their program (plug-in?) worked with Maya (the industry standard)and far surpasses previous attempts. Compare the armies in LOTR to the robot army in Star Wars. If you look real close at Star Wars you can see multiple robots that are duplicates but in LOTR every character in the army behaves independently because they are all AI.
This guy could work on something like that which would improve on the allready impressive Maya. Or you could just contribute to an open source project...
FoundNews.com - get paid to blog.,
Then realize that you're an atheist and you've just been wasting your time.
Here's a great post filled with interesting questions. Where's the Ask Slashdot-ee's answers?
Why don't the Ask Slashdot-ees every engage in the conversation? (At least not that I've seen.) Maybe they don't know when their question has been posted?
So few Ask Slashdot questions can really be truly answered based just on the posted question, just as few (if any) pieces of software can be written without interactively interviewing the users and getting a dialog going about what they want. If you're going to Ask Slashdot, do it right!
Forgiveness if the Ask Slashdotee has since replied to this, but it still holds in general.
Another SourceForge project that deserves mention in this catigory is CrystalSpace. It is very stable and looks realy good and has the advantage that it's cross platform. If nothing else, it would make a good display package for a 3D design package.
JFMILLER
Strive to make your client happy, not necessarly give them what they ask for
One thing you'll want to make sure and look at is the file formats and standards that the name-brand packages use. Try to accomodate those users that will have been using something else by making it easy to transfer files between your package and their old one. Don't make your interface too unlike other programs, either, or else it'll be confusing when your users make the switch to your package. Also, get some friends who aren't that good with computers to test stuff out, and see how easy it is for them to use it.
Good Luck!
If you are competent enough to even think of doing something so grandiose than why would you do an ask slashdot?
All other rights can be derived from freedom of speech.
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.
One such advantage for them because of this is prototyping the interface. They (or anyone else) can simply re-write the user interface, menu system or anything else. I believethis is the key to innovation in the industry.
Point? Rather than looking at the design, look at expandability, power, and ease of scripting (MEL is a lot like C).
US Democracy:The best person for the job (among These pre-selected choices...)
As one of the artists that frequents slashdot now and then, I've got to tell you that your product won't be touched by us artists if it's just a straight knock-off of 3DSMAX or Maya. Talk to artists, get some original ideas in there. Yeah, it will get ripped off by Maya or Softimage eventually, but just get some new ideas in there. 3D software could be sooooo different.
Consider implementing the Renderman interface. It's a widely accepted standard for renderers, and it's not difficult to write code that will export Renderman-ready files. The best part, I think, is that there are a diverse group of renderman renderers out there, some even GPL'ed. That way, you can focus on writing a good modeling/animation package, without having to worry about the renderer, or vice-versa.
Dan
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.
(* 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? *)
:-)
You will get a jillion different answers to this question. There are very few agreed-upon metrics for deciding which methodology is the best.
It probably depends on the personality of the coders/mainainers and on the domain (graphics in this case).
One size does not fit all. It is sometimes said that you don't get a decent design until the 3rd try.
On another note, as others have noted, there are plenty of *existing* open-source projects that need some improvements. To be practical, you should look at improving existing ones instead of starting from scratch (unless it is a purely personal quest).
Start by fix Blender's goofy interface
Table-ized A.I.
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.
Instead of attempting to conjure up a new software package and finding that many others have done this before, and failed... look at the conductors program that Alias|wavefront has for Maya and see how you can add to the community. Check out www.highend3d.com, find some local A|w and 3DS Max users groups and find out what is missing. Fact is, you're not going to make any money, and you're not going to top what A|w already has that is under patent. 5 years ago the price of Maya was 100k per seat.. now it is $2000. Let's put this in contrast with a dining room table that I just purchased. The table (made in asia) was $1299 and the 6 chairs pushed it up to $2500. Someone in Asia made this table for about $50 in parts and labor.. While Maya has costs millions of dollars and now can be had for $2000. See my point? If I were you I wouldn't waste my time.
Zaxwerks Invigorator is a conductor product that has had a wonderful return for the creator. All it does is extrude ai or eps files to 3d objects. This guy has made thousands on something that I bet you would say would be cake to make.
I would suggest using Qt from Trolltech. You can make custom widgets and it will save you cross-platform headaches. Also I would suggest just focusing on OpenGL support (atleast initially) for cross-platform reasons. I've heard good things about Python for scripting but I have limited knowledge in this area.
I would sugest that you use OpenGL it is widly used and it is better in cross platform development then DirectX is.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Hey! This seems like a really cool idea and a lot of fun! I hope you don't get discouraged by any of the other posts and go for it!
Incidentally, the products you mention have each taken hundreds of man-years to write by extremely well manned and financed companies. It's good to set goals for yourself, but is one of them living to a thousand? :-)
If you plan on making this a legacy quest for your children and grandchildren, go right ahead. Unfortunately you won't personally be there to see version 1.0 software ship.
The more realistic alternative is to choose your focus more carefully; write a component, a plug-in or a tool for a more specialized task. Research new technologies or implement and synthesize from ones most recently discovered by others. Compared to the giants you are small and flexible, make use of that advantage.
Oh, and whatever you do, do it with others. It's more fun that way.
Jouni
Jouni Mannonen | Game Designer, Consultant
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.
That first point was supposed to read:
1. Keep all your rendering loops tight. Avoid doing any extraneous operations. 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).
Have you ever thought that he is trying to get a team together from the slashdot crowd using slashdot's huge audience, and posed it as an ASKSLASHDOT just to get it on /.?
Just because he hasn't told us of any specific design plans doesn't mean he has none.
/. doesn't deserve to be an elitest crowd. It isn't good enough. So get off it.
A Good Troll is better than a Bad Human.
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
If you read the methodology of that performance comparison, you will notice that the author says:
"All artificial language performance benchmarks, mine included, do not measure real-world performance." (authors emphasis).
The performance of various languages varies greatly in different situations, and factors other than speed play a part in the choice of a scripting language for an application.
I want to build my own slashdot so that I can stuff my Karma. Any advice?
Table-ized A.I.
Not at all, should be a snap, especially with guys like me helping you out! I'll be able to pitch in just as soon as my finish my own current little project, Creating World Peace, which should be done Any Day Now, right?
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.
Why go for C++ and all its complications? Objective C is cleaner, and if using the GNUStep framework easily portable to the Mac OS X.
Obviously, if you want to Do The Right Thing you might want to use a really relational database and code in Lisp, but I do not know if that is practical already. At least the Lisp part is for sure, and one can always go to SQL as a second-best and stopgap to a real relational system.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
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
If you want to write something like 3DSMAX lightwave Maya or XSI, alone, you're either a genious or completely on crack. If you're a genious, and know how to make such an app, I don't understand where you could not have the intelligence or knowledge of coding it the right way with the right tools for the job.
I don't want to sound like a flame but comments like this always crack me up, if you want to see the biggest success of a "little people's job" look at lightwave3D, 2 guys made that software in the beginning, one guy on the modeler, one guy on the layout, today, they have a lot of people working with them because at some point, if you want to have features, one person or 2 people can't cut it anymore. Even if you know your 3d your maths and all. You'll always end up not knowing that little thing and require some research and steal valuable time...
Look at another example, project messiah, supposed to be the best thing out there, with the best renderer, the best animation software and all, all in one package... guess what? they are Late, they have a pissed off userbase, and while I have a lot of respect for that company and they did a lot in the 3d scene, they've hit a reality in the programming world that doesn't always apply in the 3D production world: you don't always meet your deadlines or objectives in time. So 1 year later than the "release announcement" they are still late, not because they suck or they have no talent, god, they got LOADS of talent there, and they've proven that they can do the work with the previous character animation plugin they've made for lightwave, but doing everything from scratch is more work than you can think of. Plus reinventing the wheel is kinda useless.
If I were you, I'd use my skills to write a new breed of plugin, there's always things that people would like implemented, new paradigms, new concepts, this year, stuff like sub-surface scattering and 3d hair were the big hit, be in advance, read some theorical siggraph paper, do some plugins, get known, and probably a 3d software company will notice you and buy your stuff to integrate it to their package and there you will be able to make a difference. I can name you people that got millionnaire that way.
Again, I'm wondering if this story isn't just a way to generate traffic and make people talk, Maya got an ARMY of developpers, Discreet (3dsmax) got a lot of people, Lightwave, less but still, it's NOT a one man's job. By the time you'll finish the basics, you'll have 10000s of features to catch up, and lots of debug too probably... anyways...
--- Metamoderating abusive downgraders since my 300th post.
Thats GNUemacs you insenstive clout!
http://saveie6.com/
My best advice for those developing 3D animation software: do 3D animation. Then write the tools you need to do it better.
It may not be that difficult to reverse-engineer an existing program (in the sense of reverse-engineering its general architecture, not necessarily duplicating it bit for bit). I find that the public documentation on Maya and Lightwave is detailed enough to get a very good idea of how their internals are structured.
First create your own hardware platform, then write from scratch a new OS (I mean at least better than Windows + Linux together), then try if possible to provide enough drivers to support most of the other existing plateforms. And finally be sure to program a full email client, web browser and word processor (so you don't have to reboot for those tasks).
After that, you'll see how easy is to develop a 3D modeler.
Et voilà !
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.
genius
That's called a wheel...
You mean to say he wasn't talking about a vibrator? Guess I need to get my mind out of the gutter...
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.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Make it compatible with 3DWM
I'd ask professional (read:old) 3D coders of maya, blender, etc... about what they would do if they had to do it all over again. Yes these products are wonderful, but anything can be made better.
Actually, at one time I had a semi-working 3d modeller, based on Visual Basic and DirectX 5. One could create simple objects or design faces by vertex, and then create objects from the faces. I seem to remember in the end I had gotten a working gl modeller, although I think the texturing had issues.
:-)
Direct3d is not incredibly difficult to work with. Although I swear that it was easier back in the days when one would import library functions from custom TLB's and there were a crapload of samples online, since the current Microsoft SDK examples suck.
I don't know if openGL is any more difficult, I imaging skilled C++ programmer could probably come up with something quite a lot better that I did in about 3 months.
My last recommendation, check for similar projects, and release your project as open source. It might net you more assistance, and it would probably make a lot of slashdotters happy as well.
I'd give you code for the old VB modeller, but looking back at it, it's so bad that even I can barely figure out what I was doing. I figure that by the time you're 90% done you'll look back and say "wow, that first month of code is absolute shit, maybe I should rewrite it."
first of all, if youre going to do this, dont try to make it work on all platforms. it will be hard enough to make it work well on one platform. if you can do that, it'll be no problem to port it cuz you'll be rolling in $$$ and can pay someone else to do that.
second, never tell anyone that you asked this question on slashdot.
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...
We had to write a modeller and a raytracer for the 3D graphics class at UCSB. The modeller was just a single window with no pull-down menus or text or anything fancy like that. You would click the 'n' key to start a new polygon, then you would click around on the screen a few times to create the polygon. We only supported polygons. You could select polygons with the mouse and use 'r' to rotate them around. The drawing to the screen was via OpenGL.
The modeller was simple, but it worked. If I recall, you hit 't' to do a raytrace of the current scene. It would pop up another window of a hard-coded size and do the raytrace for each pixel (i.e., traverse accross the data set figuring out what to draw). By the end of the quarter (it was a 10 week course), it did lighting with the blinn-hill ambient, specular, highlight model and it had different reflectivities and transparancy. Plus, in the modeller, you could save and load models and reparent objects to create a hierarchy.
Anyway, it was a good way to learn a lot of 3D graphics stuff.
My other first post is car post.
It's never apparent what the best final structure is when you start. Allow the design to evolve. I think you still want to do a fair amount of high level or top down design at the start, but don't worry about getting everything perfect. Part of this model is also working in pairs or teams.
...allow me to render a hot mamacita with a nice, bouncy 36DD rack, then by all means, code away...
A lot of people seem to like bashing this kid because of how unrealistic this is. I think it's unrealistic too, but I think he should do it anyway. Why? Because he'll learn a LOT in the process and it will make him a much better programmer. I know because I was this kid. I've started a number of projects in the past that were completely delusional in retrospect. However, this kept me coding, and it kept me learning. For some people, what keeps them inspired and motivated is working on the Next Big Thing, not fiddling around for the fun of it. Although none of those projects were completed, I was easily among the best, if not the best, programmer in my classes, and my teachers knew it. While he may not end up making the product he wants to make, what he will do is make himself a much better programmer with a lot of knowledge in this area, a lot more than the average coder coming out of college. It will serve him very well later on, since this is clearly the field he wants to work in.
The only way this will backfire is if he puts so much faith in this project that he neglects his grades, his search for a real job, or worse, drops out of college to pursue this. I don't think he will, because he knows it's huge (if not how huge) and there will be plenty of time for reality to sink in.
i have been thinking of such a program myself for a while, and i agree waiting to start coding after having a solid conception of what the code should look like will save alot of time and wrong turns. its my belief that code should work with u, in that u should think about something really small which itterates and reitterates its self into a fully functional dynamic entity. i have been thinking about AI and neural networks, and how relationships beetween processes define their own value much as we humans define ourselfs keep ur avenues open and ur lights on! ull find ur goal quicker that way. dont lock into anyone way of doing something, thats why i suggest dynamic relationships.
Have you looked at the likes of openFX (www.openfx.org)?? Small open-source programs like that can show you a lot about the good and bad ways of doing things, and sometimes they contain useful ideas for greater problems
Who me? Crazy? Never.
Sorry, maybe you can have the next one!
I'm late to this discussion so you may not be able to read this but speaking as a professional programmer but not necessarily a graphics expert.
(I am using blender as an example here but I am sure there are other packages out there where source code is available and which you can extend or experiment with.) If you want to have something that you can and will use, you have to take this approach.
But then, what kind of a hacker does not like a challenge? I can only advise the following:
but it seems to me that some of the best advice here to is to find out what people are already doing and either help make an existing project better (like the open source http://www.wings3d.com) or write your own plugin for an existing app.
i don't know if anything exists like this but if i wanted to do a lot of modelling it would be great if i could put one of those gloves on that were all the rage a few years back and create models as if i was really modelling clay. that sort of hands on motion capture ability would be brilliant.
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
Java is a good solution in my opinion for such a program. C++ will draw you into many design issues that have been solved with Java.
It has nice 3d support which is getting nicer by the minute.
It can easily handle run-time extensions.
It runs on every O/S that has a JVM (almost).
It is almost similar to C++ in syntactic aspects.
It allows for faster coding. No more separate header and source files. It is a pain in the ass to update both files with comments etc.
It provides automatic documentation through the use of metatags in comments.
It has a nicer error catching model.
It has some standard GUI libraries.
I am not saying that you can't do it in C++, but it will save you lots of time if doing it in Java.
C# is another good option but limited for the Microsoft operating systems.
What about accuracy? If I remember in games the dimensions aren't as critical, as say in things like CAD, or object modeling in a Modeller. Game engines are geared more for speed than accuracy (or correctness).
I believe that this guy has made a crucial point but not emphasized it enough: PLUGINS PLUGINS PLUGINS!
And when I say plugins, i don't neccesarily mean simple stuff. I'm talking about engineering your modeler modularly so that you can actually have a hope of finishing useful components on a reasonable timeline. A good example is a friend of mine who is really interested in modelling. So much so that he's coding his own rendering engine. While he's undertaken this project solely in his spare time, he's devoted quite a bit to it and has spent the last two years working on it. By now he's actually getting something that is working decently and it's really coming together.
So, if you want to undertake a project like this, screw the framework at the beginning. Other than a REALLY rough sketch, get straight into the design and coding of the major components.
Get a mirrored ball and a chessboard....
There is a thin line between genius and insanity. I have erased that line. -- Oscar Levant
The question you asked immediately tells me that you should probably try to tackle a smaller project 1st. Sharpen your programming, architecture, and management skills. When you are done with this and you think of your 3D program and you don't ask yourself the questions that you posed to slashdot then you are ready to lead a team at making it.
I wouldn't suggest a program of that size alone though. Inexperienced programmers often filled with the power at their finger tips often bightoff more than they can chew. I even got drunk with the power of programming myself a few times and tried to make mammoth solo projects. Years of experience later I now know they would have taken me tens of thousands of man-hours to make.
Do your project timelines 1st then caculate how long it will take you. Then realize the best planned projects usually take 3 time longer.
A concerned Software Engineering Manager.
Why are you trying to teach the ABC of real-time 3D ?
He has asked a completely different question. He wants to write a complex animation application, not an OpenGL screensaver.
The fact that you got rated as Informative, shows how 3D graphics is such a mystery for the other lamers here on Slashdot.
Professional my ass !
get with it
Not that long time ago I bought Large Scale C++ Software Sesign, its a really good book about how
to structure and design your programs.
The author himself work on a graphics program, so i think this book will be very good reading for you.
...wondered how you would do the physics part of you 3D Animation App.
:). Like instead of doing physics-to-polygons/vertices/splines/etcetc..; sratch that and built around molecule/"atoms". Let me explain myself a bit...
:). And IMO (copying) mother natures structure is the only way to get to "realistic-real". To date I don't think I've seen a sceen where I haven't been able to spot where they've used 3D illusion(s)/didn't use (yepp, even ILM's fancy-smancy illusion are noticeable to the human eye).
:) hehe....
Are you going to gather all the physics laws and apply them to your vertices/polygons of your model(s)?
I just thought if you were going to 1} do-it-your-self 2) from scratch, do something new
If you read Chemistry/Physics, you know the whole world is based around atoms that fore molekyles, that eventually fore us and the rest of the world. Every 3D Animation Package out there are striving everyday to make 3D look more and more realystic. And just they'll ever get (if they continue to strive that way) "something that may look real, but isn't real" - other words - nonreal.
I'm one of those, "if you do something, then at least do it rigth", whereby, "if you are going to do something realistic, at least make it real"
To got to my point; materials with a molecular structure are bound to become realistic-real, while material with a polygon/splines/vertecies/etcetc are bound to [just] become realistic how much one strives.
Not to mention, that there are a lot of other things that are going to get hell of a lot diffrent. E.g, applying texutre, light, rendering
But as an outcome you are bond for the future... where we (I) want things like a holodeck [try using polygons there.. hehe)
[This just my opinion, so take it with a pinch of salt, my brain can output the oddest thing to mainkind, but but, "everything is possible", right??]
I don't claim I know more than I know, and if you know you know more than I know, then by all means, let me know.
Agreed.
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.
What, like that would make a difference? :-)
Build stuff. Stuff that walks, stuff that rolls, whatever.
just wanted to clear a few misspellings.
Fore == Forge
And just they'll == And that's just they'll
To got to my point == to get to my point
bond == bound
This just == This is just
I don't claim I know more than I know, and if you know you know more than I know, then by all means, let me know.
Are you looking at my bum, you cheaky monkey!
This sig was generated by a barrel of trained kittens for SeXy_Red (550409).
That was possibly the best, most helpful reply I have ever read on Slashdot.
Kudos to you sir.
Cheers,
Backov
In the law there is no overlap between theft and copyright infringement whatsoever.
Here's a radical idea...
Team up with some artists that would ACTUALLY USE the software. The a programmer and developer works IS NOT the way a user works.
You have to get with the users.
The great advantage specifically for a 3D modeler/renderer is that you can do up the UI (and yeah, you get to have fun writing 3D routines for displaying the wireframe or solid modeled for display to the user) but you can then program to output in a known format (and take care of one of your "export" filters at the same time), and have a 3rd party renderer take care of the messiness for you. Once you're happy with how the UI works, you can write your own renderer if you still feel up to it.
The disadvantage with writing it either all-at-once (or writing only the renderer first) is that you can't test things nearly as quickly. Let's say you hammer out 3M lines of code, open the UI window, model a sphere, assign a texture, click the "render" button, and you end up with a black window. Did the sphere not get modeled? Was there an issue passing it to the renderer? Did the renderer mess up with the texture? Does the UI for some reason pass all objects as coloured perfectly flat black?
As for all those who say "why are you doing this, there are all ready free renderers", screw 'em. Sometimes it's fun to play areound and design/code a massive app just for the hell of it, right. Although, these massive apps rarely get completed...
"A dictatorship would be a heck of a lot easier, there's no question about it." -George W. Bush
Probably it would be a waste of time (if written from scratch)... I'd suggest you to take a look to www.sf.net and become a member of "similar" project(s). My 0.0001$ :-)
http://smeschini.altervista.org
Unrealistically, what I'd really like to see would be a programming model that could take a general model, and then at will recalculate the general model based upon specifics. Of course, I too have some physics and math, and I'm not to sure one could really do this.
But if I were going to do it, I would probably use Taylor function matrices everywhere, and use the Parker-Sochacki Picard iteration (better explanation here) to do the specific calculations as needed. My data would then be stored first in a lookup table, as spotty as it could be, and secondarily as a Taylor function, and on third order the Taylor function would be recalculated whenever there was time.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
Sorry, there was a URL error in posting the " better explanation " , the second link. It didn't post, for some reason. Here it is, again, above, and below (in text), in case it still doesn't work. http://www.math.jmu.edu/~jim/full.ps The better explanation is actually intuitive, such that a normal person with a normal education in Differential Calculus would understand it. Shoot, even a person with just algebra could understand it if they understood *what* differential equations were.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
"this package will be similar to Maya, 3DS Max, etc... in many respects."
But why? This is the part you didn't even put in your question, but it's arguably the most important.
Your end users don't give a rotten tomato whether the rendering engine is DirectX, OpenGL, or something you put together with chewing gum and string. What they need to do is use the application in a way that makes sense to them. Given the opportunity to choose for themselves what widgets are where and how workflow is controlled by the application, do you really think they'd all vote for Maya, 3DS, or whatever? Think maybe the fact that the apps they used to learn this stuff in the first place would influence their decisions maybe a little?
If you intend to create something genuinely new, consider making it more than a poor man's carbon copy of an already existing effort. Look at the following Blender has as an example of what can happen when you break the mold.
... There's no way in hell you'll ever complete the project.
start off with your 3d engine. make it cross platform/api as you would for a regular 3d engine.
:) ( http://fatgrah.am , merked )
and have your editor as a new "game" on your engine
render some test triangles.
store those triangles
translate input (2d) to model related input (3d) and use it for clicks/drags and manipluate your verts
add "bones" as well as verts to create/drag around.
link your verts to your bones, and make a timeline and add keyframes to the bones, and store the movement from the bones' original positions to the keyframes positions
add functionality to save your file!
worked for me
I'd highly recommend working *hard* to define an internal interface (API) that allows *every* functionl part of your program to be done as pluggable modules. It makes it very easy to isolate problems, it makes things more rebust, it makes things extensible. (3DS does a good job in many ways with modules.)
By doing this, 95% of the system could be done as modules, and you can also keep all system-dependant stuff out of these modules, greatly enhancing portability. Thing of the core of the system as being a meta-operating system, a 3D animation operating system supporting these plugin modules.
Another possibility with this approach, is that with proper definition of the interface between the core and the modules, you could even have language indepedence in the modules. (Probably not a biggie initially, but might be good for extensibility at some point; or even good initially for prototyping parts.)
In almost every project I've seen go awry, taking additional time to properly define "internal interfaces," how the parts speak to each other, would have saved a lot of grief.
Take a long hard look at 3D studio's transformation stack; being able to keep track of what took place to get where you are, and being able to apply that to other objects, modifying or branching as appropriate, is incredibly powerful. Being able to animate every parameter of these transformations is also key to a powerful package.
Again, to summarize, modules, modules, modules, modules. :-)
Love many, trust a few, do harm to none.
Crabs do this, not lobsters. GET YOUR CRUSTACEANS STRAIGHT before you post an allegorical story to Slashdot.
I am your 3D architectural design market. If you have any questions, I'd love to help.
1. An efficient and easy to manage object/group heirachy, that would allow the inheritance of a wide range of object properties from the group. min: materiality, visibility, snapability (snapping funtions are assumed), selection and line type/colour. This is a core modelling interface for anything more complicated than a chair. I would spend as much time on designing this as the modelling window interface. Everything else will REALLY only be accessed using hotkeys. I like the Gimps easy hotkey modification. It doesn't take too long to change them to photoshop defaults.
2. Object creation and editing at a range of geometry levels. Creation of solids, faces, lines and points in an intuitive way (an active plane and object snaps). Selection, deletion, translation, copying and insertion of geometry at all of these object levels.
3. Intuitive view creation, saving, switching and interpolation using a choice of cones of vision or camera to splines.
4. Viewports should be separate from the active plains to allow the editing of the model in a perspectival wireframe interface instead of some archaic three pane orthographic design system.
5. Easy creation, sharing and use of external objects or blocks.
6. An amazing raytraced rendering engine, a shadow mapping engine, a shader (openGL) and wireframe/hide engines (hide with line weights to postscript would be devastating). I advise using a range of external rendering engines. If these renderings could be converted into a range of video formats on the fly, it would be great.
7. Whilst this is clearly intended as a modelling project, I would need either an easy way to take plans, elevations and sections out of a model (If these could be dynamically updatable then great. Viewports with clipping planes on the cones of vision would be a great way to do this) or to export it to a package that is able to do this.
8. A practical note, a tool for making solid terrains from contours (or IGES points.)
9. Really good boolean operators.
With the exception of the external objects/blocks, projects like Blender do not have these features. I am a designer. I understand some programming principals, but I repeat, I am not a programmer. If you would find me useful in this capacity, then let me know.
p.s. for me a simple xml based file format with an internal binary format for speed would be cool, and would allow a grunt CAD jockey like me to play with the code. Most of us undersand HTML as a basic professional skill. XML isn't a big jump at all. It would also make the file format strictly formatted, unlike dxf, dwg, 3ds, max, and others.
No warranty of any kind is offered as to the quality of this post.
First of all its not a bad idea to get some of the big name modelers (3ds, maya, xsi, lightwave, etc.). You can get demoes from most of the big name companies now so this isn't the problem it used to be. :-) Then look in the nooks and crannys for the better free modelers (Blender, Wings, Milkshape etc). Then interview the user communities of these applications and see what they love and what they hate about their particular app and where they feel their app is weak in comparison to other 3d modelers. You'll get some fanboys of that particular application but looks for the honest evaluations and esp look for the answers from people who have used other 3d modeling programs. Just using the applications yourself is all well and good but you'll never get to know all these program's warts (and nicer parts) like an artist would. No one person has the time for all that. :-)
To me the ideal modeler would be a modeler which had the polygonal modeling capabilities of Wings, the nurbs editing and animation system of Animation Master and Maya, the booleans of Truespace and a scripting/plugin interface which uses Python. But that's just one person's opinion. Go out and get a bunch more!
After you get all the user feedback try and figure out a way to squeeze all the best of breed features into one program (easier said than done lol!). Look at other modeler's design and source code that are available to you (Blender for one OpenFX is another). Then write a design document, begin coding and start recruiting people. If you've done your job right after your modeler starts to take shape you'll probably start attracting other developers. I'm sure I've missed a lot of things you should be doing but this will give you a nice start.
Honestly, the 3D Market is Dog-eat-Dog competitive. Even Houdini had to drop pricing to something like 20%, and thats a really good package that costed $20K just 1,5 years ago. /anim performance ratio), Realsoft3D (also best price / performance ratio), Virtools (3D Realtime/Web IDE), Blender (kickass GPLd Package w. RT/Web) and all the rest that are fighting tooth and nail for a share of the next best thing since sliced bread.
User interfaces that make long term sense are rare and there's one package out there that's just been GPLd (Blender) that does that part very well. And memorize:
No fuckin' way are you gonna stink up against Cinema (Newbie friendly from the first minute on), Maya (ILMs favorite), Softimage (also ILMs favorite), Hash AnimMaster (best Price
Honestly, man, just plain forget it . Blender has gone GPL just now and that a *very* cool package (I got the full version) that needs a good *team* to get on with weeding out and putting in some cool new features that can put it on par with the other ones I mentioned. Join them! If your are only half as good as Ton Roosendal (which I, mind you, don't think) you'll have more than enough to do with that.
Anyhow, whatever you do, *don't* waste your time doing stuff from scratch that others have done 6,7,8 years in a row before you. Especially when one of the best is (for) free (as in speech).
We suffer more in our imagination than in reality. - Seneca
If You want to do GPL Software just check out Blender and extend it. It will be released soon under the GPL. You have a large and active community to give You feedback and do the testing, You don't have to start from scratch and You can learn a lot just by trying to figure out what the hell those guys thought when they wrote the code You are trying to hack some additions too. Also You already have a user interface ...
This all applys, when You want to do GPL. If You want to write closed source, well, then You are on Your own.
> The question is, what is the best programming paradigm to use for such a project?
The best paradigm? "Not Invented Here". You appear to be well down that path already... seriously, look at Blender, Innovation 3D, K3D, Moonlight, or any of the existing and mature 3D editors rather than doing everything from scratch.
Hey, I have a 3.5 floppy AND a 512K memory expansion. Even a mouse! Please think of us 8 bitters. Rendering times will be a million times faster because there's only 16 colors. Think about it!
So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.
The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.
There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.
What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.
Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.
In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).
So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.
WWJD for a Klondike Bar?
Very true richie2000...
While planning is not 100% necessary to the people writing the code it is ESSENTIAL to the people who are supervising the project.
Since it didn't seem as though he's doing this for a company or a suit, he is wearing all the hats in this matter, working all (or mostly) alone.
1) Design
2) Management
3) Development
4) Testing
5) Marketing (if he chooses to sell or publicize his findings)
Why would he approach a potentially mammoth project like this from only one point of view? It is extremely ignorant to believe that you can create anything BUT bloatware by not planning the project! In fact, you are more likely to produce code that is only interpretable to you. It will be completely riddled with your bad programming habits (because who will tell you otherwise) and who else but you could actually look at the code and immediately say, "oh, that's what you're trying to do"?
Sure, it requires patience and a lot of thought. Isn't that what's fun about programming? Churning out code immediately that you will just have to throw away may or may not be the answer. Who am I to convince someone else that has never planned a program they've written on anything more than a fleeting idea that they can be far more effective if they took the time to plan?
Additionally, regarding the fact that planning alone will not help (i.e. Microsoft)... I disagree. You first have to have a good idea (everyone tends to believe that their own ideas fall into this category by default), then, if you're to use planning effectively, you have to have a clear goal. This is where Microsoft excels. Their planning is purely for economic gain (after all, they ARE a business, not a foundation). If their IT department was autonomous and not taking mandates from the marketing/total world dominance department, they would probably produce software as good as the next company.
Do they fail in their current model? Microsoft is a multi-Billion dollar company so I think they are rampantly successful in their current model. Just imagine if they were able to put all those resources into developing what people actually NEED instead of what will sell. They'd be great purists who would run out of money after outperforming every other group of purists, producing a lot of really good stuff (eventually ending up on government funding, I imagine, to produce bloatware again).
Microsoft is the most effective company of all time at what they do. If money is not your goal then there is no reason why you can't be just as effective in achieving your own goal. On the other hand, a great product idea to you may be a piece of junk to me. My advice would be that if you don't like planning, suck it up and like it. Ask this vast community of computer users what they want in a product (I'm a user of 3dsmax and AutoCAD and while they are great programs, they have some extremely poorly thought out (in my opinion) segments that would drive me to switch to a smarter product), not how they would make it if they were developing it!
If you're coding alone, how to make it is YOUR job (I think you're off to a brilliant start by planning this thoroughly). If you want to make this program for anyone other than yourself, what they want is THEIR job.
Best of luck to you!
Actually I think /. is a great place to get advice on how. The real problem is getting advice on what.
Might I suggest two general approaches?
First of all, talk to actual customers in fields where they spend money on this sort of thing. Use a group like the American Institute of Architects or the American Society of Mechanical Engineers to reach the people who actually *do* flythroughs and renderings and see what they want from such a product. You may also find that talking to folk at a second-string engineering school (Stevens or RPI rather than MIT or CMU) you'll be able to get plenty of eager beta testers as unlike the more famous places, they don't get as many offers but they've got plenty of brains.
A variation on that would be to check out reviews of products in magazines like Architectural Record, and further, write to the relevant editors (not phone, you want to make it clear that you weren't just bored and calling on a lazy whim) and see what they've got to say.
This page will give you a solid start on relevant organizations and variables.
Secondly, the current situation of having to use five different programs to finish the job is a little silly. I continue to be amazed by the frequency with which I hear somebody say that they do the sketching on paper or with something like Illustrator, then do the technical work in something like AutoCAD, drop in some people from Poser, then export to something like Maya, fix the resulting problems and render there, and then do final changes in Photoshop. Meanwhile stereolithography outputting is moved to something like Lightyear or Buildstation.
Might I suggest a rigorous NURBS implementation with an intuitive basic functionality such that an item can be rough generated with a PowerGlove/Glasstron UI and make it all the way through the process right to render, animation, and outputting of models. I know that it's a lot to ask but, hey, you *said* that you were ambitious. In fact, I suspect that if you can do a system such that you sell a $50 crippleware version through places like Download.com and the serious version elsewhere, you'ld be able to build your user set quickly and also get to market faster.
A side note is that the ability to generate objects for systems like Adobe Atmospherewould finalize the build once-use many times paradigm that I'm talking about. After all, how much overlap is there between these communities? I'ld say considerable, and if gamers can then use the objects they created for one part of their lives in another, they'll be happy campers.
Best of luck to you,
Rustin (former techie for Sweets, Arch. Record, Design-Build, This Old House, Index, Woodworker, etc.)
Data is the lever, rigor the fulcrum, brains the force that drives it all.
or buy a 12 pack of Bud.
Bud beer? Hell no. See my previous comment. Besides, not all people who are considering using Blender are of legal age for consuming alcoholic beverages.
Will I retire or break 10K?
Here are some open source initiatives that might be worth a look:
Art of Illusion - Full 3d Modeller/Renderer/Animator suite written in Java
www.artofillusion.org
Wings3d - An excellent modeller. www.wings3d.com
Pov-ray - An excellent free raytracer (perhaps a front-end is the way to go?) www.povray.org
*** Penguins are so sensitive to my needs. --Lyle Lovett
Hope this helps...
I'd like to build a bridge to Hawaii with popsicle sticks, I feel I'm up to the task.
Sure, if you are a genius, you can do some amazing things alone (e.g. Linus Thorvalds, Donald Knuth, Larry Wall, ....), but since you have to ask this question, you are obviously not demigod material.
The question is, what is the best programming paradigm to use for such a project?
I have no idea what you mean about programming paradigm here. In my normal everyday use of those two words following each other in sequence, it means things such as the logic programming paradigm, functional programming, object-oriented programming, etc... If you don't know which paradigm you would want to choose, you can't as you claim to, have a solid foundation in computer programming, because that would mean you'd picked a favourite already. It doesn't really matter, as long as you pick the right one :-)
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.
Well, then you can just sit and wait, because by them time you will have a good design plan you will not only be dead, but also western civilisation will be dead, the earth gone into a new ice-age, then vaporized when the sun went nova, and eventually the universe will have undergone heat-death.
The only way to come up with a good design plan, is to write it after you discover the errors in your last design plan. And the only way to discover the errors in your last design plan, is to try to use it to write some code. This sequence of analyse-design-write-test cycles is known as iterative project management. What you seem to want to do is the waterfall model, and any software engineer will be able to tell you that while it might sound like a good idea, in reality it has never actually worked for anyone...
Plus, if you have all the major concepts and relationships in mind, why are you even asking this question? Seems to me it should just be a matter of coding left then?
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?
Ehh, just write the darn thing? It's not like it is especially hard to use an API, or what is your problem?
My second question would be, why on earth do you want to tie it into everything? Just to have a list of buzzwords to spread around? Try to focus on functionality, not how much you can "tie it into"...
[...feature...buzzword...feature...feature...featu re...feature...buzzword...feature...feature...buzz word...feature...feature] Any design suggestions?
Yes. KISS.
Another mad soloist looking for a twisted project, good luck! hopefully you'll learn something. Check out Java3D, its very OO and easy to use, covers almost all platforms, also you can compile to native code for most platforms (Windows, Solaris), so you can get performance out of it. There are a bunch of loaders, and x-tra API's for free, also check out Jon Barrilleaux's 3D User Interface book and framework. MM
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.
Actually, you can accomplish what you used to accomplish in C++-style multiple inheritance by inheriting/implementing multiple interfaces instead.
Interfaces were not a part of C++, so you were forced to use multiple inheritance if you wanted to combine the properties-capabilities of two objects. Not so anymore.
This question is difficult to understand because commercial software and free software are not opposites. One can sell free software.
Again, to those that know the difference between these two movements, this question doesn't parse.
It's unfortunate Torvalds encourages that lie by not correcting the idea that he somehow "makes his own OS" (a quote from your article, not the BBC interview). I think the GNU project is asking nicely for something they rightly deserve credit for making. Software freedom is another big contribution for which I am grateful to have the FSF and the GNU project. I appreciate the contribution of Torvalds and all the other contributors to the Linux kernal, but the kernal alone is not an operating system.
Digital Citizen
Schnapple
I was working on a movie, trying to do procedural animation in Alias Power Animator (the rediculously inferior predecessor to Maya) and decided that I could write my own animation system faster than I could get the animation done in PA. So I did.
The z animation system is designed for a particular class of animation common to visual effects, animation where a procedural description (that is, a script or a program) is the best way to do describe the animation. This is distinctly different from "character animation", but we are an FX house and not an animation house.
I chose to use a real programming language as the scripting language. I think that this is extremely important; for a number of reasons -- but the most important two in my experience is that every animation-language I've used has been terrible (slow, buggy, limiting, hard to debug, and slow); and standard languages have great IDEs, debuggers, compilers, and are instantly portable to a wide class of machines. I used C, and have been extremely happy with that choice.
Now, one might complain that C is a programming language and not a scripting language; and that it's hard to learn. I don't feel that there is a difference between scripting and programming -- and C is really quite an easy language to learn, there are great books, good courses, and a tremendous amount of code out there to learn from.
We use Pixar's RenderMan as our offline renderer, and use OpenGL as the real-time interactive renderer. These are really pretty similar in many ways, and with the combination of the C language, RenderMan, and OpenGL, the animation system is just glue holding these together; along with some spreadsheet and curve-editing libraries I already had lying around.
We've been moderately successful. About 1/3 of the FX you saw in X-Men were done in z, as were the FX you didn't see in Blue Crush (you didn't see them because our animators did such a good job.) We've worked on some 40 other movies over the last five years, and while we have Maya we haven't felt the need to use it except in some very character-animation-like instances.
One nice thing about the system that you are talking about is that you can do some core functionality pretty quickly, I would think, and then you can just add stuff as time goes on. Get polygons and spline surfaces working, then do subdivision surfaces down the road. Add sound when you need it. Texturing is free with current graphics boards, so that can go in at the beginning.
I believe that we are on the brink of a true revolution in graphics technology; and that we will leave pure software renderers behind in the next couple of years; so having a system that evolves with the upcoming graphics hardware could be a very useful and unique thing.
I also believe that Maya will probably be the last of the all-singing/all-dancing commercial animation systems. If you want to do everything that it does, you'll have to invest the 500 or so man-years that they put into it. To do that in a commercial system, with the frighteningly small size of the visual effects/animation market, is folly. I don't think it will be done again.
thad
I love Mondays. On a Monday, anything is possible.
Actually I used to know a guy who did 30+years of research on bike cadence (and unfortunately all of his files are sitting behind me at this very moment) and he concluded that Biopace gearing failed primarily because of a misunderstanding of the exertion patterns of most riders and so claimed that if you just mounted them 90 degrees off from the recommended pedal alignment they worked just fine.
Which takes us right back to the main discussion. Yep, TANSTAAFL, so this guy will have to just put in the time to get things right and probably suffer through quite a lot of "wasted" time on the way to building something good. But please document what *went wrong*. That way at least the next poor schmuck won't have to make *all* of the same mistakes the next time around.
So determine the metrics of "success", then (1) measure twice
(2) cut once
(3) test
(4) analyze re metrics and document results, if not ready (5), if ready (7)
(5) redesign
(6) return to step (1)
(7) move on to next problem and start the whole bloody thing over again.
And maybe even eventually
(n) profit ! ! ! !
Data is the lever, rigor the fulcrum, brains the force that drives it all.
It might be helpful to consider free software versus proprietary software. I'm talking about two different ends of the spectrum here, but these are useful terms to describe what I think you're after. A couple common combinations are a completely free software operating system (this is pretty easy to do with Debian GNU/Linux, for example, even though Debian's guidelines for what it considers free software are different from what the FSF defined years before) and a proprietary operating system on which they run some free software applications (using Mozilla on Microsoft Windows, for instance).
That software would be proprietary software. When one is talking about GNU, the Linux kernal, GIMP, etc., it is easy to think about free software where one is using the term "free" to mean freedom, not price ("logiciel libre", not "logiciel gratuit" if you speak French; free as in speech, not as in beer). This particular problem doesn't occur in other languages.
That is what they say on the front page of the GNU website:
GNU project and FSF representatives also pronounce GNU as "guh-NEW" in their speeches. If you haven't already heard them give them a listen, they're interesting and worthwhile.
In any event, thanks for remembering GNU and software freedom. Happy hacking.
Digital Citizen
the best thing to do is use existing rendering libraries and concentrate on design. Try to use cross platform libraries (a la OpenGL) where possible to minimize porting issues and remember that the best software is about 70% planning and 30% coding.
Performance is important, but not at the expense of portability, unless of course, you plan to take on the SGI's of the world.
In this case, find a hardware company that supports their hardware well, like nVidia (not that I would recommend nVidia for high end rendering!) and code for the platform.
Linux is fast becoming more accepted in the professional world because of a lot of reasons... ILM is testing it right now. If you code for linux using opengl and qt, you can be assured of a portable product that will have a fairly large audience (windows and linux). If you are going for the highest performance possible, you may need to get into specialized hardware/rendering and forget about portability, unless you have a large team of course...
Personally I would go for OpenGL and a cross platform widget library.
Then again, I don't know a whole hell of a lot about 3d programming, I only know that OpenGL is pretty freaking fast from a user perspective, and is cross platform. On linux, it smokes with well written vendor drivers.
Take a look at unreal tournament 2003, on linux, with a GeForce 4 or ATI Radian min 64MB (only seen the ATI on windows, personally)... It will knock your socks off.
l8,
AC
For animation check out the research on reactive programming at yale and microsoft research. This is the modern version of ActiveVRML that was out around 1995. Haskells AFRP is the most recent version, that uses arrows (a concept derived from category theory), at http://www.haskell.org/afrp. There is more information at http://www.haskell.org/frp, http://research.microsoft.com/~conal/fran/, and http://research.microsoft.com/~conal/newfran/
maybe?
>> I think the GNU project is asking nicely for something they rightly deserve credit for making.
In the docs on their website, they seem to be asking nicely. In person and in interviews, RMS in particular acts like a baby throwing a tantrum.
I'm a 3D animator by trade, and I worked for a 3D software company for years before that. From what I've seen, there are two big things I'd do:
1) Base the whole design around plug-ins. That way, you can build as you go and replace parts that become outdated. Make every object, light, and renderer a plug-in.
2) Implement a scripting language early on. Go with an existing OO scripting language and extend it to your application. A lot of the application's UI can be implemented in the scripting language. Later versions of 3DSMax use MAXscript for a lot of the UI, and Maya uses MEL all over the place.
Actually I would have preferred that there had never been a Linux. All this work SHOULD have gone into BSD. The Linux kernel is a bad hack and virtually everything on top of it is too. Too bad Linux didn't listen :(
But that's not the best part. The best part is that everything is in it. Everything. Planets, dogs, food, galaxies, weird physical phenomena, you name it. Plus, it's set up so that whatever is not there eventually gets created from the things that are there. Cool, eh. Just the thing you would expect from a Truly Lazy Programmer.
BTW, it also will have quite a few 3D animation packages, so perhaps you might think twice about writing another one, especially from scratch.