http://blog.mmacklin.com/posts/ Recent content in Posts on Miles Macklin Hugo -- gohugo.io en-us © 2019 Miles Macklin Wed, 17 May 2017 00:00:00 +0000 http://blog.mmacklin.com/posts/books/ Wed, 17 May 2017 00:00:00 +0000 http://blog.mmacklin.com/posts/books/ Some people always seem to have the right answer. The kind of people who casually pop up and make a difficult problem seem trivial. These people can be impressive, but the question I am often left with is: "how did you know that?" It is somehow unsatisfying to just be given the answer, I want to know the backstory. More often than not, that backstory is written in books. Blog posts and Twitter threads are great to get exposure to a new problem or subject, but they can also be shallow treatments. http://blog.mmacklin.com/2016/10/12/xpbd-slides-and-stiffness/ Wed, 12 Oct 2016 05:16:03 +0000 http://blog.mmacklin.com/2016/10/12/xpbd-slides-and-stiffness/ The slides for my talk on XPBD are now up on the publications page, or available here. I spoke to someone who had already implemented the method and who was surprised to find they needed to use very small compliance values in the range of 10-6 to get stiffness comparable to regular PBD. The reason for this is that, unlike stiffness in PBD, compliance in XPBD has a direct correspondence to engineering stiffness, i. http://blog.mmacklin.com/2016/09/15/xpbd/ Thu, 15 Sep 2016 00:54:50 +0000 http://blog.mmacklin.com/2016/09/15/xpbd/ Anyone who has worked with Position-Based Dynamics (PBD) in production will know that the constraint stiffness is heavily dependent on the number of iterations performed by the solver. Regardless of how you set the stiffness coefficients, the solver will converge to an infinitely stiff solution given enough iterations. We have a new paper that solves this iteration count and time step dependent stiffness with a very small addition to the original algorithm. http://blog.mmacklin.com/2014/05/15/new-siggraph-paper/ Thu, 15 May 2014 00:28:00 +0000 http://blog.mmacklin.com/2014/05/15/new-siggraph-paper/ Just a quick note to say that the pre-print for our paper on particle physics for real-time applications is now available. Visit the project page for all the downloads, or check out the submission video below: The paper contains most of the practical knowledge and insight about Position-Based Dynamics that I gained while developing Flex. In addition, it introduces a few new features such as implicit friction and smoke simulation. http://blog.mmacklin.com/2013/11/13/flex/ Wed, 13 Nov 2013 03:51:40 +0000 http://blog.mmacklin.com/2013/11/13/flex/ FLEX is the name of the new GPU physics solver I have been working on at NVIDIA. It was announced at the Montreal editor's day a few weeks ago, and today we have released some more information in the form of a video trailer and a Q&A with the PhysX fan site. The solver builds on my Position Based Fluids work, but adds many new features such as granular materials, clothing, pressure constraints, lift + drag model, rigid bodies with plastic deformation, and more. http://blog.mmacklin.com/2013/07/25/siggraph-slides/ Thu, 25 Jul 2013 18:08:59 +0000 http://blog.mmacklin.com/2013/07/25/siggraph-slides/ Slides for my SIGGRAPH presentation of Position Based Fluids are available here: http://mmacklin.com/pbf_slides.pdf During the presentation I showed videos of some more recent results including two-way coupling of fluids with clothing and rigid bodies. They're embedded below: Overall it has been a great SIGGRAPH, I met tons of new people who provided lots of inspiration for new research ideas. Thanks! http://blog.mmacklin.com/2013/06/11/real-time-video-capture-with-ffmpeg/ Tue, 11 Jun 2013 23:46:33 +0000 http://blog.mmacklin.com/2013/06/11/real-time-video-capture-with-ffmpeg/ Working on a distributed team means that often the best way to share new results is via video captures of simulations. Previously I would do this by dumping uncompressed frames from OpenGL to disk, and then compressing with FFmpeg. I prefer this over tools like Fraps because it gives more control over compression quality, and has no watermarking or time limits. The problem with this method is simply that saving uncompressed frames generates a large amount of data that quickly fills up the write cache and slows down the whole system during capture, it also makes FFmpeg disk bound on reads during encoding. http://blog.mmacklin.com/2013/04/24/position-based-fluids/ Wed, 24 Apr 2013 06:33:12 +0000 http://blog.mmacklin.com/2013/04/24/position-based-fluids/ Position Based Fluids (PBF) is the title of our paper that has been accepted for presentation at SIGGRAPH 2013. I've set up a project page where you can download the paper and all the related content here: http://blog.mmacklin.com/publications I have continued working on the technique since the submission, mainly improving the rendering, and adding features like spray and foam (based on the excellent paper from the University of Freiburg: Unified Spray, Foam and Bubbles for Particle-Based Fluids). http://blog.mmacklin.com/2012/06/27/2d-fem/ Wed, 27 Jun 2012 10:40:40 +0000 http://blog.mmacklin.com/2012/06/27/2d-fem/ This post is about generating meshes for finite element simulations. I'll be covering other aspects of FEM based simulation in a later post, until then I recommend checking out Matthias Müller's very good introduction in the SIGGRAPH 2008 Real Time Physics course [1]. After spending the last few weeks reading, implementing and debugging meshing algorithms I have a new-found respect for people in this field. It is amazing how many ways meshes can "go wrong", even the experts have it tough: http://blog.mmacklin.com/2012/05/04/implicitsprings/ Fri, 04 May 2012 11:43:39 +0000 http://blog.mmacklin.com/2012/05/04/implicitsprings/ This is a quick post to document some work I did while writing a mass spring simulation using an implicit integrator. Implicit, or backward Euler integration is well described in David Baraff's Physically Based Modelling SIGGRAPH course and this post assumes some familiarity with it. Springs are a workhorse in physical simulation, once you have unconditionally stable springs you can use them to model just about anything, from rigid bodies to drool and snot. http://blog.mmacklin.com/2012/05/03/new-look/ Thu, 03 May 2012 00:29:09 +0000 http://blog.mmacklin.com/2012/05/03/new-look/ Hi all, welcome to my new site. I've moved to my own hosting and have updated a few things - a new theme and a switch to MathJax for equation rendering. Apologies to RSS readers who will now see only a bunch of Latex code, but it is currently by far the easiest way to put decent looking equations in a web page. It's been a little over a year since I started working at NVIDIA and not coincidentally, since my last blog post. http://blog.mmacklin.com/2010/12/29/blackbody-rendering/ Wed, 29 Dec 2010 08:21:08 +0000 http://blog.mmacklin.com/2010/12/29/blackbody-rendering/ In between bouts of festive over-eating I added support for blackbody emission to my fluid simulator and thought I'd describe what was involved. Briefly, a blackbody is an idealised substance that gives off light when heated. Planck's formula describes the intensity of light per-wavelength with units W·sr-1·m-2·m-1 for a given temperature in Kelvins. Radiance has units W·sr-1·m-2 so we need a way to convert the wavelength dependent power distribution given by Planck's formula to a radiance value in RGB that we can use in our shader / ray-tracer. http://blog.mmacklin.com/2010/11/01/adventures-in-fluid-simulation/ Tue, 02 Nov 2010 01:34:27 +0000 http://blog.mmacklin.com/2010/11/01/adventures-in-fluid-simulation/ I have to admit to being simultaneously fascinated and slightly intimidated by the fluid simulation crowd. I've been watching the videos on Ron Fedkiw's page for years and am still in awe of his results, which sometimes seem little short of magic. Recently I resolved to write my first fluid simulator and purchased a copy of Fluid Simulation for Computer Graphics by Robert Bridson. Like a lot of developers my first exposure to the subject was Jos Stam's stable fluids paper and his more accessible Fluid Dynamics for Games presentation, while the ideas are undeniable great I never came away feeling like I truly understood the concepts or the mathematics behind it. http://blog.mmacklin.com/2010/10/03/tracing/ Sun, 03 Oct 2010 23:37:47 +0000 http://blog.mmacklin.com/2010/10/03/tracing/ Gregory Pakosz reminded me to write a follow up on my path tracing efforts since my last post on the subject. It's good timing because the friendly work-place competition between Tom and me has been in full swing. The great thing about ray tracing is that there are many opportunities for optimisation at all levels of computation. This keeps you "hooked" by constantly offering decent speed increases for relatively little effort. http://blog.mmacklin.com/2010/06/10/faster-fog/ Fri, 11 Jun 2010 03:24:11 +0000 http://blog.mmacklin.com/2010/06/10/faster-fog/ Cedrick at Lucas suggested some nice optimisations for the in-scattering equation I posted last time. I had left off at: \[L_{s} = \frac{\sigma_{s}I}{v}( \tan^{-1}\left(\frac{d+b}{v}\right) - \tan^{-1}\left(\frac{b}{v}\right) )\] But we can remove one of the two inverse trigonometric functions by using the following identity: \[\tan^{-1}x - \tan^{-1}y = \tan^{-1}\frac{x-y}{1+xy}\] Which simplifies the expression for $L_{s}$ to: \[L_{s} = \frac{\sigma_{s}I}{v}( \tan^{-1}\frac{x-y}{1+xy} )\] With $x$ and $y$ being replaced by: \[\begin{array}{lcl} x = \frac{d+b}{v} \\ y = \frac{b}{v}\end{array}\] http://blog.mmacklin.com/2010/05/29/in-scattering-demo/ Sat, 29 May 2010 23:32:07 +0000 http://blog.mmacklin.com/2010/05/29/in-scattering-demo/ This demo shows an analytic solution to the differential in-scattering equation for light in participating media. It's a similar but simplified version of equations found in[1], [2] and as I recently discovered [3]. However I thought showing the derivation might be interesting for some out there, plus it was a good excuse for me to brush up on my \(\LaTeX\). You might notice I also updated the site's theme, unfortunately you need a white background to make wordpress. http://blog.mmacklin.com/2010/05/24/threading-fun/ Tue, 25 May 2010 06:01:41 +0000 http://blog.mmacklin.com/2010/05/24/threading-fun/ So we had an interesting threading bug at work today which I thought I'd write up here as I hadn't seen this specific problem before (note I didn't write this code, I just helped debug it). The set up was a basic single producer single consumer arrangement something like this: #include <Windows.h> #include <cassert> volatile LONG gAvailable = 0; // thread 1 DWORD WINAPI Producer(LPVOID) { while (1) { InterlockedIncrement(&gAvailable); } } // thread 2 DWORD WINAPI Consumer(LPVOID) { while (1) { // pull available work with a limit of 5 items per iteration LONG work = min(gAvailable, 5); // this should never fire. http://blog.mmacklin.com/2010/03/11/gow-iii-shadows/ Fri, 12 Mar 2010 06:09:31 +0000 http://blog.mmacklin.com/2010/03/11/gow-iii-shadows/ I checked out this session at GDC today - I'll try and sum up the main takeaways (at least for me): Artist controlled cascaded shadow maps, each cascade is accumulated into a 'white buffer' (new term coined?) in deferred style passes using standard PCF filtering Shadow accumulation pass re-projects world space position from an FP32 depth buffer (separate from the main depth buffer). The motivation for the separate depth buffer is performance so I assume they store linear depth which means they can reconstruct the world position using just a single multiply-add (saving a reciprocal). http://blog.mmacklin.com/2010/02/07/stochastic-pruning-2/ Sun, 07 Feb 2010 07:39:41 +0000 http://blog.mmacklin.com/2010/02/07/stochastic-pruning-2/ A quick update for anyone who was having problems running my stochastic pruning demo on NVIDIA cards, I've updated the demo with a fix (I had forgotten to disable a vertex array). While I was at it I added some grass: The grass uses stochastic pruning but still generates a lot of geometry, it's just one grass tile flipped around and rendered multiple times. I wanted to see if it would be practical for games to render grass using pure geometry but really you'd need to be much more aggressive with the LOD (Update: apparently the same technique was used in Flower, see comments). http://blog.mmacklin.com/2010/01/12/stochastic-pruning-for-real-time-lod/ Tue, 12 Jan 2010 07:28:31 +0000 http://blog.mmacklin.com/2010/01/12/stochastic-pruning-for-real-time-lod/ Rendering plants efficiently has always been a challenge in computer graphics, a relatively new technique to address this is Pixar's stochastic pruning algorithm. Originally developed for rendering the desert scenes in Cars, Weta also claim to have used the same technique on Avatar. Although designed with offline rendering in mind it maps very naturally to the GPU and real-time rendering. The basic algorithm is this: Build your mesh of N elements (in the case of a tree the elements would be leaves, usually represented by quads) http://blog.mmacklin.com/2009/12/31/sky/ Thu, 31 Dec 2009 22:46:48 +0000 http://blog.mmacklin.com/2009/12/31/sky/ I had been meaning to implement Preetham's analytic sky model ever since I first came across it years ago. Well I finally got around to it and was pleased to find it's one of those few papers that gives you pretty much everything you need to put together an implementation (although with over 50 unique constants you need to be careful with your typing). I integrated it into my path tracer which made for some nice images: http://blog.mmacklin.com/2009/12/02/path-tracing/ Thu, 03 Dec 2009 06:59:48 +0000 http://blog.mmacklin.com/2009/12/02/path-tracing/ A few of us at work have been having a friendly path-tracing competition (greets to Tom & Dom). It's been a lot of fun and comparing images in the office each Monday morning is a great motivation to get features in and renders out. I thought I'd write a post about it to record my progress and gather links to some reference material. Here's a list of features I've implemented so far and some pics below: http://blog.mmacklin.com/2009/09/28/trees-the-green-kind/ Mon, 28 Sep 2009 17:13:26 +0000 http://blog.mmacklin.com/2009/09/28/trees-the-green-kind/ I've always had an interest in computer generated plants so I was pleased to read Self-organising tree models for image synthesis from Siggraph this year. The paper basically pulls together a bunch of techniques that have been around for a while and uses them to generate some really good looking tree models. Seeing as I've had a bit of time on my hands between Batman and before I start at LucasArts I decided to put together an implementation in OpenGL (being a games programmer I want realtime feedback). http://blog.mmacklin.com/2009/08/19/atomic-float/ Wed, 19 Aug 2009 12:50:56 +0000 http://blog.mmacklin.com/2009/08/19/atomic-float/ No hardware I know of has atomic floating point operations but here's a handy little code snippet from Matt Pharr over on the PBRT mailing list which emulates the same functionality using an atomic compare and swap: inline float AtomicAdd(volatile float *val, float delta) { union bits { float f; int32_t i; }; bits oldVal, newVal; do { oldVal.f = *val; newVal.f = oldVal.f + delta; } while (AtomicCompareAndSwap(*((AtomicInt32 *)val), newVal. http://blog.mmacklin.com/2009/08/14/fin/ Fri, 14 Aug 2009 12:49:11 +0000 http://blog.mmacklin.com/2009/08/14/fin/ Batman: Arkham Asylum is finished and the demo is up on PSN and Xbox Live. I was pretty much responsible for the PS3 version on the engineering side so anything wrong with it is ultimately my fault. I think most PS3 engineers working on a cross platform title will tell you that there is always some apprehension of the 'side by side comparisons' which are so popular these days. This one popped up pretty quickly after the demo was released: http://blog.mmacklin.com/2009/08/14/tim-sweeneys-hpg-talk/ Fri, 14 Aug 2009 12:14:37 +0000 http://blog.mmacklin.com/2009/08/14/tim-sweeneys-hpg-talk/ This link was going round our office, a discussion over at Lambda the Ultimate regarding Tim Sweeney's HPG talk. http://lambda-the-ultimate.org/node/3560 Tim chimes in a bit further down in the comments. http://blog.mmacklin.com/2009/07/24/handy-hints-for-bovine-occlusion/ Fri, 24 Jul 2009 10:42:55 +0000 http://blog.mmacklin.com/2009/07/24/handy-hints-for-bovine-occlusion/ Code517E recently reminded me of a site I've used before when looking up form factors for various geometric configurations. One I had missed the first time though is the differential element on ceiling, floor or wall to cow. http://www.me.utexas.edu/~howell/sectionb/B-68.html Very handy if you're writing a farmyard simulator I'm sure. http://blog.mmacklin.com/2009/06/15/particle-lighting/ Mon, 15 Jun 2009 22:39:50 +0000 http://blog.mmacklin.com/2009/06/15/particle-lighting/ I put together an implementation of the particle shadowing technique NVIDIA showed off a while ago. My original intention was to do a survey of particle lighting techniques, in the end I just tried out two different methods that I thought sounded promising. The first was the one ATI used in the Ruby White Out demo, the best take away from it is that they write out the min distance, max distance and density in one pass. http://blog.mmacklin.com/2009/04/01/code-charity/ Wed, 01 Apr 2009 23:11:17 +0000 http://blog.mmacklin.com/2009/04/01/code-charity/ A friend just sent me this: http://playpower.org/ It's a non-profit organisation with the goal of developing educational games for developing countries that run on 8bit NES hardware. The old Nintedo chips are now patent-free and clones are very common: They're trying to recruit programmers with a social conscience, I'm not old-school enough to know 8bit assembly but then I wouldn't mind learning.. who needs GPUs anyway! http://blog.mmacklin.com/2009/04/01/red-balls/ Wed, 01 Apr 2009 23:00:13 +0000 http://blog.mmacklin.com/2009/04/01/red-balls/ A small update on my global illumination renderer, I've ported the radiance transfer to the GPU. It was fairly straight forward as my CPU tree structure was already set up for easy GPU traversal, basically just a matter of converting array offsets into texture coordinates and packing into an indices texture. The hardest part is of course wrangling OpenGL to do what you want and give you a proper error message. http://blog.mmacklin.com/2009/02/22/tree-traversals/ Sun, 22 Feb 2009 21:37:27 +0000 http://blog.mmacklin.com/2009/02/22/tree-traversals/ I changed my surfel renderer over to use a pre-order traversal layout for the nodes, this generally gives better cache utilisation and I did see a small speed up from using it. The layout is quite nice because to traverse your tree you just linearly iterate over your array and whenever you find a subtree you want to skip you just increment your node pointer by the size of that subtree (which is precomputed, see Real Time Collision Detection 6. http://blog.mmacklin.com/2009/02/22/pbrt/ Sun, 22 Feb 2009 20:25:55 +0000 http://blog.mmacklin.com/2009/02/22/pbrt/ I just bought a copy of Physically Based Rendering, I've been meaning to get one for ages as it's often recommended and I thought it might be useful given my recent interest in global illumination. I'm also hoping to get a more formal background in rendering rather than the hacktastic world of real time. The subjects covered are broad and it's very readable. It's my first exposure to literate programming, where essentially the book describes and contains the full implementation of a program. http://blog.mmacklin.com/2009/01/21/almost-realtime-gi/ Wed, 21 Jan 2009 23:40:01 +0000 http://blog.mmacklin.com/2009/01/21/almost-realtime-gi/ After my initial implementation of surfel based illumination I've extended it to do hierarchical clustering of surfels based on a similar idea to the one presented in GPU Gems 2. A few differences: I'm using a k-means clustering to build the approximation hierarchy bottom up. A couple of iterations of Lloyd's algorithm provides pretty good results. Really you could get away with one iteration. To seed the clustering I'm simply selecting every n'th surfel from the source input. http://blog.mmacklin.com/2009/01/11/indirect-illumination/ Sun, 11 Jan 2009 23:44:57 +0000 http://blog.mmacklin.com/2009/01/11/indirect-illumination/ It's been a while since I checked in on the state of the art in global illumination but there is some seriously cool research happening at the moment. I liked the basic idea Dreamworks used on Shrek2 (An Approximate Global Illumination System for Computer Generated Films) which stores direct illumination in light maps and then runs a final gather pass on that to calculate one bounce of indirect. It might be possible to adapt this to real-time if you could pre-compute and store the sample coordinates for each point. http://blog.mmacklin.com/2009/01/09/branch-free-clamp/ Fri, 09 Jan 2009 23:03:37 +0000 http://blog.mmacklin.com/2009/01/09/branch-free-clamp/ One of my work mates had some code with a lot of floating point clamps in it the other day so I wrote this little branch free version using the PS3's floating point select intrinsic: float Clamp(float x, float lower, float upper) { float t = __fsels(x-lower, x, lower); return __fsels(t-upper, upper, t); } __fsels basically does this: float __fsels(float x, float a, float b) { return (x = 0. http://blog.mmacklin.com/2009/01/09/two-threads-one-cache-line/ Fri, 09 Jan 2009 22:20:30 +0000 http://blog.mmacklin.com/2009/01/09/two-threads-one-cache-line/ An interesting thread going around the GDA mailing list at the moment about multithreaded programming reminded me of a little test app I wrote a while back to measure the cost of two threads accessing memory on the same cache line. The program basically creates two threads which increment a variable a large number of times measuring the time it takes to complete with different distances between the write addresses. Something like this: http://blog.mmacklin.com/2008/12/28/more-metaballs/ Sun, 28 Dec 2008 16:46:09 +0000 http://blog.mmacklin.com/2008/12/28/more-metaballs/ So after running my Metaballs demo on my girlfriends laptop it appears to be GPU limited due to fillrate. This is mainly due to the overkill number of particles in my test setup and the fact they hang round for so long, but the technique is fillrate heavy so it might be a problem. It'd be nice to do a multithreaded CPU implementation to see how that compares, but the advantage of the current method is that it keeps the CPU free to do other things. http://blog.mmacklin.com/2008/12/20/gpu-metaballs/ Sat, 20 Dec 2008 14:10:56 +0000 http://blog.mmacklin.com/2008/12/20/gpu-metaballs/ I've been meaning to implement this idea for ages, it's a GPU implementation of 2D metaballs. It's very simple, very fast and doesn't even require hardware shader support. Seems like the kind of effect that could be useful in some little game.. It's quite fun to play with (use left drag to rotate the emitter), so I might try and fancy it up with some better graphics and collision. The demo is below, I'll probably release source at some stage but at the moment it's all tied up in my dev framework which needs to be cleaned up (the exe is also larger than it should be as I have all sorts of crap linked in). http://blog.mmacklin.com/2008/11/03/sprite-mipmaps/ Mon, 03 Nov 2008 22:31:35 +0000 http://blog.mmacklin.com/2008/11/03/sprite-mipmaps/ Information on how to correctly make sprite textures is just not on the web anywhere. There are so many subtle problems with making transparent textures for use in a 3D engine, here are some of the things I learned recently from my hobby project: Generally the easiest way is to paint on a transparent background, that is, don't try and paint the alpha channel yourself. That's because it's a complete nightmare trying to match up your rgb and alpha channels correctly. http://blog.mmacklin.com/2008/09/06/iphone-gl-specs/ Sat, 06 Sep 2008 12:23:52 +0000 http://blog.mmacklin.com/2008/09/06/iphone-gl-specs/ So I've been trying to find out a bit more about the iPhone's capabilities, this site has some good details. No shaders, roughly enough power for 15000 lit triangles @ 30hz. Not too shabby, I wonder about the power consumption and if certain hardware paths drain the battery faster than others. It would be nice to make something that people can play for more than 3 hours. So the word on the street is that O2 are bringing out a pre-pay iPhone in December, I'm currently debating whether to wait for that or just get an iPod touch which you can still develop for using pretty much the same feature set. http://blog.mmacklin.com/2008/07/18/parallelisation-and-cups-of-tea/ Fri, 18 Jul 2008 08:51:54 +0000 http://blog.mmacklin.com/2008/07/18/parallelisation-and-cups-of-tea/ While I was at Sony I spent a lot of time thinking about making tasks run concurrently and how they should be scheduled to maximise performance. Recently this kind of analysis has been spilling over into my everyday life and you start seeing ways you could parallelise all sorts of tasks. Of course this is just common sense and something we all do naturally do different degrees. A simple example is making a cup of tea, you don't want to get the tea bags and the cups first, no, that would be a waste of precious milliseconds. http://blog.mmacklin.com/2008/07/17/5/ Thu, 17 Jul 2008 23:25:31 +0000 http://blog.mmacklin.com/2008/07/17/5/ So I took a new job today, working for Rocksteady in London. Quite exciting, they use Unreal3 tech which I've always respected (and stolen ideas from). It's a big game title and technically I don't know what it is.. but it's a big franchise and should do well. Plus working with friends in Kentish Town, s'all good.