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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML>
<HEAD><style> A { color:black }</style>
<!-- hennerik CVSweb $Revision: 1.93 $ -->
<TITLE>code/nel/doc/whitepaper.dxt - view - 1.17</TITLE></HEAD>
<BODY BGCOLOR="#eeeeee">
<table width="100%" border=0 cellspacing=0 cellpadding=1 bgcolor="#aaaaaa"><tr valign=bottom><td><a href="whitepaper.dxt?sortby=log"><IMG SRC="http://www.nevrax.org/inc/img/picto-up.gif" ALT="[BACK]" BORDER="0" WIDTH="14" HEIGHT="13"></a> <b>Return to <A HREF="whitepaper.dxt?sortby=log">whitepaper.dxt</A>
CVS log</b> <IMG SRC="http://www.nevrax.org/inc/img/picto-news.gif" ALT="[TXT]" BORDER="0" WIDTH="13" HEIGHT="15"></td><td align=right><IMG SRC="http://www.nevrax.org/inc/img/picto-dir.gif" ALT="[DIR]" BORDER="0" WIDTH="15" HEIGHT="13"> <b>Up to <a href="/cvs/cvsweb.cgi/?sortby=log">Nevrax</a> / <a href="/cvs/cvsweb.cgi/code/?sortby=log">code</a> / <a href="/cvs/cvsweb.cgi/code/nel/?sortby=log">nel</a> / <a href="/cvs/cvsweb.cgi/code/nel/doc/?sortby=log">doc</a></b></td></tr></table><HR noshade><table width="100%"><tr><td bgcolor="#ffffff">File: <a href="/cvs/cvsweb.cgi/?sortby=log">Nevrax</a> / <a href="/cvs/cvsweb.cgi/code/?sortby=log">code</a> / <a href="/cvs/cvsweb.cgi/code/nel/?sortby=log">nel</a> / <a href="/cvs/cvsweb.cgi/code/nel/doc/?sortby=log">doc</a> / <a href="/cvs/cvsweb.cgi/code/nel/doc/whitepaper.dxt?sortby=log">whitepaper.dxt</a> (<A HREF="/cvs/cvsweb.cgi/~checkout~/code/nel/doc/whitepaper.dxt?rev=1.17&sortby=log" target="cvs_checkout" onClick="window.open('/cvs/cvsweb.cgi/~checkout~/code/nel/doc/whitepaper.dxt?rev=1.17','cvs_checkout','resizeable,scrollbars');"><b>download</b></A>)<BR>
Revision <B>1.17</B>, <i>Thu Apr 11 07:29:48 2002 UTC</i> (3 months ago) by <i>lecroart</i>
<BR>Branch: <b>MAIN</b>
<BR>CVS Tags: <b>georges_v2, HEAD</b><BR>Changes since <b>1.16: +1 -1
lines</b><PRE>
CHANGED: using .png instead of .gif
</PRE>
</td></tr></table><HR noshade><PRE>/**
\page general NeL Whitepaper
\author Vincent Archer
The purpose of this document is to present a general overview of the whole of the
NeL infrastructure. After reading this document, you should have a good understanding
of how NeL is structured, what parts compose it, why these parts are there, and how
they are intended to be used for the building of a finished product.
This is not an interface description or a programming manual. These interface
descriptions are generated using the Doxygen documentation tool, and separate
general interface description documents for each component are provided. There is also a
separate global programming manual, describing exactly how to code for a complete product
using NeL components.
The NeL library is further divided into a few libraries: network, ai, 3d and misc. If you want
to use ai, 3d or network you also need to use the misc part of the library. Ai, 3d and network are
totally independant from each other so you can use only the parts you really need in your project.
A good example is the platform Nevrax intends to use NeL for. That platform uses the
following architecture:
\image html architect.png
\section build Building system
Building systems are very different, depending on whether you work on a Windows/Visual
C++ environment, or a Unix/g++ environment (the two development environments currently
supported in the official NeL system).
The building system reflects this and thus consists of two different subsystems:
\subsection unixbuild Unix build
Building the NeL system in a Unix-based environment uses the auto-configure system
that is pretty much a standard in GNU tools and other environment-portable packages. The
NeL library top level thus has a configure.in, which autoconf/autoheader turns into
the classic configure script.
That directory, and all its subdirectories, has a Makefile.am, which automake uses to
generate a set of Makefile.in. All modifications (notably adding source files) are made
into the Makefile.am files themselves, and never to Makefile.in or Makefile. The .am
template is stored in the CVS tree, but not the rest. A full regeneration of the files
must be done after a checkout.
\subsection winbuild Windows build
First, you need to have visual c++ (VC++) version 6 and at least VC++ service pack 4.
Only .dsp (project) files and .dsw (workspace) are stored in the CVS tree. All
other specific visual c++ files are automatically created in the build process.
To build NeL, you have to start vc++ and load the nel workspace and compile
all projects contained in the workspace. Each project create a .lib (library) file in
the lib directory.
Other compilation environments on a Windows system may be possible, but are not currently
supported.
\section components Components
\subsection component3d 3D library
The purpose of the 3D Library is to provide a graphical view of a full 3D Universe. It
is not based on a pre-existing high-level library because of specific constraints on the
final environment to render, which consists of large landscapes with smooth natural
features and lots of objects.
To achieve this objective, the library implements several techniques:
- Geometry:
- The ROAM algorithm, which provides an adaptative subdivision of the landscape base
depending on various parameters like distance, steepness of the landscape, etc.
- Use of Bezier Patches to create smooth-looking landscapes
- Multi-Resolution Meshes, to provide a smooth reduction in polygon count as objects
retreat further in distance, details degree and so on
- Object Interfaces, which allows the correct assembly of multiple "parts" of objects
into a single mesh without leaving unconnected parts or holes
- Rendering:
- Bump Mapping of surfaces for more natural-looking textures
- Environment Map for metal like surface
- Support of User Colors (specific areas in textures tagged for replacement with a
program-defined color upon rendering)
- Full hardware Transform and Lighting support
- Hardware Pixel Shaders and Vertex Shaders
- Animation:
- Skinning, using a base skeleton for animations
- Blended Shapes, to provide lip-sync style animations
- Inverse kinematics
- Blend of animations to provide smooth transitions between various animations
- Low level services:
- Object streaming, to provide a transparent load-on-demand, including the multi-
resolution meshes
- Object Picking in a scene
The 3d library works best with a set of 3DSMax plug-ins to generate data for use with the
software.
The 3d library itself is organised in three successive layers:
- Layer 1, or driver layer, which implements the effective 3D operations. This is
highly API and platform-dependent. Right now, an OpenGL driver is provided, but a
directX would not require much effort.
- Layer 2, or object layer, which implements the various objects (landscapes, meshes
light and so on) and rendering.
- Layer 3, or high level layer, which provide the spatial manipulation and the
necessary interfaces to create the whole scene, and modify it according to the model
of your universe. It manages the scene graph depending of the needs of the environment.
Modification of the layer 1 should be very rare, as it is the most stable part of the
NeL 3D library. New extensions to OpenGL or new drivers will require intervention in
that layer.
Modification of the layer 2 occurs only if you create new object types, such as special
smooth surfaces not based on Bezier Patches, different styles of animations, and so on.
Modification of the layer 3 is reserved to changes in the whole predicate on which the
NeL library is based, as it is where objects are created and removed, their properties
altered, according to the necessities of the 3D universe.
\subsection componentai Artificial Intelligence
The purpose of the AI library is to provide a pragmatic approach to creating a distributed
agents platform. Its focus is agents; individual entities that communicate regardless of
location, using an action-reaction model.
The ai library provide three different categories of concepts:
- Autonomous agents
- Basic components that can be assembled to build an agent
- Messages that can be sent between agents
- Triggers
- A dedicated scripting language
- Based on a virtual machine approach (similar to Java)
- Object oriented, with a strong agent flavor
- Declarative rather than procedural (allows to define sets of actions, then select
among them which one to take)
- Basic AI techniques
- Pathfinding in a 3D universe (animated objects may have different paths depending on
their physical abilities)
- Basic expert system framework
- Order-1 logic
- Fuzzy logic operations
- Evolutive algorithms
The ai library offers three different layers of code:
- Layer 1, or base classes layer, which implements the basic classes, and all the basic
AI techniques available to agents
- Layer 2, or agent layer, which provides the base agent, and the components used to
build an agent
- Layer 3, or scripting layer, which defines the scripting language, the virtual machine,
and allows the programmer to create, assemble and define agent behaviours. This is where
the AI programmer acts to create specific agents.
Modification of the layer 1 should be very infrequent, and occur only if someone wants
to add new AI techniques, or alter the communication layers between agents.
Modification of the layer 2 occurs only if you want to create different agent types. In
general, this is not necessary; the set of agents implemented in the layer 2 is assumed
to be adequate to cover all bases.
Modification of the layer 3 is where one may add new functionalities to the scripting
language, such as allowing to call other scripts (in Python, Perl, or whatever langage)
or external compiled code.
\subsection componentdb Database & File
The storage library provides access to hard drive files. It provides an API for general
use based on a serialize class. All class can be serializable by inheriting a base class.
Doing this enable the class to be serialized on every type of streams, which could be memory streams,
file streams, network streams and so on. It is a full extensible system that allow NeL to
add new complex streams like compressed file stream or distributed file stream.
The database is managed by a third party library. It could be either an object oriented
database (OODBMS) that support transparent object storage and access, security and backup
system, or a classical relational database. The decision to orient the architecture toward
one or the other isn't yet set in stone.
The NeL database interface merely provides access to that specific database,
but NeL does not require any specific kind of database to be useable.
\subsection componentnet Network
The network library serves a twofold purpose. It provides inter-process communication,
and service system.
In purely network terms, the library offers 4 layers:
- An abstraction of the network API and links (IPC may be across a network, or local
messaging)
- Handling of asynchronous message passing, and callbacks
- An abstraction of destination (you address a service, not an IP/Port)
- A buffering and structuring of messages with generic serialization system
These network layers are reused to build distributed services. The network library
presents both a generic service skeleton, which includes the base functions of the
distributed service:
- Initialisation (reading configuration file, reading command line parameters)
- Creation and registration of callbacks for network layer 2
- Registration to the naming service for the layer 3
The library will also provide pre-existing services:
- Naming service (1 per logical cluster)
- This service handles the association between a service and the process or processes
that execute code to provide the service. Each service is registered with an ip and
a port
- Handles load balancing
- Manage all the cluster connections
- Logging service (1 per logical cluster)
- Centralizing all log messages and statistics needed by the Naming service and
Admin service
- Admin service (1 per logical cluster)
- The entry point for the cluster administrator. Enable the control all the cluster like
adding new service, close services, get cluster states, logging informations and so on.
- Admin Executor service (1 per physical computer)
- These services get statistics of the computer and send them for the Admin service via
the Logging service. They also executes all Admin service requests.
- World service (n per logial cluster)
- Manages agents and all the game systems created by AI.
Finally, the network library also proposes some basic function that are required to
build a service able to "run" a 3D Universe, such as:
- Fast communication across unreliable long-delay networks
- Dead reckoning that enable smooth moves on a slow Internet connection
The purely network library is typically self-contained, and not much subject to
modification, unless one wants to change the entire paradigm around which the platform
runs. Addition of a specific and non-standard network or network API would be the only
reason one would change layer 1.
The service system provides an easy way to add new specifical service needed by
the universe.
The structure of distributed services is the point that requires the most attention,
as these define the logical structure of a cluster.
Fine-tuning the basic network services is probably the place where most modifications can
be made.
\subsection componentpython Python scripting
Python is currently considered as the tool that will bind all the components from NeL
and the client or server together.
\subsection componentsys System
This library section deals with all the system-dependent aspects of the NeL library.
It handles interfaces with the system functions, such as starting processes, managing
system resources, thread class, sound management, keyboard and mouse inputs and so on.
\subsection componentmisc Miscellaneous
This contains all the various utility functions, classes and objects that are not
complex and large enough to warrant their own separate component, yet are fundamental
to the function of the NeL platform.
It contains, for example, debug features, smart pointers, internationalization system,
math classes, generic streaming system, and so on.
\section externals External components
The following external components are used to build the NeL system. These components
are either included directly in the NeL system and are available immediately when
extracting the NeL source tree, while others are kept separate, and require you to
obtain them separately prior to building NeL.
- Autoconfig & Automake : The GNU standard configuration tools for Open Source development.
- STLPorts (www.stlport.org)
- FreeType2 (www.freetype.org)
*/</PRE>
|
