2.2
Concepts

- 2.2.1. Overview
- 2.2.2. Renderer
- 2.2.3. Render Target
- 2.2.4. Geometry Buffer
- 2.2.5. Light Buffer
- 2.2.6. Mesh
- 2.2.7. Transform
- 2.2.8. Instance
- 2.2.9. Light
- 2.2.10. Light Clip Group
- 2.2.11. Light Group
- 2.2.12. Shader
- 2.2.13. Material

2.2.1
Overview
1
This section attempts to provide a rough overview of the concepts present in the r2 package. Specific implementation details, mathematics, and other technical information is given in later sections that focus on each concept in detail.
2.2.2
Renderer
1
A renderer is a function that takes an input of some type and produces an output to a render target.
2
The renderers expose an interface of stateless functions from inputs to outputs. That is, the renderers should be considered to simply take input and produce return images as output. In reality, because the Java language is not pure and because the code is required to perform I/O in order to speak to the GPU, the renderer functions are not really pure. Nevertheless, for the sake of ease of use, lack of surprising results, and correctness, the renderers at least attempt to adhere to the idea of pure functional rendering! This means that the renderers are very easy to integrate into any existing system: They are simply functions that are evaluated whenever the programmer wants an image. The renderers do not have their own main loop, they do not have any concept of time, do not remember any images that they have produced previously, do not maintain any state of their own, and simply write their results to a programmer-provided render target. Passing the same input to a renderer multiple times should result in the same image each time.
2.2.3
Render Target
1
A render target is a rectangular region of memory allocated on the GPU that can accept the results of a rendering operation. The programmer typically allocates one render target, passes it to a renderer along with a renderer-specific input value, and the renderer populates the given render target with the results. The programmer can then copy the contents of this render target to the screen for viewing, pass it on to a separate filter for extra visual effects, use it as a texture to be applied to objects in further rendered images, etc.
2.2.4
Geometry Buffer
1
A geometry buffer is a specific type of render target that contains the surface attributes of a set of rendered instances. It is a fundamental part of deferred rendering that allows lighting to be efficiently calculated in screen space, touching only those pixels that will actually contribute to the final rendered image.
2.2.5
Light Buffer
1
A light buffer is a specific type of render target that contains the summed light contributions for each pixel in the currently rendered scene.
2.2.6
Mesh
1
A mesh is a collection of vertices that define a polyhedral object, along with a list of indices that describe how to make triangles out of the given vertices.
2
Meshes are allocated on the GPU and can be shared between any number of instances (meaning that rendering 100 identical objects does not require storing 100 copies of the mesh data).
2.2.7
Transform
1
A transform moves coordinates in one coordinate space to another. Typically, a transform is used to position and orient a mesh inside a visible set.
2.2.8
Instance
1
An instance is essentially an object or group of objects that can be rendered. Instances come in several forms: single, batched, and billboarded.
2
A single instance consists of a reference to a mesh and a transform for positioning the instance within a scene.
3
A batched instance consists of a reference to a mesh and an array of transforms. The results of rendering a batched instance are the same as if a single instance had been created and rendered for each transform in the array. The advantage of batched instances is efficiency: Batched instances are submitted to the GPU for rendering in a single draw call. Reducing the total number of draw calls per scene is an important optimization on modern graphics hardware, and batched instances provide a means to achieve this.
4
A billboarded instance is a further specialization of a batched instance intended for rendering large numbers of objects that always face towards the observer. Billboarding is a technique that is often used to render large numbers of distant objects in a scene: Rather than incur the overhead of rendering lots of barely-visible objects at full detail, the objects are replaced with billboarded sprites at a fraction of the cost. There is also a significant saving in the memory used to store transforms, because a billboarded sprite need only store a position and scale as opposed to a full transform matrix per rendered object.
2.2.9
Light
1
A light describes a light source within a scene. There are many different types of lights, each with different behaviours. Lights may or may not cast shadows, depending on their type. All lighting in the r2 package is completely dynamic; there is no support for static lighting in any form. Shadows are exclusively provided via shadow mapping, resulting in efficient per-pixel shadows.
2.2.10
Light Clip Group
1
A light clip group is a means of constraining the contributions of groups of lights to a provided volume.
2
Because, like most renderers, the r2 package implements so-called local illumination, lights that do not have explicit shadow mapping enabled are able to bleed through solid objects:
2.2.10.3 Local Light Bleed
4
Enabling shadow mapping for every single light source would be prohibitively expensive [3], but for some scenes, acceptable results can be achieved by simply preventing the light source from affecting pixels outside of a given clip volume.
2.2.10.5 Local Light Clipped
2.2.11
Light Group
1
A light group is similar to a light clip group in that is intended to constrain the contributions of a set of lights. A light group instead requires the cooperation of a renderer that can mark groups of instances using the stencil component of the current geometry buffer. At most 15 light groups can be present in a given scene, and for a given light group n, only instances in group n will be affected by lights in group n. By default, if a group is not otherwise specified, all lights and instances are rendered in group 1.
2.2.12
Shader
1
A shader is a small program that executes on the GPU and is used to produce images. The r2 package provides a wide array of general-purpose shaders, and the intention is that users of the package will not typically have to write their own [2].
2
The package roughly divides shaders into categories. Single instance shaders are typically used to calculate and render the surface attributes of single instances into a geometry buffer. Batched instance shaders do the same for batched instances. Light shaders render the contributions of light sources into a light buffer. There are many other types of shader in the r2 package but users are generally not exposed to them directly.
3
Shaders are intended to be effectively stateless. A given shader S is an opaque function that takes a single parameter value M, and the user actually supplies M by configuring a material for S and then using it each frame.
2.2.13
Material
1
A material is a pair consisting of a shader and a set of parameters for that shader [1].

[1]
The spiritual ancestor of r2, the r1 renderer, exposed only immutable materials. While these made it easier to demonstrate the correctness of the programs using the renderer, it also increased pressure on the garbage collector. Materials in the r2 may optionally be mutable or immutable, and the user is expected understand the difference and the consequences of using one over the other.
[2]
The spiritual ancestor of r2, the r1 renderer, exposed a fixed material system and did not expose shaders to the user at all. While this made it easier to demonstrate the correctness of the renderer implementation, it turned out to be needlessly inflexible and made it more difficult to experiment with new renderer features.
[3]
However, the r2 package places no limits on the number of lights that have shadow maps, so enabling them for all light sources is possible, if not actually advisable.
[3]
However, the r2 package places no limits on the number of lights that have shadow maps, so enabling them for all light sources is possible, if not actually advisable.