It’s been a while since we told you anything new about ROBLOX Studio, but it’s a constant work in progress and a focus of our engineering core. In fact, we recently added a senior software engineer to the Studio team, dedicated a web engineer to Studio development, and are seeking to add a couple more positions. Good things are in store for those of you who build and develop using Studio.

Since the launch of Studio 2013 in February, the team has been hard at work making it a more stable and efficient product. Today, we have a much-improved “dragger” tool to preview. This update will drastically improve the speed at which you can move large groups of parts – for example, skyscrapers, houses, castles, etc. – around your ROBLOX worlds.

The dragger tool is what lets you grab a part – or a series of parts or a model – and move it around your ROBLOX place using the click-and-drag method. It’s different from the “move” tool in that you can move parts across the X, Y and Z axes at the same time; it’s intuitive and constantly snaps parts downward on nearby surfaces to keep them on the desired plane. While positioning things precisely using the dragger tool is not its primary purpose, it is very useful for moving parts across vast swaths of space and moving many parts simultaneously. However, moving many parts slows the dragger – all the way to a near halt when you’ve selected hundreds and thousands of parts at a time.

The high-level reason for the lag is the dragger tool moves parts programmatically. We use an algorithm to snap parts down to the nearest surface while they’re being dragged. For every part or group of parts at every mouse location, it checks for a downward collision at increments of 1.2 studs (the width of a standard brick) until it finds a collision, then stops pushing the part(s) downward and finds the correct position in finer detail. This is an expensive process. As you select more parts and move the parts further from the baseplate (or nearest surface), you increase the number of collision check iterations and the dragging becomes slower.

The current method involves checking for collisions for every part (sorted randomly) at every mouse location.

In the last year, we’ve given builders the freedom to create ROBLOX worlds with more parts and grander scale, making it time to fix the dragger. We started by diving into the Studio code and, using timers – embedded tools that allow us to “time” different function calls – discovered the real bottleneck was the number of times the parts were transformed (or moved) for collision checks.

With our current collision check algorithms, parts must be transformed to a location before we check for collisions. In other words, there is a tight coupling between the parts’ location and the collision checking. As fast as collision checks are, the number of iterations required to reach a collision-free location was degrading the performance.

To speed things up, we had to devise a new way of finding a collision-free location without actually transforming the parts — a process that includes the overhead of updating properties and potentially firing signals. We went with a bounding box approach. Think of a bounding box as the rectangular selection box you see when you select a part in Studio.

A general example of a “false” collision, where only the bounding box collides with another part.

With this solution, we transform the bounding box instead of the actual part. When you drag something to your desired location, we first check to see whether the two bounding boxes intersect. This is a “high-level” check that quickly eliminates non-colliding objects. If we do detect a collision, we proceed with more detailed checks. Detailed checks verify whether there are any “false” collisions, which can occur with non-rectangular objects (e.g. wedges, spheres, etc.). Additional detailed checks are then performed using the geometry information of the parts and the calculated CFrame based on the bounding box. All of this can be done without any change in the parts’ location. We save the time required to actually move parts back and forth. It’s pure mathematics.

You still see the actual visualization of the parts, but the full transformation doesn’t occur until we find a collision-free location. In our lab, we saw a roughly 5x improvement in the render framerate while dragging groups of 1,024 parts. You can move a giant castle, a detailed house, or a series of skyscrapers with more precision and speed than ever.

The new method involves checking for collisions first based on parts’ bounding box (represented by the blue rectangle). Once a collision is detected (circle), the dragger proceeds with more detailed checks.

A couple other minor improvements factor into the improved dragger, as well:

• Linear to Binary: The number of iterations to find a collision-free location is also very high because of linear search. This has been changed to use binary search. From O(n), we improved to O(log n).
  
  
• Sorting of selected parts: While moving parts downward, we want the parts at the bottom of the selected group to be checked first. We’ve replaced the random order with a sorted list of parts so we can detect collisions early and can save on further collision checks. Once we find a collision-free location we apply the new location to the selected parts.

You can expect to see this go live in the near future. The dragger isn’t the only Studio feature we’re improving – we’re also working on contextual right-click menus in the 3D view, a Lua debugger, and more. Everything is going toward making it a professional-quality building and game development tool you can use to build anything, and do so efficiently.