On
http://sourcefroge.net
you can find plenty of 3D modeling software. It seems that it
would be very difficult to select a proper program. But - do not panic! We are looking
for a software, that would allow us to create virtual airplanes. It is obvious, that we need
something, which can do more than just to model in 3D space. This software should also be able
to apply textures, turn on the lights, and finally render the result into an image. This basic filter
of required functionality reduces our list to about ten programs, only. I will explain here criteria, that I have used for
the further evaluation, and the results scored by selected systems. (The evaluation, described below, took place on September 2006.)
The program should be stable – I do not want it to crash in an unexpected moment. I excluded projects, that had not reached the “Production-Stable” status. It is not surprise, that many free programs have had stopped on the “beta version” stage. I call this effect “the barrier of the version 1.0”. In every voluntary enterprise the easiest thing is to start. A group of enthusiastic programmers is concentrated on an idea of the something new. They have just started coding to bring it into life. Every modern program requires thousands lines of the code. After a year or two the original group starts to disintegrate. Some of the project team members have gone – for example, because they got a new job, and are short of their free time. If the project leader is not able to find anybody for the replacement, project slows down. Finally it can be abandoned – if it has not enough community of devoted users;
Usage of the maturity criteria has reduced the software for further evaluation to “short list” of three programs:
This criteria is rather obvious: program, which can do more, is better than the less capable one.
I have not used the expressions “more functionality” here, with premeditation. It often reads as
“more functions”, and finally abbreviates into “many commands”. Along this way it loses most of
its initial meaning. You can still do much more with a program, that has smaller command set, but
is properly designed. It is also much more easier to learn it. Programs with too many, too specific
commands, can have less functionality. Just look at classic CAD systems (like AutoCAD, for example).
They have many commands related to modeling – somewhat over 100, especially for 2D drawing. But still
it is more difficult to build models in it, than in 3D Studio Max or similar “artistic” software.
What about functionality of analyzed systems? in 2006 it was rather difficult for me, to compare
the functionality in the detail. I had some experience in 3D modeling, only. Generally I had
found that Wings 3D is concentrated mainly on the modeling, and lacking many other features. Blender
and AOI seemed to have similar functionality, at least in my eyes, on that time.
Looking at the forums, I have found many users, that use Wings 3D to create 3D meshes, and Blender or AOI
for the rest of the process.
Program should have a comprehensive manual. A kind of “First steps” tutorial is not any replacement
for it, although such tutorial is also useful. This is a point sometimes forgotten by the proud
programmers, that are concentrated on the coding. From their point of view everything is
obvious – they have dealt with this program for many years, know all its capabilities and architecture.
Such lack of end-user documentation is evidence of their inability to look at it from the perspective of
a newcomer. Because every potential user is at the beginning a newcomer, they are closing the door to
their programs.
Also the documentation of the code itself is even often neglected. Usually, there is no any kind of
a “roadmap” document, that would describe the overall program architecture. Typical explanation goes
like this: “the code is self-explanatory, just look at it”. It is not – even for the author, when he
or she will return to it after, let’s say, 2 years (it is usual situation in large programs). This attitude is just an evidence of the programmer's
laziness. If you want to share your work with another coder, be prepared that about 30%
of your time should be spent on explanations (also in the written form – program comments). The lack
of solid program documentation is often visible in missing descriptions for the script extensions.
Among analyzed programs, Blender has much more documentation than the remaining two systems. It
includes both: user documentation (in 2006 - thousands of tutorials and about two printed books).
Somewhere in the middle you can locate AOI: it has a comprehensive manual and an API documentation. On the
end I have placed Wings 3D, in this category: it has the user manual, only!
Advanced user should be able to add his/her own functions to the program. Every open source project
is theoretically in a comfort situation: any user can modify its source code. But:
for the compiled programs, such modification is a “static” one: you need to recompile the whole
thing. This sets the difficulty level very high;
usually there is no documentation of the general program architecture, which could be used as
a “roadmap”, to recognize the code. It was not a problem, when programs had not exceeded 1000 lines
of the code, and everything always started at the mian() function. But these golden days have gone,
forever. Try to dig into 100k lines of event-driven code, and you will see the difference;
Ideally, whole program should be created as a set of “loosely coupled” components, that communicate
through clearly defined interfaces. It is so-called “service – oriented” architecture. In such
architecture you can easily replace one component with the another, improved and/or altered.
(For example – to replace the user interface with a new one) As long, as it responds properly to
the interface calls, for the rest of the system nothing has been changed. Clearly, such architecture
has to be built in a very methodical way. The interfaces should anticipate all the future growth of
the program. They should be carefully documented and maintained. Components, that conforms these
interfaces, can be compiled and delivered separately, by anybody. Ideally, you should be able to
change them without stopping the system. It would useful to add a kind of scripting language to
such program – most of the tasks does not require the ultimate speed of compiled code. Scripts are
easier to maintain. A kind of integrated IDE would be valuable for working with them.
We are not living in the ideal world, and the extensibility is often added to a program when it is
already matured, and its internal architecture is fixed. The typical solution is to add an interpreter
of a script language, and expose the internal program functionality through a set of objects. These
objects can be called by the user’s script. If the object set is wide enough to cover most of the
program functionality, and the scripts are not too slow – it is still an acceptable solution. (You
can treat the object set exposed to the scripts as the definition of an extensibility interface).
From the extensibility point of view, AOI is the winner. It exposes all of its internal objects
through a Java-derived scripting language called Beanshell. This means, that user script can do
everything, there. However, it was no evidence of the debugger for this scripting language, in
2006 (maybe I had missed something?). It is more difficult to create a larger scripts, without
such tool.
Blender is still less capable in scripting than AOI. It has incorporated a standard Python
interpreter. A large, well - documented set of objects is exposed to it. Yet, there are still
functional areas inaccessible by the script. Fortunately, these "blank" regions decrease in each
subsequent version. Because Python is a popular language, it is possible to find an editor and debugger for
Blender scripts (I have utilized for this purpose SPE and Winpdb). They form an equivalent to
Python’s IDE, accessible within Blender.
Wings 3D could be the most extensible system of all three. It is written in a little bit exotic
language, called Erlang. Erlang is interpreted (in fact: “bytecoded”, like Java) language, oriented
to multithreading, concurrent processing. It seems to suit ideally the extensibility model.
You can just load, in runtime, another Erlang module, and continue! But there is no roadmap,
where to begin with the Wings 3D code. I have downloaded Erlang manual and studied this language
for a week. (I can use over 10 different programming languages, it is nothing special to learn
another one). Then I started to study the Wings 3D code, trying to identify its main areas and
architecture. At the end of the second week I gave up – there are easier, better documented systems.
How long this program can live? No one wants to use a tool, that will be discontinued in the nearest
future. Sometimes the decision of big corporation can terminate even an established product. (In 2009 such
unexpected end met TrueSpace program. It was bought by Microsoft, then dropped because of worldwide crisis).
Fortunately, the public domain software is much more democratic. The long or short life of a GPL project
depends mainly on its user community. How many users use it actually, and will use it in the future? If the community is large enough, you will always
find a new programmer as a replacement for an one, that has just quitted this project. Some other
projects live just because they have highly motivated leaders. Of course, the best situation is
when the project has a motivated leader and a large user community.
Blender project has proved its outstanding vitality on 2002, when its source was bought for the
public domain. Required amount was collected from user’s donations within few weeks (it was “Free
Blender” action). Since then it continues its live as GPL software, releasing new versions regulary.
AOI is a stable project, but it is apparently less popular than Blender.
Wings 3D is the most vulnerable of all three. It has a larger user community than AOI – because
it is often used as an external modeler for Blender, AOI, or other animation programs. The reason
of its vulnerability lay in slow pace of the development. On September, 2006, its actual version
(0.98) was over a year old, and there were no bug fixes. It looked, that this project might be
abandoned, soon. Fortunately, at the end of 2007 a new version of Wings 3D has emerged (0.99), and
a month later – some bug fixes were released. (note from 2009-07: Wings 3D has its version 1.01!)
Finally, on September 2006, I had to choose between two options: Blender and AOI. AOI had
better extensibility, but Blender was more popular. Ultimately I had chosen Blender to work with.
Since then I have invested into it over a year of my work, so I am tied to this program, for
good or bad.
There was a simple decision on selecting GIMP for general image processing. I have just browsed some
image editing programs, evaluating them for their maturity, functionality, documentation and
vitality (not extensibility!). GIMP was most popular software of its kind, so I have chosen it.
Inkscape was found “by GIMP recommendation”. In GIMP’s help, in section describing the vector
drawing possibilities, I have found one sentence. It has stated, that “the vector tools in GIMP
are not so sophisticated as in the programs specialized in vector drawing – for example Inkscape”.
Although Inkscape had the version number 0.44 in that time, I had found that it matches my needs.
So it was incorporated to the “family”.
These decisions are not so important like the selection of the main program. You can always change
your image processing software into another one, without any serious influence to your models.