[HN Gopher] Simulation Islands
___________________________________________________________________
Simulation Islands
Author : AshleysBrain
Score : 235 points
Date : 2023-10-10 07:55 UTC (15 hours ago)
(HTM) web link (box2d.org)
(TXT) w3m dump (box2d.org)
| ghusbands wrote:
| Why are the boxes always made of jelly in these physics
| simulations? Stacks/walls of boxes in real life are never that
| jiggly.
| flohofwoe wrote:
| Sometimes it's just wrong parameters (e.g. too low density, too
| low gravity, ...), but the 'jelly-like' behaviour may also help
| to keep the simulation stable (sometimes in games you can see
| the physics simulation explode, e.g. stuff being catapulted
| with near-infinite speed into space, putting some dampening
| into the simulation and allowing some 'slack' for resolving
| object intersections can help to avoid that, but also makes
| everything feel more jelly-like).
| meheleventyone wrote:
| It's due to using a Gauss-Seidel solver which iteratively
| solves each constraint rather than a global solver that solves
| all the constraints at once. The reason to use the iterative
| approach is that global solvers can end up with unbounded
| runtime or without a solution in some cases. The downside is
| that some constraints are left unsatisfied after you've run
| through your fixed set of iterations so it takes time to
| converge. With big stacks you have a lot of constraints and it
| can take even more time to converge as errors propagate energy
| through the stack. You can solve this as a sub-problem by
| itself and maybe the 'large islands' work will tackle that.
|
| TLDR; with iterative methods stiffness of things depends on the
| physics timestep size and number of iterations of constraint
| solving.
| loa_in_ wrote:
| Software engineering at it's best. And surprisingly nicely
| written up.
|
| One of my favourite reads! Would read again.
| foota wrote:
| This left me wondering if there might be a deterministic parallel
| algorithm for union find :)
|
| I did find this arxiv paper from April which claims to have one:
| https://arxiv.org/abs/2304.09331
|
| My understanding is that they process batches of edges at a time.
| If they "conflict" (meaning they want to do different things to
| the data structure) then they're processed in serial, otherwise
| all edges in the batch are handled sequentially. They provide a
| bound on how often edges should conflict, and use that to show
| the complexity.
| foota wrote:
| ...ok change sequentially to in parallel, I was sleepy when I
| wrote this.
| faldore wrote:
| It's lovely to see active development on Box2D. Thank you for
| your efforts.
| picadores wrote:
| Aka causality limitations through propagationspeed -aka
| lightspeed.
| SeanAnderson wrote:
| :) This was the same conclusion I came to when I first started
| researching this in video game design. No idea if there's
| _actual_ merit to it, but the parallels are uncanny to be sure.
| hesdeadjim wrote:
| Given how widespread the usage of Box2D has been over the last
| decade+, I truly hope the creator has seen some form of financial
| benefit from it. His work is awesome and has benefitted the
| gamedev community immensely.
|
| He mentions Jolt physics in this blog. That's another example of
| "holy shit look at what one person can do". I've found myself
| wishing I had Unity source so I could performantly inject that
| engine instead of being stuck with PhysX.
| hypertexthero wrote:
| Jolt physics is an amazing piece of work way above my level of
| understanding, but as someone who loves physics in video games
| I always enjoy learning a bit about how it all works:
|
| https://github.com/jrouwe/JoltPhysics
|
| http://jrouwe.nl/architectingjolt/ArchitectingJoltPhysics_Ro...
|
| http://jrouwe.nl/architectingjolt/
| mortallywounded wrote:
| I haven't seen or heard of box2d in years.... awesome to see
| again :)
___________________________________________________________________
(page generated 2023-10-10 23:01 UTC)