About me

My name is Rick van Miltenburg. I am currently a game programming student from the International Game Architecture and Design (IGAD) course at NHTV University of Applied Sciences in Breda, the Netherlands.

I love making games. But I am particularly fascinated in building the underlying technology for creating games, and the tools allowing programmers, designers and artists alike to interface with these underlying systems.

I see myself as a team player: Always ready to be of service for those around me. A capable programmer able to get things done, and a fast learner.


Skills

Spoken/Written languages

Dutch (native)
English (fluent)

Platforms

Windows
PlayStation 4
PlayStation 3
Linux

Programming languages

C++
C#
C89
Lua

Shading languages

HLSL
PSSL
GLSL

Engines

Unity3D
Unreal 4

Graphics APIs

DirectX 11
GNM(x)
libGCM
OpenGL 4

Interests

Gaming
Programming
History

Hi there

My name is Rick van Miltenburg. I am currently a game programming student from the International Game Architecture and Design (IGAD) course at NHTV University of Applied Sciences in Breda, the Netherlands.

I love making games. But I am particularly fascinated in building the underlying technology for creating games, and the tools allowing programmers, designers and artists alike to interface with these underlying systems.

I see myself as a team player: Always ready to be of service for those around me. A capable programmer able to get things done, and a fast learner.

Learn more about me

Here are some of the projects I've worked on:

Moonscrapers
Moonscrapers
Group Game
No Man Mayhem
No Man Mayhem
Group Game
Software rasterizer (2015)
Software rasterizer (2015)
Engine
DirectX11, Playstation 4 engine
DirectX11, Playstation 4 engine
Engine Work-in-progress
GPU Pathtracer
GPU Pathtracer
Engine
Software rasterizer (2013)
Software rasterizer (2013)
Engine Superseded

DirectX11, Playstation 4 engine


Details

Type
Specialization project (third year)
On behalf of
International Game Architecture and Design course at NHTV Breda
Role
Programmer
Tech
Direct3D 11 Playstation 4 SDK
Status
In progress

Description

Currently going under working title "Project GRAPHICS" this project is intended as a specialization project for engine and tool programming. It is intended to get general experience in the field of engine and tool development.

This project was set up with the following goals in mind:

  • Cross-platform engine architecture
  • Gamma-correct rendering
  • Simple asset conversion toolchain
  • Level editor implementation
  • Experimentation with Aspect Based engine architecture
  • More in-depth research and experimentation with the DirectX 11 and GNMX rendering APIs
  • Getting more experience with the compute pipeline

The project is currently in development. The rendering side is functional for the most part. The main focus during the remainder of my specialization will be to focus on the conversion toolchain and the level editor.

GPU Pathtracer


Details

Type
GPGPU course assignment (third year)
On behalf of
International Game Architecture and Design course at NHTV Breda
Role
Programmer
Status
Complete; Future improvements planned

Description

This GPU Pathtracer was made for the GPGPU course for the International Game Architecture and Design course at NHTV Breda. It can generate pathtraced images from 3D scenes exported in the OpenGEX format.

The assignment for the GPGPU course was to implement an algorithm and optimize it for optimal performance on the GPU. There was no API requirement for the course, allowing the implementation in CUDA, OpenCL or any other compute capable API. I decided to use DirectCompute due to its close implementation with DirectX.

The Crytek Sponza scene is currently traced at around 3 million rays/second on a GTX460.

Occasionally I turn back to the pathtracer to try and find out why the pathtracer performs significantly slower than expected, but as of yet the true cause is undetermined. It is currently assumed to be related to the BVH construction algorithm. This assumption is based on the fact that switching the BVH traversal algorithm from the basic one initially implemented to the one suggested by Aila et al did not result in a significant speedup. An alternative theory is that DirectCompute is the cause for the slow performance, but with very few functional methods of profiling on my current test setups I have very little in terms of data to back up that assumption.


Awards

  • Gamelab 2012-2013: Best Game Award

Details

Type
Educational group project (second year)
On behalf of
International Game Architecture and Design course at NHTV Breda
Role
Programmer
Tech
C++ Horde3D SFML OpenGL FMOD
Duration
28 weeks (1 day/week)
Status
Complete; Future plans are being discussed

Design
Tech
Art
Indie game developer
Sound design
  • Joris Hoogsteder
  • Daan Jansen
  • Tonny Nobel
Voice acting
  • Daniel Cuatt
  • Jana Tracuka

Description

Moonscrapers is a competetive tower-building RTS. It is played over a network connection with two players. It was built at the International Game Architecture and Design course at NHTV Breda in 28 days.

The goal of the game is to be the first player to get to the moon by building blocks on top of your tower.

In order to prevent the enemy from reaching that point, the player can construct various offensive tower blocks to attack the enemy tower, and to ultimately (partially) collapse it.

Alternatively, the player can build blocks on top of the enemy tower by building sideways. This does not only halt the enemy's upward building progress, but also allows your tower block to rest on the enemy's tower when a part of your tower collapses.

The game was originally meant for the group projects at our course known as Gamelab, but the project was continued for a short while in preparation for display at Indigo at Gamescom 2013 in Cologne, Germany. In the short span of time between final delivery for the course and Gamescom, we implemented a rudementary AI system in order to allow the game to be played by a single person on the show floor.

Role in the project

I joined the project on the 14th week of the project, at which point the first functioning prototype of Moonscrapers was done.

Our task from that point onward was to make a small set of changes to the gameplay, and to polish it.

My tasks involved:

  • Implementation of an improved particle system
  • Environmental effects (planes, zeppelins, cars etc)
  • Bug / crash fixes

After the official conclusion of the project, I worked on an improved version of Moonscrapers for display at Gamescom 2013 together with Jurre de Baare. Improvements included the addition of AI for use in singleplayer, as well as stability improvements for several crashes encountered after initial release.

Links


Awards

  • Gamelab 2013-2014: Best Game Award

Details

Type
Educational group project (third year)
On behalf of
International Game Architecture and Design course at NHTV Breda
Role
Programmer
Tech
Unity Photon
Duration
14 weeks (1 day/week)
Status
Complete

Design
Tech
Art
Audio

Description

No Man Mayhem is a four-player competetive arcade digging game. It is played over a network connection with three other players. It was built at the International Game Architecture and Design course at NHTV Breda in 14 days.

The goal of the game is to be the first player to get more than a certain amount of gold from treasures underneath the ground, while preventing other players from beating you. In order to get to the treasures, the player will have to dig tunnels towards the treasures, and climb back up with the treasure.

The most notable technical feature of this title was the terrain generation and destruction based on voxels. This was implemented by Sam Hardeman, and allowed not only for the terrain to be generated and destroyed, but also for parts of the terrain to break off and fall individually.

Role in the project

I was the tech lead on this project. My main roles as a tech lead in this team included:

  • Assigning the tasks for the programmers to work on
  • Ensuring the completion of tasks, making sure the quality is good enough
  • Handling communication between programmers and other team members
  • Merging and ensuring integration between separate components

Since my main role was not programming itself, there is no notable area which I developed on my own, apart from making the tools for the designers to import their maps. I stepped in on pretty much all fronts with fixes and improvements on the game, without specifically focussing on one single area.

Lessons learnt

This was the first experience with Unity for three of our four programmers. As such, we jumped into the project without knowing enough about the engine in order to develop the project efficiently and cleanly. This resulted in multiple difficulties.

One such difficulty was that for the first half of the project, every change by every single programmer had to be merged into a single project by hand. Only in the latter half of the project did we figure out that Unity has some settings for reasonably supporting version-control.

Furthermore, as mostly C++ developers, we did not expect any higher-level features. As we figured just before the end of the project, Unity has an excellent messaging system for inter-component communication. This is exactly what we would have needed for the project in order to clean up a lot of the dependent code, but as we did not know about the feature, we practically hacked our way around.

The main take-away is to commit more time to properly studying the existing architecture, and making sure said architecture is used optimally. The setup method used in this project and the messaging system has since been successfully used on a couple of side-projects, and drastically accelerated the development process of said projects.

Software rasterizer (2015)


Details

Type
Freetime project
Status
Work in progress

Description

This project is a freetime follow-up to the software rasterizer created for the Graphics Programming course part of International Game Architecture and Design course at NHTV Breda. The goal for this project was to improve on the former software rasterizer with better API design, more optimization, and better texture filtering.

The original project was functional, but had several flaws with regards to the architecture, optimization and rendering quality. As such, I wanted to create a new software rasterizer with solutions to these problems in mind from the start.

The goals for this project included:

  • Testing mipmap selection
  • Become better in C
  • Building a SOA math library for performance testing
  • Applied testing of custom memory allocators
  • Testing cross-platform compatibility

The project was also ported to the PlayStation 4. The PlayStation 4 was chosen because I had access to it, have a good understanding of the underlying APIs and to test portability and enable AVX optimizations, as none of my devices have AVX support.

Mipmap selection is done through rasterizing 4 pixels at a time, similar to what most GPUs appear to do. This allows for calculation of the delta in variables (such as U and V) between pixels. The system then selects the mipmap that would make the delta U and delta V to <= 1 in all directions. Then this mipmap is sampled through either nearest neighbour filtering or bilinear filtering. This nicely prevents undersampling artifacts at the cost of performance and slight blurring of details.

Current state

Currently the main points of the rasterizer have been implemented and tested. Trilinear filtering is working as intended for the most part, although some mipmap selection artifacts do still appear for unknown reasons.

Other things on my TODO list:

  • Fix the AABB frustum culling
  • Implement proper scene graph
  • Clean up the rasterizer
  • Optimize the rasterizer
  • Implement lighting

Links

Software rasterizer (2013)


Details

Type
Low level CPU rasterizer
On behalf of
International Game Architecture and Design course at NHTV Breda
Status
Complete

Description

This project was done for the Graphics Programming 2 second-year course at the International Game Architecture and Design course at NHTV Breda. The goal was to create a CPU software rasterizer, creating a 2D image out of a 3D scene. This served as a primer for graphics programming, base for understanding the job of the GPU and an excercise in optimization.

This project was part of our second course on programming a piece of 3D software from scratch. The objective was to be able to understand the process in which the GPU renders a 3D scene, and understand the optimizations necessary to do so in real-time.

Requirements included the correct rendering of triangles in a 3D scene with sub-pixel and sub-texel correct rendering of textured polygons, running at a framerate surpassing 20 FPS at 640x480 with a scene of at least 50000 polygons.

Features include:

  • Scene graph
  • Perspective-correct texture mapping
  • Flat shading
  • Hierarchical view-frustum culling
  • View frustum clipping

Lessons learnt

Looking back on this project made me realize key mistakes made in this project:

  • It is generally a bad idea to deliver precompiled libraries / DLLs with the project. When the compiler is switched - in this case from Visual Studio 2010 to Visual Studio 2013 - the project tends to break on recompilation.
  • In quite a few places in the codebase an unnecessary amount of the codebase is abstracted. In some cases, this stands in the way of performing optimizations, while in others it just makes the operations needlessly complicated.

However, in general, I am happy with the result with the state of my knowledge in the field of graphics and programming at the time, and the time constraint with other courses needing to be done. There is a lot of material for improvement. For instance, a bilinear or even trilinear filter could drastically improve the result of the rendered image, while keeping a closer eye on memory access patterns and the cache could drastically speed up the codebase.

Blog