It’s been some months I am only writing code for work (I am going to post soon about the cool things we are doing there) and have stopped the hobby projects. But this weekend (that was Easter for Greeks) there was a Ludum Dare jam with theme “Keep it alive”. Easter in quarantine was the perfect time for a break. 🙂
In a previous post, I wrote about Vkrunner, and how I used it to play with fragment shaders. While I was writing the shaders for it, I had to save them, generate a PPM image and display it to see the changes. This render to image/display repetition gave me the idea to write a minimal tool that automatically displays my changes every time I save the file with the shader code and use it when the complexity of the scene is increasing. And so, I’ve written sdrviewer, the minimal OpenGL viewer for pixel shaders of the video below:
Hair rendering and simulation can be challenging, especially in real-time. There are many sophisticated algorithms for it (based on particle systems, hair mesh simulation, mass-spring systems and more) that can give very good results. But in this post, I will try to explain a simple and somehow hacky approach I followed in my first attempt to simulate hair (the mohawk hair of the video below) using a mass-spring system.
The code can be found here: https://github.com/hikiko/mohawk
There are several methods to create and display a terrain, in real-time. In this post, I will explain the approach I followed on the demo I’m writing for my work at Igalia. Some work is still in progress.
Today, I experimented with the linux kernel modules for the first time and I’ve written a simple module that prints a message (helloworld :P) every time that someone reads from the
/dev/ktest (a custom character device) and counts how many times the device was opened for reading.
So far, I hadn’t try to morph 3D objects to other 3D objects and I thought it’s something tricky to do. Today, I realized how simple and easy it is when I wrote this small test:
If you carefully choose the 3D models to have the same number of polygons, and to meet a few topological requirements, then you only need to interpolate the values of the meshes’ vectors, normals (and materials, textures, whatever you need) and draw the intermediate mesh every time. As interpolation parameter you can choose the values of a positive function that varies from 0 to 1 and backwards (I used
(sin(msecs/factor) + 1)/2) to have that continuously changing effect. And that’s all!
The test is here: https://bitbucket.org/eleni-hikiko/morphing and it includes an obj with a scene with 3 meshes that meet the morphing requirements (I only used the first two meshes here).
Here’s a CT scan viewer I’ve started to experiment with volume rendering:
A few weeks ago, I started a minimal window system, which performs software rendering on the linux /dev/fb0. My aim was to learn some systems programming and familiarize myself with concepts like event and device handling, memory management, window management, drawing on the framebuffer, IPC mechanisms etc (and certainly not to create a full linux window system! :)p) I call the program winnie and the code is available on github here: https://github.com/hikiko/winnie/tree/winnie.clients-as-plugins, https://github.com/hikiko/winnie and lp.
The program is not finished yet and I don’t know if I ever finish it, since I came up with new project ideas again.. Nevertheless, you can see some videos of the development stages below if you are interested (most recent first):