## Working with Vulkan

So, work on Fluxions 4.0 has begun. I started out by digging into Kristian Høgsberg Kristensens’ vkCube source code. I think he did a good job laying out all the essential pieces. Vulkan like OpenGL is a C library at heart. Instead of many state calls, you need to fill in data structures with all the important information. Unfortunately, the anonymous initializer lists that C uses are not compatible with C++, so instead I used that as an opportunity to go into the vulkan_core.h header file and see what these structs do.

One key piece of information is that you need to set all the non-essential parameters of every struct to zero or you likely will cause a crash. One method is to call memset to set the entire struct to 0, which I did initially, but I think the better way is to simply initialize all the members directly. And I won’t feel that I’m adding unnecessary calls to It helps with the learning process and since the whole process of programming with Vulkan is a bit verbose anyways, not a big deal. Another option that I considered was to encapsulate every Vulkan struct as a C++ class. But there is a substantial work cost involved given the vast number of different structures in the Vulkan library.

To initialize the Vulkan library, I use SDL 2.0 to create the window, initialize OS-dependent extensions, and create a surface to render to. Ultimately, this initialization takes about 500 lines of code. I need to add the ability to create a depth-stencil buffer in addition to the color buffer, but I do not think this will take too much effort. The functionality for initialization is going to located in the VulkanContext class. The main idea is to have code that looks like:

bool MyApp::init() {
if (!context.init())
return false;
}

void MyApp::render() {
context.beginFrame();
// render objects
context.presentFrame();
}

The next concept to finalize is the render config. The render config is a thing I started in my WebGL LibXOR game engine. The idea matches the idea of the graphics pipeline in Vulkan. Of course, I was inspired by early talks about the architectures of Mantle, Direct3D, and Vulkan in hopes that I would be ready for it when I was ready to begin work with Vulkan. This has turned out to be a good strategy. While not finished, I hope to make the following code idea to be viable:

void MyApp::render() {
context.beginFrame()
if (config.use()) {
config.setLights(lights)
config.setMaterial(material)
config.useTransformation(transformation)
config.useTextures(textures)
config.draw(geometry)
config.restore()
}
context.endFrame()
}

Before I go down that road, I need to identify the material, geometry, and scene graph methodologies I want to use. The first is to use the Alias/Wavefront OBJ/MTL format which is great for static geometry. The second is to investigate the Autodesk (Filmbox) FBX format which supports animation. The third is to investigate Alembic which is an animation format for preserving animation. Lastly, I have taken a look at glTF which has a nice subset of features including animation. It may be worth my time to simply develop tools to convert these into a simpler system useful for direct upload in GPU buffers. I have played around with extending the Alias/Wavefront text file format and had good results in the past. I may keep that work and see what FBX or glTF ideas might be useful.

This last point is important because when you want to focus on physically-based rendering, you do not want to get too bogged down into a complex animation system. I do want to be able to tell animated stories with my graphics engine. But I have to balance it with the needs of the other components to my graphics engine.

So, the next work I need to do is to encapsulate the following ideas in Vulkan. How do I upload a texture map, create separate uniform buffer objects, and separate interleaved vertex array objects? Currently, I am working on abstracting the VkMemory and VkBuffer objects to make this process easier. Ultimately, I am working towards a smallish demo on using the new Ray Tracing features. Until then, Adios!

## Fluxions Engine 3.0: The History of a Research Graphics Engine

The first graphics engine I wrote was in the late 1990s which I originally named KA3D — short for Kick-Ass 3D. But, I couldn’t commit to this name because it had a slight hint of profanity which I am generally uncomfortable with. So I changed it to Fluxions after the Method of Fluxions which Isaac Newton invented. The name was cool and it had the allure of mystery. I found an old version of my website, though mostly non-working, which was cached in October 1999.

https://web.archive.org/web/19991007002444/http://skyscraper.fortunecity.com/altavista/565/

The first engine was short-lived and it was completely software-based using scan-line rendering and blended lightmaps and color look-up tables. It was written for MS-DOS using the DJGPP port of GNU C++ compilers. Then I discovered the Allegro library.

The Allegro engine was a game engine that was fairly easy to get into. It had graphical user interfaces and extensions for 3D graphics. I was also getting into Linux at the time and I was first learning about the Mesa library for rendering with OpenGL. And then I was lucky to get a hold of Riva TNT2 card which had OpenGL graphics drivers to use at school.

So I began writing the second version of Fluxions using OpenGL 1.1. I used this for a game I was working on called Outpost Wars. I remember there was an online contest for 3D demos, so I submitted the following demo. You could walk around this strange sculpture featuring rotating rings kinda like the ones from Superman.

I followed the extension scene around OpenGL until at least version 1.5. This was especially useful for doing bump mapping and other related techniques. I started working on an outer space network game with some friends from work. Unfortunately, we were not able to complete it, but I still look fondly back on that work. I was very pleased with some graphical user interface work I programmed and utilizing bump mapping and lightmapping. But programmable shaders were becoming interesting and so it was time for the longest-running Fluxions 3.0 graphics engine.

When I began working on programmable graphics, the 3D engine has taken a number of turns before it gets to its final form. But basically, it served as the basis of my Master’s and Ph.D. research. My first trip to SIGGRAPH in 2012 really brought me up to speed on many of the latest and greatest pushes into physically based rendering. You can see some of the improvements in the remaining two images.

So, I think it’s probably time that I put Fluxions 3.0 to bed. It needs a few last remaining touches, but the next version will switch to the Vulkan graphics library and make use of real-time path tracing. I will work on moving some of my earlier research work on local dynamic radiance maps, spherical harmonic lights, and scalable SH harmonics. Farewell Fluxions 3.0, and good tidings to the new Fluxions 4.0 engine.

## FreeBSD Part 4

Today, I am getting my development environment all set up. I wanted to use VS Code, but it wasn’t in the pkg system for 12.1. So I tried to use the ports system, however, the 49GB slice I have for my /usr folder was filling up — fast. OK, so instead I decided to see if I could update where I’m getting the software. So I changed from release_0 to latest inside my /usr/local/etc/pkg/repos/FreeBSD.conf. This file does not exist initially, so you have to create it. Afterward, I type in the following and I’m able to install newer software!

FreeBSD: {

## FreeBSD Part 2

So I tried FreeBSD in VirtualBox. Step 2 was to try and install it on my Thinkpad. Unfortunately, I am having boot issues. Perhaps it was too many operating systems. I deleted everything but Windows 10 and then reinstalled Fedora 29. I may try again on my Intel NUC that I am currently using PopOS with. In the mean time, the Raspberry Pi 3 is getting a go at it. The wifi does not work, so it is tethered to my router so I can install X11. I used the image from the FreeBSD website. When I get everything installed, we’ll see how the experience is.