I wanted to play around with some shaders recently so I was looking for simple things to implement. One of the nicest ways to get started in a new graphics framework is to get some fractals going—so this is what I did.

# The Mandelbrot shader

We first require some GLSL magic to make the Mandelbrot fractal happen:

uniform int iterations; uniform highp vec2 centre; uniform highp float scale; varying highp vec2 texture_out; void main() { vec2 z; vec2 c; c.x = scale * ( 3.0 * texture_out.x - 2.0 ) + centre.x; c.y = scale * ( 2.0 * texture_out.y - 1.0 ) + centre.y; z = c; int i = 0; for(; i < iterations; ++i) { float x = z.x*z.x - z.y*z.y + c.x; float y = z.x*z.y + z.y*z.x + c.y; if( x*x + y*y > 4.0 ) break; z.x = x; z.y = y; } vec4 color = vec4(0.0); if(i < iterations - 1) { color.x = sin(float(i) / 3.0); color.y = sin(float(i) / 6.0); color.z = cos(float(i) / 12.0 + 3.141 / 4.0); } gl_FragColor = color; }

Basically, I am filling the texture coordinates with colours, based on
the number of iterations it took for the series to reach the desired
norm of 4.0. The `scale`

and `centre`

parameter exist only for the
purpose of modifying the view within the controlling application.

# The Julia set shader

Now let's add another shader for the Julia set:

uniform int iterations; uniform highp vec2 c; uniform highp vec2 centre; uniform highp float scale; varying highp vec2 texture_out; void main() { vec2 z; z.x = scale * ( 3.0 * texture_out.x - 2.0 ) + centre.x; z.y = scale * ( 2.0 * texture_out.y - 1.0 ) + centre.y; int i = 0; for(; i < iterations; ++i) { float x = z.x*z.x - z.y*z.y + c.x; float y = z.x*z.y + z.y*z.x + c.y; if( x*x + y*y > 4.0 ) break; z.x = x; z.y = y; } vec4 color = vec4(0.0); if(i < iterations - 1) { color.x = sin(float(i) / 3.0); color.y = sin(float(i) / 6.0); color.z = cos(float(i) / 12.0 + 3.141 / 4.0); } gl_FragColor = color; }

Note that the differences between the shaders are minuscule at best.

# Using Qt 5 to put it together

Putting the fractals on the screen then turned out to be a rather easy
exercise with Qt 5. Using a `QGLShaderProgram`

, I only need to render a
quad onto the screen, bind the appropriate shader, and we are done.
Check out the code on
GitHub for more details.

# Screenshots

Click to see the screenshots in their original resolution.

I just had the privilege of watching lots of great talks at the EuroVis 2015 conference. Since giving a talk about your research is a common occurrence, even for undergraduate students, I thought it worthwhile to think a little bit about what makes a talk truly great.

It goes without saying these are my personal opinions. They reflect the ways in which I perceive a talk. Still, here are some rules that good talks tend to adhere to:

*Preparing a good talk takes time*. You should figure that into your calculations. To prepare a good talk, several iterations are probably required. Test it on your friends, your colleagues, your family, and so on.*Avoid last-minute changes*. Been there, done that. Try to avoid it unless your colleagues or supervisor have some specific criticisms about your slides that can be fixed. Do not do it on your own.*Know your audience*. Your audience determines the level of specificity your talk should have. An all-expert audience can take more technical details than a more general audience. If in doubt, follow the*rule of thirds*: Prepare one third of your talk for the experts, one third for your peers, and one third for the general listener.*Avoid death-by-detail*. This is somewhat interlinked with the previous rule. A good research talk should show your the interesting challenges in your research. It should make people want to read your thesis, your paper, or discuss stuff with you. The quickest way to lose an audience is too bog them down with too many details. When in doubt, always opt for the*bird's eye view*. Technical details can always be read in the paper or discussed face-to-face. Of course, you should outline the challenges you had to face and the obstacles your research overcame. If this involves some details, so be it. Just make sure that people who have*not*(yet) read your paper will follow you.*Know the format of your talk and know what it should accomplish*. Lest you think that I advocate a marketing presentation in rule 4, rest assured. If you have one hour of speaking time to convince a funding committee that your work is great or your advisers to give you the coveted degree, it is probably a good idea to include as many details as possible. At a conference, however, you have to convince people to read your paper. These two goals have a very different nature and need to be tackled differently.*Whenever possible, give the audience time to breathe again*. So you just waltzed through a very different mathematical technique? Add a slide in which you explain*why*this was done. Give the audience a chance to catch their breath. Remind them of the overall goal you want to accomplish, for example showing that a certain algorithm scales to larger data sets. This gives the audience the possibility to nod their heads in agreement and see your motivation, even if they did not understand everything perfectly.*Consistency*. Try to be as consistent as possible, with respect to colours, names, and even the layout of your slides. Is it possible to refer to your method as either*foo*or*bar*? Pick only one. Are there two possibilities A and B for solving something? Show things pertaining to A always in the same colour. Use a different colour for B.*Add visual metaphors*. Does your method work like a cheese grater? Or like a meat grinder? Use these metaphors to get members of the audience to understand what you are talking about. However, do not attempt to force a metaphor if there is none. I would rather have you talk about the differential structure of non-Euclidean manifolds than try to convince me that they "work exactly like a trash can"...*Make a test-run of your presentation*. Bring all your adapters. Make yourself familiar with how to connect your notebook to the projector. Check that your operating system is using the proper resolution, and so on. There is nothing worse than being nervous and having to fiddle for what feels like an eternity with different cables, settings, and so on.*Speak freely*. If you are very inexperienced with giving a talk, reading off a fully-formulated talk might put you at ease. It is however also possible that you stumble over one sentence and are completely thrown off course. I saw this happen multiple times and it is very hard to recover from this. I rather have a presenter speaking freely and sounding*authentic*than a completely-polished talk that is only read-off.

These are some of the rules I would like to impart on people who have to
give a talk. Finally, the most important rule of all: *Have fun and do
not forget that other people are nervous as well*. The final rule does
not get a number because 10 rules are much better than 11.

Enjoy your talks, be it as a speaker or an audience member.