### Pinball physics

This might be the first time I reveal something about an upcoming title on this blog, but here it is – we are currently working on a pinball game. Not a classical pinball game, it has a pretty cool twist, but the basic mechanic is still very similar. As a physics programmer this sounded easy at first. Hey, it's just a sphere. What could possibly be easier to simulate?

I wouldn't call myself a pinball player, but I've always enjoyed it and spent a lot of time with the old Amiga games Pinball Dreams/Fantasies and even more with Slam Tilt. It's an interesting challenge to create a pinball simulation because it is quite the opposite of what physics programmers are usually facing – forget stacks of boxes, thousands of objects, streaming geometry and convex decomposition. With pinball it's all about detail and accuracy. We are not aiming for maximum realism in this game, but I think realism is a good place to start and then tweak the parameters to fit the gameplay.

Let's go over the pinball components. There is the ball, not much to say. It's a perfect, solid sphere. The table is a glossy, very slippery, polished surface, similar to the floor in a bowling alley. We also have a lot of curved geometry, ramps and various obstacles. The last component are the flippers. This might be the hardest part to get right. They are built with a double-coiled solenoid actuating a hinged, plastic flipper covered with high friction rubber. The main coil causes the initial strong pull, and at the end of the stroke it switches to just using the outer layer, holding the flipper up without overheating.

This particular setup seems to be important to give pinball it's signature characteristics and enables a lot of advanced playing techniques that simply wouldn't work with a different setup, for example the live catch, drop catch and tip pass.

Since the ball is solid steel it has a fairly high moment of inertia. The glossy table causes the ball to mostly slide across the surface, but when touching high-friction rubber on a flipper, it has to start rotating. In physical terms this translates linear momentum into angular momentum, causing the ball to drop a lot of speed. This gives the player control, being able to capture the ball using the flippers. The reverse is of course also true, if the ball is rotating heavily and touching a flipper, it will translate angular momentum into linear momentum.

Curved geometry is important in order to alter the direction of motion of the ball without loosing too much momentum. This is a bit of a headache in physics, since we're used to model most things using convex polyhedra, and now suddenly everything is concave! On the up-side collision detection will not be a performance bottleneck with a single sphere, so we can easily use detailed triangle meshes for everything, but on the down-side no matter how many triangles we use, they still aren't curved – they're flat!

Another thing in pinball is the speed. The ball can easily travel at 6 m/s, which translates to more than three times the diameter per frame at 60 FPS. Fortunately, this can easily be solved using substepping, as performance is not an issue.

I'm only starting to explore this world and I will post more details as I dive deeper into each specific part.

1. For curved collision geometry, you might try nurbs patches. I guess it's beneficial to have accurate collision response of the ball when it comes to pinball, although with very detailed meshes you might get close enough. Of course things can get a bit hairy compuitation wise. Just a thought.

### Bokeh depth of field in a single pass

When I implemented bokeh depth of field I stumbled upon a neat blending trick almost by accident. In my opinion, the quality of depth of field is more related to how objects of different depths blend together, rather than the blur itself. Sure, bokeh is nicer than gaussian, but if the blending is off the whole thing falls flat. There seems to be many different approaches to this out there, most of them requiring multiple passes and sometimes separation of what's behind and in front of the focal plane. I experimented a bit and stumbled upon a nice trick, almost by accident. I'm not going to get into technical details about lenses, circle of confusion, etc. It has been described very well many times before, so I'm just going to assume you know the basics. I can try to summarize what we want to do in one sentence – render each pixel as a discs where the radius is determined by how out of focus it is, also taking depth into consideration "somehow". Taking depth i

### Screen Space Path Tracing – Diffuse

The last few posts has been about my new screen space renderer. Apart from a few details I haven't really described how it works, so here we go. I split up the entire pipeline into diffuse and specular light. This post will focusing on diffuse light, which is the hard part. My method is very similar to SSAO, but instead of doing a number of samples on the hemisphere at a fixed distance, I raymarch every sample against the depth buffer. Note that the depth buffer is not a regular, single value depth buffer, but each pixel contains front and back face depth for the first and second layer of geometry, as described in this post . The increment for each step is not view dependant, but fixed in world space, otherwise shadows would move with the camera. I start with a small step and then increase the step exponentially until I reach a maximum distance, at which the ray is considered a miss. Needless to say, raymarching multiple samples for every pixel is very costly, and this is with

### Stratified sampling

After finishing my framework overhaul I'm now back on hybrid rendering and screen space raytracing. My first plan was to just port the old renderer to the new framework but I ended up rewriting all of it instead, finally trying out a few things that has been on my mind for a while. I've been wanting to try stratified sampling for a long time as a way to reduce noise in the diffuse light. The idea is to sample the hemisphere within a certain set of fixed strata instead of completely random to give a more uniform distribution. The direction within each stratum is still random, so it would still cover the whole hemisphere and converge to the same result, just in a slightly more predictable way. I won't go into more detail, but full explanation is all over the Internet, for instance here . Let's look at the difference between stratified and uniform sampling. To make a fair comparison there is no lighting in these images, just ambient occlusion and an emissive object.