Hello! I am Manon, Rendering Engineer at Traverse Research. I have a bachelor's degree in International Game Architecture and Design (IGAD) with a focus on graphics programming and some years of working experience in the field. One of my hobbies is to write software rasterizers in my spare time.
I see myself as a team player, ready to help where I can. I love a challenge and enjoy discussing programming with other people to further improve. A strong sense of responsiblity is my underlying drive.
Although I love making games, I have an even greater interest in the underlying technology of games. Working on performance critical code, like a rendering engine, is my favourite.
Because I think doing community service is important to society, especially for children, that is why I spent my Saturdays as voluntary cub scout leader where I organize activites, together with seven other staff members for about twenty five children.
Ray tracing, Path tracing, Bounding Volume Hiearchy, GPU, C++, CUDA
This project was part of a course about Ray Tracing, taught by Jacco Bikker. The goal was to create a ray tracer that can simulate a scene as accurately as possible. Although speed was not a requirement, optimizations like a Bounding Volume Hierarchy (BVH) were required to allow for a more complex scene.
The path tracer is written in C++ and CUDA. CUDA allowed me to leverage the power of the GPU, thus majorly increasing performance.
Next time I could further improve by postponing low level optimizations after high level optimizations, to prevent wasting time optimizing code that is going to be deleted. I also want to improve by keeping a closer look on the output of my code. There were a few cases where a visual effect seemed to be implemented correctly, even though it was not.
|Tech:||C++ CUDA BVH|
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.
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.
|Tasks:||Graphics and Gameplay programming|
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.
|Tasks:||Graphics and Gameplay programming|
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.
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.
|Tech:||C++, Unreal Engine 4, Direct3D 12|
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.
|Tech:||C++, OpenGL4, Direct3D11, Direct3D12|
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.
|Role:||Programmer, Tech Lead|
|Tech:||Go, Typescript, React|
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.
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.
|Team Size:||14 (4 Programmers)|
|Tasks:||Animation, Audio, Particles, General Programming|
|Duration:||14 weeks (112 hours)|
|Tech:||C++ PhyreEngine PS4|
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.
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.
|Tech:||C++, OpenGL, GLSL|
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
|Tasks:||Graphics programming, Engine Programming|
|Tech:||C++, Direct3D 11, HLSL, Bullet Physics|