New CSG system in Studio: try it out, tell us what you think

Hi all,

We’ve been busy working on a replacement CSG system for Roblox, and it’s starting to look good enough for testing by a wider audience. The intention of this post is to to get more people try the new CSG system out, to get a better understanding of what issues remain.

The geometry generated by the new system can never be exactly the same as that of the old one, due to large differences in how the numerical issues are dealt with, so

Remember to back up your .rbxl files before opening them with the new CSG system!!

To enable the new CSG system in Studio, you need to go to “Settings” under the FILE menu, select the “Physics” tab and scroll all the way down to find the “UseCSGv2” setting. If the box is checked, Studio will use the new CSG system instead of the old one (no need to restart for this particular setting). You’ll find pictures of the relevant menus below.

There are a number of issues we are aware of, fixes for which are in the pipeline but not released yet, namely

  • Separating scaled CSG objects results in miscalculated offsets in the constituent parts
  • Decals on CSG objects have incorrect offsets
  • Texture mapping is applied in world space instead of local space
  • A special mesh with scale set to 0 on one or more dimensions results in error -3.
  • Trying to CSG objects further than 2048 studs away from origin causes an error

The known problems listed above will be addressed in the near future, however if you encounter any other problems, especially error messages with a code (-3, -4, -21) please report them by replying to this thread and attach a file with a repro case.

Thank you in advance!

44 PM
39 PM


Is this available on macOS?


I mean, the screenshots were taken on an Apple product, so I’d only assume so.


Yes, this is available on both macOS and Windows.


Hasn’t this been here for months? I’ve had it on since July/August


Correct, it has been around for a while, and we are aware that several people have been using it for a while. This post is mostly to get a wider audience, and to have a place for defect reports.


Ah alright :stuck_out_tongue:

1 Like

While I don’t really use unions at all anymore, I was able to test awhile back and noticed that spheres caused a noticeable amount of polys made compared to what was needed. Has this been fixed?

There have been significant improvements in polygon count since earlier this summer, and there are more improvements coming on that front.

The sphere primitive itself remains more complicated than it needs to be, which is something to be addressed, but the polygon count on unions is better than it used to.



Funny you should mention this. I’ve been working on a small project that imports maps from Half-Life 2 using the new CSG engine.

Half-Life 2 uses the Source Engine, which uses the VMF file format.

Map geometry in Source is defined by the intersections of planes in a group.

  • Where 2 planes intersect, it forms an edge.
  • Where 3 planes intersect, it forms a vertex.

Visual example:

I’m a little incompetent when it comes to math like this, so I decided to do some workarounds using Roblox’s CSG engine. I generate a rough bounding box of the solid using the points defined by the planes, then I compute the directional vector of the plane using (B-A):Cross(C-A).Unit. Finally, I create a negative part that is capable of slicing out everything that is in front of the plane, and I repeat that for all of the defined planes.

The end result looks a bit like this:

This project pushes the new CSG engine to the ultimate test of 100% reliability, and so far I’d give it a 99.9% on that reliability scale. It’s rare, but I do periodically get the -7 error and some inconsistent crashes.

In this video where I show off the map being imported in real time, you’ll notice that Roblox crashes at the very end before it can complete everything:

I’m not sure what exactly is triggering this crash at the moment, but I can provide some crash dump files if that would be of any help.

(Here is the plugin itself:


you’re too good, oh my god.


So long as I don’t get spammed with errors that shouldn’t be errors, I’m alright with any kind of CSG engine.


CSGv2 doesn’t seem to be handling spheres right. I made two spheres flush with a cylinder. In CSGv1, the resulting union is also flush (left), but in CSGv2 the spheres seem to expand a little (right):

CSGv2 Bug.rbxm (193.4 KB)


Thanks for reporting.

This is a known issue with the current geometry generators in CSGv2, and will be addressed in the near term.


This union gives error 21 when i try to seperate it: UnionBug.rbxmx (20.6 KB)

It was unioned a long while ago with the first csg system

1 Like

Another problem i noticed is that sometimes when you have a negative part with exact matching edges of another part and union, it will create some sort of 2D panels


Creates this:

Combination used: CSGCombination.rbxmx (11.1 KB)

This creates some unexpected behaviour because CSGv1 doesn’t do this which means that if i unioned this combination with CSGv1 (which doesn’t create the 2D panels and it’ll just look like a shorter part), and then union another part to this combination with CSGv2 the 2D panels will appear when they weren’t there before. Example: Old Union with another part.rbxmx (12.8 KB)


I believe that, with CSGV2, parts are shifted slightly in order to properly solve the union. This is why you don’t get the “failed to solve” error all the time–it’s doing the trial and error for you, at the cost of accuracy.


I feel like this is the case, with that one and with the sphere and cylinder case where the size of the spheres is changed to make it work. Hopefully this will be improved.


The reason for this is that CSGv2 evaluates the result exactly, whereas the old system tried to merge things that were close to each other. We are hesitant to come up with ad hoc solutions like merging nearby things to address this, because heuristic approaches in computational geometry always fail.

Technically, the 2D slivers you see here are very thin volumes, and they result from teeny tiny offsets arising from rounding errors in the Studio transformation tools.

We’ll work on resolving this issue in the future, but we haven’t currently decided which path to take.