Description

This project was part course about software rasterization. The goal was to write a software rasterizer that could render 100K triangles at 50 FPS with a screen resolution of 512x384. Back face culled triangles counted towards the triangle count. One of the requirements was that also a minimal game had built using the software rasterizer.

The shading and bilinear filtering is done by using pre-shading the texture palettes. This way colors did not need to be scaled during rendering. The asteroids are procedurally generated by first taking an icosphere, subdividing that, and then offsetting vertices to create a rocky surface.

Reflection

In this project I learned a lot about how the rendering pipeline works. I also got a lot of extra experience in optimizing C++ code.

Description

This is a side project that I started on when I was bored. There was a lot of optimizations I came up with after handing in my original software rasterizer. I also wanted to try out a framework library I had been working on for a while.

The new software rasterizer is a lot faster than my last one. It also follows the GPU rasterization pipeline a lot closer than my last one. I also implemented an algorithm that paletizes textures. I still want to add more features later, once I have some more free time.

Description

This is a side project that I mostly worked on while travelling to and from work by train. It uses a tile based rendering system like in mobile GPUs, because of the low memory bandwidth constraint on CPUs.

The software rasterizer is heavily optmized for Zen 1. It for example does not use AVX instructions as it gives slightly worse performance over SSE.

Description

While doing contracting work for Confetti, I was tasked with porting the PresenZ player to D3D12 using Confetti's rendering framework. While rewriting the renderer, I also did some optimization, like removing the need for geometry shaders.

Once the project was running in D3D12, the next task was to integrate it in Unreal Engine 4. The first approach I tried, was to reroute all rendering calls that the PresenZ player did to the rendering framework, to Unreal Engine 4 rendering system. Unfortunately, there were some problems with that solution, so a different approach was used. The solution that was used in the end, was to let the PresenZ player render on a separate D3D12 device, and then copy the resulting render target to Unreal Engine's render target using D3D11-D3D12 interop.

Description

When I was an intern, and later a full-time contractor at Confetti, I worked on the StarVR SDK. StarVR is a VR system for usage in Arcades. The hardware that is used is above consumer grade to allow for more immersive experiences.

The SDK was designed to be familiar to developers using the openVR API by Valve. The rendering system has been optimized to remove as much latency as possible. It achieves this is by using advanced techniques like rendering directly to the front buffer and updating constant buffers while the GPU is executing draw calls. It also attempts to predict the movement of the headset to further hide latency.

Description

At Xim Systems I had a leading role in the development of the in-house Content Management System (CMS). The CMS allows people to create and edit web pages for corporate website using an intuitive UI. It manages to make the editor look exactly like what visitors are going to being shown, so users can see exactly what they are doing when building their web page.

I mainly worked on the backend of the system, which is written in Go. This static low level language allowed us to write far more efficient and maintainable code than in more dynamic languages like PHP.

The CMS is also built around modular components, as different websites have different needs. One website may for example have news pages, while another website has pages for research papers.

Description

This is a game developed in 14 weeks (1 day a week) in the PhyreEngine. This project started of as doing a port of an already existing school project, which I did not work on. Eventually game was redesigned and got a new art style. It was, for this team, the game we developed in the PhyreEngine. Even though we had to learn a lot about the engine, we managed to build a game of quality in it.

Reflection

This project has some very valueable lessons for me. Some of these lessons are NDA sensitive. The most valueable experience was to work with a very bare bones engine. The only engine I worked with before was Unity3D, this engine required a lot more work to make a game.

Description

This project is a work in progress. The goal is to create a voxel cone tracer that runs in real time and is able to handle almost any scenes. The current implementation is written in C++ and uses OpenGL. It runs the scene displayed above at around 6 FPS on a resulution of 1280x720. Almost no optimizations have been done so far. I will be working on this project for the rest of the school year. My plan is to further improve the quality and performance by implementing: anisotropic voxels, cascaded voxels, deferred rendering, and specular reflections. This project will also be integrated into an engine that is being developed by other students.

The source code for this prototype is availabe on github: https://github.com/Lijmer/voxel_cone_tracer.

Reflection

So far I learned a lot from this project. I learned a valueable lesson about GLSL shader compilation, where some compilers do not follow the specification. I also learned that OpenGL is not a good platform to prototype in, since there are almost no debugging tools available.

Description

This project is a work in progress. It features a custom game engine build from the ground up for one specific game. Physics are handled by Bullet. A custom memory manger is used to improve cache cohrency for game object components. The engine is also going to be ported to the Playstation 4