Blockland Physics

I spent some of my downtime over the past few months working on client-side brick physics for Blockland. The feature has finally been announced, so I can talk about it. The video shows off most of the features; the main one that isn’t shown is the interaction between players/vehicles and bricks; they will push bricks around but aren’t affected themselves. Watch it in full screen, it’s full 720p HD video.

There were two big problems related to doing physics for Blockland. The first was the scale of the problem – there can be well over 100,000 bricks in a single server, which is beyond the capabilities of most physics SDKs to simulate as discrete objects. I started with PhysX, and moved to Bullet after realizing that the PhysX runtime is 80mb, far more than could be included in the Blockland download (which weighs in at 20 mb). Both of these libraries broke in different ways with large numbers of objects.

At first, I implemented a management system for brick proxies, so that it kept them under the hard limit in the SDK (around 2**16). PhysX accepted this, but Bullet’s broadphase has some stuff that’s O(# objects) or worse, so it fell down. Eventually, I moved everything into the same system used for static world geometry, which was a grid of static meshes. It turns out that Bullet is a bit faster at creating these mesh objects than PhysX was.

The static mesh cache took quite a bit work to get solid. Because the simulation is for aesthetic purposes, it can tolerate a fair amount of “fudge,” which I take full advantage of. Nearly every kind of update is timesliced so that only a little bit is done each tick. This keeps things smooth, even at the cost of the physical state being inconsistent for a tick or two. Most updates are lazy, as well, only done if a dynamically moving brick, player, or vehicle comes into the area.

The other problem is the wide variability of Blockland user’s computers and usage patterns. Not every user has enough CPU to run physics. And every user has the potential to build something that is very resource intensive to simulate. I spent a lot of time implementing a “physics diaper” – logic to detect when physics calculations were taking too much time, and scaling back the simulation until it’s fast again. This takes two forms. First, if physics ticks are too slow, the simulation is decimated – every other brick on the list of moving bricks is converted to a lighter weight parametric simulation that doesn’t consider collisions. If they remain too slow, then eventually the physics simulation is disabled entirely, until the user turns it back on. This can help with very complex builds or very slow computers.

Thanks to good physics middleware (I include both PhysX and Bullet under the “good” category, even though PhysX is a little on the bloated side), I was able to solve a pretty tough problem – simulating motion for hundreds of thousands of bricks on commodity hardware – in short order. And I have to thank my friend Eric for making such an awesome sandbox and letting me play in it. 🙂

Author: Ben Garney

See https://bengarney.com/ and @bengarney for details.

31 thoughts on “Blockland Physics”

  21. We ended up having such focused and strange usage of the physics APIs it tended to be easier to simply abstract the code cleanly and write directly to our target API. We started with PhysX and switch to Bullet, which took a few days, but had good performance. I am worried that PAL will introduce slowdowns in things that are not normally a concern but are for us, like runtime trimesh shape generation.

  22. did you try looking at the Physics engine Abstraction Layer before beginning your adventures? i use it to try out my proof of concept stuff and settle on the physics engine I want to use in my final product, it comes in really handy for benchmarking performance etc.

  24. Here's a sudgestion, you could have a checkmark after the fakekill event output that would enable that individual brick to sync with the server and clients, that way users could have control over the few bricks that are part of their “contraptions” and the normal wreckage system would remain clientside.

  26. Good question, Gilbert. It's purely client side, so they're similar but not guaranteed to be the same. If you knew your users had more bandwidth and compute power you could probably get it synch'ed up, but it would be hard, especially when you're looking at events where you might be transitioning hundreds or thousands of bricks to physics mode.Source has some nice physics capabilities, but see http://developer.valvesoftware.com/wiki/Physics… – they have to make the same hacks for their games, which involve a lot fewer physical objects than your typical Blockland scene.

  27. Touche. I have another question though: would all the clients, who have fast enough PCs to render the collision detection, see the same event, or would they each see it slightly differently?

  28. Yes, it is a purely client side effect. Though I wouldn't go so far as to say that true physics are impossible – I think if you enforced high-end hardware and fast connections, you could get pretty close.

  29. So true physics are indeed not possible, as true physics would be able to effect the environment as much as the environment would effect them, and such a system isn't possible client-side, server-side with 100,000 objects, or with just the brick vectors themselves. Basically what you have here is a glorified, though certainly quite impressive, fireworks show.

Comments are closed.

%d bloggers like this: