Geometry Shaders – An Introduction

It is well accepted that Shaders have played a very important role in fast and effective visualization effects. After Vertex Shaders and Fragment Shaders, we have a very important Shader – Geometry Shader.

Fragment Shaders and Vertex Shaders are the building blocks of any rendering scene. But it would be very cumbersome and difficult to construct a complicated shape using ONLY vertex shaders and fragment shaders. This is because it is very difficult to code details of each and every vertex. Hence, we have with us the Geometry Shader. A Geometry Shader takes the whole primitive as input and produces a geometry which can then be used as a block rather than handling each and every vertex separately.

A geometry shader can be thought of as vertex amplifier, that is, it helps in rendering more vertices than what it actually would take to do it using Vertex and Fragment Shaders.  Thus as given in the example here, only a single instance of Points would render different shapes. This is helpful in complicated rendering scenes, like rain, fireworks etc.

But all of this comes with some limitations. A geometry shader is slow compared to normal rendering and this is not that big a surprise. Also, as described here,  there is a limit to the number of primitives I can use per input to Geometry Shader. The limit given here is 1024. This may vary over systems but the message is that we can not use it for too big data.

Is this useful for us?

dipy requires rendering complicated data with a large number of vertices. I have not fully explored the possibilities in Geometry Shader but I am sure this would be very helpful to us. GS would make it easy to code the vertices of the data. This does compromise the speed but that must be marginal. More would be known after working with actual datasets.

My approach now

Currently, I am trying to replicate the example given here using python-vtk. This is a little bit tricky as I have never read examples of GS in python-vtk. I guess this would be completed after having a discussion with mentors and reading relevant documentation.

Shaders – Resources and Examples

Shaders are probably the best tool for start-of-art visualizations. Having shaders in our dipy would be a cool addition.  Apart from the implementation, I also spend time getting to know the shaders better. Fragment shaders and Vertex Shaders are not very trivial and it takes a bit of time to understand and digest completely. Below are some points about Shaders and some easy examples of how they work.

Vertex Shaders

As the name suggests, Vertex Shaders contains attributes about a particular vertex in a shape. All the information about a vertex is contained in it including the color and texture. As mentioned here, there is always a 1:1 correspondence between the input vertex and the output vertex. Just the shader does a particular transform on the attributes.

Fragment Shaders

Fragment Shaders gives the color and the depth value of an input pixel. The fragment shader is something which is independent of the movement of the object. It is very important to note that each Fragment Shader has its own “window space” which acts as the output of the stream.

It requires examples to properly understand the difference between the two and how both of them when combined, can render interesting shapes.

Now, look at the sample code given below:

#ifdef GL_ES

precision medium float;


void main() {

fl_FragColor = vec4(1.0, 0.0, 1.0, 1.0);


Clearly, this deals with the fragment shader. Why so? It is because of the fact that we just want to see the color of the output and no vertex is involved here. Hence, Fragment Shaders makes sense here. The color of the screen is set to Red and Blue, which yields Pink.

There are a lot of interesting examples which uses the combination of two to get eye-catching examples and visualizations.

Inbuilt Variables in Shaders

It is very very important to know what all predefined variables comes along with shader so that you don’t have to keep looking for where it was first used. So, here is a resource which gives major focus on the predefined variables and what it does. It also has important data types required for visualization tasks.

*NOTE* This blog will be updated regularly as I read more about Shaders and try them out.

More into my experiments on vtk

It’s time for another update of the work.  After having spent a lot of time exploring shaders, I came up with beautiful illustrations in my last blog. This time around, I will discuss the brief extension of the work done and will also talk about my recent Pull Request being merged.

vtk Ellipsoid with adjustable semi-major axis length

So, last week I introduced a sphere which can change colors based on the color input by the user. The next step is to move this further and make a sphere which can dynamically adjust the parameters while rendering continuously. The following example uses a slider to set the value of the semi-major axis. In our case, we are only changing the x coordinate to adjust the ellipsoid.

Initially, I had issues with dynamically rendering the screen. On discussion with Ranveer, we had in our mind two possible solutions:-

  • Destroy the renderer and render afresh every time. It is clear that this is not an elegant solution to the problem.
  • Update the renderer every time. This was an acceptable solution and quite logical.

This was discussed with Elef during our periodic conversation and he helped me sort out the problem of assigning the updated value back to the vtk ellipsoid.

The code is available here.

My Pull Request to Add Sphere object to the sphere class is merged.

My work on adding Sphere objects as a parameter to the sphere function got merged. The pull request can be seen here. I added faces and vertices parameter to the sphere. Now instead of providing the function every time with centers and radii, we can simply provide the faces and vertices which we get from the Sphere function of dipy.

Also, I am working on resolving my doubts with the function MapDataArrayToVertexAttribute. After today’s meet, it is clear and I will soon come up with the corrected version of my code.

The has been a good journey so far. I hope to say this till the end of my summers. Shaders are quite interesting and exciting. Looking forward to more fun.