Project Overview
The Uranium framework consists of several parts, divided over several modules. These modules are Core, Backend, Math, Mesh, Scene, Settings and View. In addition, there are two toolkit-specific modules that implement a lot of UI bits for the applications.
The Core module is formed of base classes and central objects relevant to all applications. Primary among these are the PluginRegistry and Application classes. The Application class is the central object of any application. Its primary function is providing a central access point for other central objects like the Controller and MeshFileHandler.
The PluginRegistry class is responsible for loading plugins and their metadata. For more details on writing plugins, see plugins.
Another important class is the Signal class. This provides a mechanism for simplified event handling using callbacks. This is used throughout the library for handling events. For example, the Controller class provides an activeViewChanged signal that gets emitted whenever the active view changes. Other classes can connect to this signal to receive notifications about this event.
Other classes part of the core are the Controller, which is a central object providing communication between the Scene and the View classes, in addition to handling events between scene, view, input device and tools. The Event class represents the base class for any event in the system, with several subclasses provided for common events. InputDevice is an abstract base class for devices providing input to tools and/or view and should be subclassed by plugins that want to provide custom input devices. Logger is a base class for classes that log to a certain output. These can be subclassed by plugins to provide alternative logging capabilities. OutputDevice provides an abstraction around file opening and closing, it should be subclassed by plugins that want to do things like provide file uploading. Finally, Tool is the base class for any tool that operates on the scene.
The Backend module provides classes for communication with external applications in order to process data.
For example communicating with CuraEngine for slicing.
The Backend class is the primary class to facilitate this functionality. It provides an abstract base that should be subclassed by plugins that want to provide backend functionality. The backend class provides a list of the commands that are supported by that backend.
The Socket class creates a system socket that is used for the communication with the backend. The Command objects are responsible for serialising and deserialising the actual data sent over this socket.
The Math module provides classes for dealing with linear algebra. It includes a Matrix, Vector and Quaternion class that are based on Numpy arrays and implement basic 4x4 affine transformation logic. These are primarily used by SceneNode and related objects for their transformations.
The Mesh module provides several classes for dealing with mesh data. The primary class for this module is MeshFileHandler, which gets created by the Application object and provides read and write capabilities for meshes. It uses a list of MeshReader and MeshWriter objects that implement the actual mesh reading and writing logic. These two classes should be subclassed by plugins that want to provide suport for reading and or writing a certain mesh format.
When reading a mesh, the MeshFileHandler returns a MeshData object which is the internal data object for storing mesh data.
The Scene module provides classes that handle all the data in the scene. The scene itself is represented by the Scene class. The Scene class provides the root SceneNode object. The SceneNode is a node in a tree of nodes that form the scene graph. Each scene node has a transformation and can provide that transformation relative to its parents. In addition to the root scene node, the Scene class also provides the active Camera object.
The Settings module provides classes for handling machine settings.
The View module contains base classes for views and renderers. Plugins that want to provide a view should subclass the View class. The view class controls the complete rendering path and should decide how everything is rendered. It should make use of the renderer provided by the application to render the scene. The Renderer is created by the application and abstracts the underlying graphics API.
Most of the library does not contain any toolkit specific code. Instead, most toolkit specific code is contained in a toolkit-specific submodule. Currently, this concerns the Qt submodule, which contains toolkit specific classes that implement most of the UI bits on top of Qt, using PyQt.
