Jreality

jReality
Developer(s)	jReality Community
Operating system	Cross-platform
Type	3D computer graphics software (library/API)
License	BSD license
Website	www3.math.tu-berlin.de/jreality/

jReality (Jreality, JReality) is an open source Java scene graph library for creating real-time interactive applications with 3D computer graphics and spatialized audio. jReality is running on platforms ranging from desktop machines to immersive virtual environment like CAVEs with motion tracking, multiple screens with 3D stereo projection. It supports euclidean, hyperbolic and elliptic geometry.^[1]^[2]^[3]^[4]^[5]^[6]

jReality provides a number of graphics rendering backends, ranging from pure software to hardware-accelerated to photorealistic. A distributed backend for cluster-based virtual environments exists too. Audio backends range from a basic stereo renderer to a high-performance Ambisonics renderer for arbitrary 3D speaker configurations.

The user interaction is device-independent through a layer of abstract input devices - matched at runtime with available physical devices. jReality also works with keyboard and mouse in a desktop environment as well as with motion tracking in a virtual environment.

Design

jReality provides a clear separation between functionality:^[7]

The scene graph describes the 3D scene including geometry, appearance attributes, audio sources as well as tools, which define interaction with the 3D scene.

Rendering backends convert a jreality scene graph into graphics. There are various backend for interactive and non-interactive rendering.

The tool system triggers the tools attached to the scene graph based user interaction via input devices.

Audio backends render the spatial audio of the scene. There are different backends for different speaker setups, for instance stereo, 5.1 surround or ambisonics for arbitrary speaker setups.

Features

on-line switching between real-time rendering backends (opengl 2, opengl 3, software)
line/point rendering through tubes/spheres with full lighting (instancing in opengl 3 backend)
sprites as a fast sphere alternative
displacement mapped sphere sprites (opengl 3 backend)
material properties(vertex/edge/face color)
huge number of lights (over 1000 in the opengl 3 backend)
spot lights, point lights and directional lights
ADS phong shading (opengl 3 backend)
texture mapping (texture coordinates per vertex-face pair in opengl 3 backend)
sky box / environment map reflections
supersample/multisample anti-aliasing
order-independent transparency through depth peeling (opengl 3 backend)
field of view up to 360 degree (through dome backend)
custom GLSL shaders
rendering in spherical and hyperbolic space

Users

polymake
The Gavrov Project^[8]
Varylab^[9]

The jReality scene graph

A jReality scene graph is a directed graph without cycles. A scene graph is not necessarily a tree because an instance of a scene graph node may appear in different locations of the graph at the same time. The location of a node in the scene graph is specified by a path to the node.

Rendering backends are derived from the abstract class Viewer. Viewers take two parameters: a scene graph root node and a path that specifies the currently active camera. Note that the root node is not an intrinsic property of the scene graph but a choice for rendering purposes.

In jReality, all nodes of the scene graph are derived from a common abstract superclass: SceneGraphNode. SceneGraphComponent is the only one subclass of SceneGraphNode whose instance can have descendants. All other nodes are leaves. The leaves in detail:

Transformation: a leaf node of the scene graph that specifies a local coordinate system via a 4x4 matrix. This class supports transformations in euclidean, spherical and hyperbolic geometries. The transformation from object coordinates to world coordinates is the composition of transformations along a path from an object node up to the root node.

Appearance: a leaf node of the scene graph that represents shading attributes such as colors and textures as a key-value dictionary. Keys must be strings; values can be one of several standard types or an arbitrary Java class instance. There is no fixed list of attributes; different viewers may honor different sets of attributes. Shader names themselves are part of this dictionary, so that different shaders can be specified. While each rendering backend is responsible for implementing a standard set of shaders not all backends are expected to implement all shaders. For example, the OpenGL backend supports shaders written in the OpenGL Shading Language, and shader parameters for RenderMan, will only make sense for certain viewers. A backend that encounters an unknown shader falls back on one of the standard shaders.

When traversing a scene graph, viewers are expected to maintain a stack of appearances encountered on the way from the node. The value of the dictionary at a specific node in the scene graph is then controlled by an inheritance mechanism which depends on the collected appearances along the path from the root through the scene graph to this node.

Geometry: a leaf of the scene graph that holds geometry information, such as face sets, Bézier patches, etc. Instances of this class can store attributes beyond the usual coordinates and connectivity information.

As in the case of appearances, the set of possible attributes is not fixed, and again stored in dictionaries (separate ones for vertex, edge, and face attributes). This way data for non-standard shaders (like a per-vertex temperature information) can be stored directly on the geometry using the appropriate key. There is no inheritance for geometry attributes.

Camera: a leaf that holds a camera. Every jReality viewer contains a scene graph root node, and a camera path. The latter is a scene graph path that begins with the root and ends at a camera node. Rendering for this viewer is always with respect to this camera. Cameras are general enough to support rendering in a variety of environments, including stereo and off-axis alignment (such as CAVEs).

Light: a leaf that holds a light source. Lights can be global or local, with standard distant, point, and spot light support. Backends collect lights before rendering.

References