[HN Gopher] Pixar's notes on Rigid Body Simulation (2001) [pdf]
       ___________________________________________________________________
        
       Pixar's notes on Rigid Body Simulation (2001) [pdf]
        
       Author : cpp_frog
       Score  : 86 points
       Date   : 2022-05-29 14:57 UTC (8 hours ago)
        
 (HTM) web link (graphics.pixar.com)
 (TXT) w3m dump (graphics.pixar.com)
        
       | gabereiser wrote:
       | Pixar is one of those companies I admire. Not just because they
       | make amazing stories, but because they make amazing tech.
       | 
       | A long time debian user, I found renderman to be ridiculously
       | awesome. The scale of which a frame can render across a network
       | of random machines...
       | 
       | Not to mention the graphics problems they have solved and
       | optimized to bring to the entertainment industry. It's like if
       | mathematicians and artists were combined into the head of a
       | hydra.
       | 
       | They have more papers out there.
       | 
       | We take for granted today the problems Pixar and co faced in the
       | 90s. Only now we do it at 300fps.
        
         | djmips wrote:
         | I agree with you and I feel it's remiss to not point out a lot
         | of the groundwork by Baraff was done at Carnegie Mellon
         | University prior to his joining Pixar. I, like many others used
         | his work and papers with Witkin from CMU as the basis of rigid
         | body simulation in the nineties.
        
         | imachine1980_ wrote:
         | i'm feeling that mass production of the last year is making
         | this lees than was before. for example i feel the best looking
         | pixar movie is toystory 4(graphic wise, and coco graphic+art
         | direction), current movies like red, or souls, feel cheaper
         | being a lot less "magic feeling", and look like inside out
         | graphics a movie from 2015(7 years), movies like encanto feel
         | more polished and movies like the spiderverse from 2018 feels
         | more creative and risky.
        
           | pfranz wrote:
           | My wish/dream has been that realistic tech is so mature
           | they're no longer spectacles. I felt "tentpole" movies were
           | getting there before Marvel kicked off. Instead the focus is
           | either on story or stylization. I love that in Turning Red
           | they billowing smoke will dissipate into clumping bubbles and
           | they adopted a lot of anime styles into 3d. Effects like
           | smoke, water, and fire are the easiest to focus on. 2d
           | animation has done a lot of this for decades; Malificent's
           | dragon breath, Genie's smoke, Akira's effects.
           | 
           | I think CG sequels, especially as far apart as Toy Story 1
           | and 4 (24 years!), are a unique thing. It has to be familiar
           | and consistent with previous movies that used older tech, but
           | they can't make a new movie using 24 year old tech, either.
        
       | juanre wrote:
       | The simulation of collisions becomes trickier when tangential
       | compliance cannot be ignored. For example, a ping-pong ball (very
       | high tangential stiffness) rotating around an axis perpendicular
       | to the motion falls straight on a table and bounces back up; the
       | rotational velocity decreases, but it does not change sign.
       | Whereas a superball (low tangential stiffness) will change the
       | direction of the rotational velocity. I did my PhD on this, back
       | in 2000, but haven't kept up with the field.
       | 
       | If anyone is interested in a way to take tangential compliance
       | into account my thesis may be of interest:
       | 
       | https://s3.amazonaws.com/collisions/collision.pdf
        
       | amelius wrote:
       | For a more advanced approach, see [1], [2].
       | 
       | [1] https://ieeexplore.ieee.org/abstract/document/6907751
       | 
       | [2] https://mujoco.org/
        
         | cyber_kinetist wrote:
         | Note that there are multiple approaches to implementing rigid
         | body simulation (especially when it comes to resolving
         | collisions), and each of them all have their benefits and
         | disadvantages.
         | 
         | For example, Mujoco uses a soft contact model where
         | penetrations can happen, this can be undesirable for some use
         | cases but might not really matter for most people. Mujoco also
         | assumes every object in the simulation to be defined beforehand
         | and remain static. This is good for performance (since memory
         | can be preallocated beforehand, some values can be
         | precalculated, etc.) but the drawback is that it's hard to
         | dynamically add/remove/change objects in your simulation. In
         | overall, Mujoco is fine-tuned and intended to be used in
         | robotics simulations, and might have some undesirable
         | properties when used in other applications like games and 3D
         | animation.
         | 
         | Although Baraff's notes for rigid body simulation are more than
         | 20 years ago, it's still roughly the same method used in most
         | game physics engines (PhysX, Havok, Bullet, etc.). It struggles
         | with modelling accurate friction (you can't do that much with
         | LCP constraints), and the contact solver can be unstable at
         | times (especially when CCD comes into the picture), but it's
         | still really performant and "realistic" enough for a wide
         | variety of games and animation.
        
           | saboot wrote:
           | I've been implementing a 2D physics sim myself, I'd take be
           | interested to hear more about different approaches. For
           | example one that can handle the creation of more objects and
           | handles friction accurately.
        
           | Animats wrote:
           | I was doing spring/damper collision ragdolls in the late
           | 1990s.[1] Slower, but more accurate. Friction works. Not real
           | time back then, though. Not enough CPU power yet. You can be
           | too early.
           | 
           | Impulse-constraint systems have a "boink" problem. Velocities
           | change instantaneously. This looks OK for small objects, but
           | bad for large ones.
           | 
           | [1] https://www.youtube.com/watch?v=5lHqEwk7YHs
        
             | erwincoumans wrote:
             | Hi John, I recall that, those ragdolls falling down stairs.
             | From what I heard from a few Pixel employees, Pixar uses
             | Bullet for some rigid body VFX effects, and Bullet still
             | uses velocity-level LCP in combination with maximal
             | coordinate constraints or with Featherstone-style reduced
             | coordinate forward dynamics.
             | 
             | The impulse/velocity-based contact model allows to model
             | arbitrary soft contact (using contact force mixing (CFM)
             | and error reduction parameter (ERP) terms), similar to
             | spring-damper or MuJoCo-style contact (for MuJoCo see
             | https://mujoco.readthedocs.io/en/latest/computation.html
             | and https://github.com/deepmind/mujoco). For the last 10
             | years we use this also for robotics simulation for
             | quadruped robots and robot arm grasping contact. Check out
             | Erin Catto's presentation about re-inventing soft springs
             | in this PDF: https://box2d.org/files/ErinCatto_SoftConstrai
             | nts_GDC2011.pd...
             | 
             | Furthermore, impulse/velocity-level LCP based constraint
             | solving can be combined with finite element method (FEM) or
             | mass-spring based deformable contact solving if higher-
             | accuracy contact and friction modeling is needed.
        
       ___________________________________________________________________
       (page generated 2022-05-29 23:00 UTC)