I have spent a bit of time looking into instancing with glium and OpenGL. It turns out that glium makes it very easy to make use of the powerful tehcnique.

### Instancing

In my previous code I created an array of cubes by creating the actual vertices for every cube that I wanted to display. This is clearly incredibly inefficient and inflexible. Once the cubes have been created they can't easily be moved or adjusted and I am duplicating a lot of vertices. I could draw one cube per

`draw`

call but the overhead per call can become substantial if there are a lot of cubes ( or other objects).
Instancing reuses the same object data and redraws the same object where

**some**of the data changes for each instance.
OpenGL has several ways of supporting instancing.

- You can use a special
`glsl`

variable`InstanceID`

that is incremented for each instance and use this to modify the vertex data ( for example, by looking up data by`InstanceID`

). - You can define a vertex type where some of the vertex data only changes for each instance. This is the approach I am going to take

### Vertex types for Instancing

I am keeping my existing vertex

`Vertex3t2`

type that defines the position and texture coordinates but I am also defining a new vertex type `Attr`

that has all per-instance data. The new vertex will have the matrix for defining the instance position and orientation and its color;#[derive(Copy, Clone)] struct Attr { world_matrix: [[f32; 4]; 4], } glium::implement_vertex!(Attr, world_matrix);

This new "instance" vertex is defined using the exactly same type of code as ordinary vertices.

### Setting up the vertex data

Because I am using instancing I build only one cube centered around the origin. I use the exactly same

`add_cube`

function I developed in the last post.let mut verts: Vec<Vertex3t2> = Vec::new(); add_cube(&mut verts, &glm::Vec3::new(0.0, 0.0, 0.0)); let indices = glium::index::NoIndices(glium::index::PrimitiveType::TrianglesList);

I also need to build the per-instance vertex data. Because the

`Attr`

vertices will be used for data changes for each frame I creating the vertex buffer using `dynamic`

to let glium know that the vertices will be dynamcic ( whereas the cube vertices are stored in a regular vertex buffer )let mut positions: Vec<Attr> = Vec::new(); build_object(&mut positions); let position_buffer = glium::VertexBuffer::dynamic(&display, &positions).unwrap();

The build object creates position and color vertices. For now I will simply recreate the same array of cubes that I created before.

fn build_object(attribs: &mut Vec<Attr>) { for x in -4..5 { for y in -4..5 { for z in -4..5 { let pos_matrix = glm::translate(&glm::identity(), &(glm::Vec3::new( x as f32, y as f32, z as f32 )*1.5f32 ) ); attribs.push(Attr { world_matrix: pos_matrix.into() }); } } } }

### Updating the shader code

The vertex shader needs to be updated to make use of the additional instance specific data. The vertex shader sees the instance data just like any other vertex data but it only gets updated between instances;

in vec3 position; in vec2 tex_coords; in mat4 world_matrix; out vec2 v_tex_position; uniform mat4 view_matrix; uniform mat4 perspective; void main() { v_tex_position = tex_coords; gl_Position = perspective * view_matrix * world_matrix * vec4(position, 1.0); }

There are a couple of changes here.

- There is a new vertex input
`world_matrix`

which is the instance specific matrix that holds the object-to-world transformation - The old
`matrix`

uniform has been replaced by the`view_matrix`

uniform. The previous code did not separate the world and view transforms but now we want to move both the instances and the camera independently so we separate out the view and world matrices - The calculation of the position has been changed to reflect the separate view and matrix transformations. The way to read the position calculation code is from right-to-left; First the position is transformed into world coordinates, then into view space and finally the perspective is applied.

The fragment shader does not need any changes.

### Updating the rendering code

I have updated the code in the draw loop to make the part view matrix plays much explicit than before.

The view matrix is constructed around the idea that the camera always looks at the origin and rotates around it around the y- and x-axes.

Because the view matrix describes the transform from world space into view space it is constructed as the inverse of the camera-to-world transformation. I could construct the camera-to-world matrix and then take its inverse but I have chosen to manually construct the view matrix by applying the different transforms in opposite direction and order.

let mut view_matrix_glm = glm::translate(&glm::identity(), &glm::Vec3::new(0.0, 0.0, -18.0)); view_matrix_glm = glm::rotate_x(&view_matrix_glm, camera_angles.x); view_matrix_glm = glm::rotate_y(&view_matrix_glm, camera_angles.y); let view_matrix: [[f32; 4]; 4] = view_matrix_glm.into(); let perspective_glm = glm::perspective(1.0, 3.14 / 2.0, 0.1, 1000.0); let perspective: [[f32; 4]; 4] = perspective_glm.into(); let uniforms = glium::uniform! { view_matrix : view_matrix, perspective : perspective };

Finally, the actual render call needs to be updated to let glium know we now using two vertex buffers.

target.draw( (&vertex_buffer, position_buffer.per_instance().unwrap()), &indices, &program, &uniforms, ¶ms ).unwrap();

The difference is that now we pass in a tuple of vertex buffers. The first member contains the cube vertices and the seconds buffer contains the instance vertices.

The draw code now uses a unique matrix for each cube.

### Updating the camera

I want to be able to move the camera. We already have the code for converting the camera angles into a view matrix so I just need to hook up to the mouse events to update the camera angles.

The camera should only be updated when the mouse is pressed down, so I need to capture the left mouse button state;

glutin::WindowEvent::MouseInput { device_id: _device_id, state, button, ..} => match button { glutin::MouseButton::Left => { mouse_down = state == glutin::ElementState::Pressed; } }

The mouse positions are posted via

`DeviceEvents`

so it needs to in its own match statement;glutin::Event::DeviceEvent { device_id, event } => match event { glutin::DeviceEvent::MouseMotion { delta } => { if mouse_down { camera_angles.y += delta.0 as f32 / 100.0f32; camera_angles.x += delta.1 as f32 / 100.0f32; } } _ => (), },

### Animating the cubes

To really see the instance based matrices in action they need to be animated. So I replace the

`build_object `

function with some code to allocate space for the matrices.let world_matrix : [[f32;4];4] = ( glm::Mat4x4::identity() ).into(); let mut positions : Vec<Attr> = vec!( Attr { world_matrix: world_matrix }; 32*80);

This create 32*80 matrices ( this number is completely arbitrary and depends on the animation function. Something I will address in the future ) and sets them all to identity. Before the draw I call

`animate_object`

that recalculates all the matrices, overriding the previous matrices. Finally I call `write`

on the vertex buffer object to push them to OpenGL.animate_object(&mut positions, t); position_buffer.write(&positions);

The code inside

`animate_object`

function that animates the matrices somewhat unimportant as long as the cubes get animated. It is a lot of fun to play with for the purpose of demonstrating but is fun to play with. The code below produces the pulsating arch at the top of this posting.fn animate_object(attribs: &mut Vec<Attr>, iTime: f32) { let mut cursor: glm::Mat4x4 = glm::Mat4x4::identity(); cursor = glm::translate(&cursor, &glm::Vec3::new( -5.0, -10.0f32, 0.0f32 ) ); let mut idx : usize = 0; for y in 0..80 { cursor = glm::translate(&cursor, &glm::Vec3::new(0.0, 1.5, 0.0)); cursor = glm::rotate_x(&cursor, 0.04); let radius = 7.0 + f32::sin(iTime + y as f32 * 0.4f32) * 2.0f32 * glm::smoothstep(0.0, 0.2, (y as f32) / 20.0f32); let points = 32; for c in 0..points { let mut inner = glm::rotate_y(&cursor, std::f32::consts::PI * 2.0 * c as f32 / (points as f32)); inner = glm::translate(&inner, &glm::Vec3::new(0.0, 0.0, radius)); attribs[ idx ].world_matrix = inner.into(); idx += 1; } } }

The code is a reasonable demonstration of how powerful instancing is and how easy it is to do instancing with glium.

The cubes are pretty ugly as they don't really have any proper shading. In my next blog post I want to add better, more interesting shading

_{}

^{}