Getting frustum points in world-space can be useful in a number of scenarios, such as debug visualisation or building a coarse volume around a partition in your frustum. Each method can be used depending what information you have available to you and what you want to avoid recalculating.
When you develop a solver for the Tammes problem you’re usually concerned with distributing points evenly on the sphere, ensuring they are equidistant from each other. The radius of the circles you place at those points is generally not considered:
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.
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.
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.
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.