I posted an article a while back, entitled Very Fast, High-Precision SIMD/GPU Gradient Noise, where I outlined a technique for achieving double-resolution noise at speeds close to that when using float arithmetic. The key observation was that floor could be used on cell boundaries to mask off the ranges that require double arithmetic, allowing the bulk of the work to use float arithmetic. The GPU code was initially written in OpenCL and then ported to CUDA using ComputeBridge.

And we are back! It must be a year now since my old site donw.org went dark for many reasons, including being busy working on my own game. There’s some big changes with this new setup: I own the domain donw.io this time round. I’ve gone through a bunch of domains – donw.org, donw.co.uk, etc. – that I used to pay somebody else to manage for me. That was obviously not the right way of going about this as I no longer own them.

This is a small test post exercising math notation with MathJax in Hugo. Epic use the following equation for a spherical light source [1]: $$\mathbf{C} = (\mathbf{L} \cdot \mathbf{r})\mathbf{r} - \mathbf{L}$$ $$\mathbf{P} = \mathbf{L} + \langle \frac{sourceRadius}{ | \mathbf{C} | } \rangle \mathbf{C}$$ where the point with the smallest distance to the reflected ray is then $∥\mathbf{P}∥$. Implicit in this equation is that $\mathbf{L}$ is unnormalised. With a Sun/Earth distance of 149,600,000km and Sun radius of 695,800km these calculations are not really going to work in limited precision shaders.

A recently published article by Inigo Quilez on Voronoi Edges highlights the technique of shifting the co-ordinate frame of procedural algorithms to improve precision. This is a really important little trick that I felt was worth reviewing, as it provides huge benefits to world generation at a planetary scale. The GPGPU crowd have used similar techniques for a while, dubbed Mixed Precision Methods and the first reference I can find to using relative values for “Infinite noise” is in Pixar’s paper on Wavelet Noise.

This is a bit of a fun post highlighting how some simple maths can be used to create great visual results. With some basic statistics, we can create looping skeletal animations from an input data set that contains non-exact loops. A typical example is a motion capture sampled run animation: This is derived from the CMU Graphics Lab Motion Capture Database, which has been converted to BVH files by Bruce Hahne.

For some reason I like quaternions. I fell in love with complex numbers back in school when I found out that they made more sense than real numbers. While it might not exactly be helpful to visualise quaternions as an extension of complex numbers, there’s something in there that just grabs at me. Unlike previous posts, I’ve managed to update to D3D11 so I’ll be discussing implementation details in terms of HLSL (Shader Model 4, as I also have a D3D10 dev machine).

The first part in this series on Reflection in C++ gave a high level overview of many of the possibilities open to you when adding reflection to your games. In this second part I’m going to go into details and cover the system used to aid the rendering engine in Splinter Cell: Conviction (SC5). The motivation for the development of the SC5 engine was a clean break from the past. We were working with a very, very large code base that used Unreal 2.5 with many years of modifications and rewrites.

If there was one job I’d love to do other than writing games it’d be writing compilers. This probably explains my obsession with the subject of reflection; a topic I’ve been hammering away at for almost 10 years now. Having written a few compilers in the past, it became glaringly obvious to me that reflection would be quite simple to add to C++ – if you’re willing to place some limits on it – and that the language has suffered from its absence.