---

Translated from "fr dossier 2001 / projet_3d_architecture_reviewed" and "fr dossier 2002 / Projet NeL - 3D - Architecture moteur REVIEWED". Both versions are essentially identical; the 2002 version is a cleaned-up resubmission. {.is-info}

Nevrax develops Ryzom, a 3D interactive MMORPG (Massively Multiplayer Online Role Playing Game). To render a world like Ryzom to the screen, a software architecture that is both solid and flexible was needed — to allow indoor and outdoor rendering, to calibrate quantity/quality based on the machine's power and hardware, and to dynamically load the large number of different elements.

Most 3D libraries at the time are hardware-only, meaning that if the user does not have a 3D accelerator card, they see nothing. Furthermore, current engines are monolithic — they can only really be adapted for the games they were designed for, and are difficult to extend.

The programming interface "OpenGL Performer", for example, has only a single scene graph for all routines. All modifiers must therefore be designed to work with this scene graph, and if it would be easier to arrange elements in a completely different way (to optimize the code, change the representation, or clarify the parts), it cannot be done — the data must be arranged to create interpretation shortcuts.

Starting from the principle that we don't know everything we'll need in terms of model types, lighting, and processing before the end, flexibility must be planned for, because over 2 years of development rendering techniques change and the engine must constantly adapt to market demands.

Bibliography: Siggraph 2000, Electronic Art And Animation Catalog, Ghali, Blythe, Sowizral, Kettner, "Introduction To Scene Graph", pp 58-110.

The objectives for this architecture are flexibility of use and extension, while maintaining a robust architecture that won't generate many bugs. The adoption of a fully object-oriented design made it possible to isolate the elements of the graphics pipeline: the process part and the data part ended up well decoupled.

• Choices
• Future extensions
• Modeling

The tasks performed on the engine were numerous because it was necessary to experiment to arrive at a stable final state. Once adopted, the foundation is difficult to interchange, and the base architecture must often be questioned when new features need to be implemented. This iterative procedure with error correction is the same as in a feedback control system. This loop allowed us to converge on an optimal solution for our needs.

We went through three interleaved layers before having a finalized version of the engine:

• Definition of the foundation (software component architecture)
• MOT architecture (Model/Observer/Traversal)
• Multi-threaded engine (parallel loading management)

At the base of the 3D engine is API abstraction. The machine is programmed nowadays through driver access. Since there is a specific driver per 3D card, the operating system providers already offer a number of higher-level means so that developers don't have to worry about the physical implementation. This is the role filled by layers like Direct3D (part of the DirectX libraries) or OpenGL. To manage these different layers, the 3D part of NeL must have its own abstraction interface. This is what we somewhat casually called the NeL_Driver.

Global architecture of NeL3D in relation to the system.

The low-level access interface (everything related to display) is identical regardless of the driver. This is the essential abstraction layer, should we have other operating systems with other 3D card access APIs in the future. One could even imagine a driver (in the NeL sense) that is completely software-based, reproducing all the functionality of a 3D card. This would allow non-equipped computers to still benefit from the application.

After separating the hardware access from the lowest level NeL layer through the driver, we were able to focus on creating a high-level system for managing objects, groups of objects, and entire worlds. This system is called MOT for Model, Observer, Traversal. A Model corresponds to the 3D data, a Traversal corresponds to a stage of the rendering pipeline, and an Observer corresponds to the processing to apply to the Model to pass through a rendering stage.

The heart of the 3D library: The MOT — Model, Observer, Traversal.

What links a Model and a Traversal is an Observer. There are as many Observers as there are Models per Traversal.

List of observers per traversal for each model.

This is a lot of Observers to store for each Model — flexibility comes at this price. Indeed, if we decide to add a Traversal (a processing step, e.g. ray tracing), we don't need to rewrite all the models. This can be very useful if, for example, we want to create a plugin-based library. We could dynamically add either a new model by writing all the required observers (or only the relevant/desired ones) for the data processing, or proceed in reverse.

All the main traversals and models of the NeL 3D engine.

The NeL 3D library consists of the following main traversals for rendering:

• Hierarchy: Transform objects from object space to world space.
• Clipping: Visibility acceleration and rejection of non-visible objects.
• Animation: Remaining objects are animated.
• Equalizer: Load balancing based on the machine's capability and the scene's complexity.
• Lighting: Light the objects.
• Render: Render the lit objects to screen (screen space transformation).

Even though multi-threading is not handled in the core of NeL3D, it is important to note that it is an integral part of the architecture. It was decided to perform data loading in parallel with rendering. Needless to say, texture processing was a thorny issue. The shared memory accessed by the low-level driver (OpenGL, DirectX, etc.) is not protected against task sharing. The transfer of textures from main memory to video memory (memory embedded on the graphics card) is therefore done gradually. At each render, a certain quantity is transferred (variable depending on the size and type of the bus — AGP, 2x, 4x, etc.)

Loading from the hard drive, on the other hand, occurs in a completely separate time quantum. If the machine is multi-processor and the operating system supports it, data loading from the hard drive will occur in parallel, so the user will not feel that the machine is being disturbed by anything (this is frequently manifested as a slowdown of the application).

Multi-threaded architecture: two parallel loops — rendering (with incremental texture upload to VRAM) and background loading from disk.

The architecture of the NeL 3D engine is flexible and extensible. Unfortunately, during implementation, this flexibility was sacrificed on the altar of performance. This implies shortcuts in the traversals to avoid double indirections, temporary data within the objects themselves, etc. It is not certain that the same engine written monolithically would have been faster to write or less buggy.

The NeL 3D library takes a step forward by bringing together cutting-edge technologies in the field of 3D processing — in rendering as well as in lighting and clipping.

4 people for 1 year. 10 different machines.