Conversion Pipeline and Coordinate spaces

Conversion Pipeline

The following graphic sketches out the conversion pipeline of data given to a plot with space = :data for GL backends.

Argument Conversions

When calling a plot function, e.g. scatter!(axis_or_scene, args...) a new plot object is constructed. The plot object keeps track of the original input arguments converted to Observables in plot.args. Those input arguments are then converted via convert_arguments and stored in plot.converted. Generally speaking these methods either dispatch on the plot type or the result of conversion_trait(PlotType, args...), i.e. convert_arguments(type_or_trait, args...). They are expected to generalize and simplify the structure of data given to a plot while leaving the numeric type as either a Float32 or Float64 as appropriate.

The full conversion pipeline is run in Makie.conversion_pipeline which also applies dim converts and checks if the conversion was successful.

Transformation Objects

The remaining transformed versions of data are not accessible, but rather abstract representations which the data goes through. As such they are named based on the coordinate space they are in and grayed out. Note as well that these representations are only relevant to primitive plots like lines or mesh. Ignoring Float32Convert for now, the next two transformations are summarized under the Transformation object present in plot.transformation and scene.transformation.

The first transformation is transformation.transform_func, which holds a function which is applied to a Vector{Point{N, T}} element by element. It is meant to resolve transformations that cannot be represented as a matrix operations, for example moving data into a logarithmic space or into Polar coordinates. They are implemented using the apply_transform(func, data) methods. Generally we also expect transform function to be (partially) invertible and their inverse to be returned by inverse_transform(func).

The second transformation is transformation.model, which combines translate!(plot, ...), scale!(plot, ...) and rotate!(plot, ...) into a matrix. The order of operations here is fixed - rotations apply first, then scaling and finally translations. As a matrix operation they can and are handled on the GPU.

Float32Convert

Nested between transform_func and model is the application of scene.float32convert. Its job is to bring the transformed data into a range acceptable for Float32, which is used on the GPU.

Currently only Axis actually defines this transformation. When calling plot!(axis, ...) it takes a snapshot of the limits of the plot using data_limits(plot) and updates its internal limits. These are combined with other sources to generate axis.finallimits. When setting the camera matrices axis.finallimits gets transformed by transform_func and processed by scene.float32convert to generate a valid Float32 range for the camera. This processing will update the Float32Convert if needed.

With respect to the conversion pipeline the Float32Convert is a linear function applied to transformed data using f32_convert(scene, data). After the transformation, data strictly uses Float32 as a numeric type.

Note that since the Float32Convert is based on and transforms the limits used to create the camera (matrices), it should technically act between model and view. In fact, this order is used for CairoMakie and some CPU projection code. For the GPU however, we want to avoid applying model on the CPU. To do that we calculate a new model matrix using new_model = patch_model(scene, model), which acts after Float32Convert.

Camera

Next in our conversion pipeline are the camera matrices tracked in scene.camera. Their job is to transform plot data to a normalized "clip" space. While not consistently followed, the view matrix is supposed to adjust the coordinate system to that of the viewer and the projection matrix is supposed to apply scaling and perspective projection if applicable. The viewers position and orientation is set by either the the camera controller of the scene or the parent Block.

Coordinate spaces

Currently Makie defines 4 coordinate spaces: :data, :clip, :relative and :pixel. The example above shows te conversion pipeline for space = :data.

For space = :clip we consider plot.converted to be in clip space, meaning that transform_func, model, view and projection can be skipped, and Float32Convert only does a cast to Float32. The x and y direction correspond to right and up, with z increasing towards the viewer. All coordinates are limited to a -1 .. 1 range.

The other two spaces each include one matrix transformation to clip space. For space = :relative this simply rescales the x and y dimension to a 0 .. 1 range. And for space = :pixel the camera.pixel_space matrix is used to set the x and y range the size of the scene and the z range to -10000 .. 10000, with z facing away from the viewer.