This electronics project is able to tap into some car's data bus to read speed-related informations and display them on an LCD screen. This screen is then reflected on the windshield using a semireflective sticker, thus forming a head-up display (HUD). The car I was experimenting on uses a Vehicle Area Network (VAN) bus. As this is quite an uncommon protocol, I had to decode the VAN frames myself, which was a bit of a challenge. The project uses two microcontrollers, a PIC which focuses on decoding the VAN frames, and an STM32F which communicates with the PIC through SPI and display the data on the LCD screen. I also learned how to design my own PCBs and how to solder 0.5mm pitch microchips while making this project.
GemStudio is a university project developed during spring 2019. The goal was to render a photo-realistic looking gem in real-time using OpenGL. GemStudio achieves this by simulating a few effects such as reflection and refraction while using a High-Dynamic Range (HDR) pipeline with automatic exposure management. This project relies on two libraries described below: MGPCL as well as the user interface system used in mGraph.
ELK-based Monitoring Solution
During my autumn 2018 internship, I was tasked with setting up a monitoring system for an existing app, using mostly the generated logs. For this purpose, I adapted, configured and deployed a stack of software similar to the well-known ELK stack (ElasticSearch, Logstash and Kibana). I then had to automate the deploying process using Ansible. As I did not know these pieces of software at my arrival, I had to learn how to use them on the fly. During this internship, I realized how useful and convenient the ELK stack could be, so I later decided to set-up my own ELK stack on my dedicated server.
MGE (Montoyo's Game Engine) is the first (C++) 3D game engine I ever made. It is the project that got me into OpenGL and 3D APIs in general. It began in 2012, and it is certainly the biggest project I ever made: it has a home-made GUI, TCP+UDP networking system, level editor, and audio system. It was working very well, but because I learned a lot since then, I decided to drop it and instead write a new game engine using newest technologies such as Vulkan. I would like to point out that the only libraries I used for this are the ones in the tags below.
Polavivalitiquarium is a university Java project. It features a 3D vivarium which contains entities interacting with each-others. I was responsible for the graphics part, which involves a custom engine based on OpenGL 3.3 using the LWJGL Java wrapper. We were a team of 4 students and worked together using a private BitBucket repository. With over 16,000 lines of code, the project was a success and we all had a lot of fun writing it. During its development, I learned a lot about the GLTF 3D model format, since it's one of the main features of the graphics engine.
mGraph is a project based on my library MGPCL and OpenGL. It is made out of two important components: a GUI system and common graph theory algorithm implementations. It was very useful during autumn 2017 while I was learning about graph theory and its applications at university. Because I was quite happy with the GUI system I made for this project, I used my free time to optimize it so that rendering the whole GUI would take a single drawcall (if nothing is changing, that is). The renderer I came up with is not perfect but achieves the single-drawcall thing in pretty much all cases.
MGPCL (Montoyo's General Purpose C++ Library) is a static library I am developing mostly for personal uses. It was a great opportunity to learn about OS internals for both Windows and Linux, SIMD, and some shady C++ features such as SFINAE. It features basic containers, threading & locking primitives, SSE FFT, raycast utilities, JSON, INI and program argument parsing utilities, an HTTP client, and a few other stuff.
Portable Counting Device (Patent)
While I was working as a production line operator during an internship, I noticed how hard it is to keep track of the number of parts processed, especially when the job consists in repeating the same movement over and over again. The problem is that putting the wrong number of parts in the container could lead to extra billing. We had simple devices with a button and a tiny display showing the number of times we pushed the button, but it was very easy to forget to push the button. That's how I came up with this idea: put a sensor in the operator's glove, and let it keep track of the part count for you. I made a little prototype using an Arduino and an inductive proximity sensor.