So a lot has happened since my last update on this project. It has gone through another major overhaul. The renderer has been built from scratch again. Now, rather than voxellize the whole scene, I voxellize each collection of shapes (Mosaics) and raymarch a collection of those. This now has improved quality and in many cases performance debating on the AABB per collection. In terms of new features since the last version, there are:
Here's a couple of demos of things made entirely in engine
After taking a break from the raymarched SDF project (Esdief), I found myself constantly thinking about it. I had played around watched some talks with similar software, like Unbound and Claybook, and of course Dreams, and was fascinated they were full fledged game engines, running real time. I wanted to take another stab at it, building off the original Esdief, but this time focussing on performance, and actually making a game with the tool, adding features to the engine, to support a game inheriting from it. In the previous iteration, I would start getting < 60 fps with around 20 unique shapes on screen with an average window resolution of 800x600. I definitely had to surpass that for a proper game engine. First thing I did was recreate the original one from scratch, making small optimizations as I go, caching transforms here, culling unseen objects there, etc. But generally speaking, these were not really my bottleneck. The Raymarching shader was. As we all know, branching in GPUs causes a lot of slowdown, so I did my best there, which certainly saves me a few frames, but unfortunately is not going to cut it. Then I watched a Claybook tech talk, and saw how they're rendering so many on screen. Well, they do a million things for optimizations, but the major thing I thought I could recreate in not too much time is the voxellization. In a compute shader, a voxelized representation of the world is generated, and the raymarch shader only has to sample that to get the distance/other sdf information once per raymarch step. GENIUS! So after some time I got a basic implementation of that working, and wow, that speeds it up. But that's only the first step, many more to come.
Screenshots below are from a work in progress game.
Stup Engine was my attempt at a grander scale OpenGL Mesh Renderer and Game Engine. I expanded on almost all the features of GLEngine, but focused less on asset creation, and more on scene rendering and game flow.
Current features include:
Libraries Used:
Esdief is a runtime environment and editor for creating SDF scenes dynamically. I've been very interested in SDFs since discovering work by Inigo Quilez and video games such as Media Molecule's Dreams. I loved playing around with ShaderToy but found it hard to visualize exactly what I was doing since you had to manually adjust values by hand. I wanted to have more control over how things were going to look. I'm aware of online tools such as Womp and Inigo Quilez's incredible showcase of the recent Project Neo at Adobe, but aside from wanting to build one myself, there were a few features I thought would be interesting that I was not seeing as part of theirs. So I built my own.
GLEngine was my first attempt at building a custom 3D Mesh OpenGL engine written in C++ from the ground up. Originally included modelling/rigging tools, but removed as the scope was getting too large.
Current features include:
Libraries Used:
PyDCC was simply an attempt to make a simple 3D DCC tool inside Python using PyGame's 2D Graphics library. Didn't get very far, polygon rasterization simple lighting, basic object manipulation, and the start of a modifier stack.
I'm not much of an artist, especially using the mouse. Playing games like gartic phone, jackbox, and pictionary with my friends really showcased this. So I wrote a program to draw for me. Simply load in the image you want to draw, choose whether to draw via edge detection, or line detection, choose your settings, and draw away. Don't forget to click and drag your boundaries of the drawing space. Feel free to save your settings. If I had more time, I'd add proper curve drawing and shape detection.
This tool was developed while my wife and I were looking for houses for purchase. This scraping algorithm would keep me updated on homes we were interested in, and the tool would automatically calculate relevant financial information for me, given my budget, mortgage, and others. A lot of information has been redacted as it is private, and also not releasing this tool as since I've stopped using it, the sites I was scraping have updated their backend so it no longer works as intended without significant redesign.
In 2015, my theory here was that, since I saw a lot of those artsy collage images where one image is made up of many smaller ones, could I automate that, and have it use any base blocks of my choosing. The answer was unfortunately yes, and my test base blocks were of course, everyone's favourite new sensation, emojis!
My method for going about this was to load up the base blocks, in this case emojis, and create a datamap mapping the average RGB for each block to actual block itself. Then go through the image you wish to recreate, segment it, and for each segmentation, find which base block has the most similar average RGB. Basically a KNN where K = 1.
Here are a few examples.
It's worth noting the size of the image compared to the size of the emojis will change how detailed or accurate the recreation is.
My program allows for the desired scaling of the original image as even though the scale won't preserve quality of the image, average colour's will be, so the recreated image will only look more detailed. As mentioned, this is modular, and will work with any given dataset of base blocks. Here is an example using the entire hearthstone library.
And finally, if you've decided to stick around this long, the program allows for full video integration. So please strap yourself before clicking here.
Coeus is an offline password manager I've developed for my own purposes. It's simple, it stores passwords and encrypts them to a local directory using a single encrypt/decrypt password that the user defines. Secure? Probably not, but very useful for my use cases.
