Return to whitepaper.dxt CVS log | Up to Nevrax / code / nel / doc |
File: Nevrax / code / nel / doc / whitepaper.dxt (download) Revision 1.17, Thu Apr 11 07:29:48 2002 UTC (3 months ago) by lecroart Branch: MAIN CVS Tags: georges_v2, HEAD Changes since 1.16: +1 -1 lines CHANGED: using .png instead of .gif |
/** \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) */