1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
<chapter id="decisions">
<title>History, Goals and Design Decisions</title>
<para>
This chapter provides some background information about the development of
Cal3D. It does not contain any crucial facts you have to know in order to use
the library, but it can help you understand why it was designed the way it is.
</para>
<sect1 id="history">
<title>A brief History of Cal3D</title>
<para>
The origin of the Cal3D library lies in the
<ulink url="http://www.worldforge.org">WorldForge</ulink> project: A nifty 3D
client was to be built for it (see
<ulink url="http://www.worldforge.org">www.worldforge.org</ulink> for more
information about this system for massively multiplayer online roleplaying
games). One of the needed components was a character animation system. Looking
at the existing solutions available under a free license, it was obvious that
most of them were based on one of the many popular first-person shooter games,
and therefore quite limited in terms of flexibility and functionality. The
decision was made that none of them actually fits the desired requirements. Thus
Cal3D was born, most probably the first library specialized on character
animation released under a <link linkend="licenses">free license</link>.
</para>
</sect1>
<sect1 id="goals">
<title>Goals and Design Decisions</title>
<para>
Dreaming about the future features is one of the cool things to do when you
start a new project: The usual sentence you get to hear is something along: "It
will be better than anything you have ever seen before in every aspect you can
think of". It should be evident that you are very unlikely to come up with
something just like that. However, to make the Cal3D project a worthy challenge,
the goals were still set very high. Even though, they should be seen more as a
primary basis for design decisions than an ultimate target that needs to be
reached by 100%. Should it happen, even better.
</para>
<sect2>
<title>Functionality</title>
<para>
At the time of the project kick-off, the most promising and flexible technology
for character animation was the skeletal-based approach. It gives you a lot of
freedom over the animation process and was therefore chosen as a core feature of
the Cal3D library. On top of it, there is a powerful control system that
handles the sequence and blending of the animations. Different types, such as
cycles, actions or poses, will be supported, and it should be easy to add new
ones to this system. A flexible handling of materials and meshes should make it
possible to completely change the look of a model. Attachment of other objects
and models is another 'must have'. Advanced features, such as level-of-detail,
inverse kinematics, collision-detection and physics will either be outsourced to
external libraries or will become part of the Cal3D library in the long-term.
</para>
</sect2>
<sect2>
<title>Ease of Use</title>
<para>
In spite of the large functionality planned for the library, its usage should be
simple, logical and intuitive. Unwanted advanced features do not have to be
taken care of by the user, so basically, there must be a default handling for
all of them. However, this behaviour should easily be modified or extended
if needed.
</para>
</sect2>
<sect2>
<title>Portability</title>
<para>
It does not make sense to develop a platform-dependent library for an
application that has to be portable. Hardcoded dependencies on libraries and on
APIs, such as OpenGL or DirectX, must be avoided. Therefore the library is
coded in C++ and only depends on the STL. It does not handle the actual
rendering and the texture-management itself. Necessary platform-dependent code
(such as endianness) must be minimized and encapsulated into a single class to
make it easy to add support for other platforms.
</para>
</sect2>
<sect2>
<title>Scalability</title>
<para>
All aspects of the library must be as scalable as possible. To avoid hardcoded
limits, the library makes heavy usage of the STL containers to store data.
Common data of different model instances are shared through the mechanism of
a core model. Support of a broad range of system configurations, in terms of cpu
power and other such properties, is provided by implementing level-of-detail
technologies for models and animations. Thread safety should also be considered
in the long-term.
</para>
</sect2>
<sect2>
<title>Flexibility</title>
<para>
Focussing on a single use for the library would prevent its flexibility. So the
library is developed as a stand-alone component and is not tied up
with a specific application. Unnecessary constraints and an obscure black-box
design is a big 'no-no'. Furthermore, all specifications (such as the
file-formats) are open and freely available. A good documentation goes
without saying.
</para>
</sect2>
<sect2>
<title>Performance</title>
<para>
The overall performance of the library is very important. As previously
mentioned, it will be part of a MMORPG client and should therefore be able to
handle numerous models at the same time. Besides optimizing the computations
inside the library itself, the data exchange across the interface has to be
designed as efficient as possible. Current graphic APIs make heavy use of vertex
buffers, so this is the choice for the output data. Because render state
changes strongly affect render performance, the ouput is grouped and
sorted to minimize those. Caution should be taken that the optimizations do not
break the clean design of the library.
</para>
</sect2>
<sect2>
<title>Interoperability</title>
<para>
The library is only useful and used if sufficient and suited tools and
exporters exist that can produce Cal3D data files. A portable and
application-independent exporter framework helps in developing exporters for
the various 3d modelling packages. As some tools may not be able to use the
framework, an intermediate file-format in XML should be available too.
</para>
</sect2>
</sect1>
</chapter>
|
