With our recent release of featherweight parts we drastically lightened the load, so to speak, of objects in the ROBLOX graphics pipeline. In an effort to continue down this path, we’re developing a system that can switch between featherweight and non-featherweight parts on the fly, in real time. We like to keep things simple around here, so we’ve elected to call them fast parts.
Why would you want to be able to switch? What are the benefits? What type of hardware will be able to handle these new parts? These and many other questions will be answered in this article. Let’s brush over the basics first.
The Basics
Let’s say you construct a building in ROBLOX. The building itself is composed of static (non-moving), featherweight parts. All of the parts are anchored. It’s not meant to move–by virtue a building doesn’t go mobile (we don’t remember the last time a building stood up and walked around the corner, and if we did remember something like that, you better believe we would’ve blogged about it already). The building is grounded and stationary.
Here’s where it gets a little more trickier. Say you launch a rocket at the building, destroying the joints. The building collapses into the thousands of blocks that made it. This simply can’t be done with featherweight parts, because featherweight parts can’t move. There needs to be a transitional period where the parts individually falling to the floor are given more computational wiggle room. When a building collapses virtually, all the parts that made it begin to move, change position and fall. That takes a lot more computing power. And that’s where our fast parts come in.
The Process
With fast parts, we can batch up to 80 moving objects, which is the hard limit amount that we can pass per batch using vertex shading (more on this later). Each batch is grouped by its objects’ proximity to the player, and their textures. When you fire a rocket at a building, every featherweight item that constructed the building will change instantaneously to fast parts in order to fall and crumble realistically. As soon as the building is reduced to a pile of rubble, and no more movement is involved, the parts in the rubble will return to being featherweight parts.
This is all in an effort to make every part on ROBLOX a featherweight part, or share performance characteristics at the very least. Since we’ve made all static objects featherweight, now it’s time to focus on moving parts. So let’s look at our example of a collapsing building. When a building begins to crumble and fall, a lot of things are going on behind the scenes. A conversation is started with the graphics card in your computer. Each section of the crumbling building is spread into a different batch–each batch focusing on the movement of the collapsing blocks. The position of the blocks is going to change as they fall because of physics. Rendering many moving parts individually would not be efficient, as they’d be in a different physical space every frame.
Our solution allows us to group these parts together into batches–each of which can carry a maximum of 80 parts. And thanks to dynamic shaders, each of the individual parts within a batch can move independently from one another. This allows us to keep moving parts running at a consistent frame rate that doesn’t overload your system. The trick we’re implementing will be very subtle, which is precisely the point. We want featherweight parts to become fast parts (and vice versa) with no visual cues of any kind, ultimately creating an environment where both types of parts–featherweight for static objects and fast parts for moving objects–are seamlessly integrated.
The Vertex Shader Solution
Our fast parts will utilize vertex shaders on your computers’ graphics processing unit (GPU) to ensure that multiple parts in a single geometry buffer can be transformed independently. Vertex shading is a special GPU feature that allows you to customize the way triangles are transformed in games. This is particularly of use for us–everything in ROBLOX, including parts, are drawn using triangles. With our fast parts, they help us create realistic batch block movements (like falling blocks from a destroyed building). Let’s go back to our collapsing building example to explain this solution.
You’ve fired a rocket at the building. Chaos. Blocks everywhere. The blocks have now turned into fast parts, and each one is grouped in a batch. Without Vertex Shading, we would have to instruct each batch which way to fall in uniform (which would be totally unrealistic behavior). With vertex shading, we can take each block within any given batch and tell it to behave differently. That way, every crumbling block has its own behavior. We can tell each block within a batch to fall at a different angle, at a different speed, creating a much more realistic depiction of a collapsing building.
The Numbers
We tested this feature to figure out how much it affects overall gameplay. We agreed that our test machine was relatively “middle-of-the-road”– our rig featured a dated Intel i3-2100 processor with an integrated Intel HD Graphics chip. Hardly state of the art.
In our test, we opted to blow up a structure made up of 9,000 parts. Before, doing so would slow ROBLOX down to about 4-5 frames per second. With our new fast parts, our frame rate jumped five times that amount, hovering between 20-25 frames per second while parts were in motion.
The Release
We’ve just turned on our fast parts in default mode, and we estimate that 80%-85% of our PC users (and about 90% of our Mac users) have the GPU capabilities to benefit from them. We’ll be releasing this to be accessible from all machines soon.