New CSG system will be made default in Studio

The time has come. We’ll switch the new system on by default tomorrow morning (thursday, PST). If everything goes well, we’ll keep it on, but if there are too many problems to bear, we’ll turn it back off, fix it and then repeat…

Work is still ongoing on a number of cosmetic issues, but since the geometry generated by the new system won’t ever be exactly the same as that of the old one, no amount of work can make the switch completely seamless.

We apologize in advance for any inconvenience this will cause, but we think the upside of generally reliable operation already outweighs the backwards compatibility issues that remain.

The new system can still be explicitly disabled in Studio for a transition period. To use the old system after the new one has been made default, you need to go to “Settings” under the FILE menu, select the “Physics” tab and scroll all the way down to find the “DisableCSGv2” setting. If the box is checked, Studio will use the old CSG system. There is no need to restart Studio for this setting to take effect, even if it tells you otherwise.

44 PM
17 PM

Please report problems below.


mm mmmmmm i love me some spicy new updates

But really dang, already moving into the new CSG system that quickly. Amazing :heart:


Woop woop!

1 Like

More updates. :ok_hand:

Hyped for the new CSG System. :thumbsup:

I have been testing the new system for a while now and something I noticed was that negations on parts no longer have the color of the negative parts which were used. (I can’t show any screenshots because I am on mobile right now, but basically, if you had, say, a yellow brick, negated it and unioned it with a white brick, the negated part of the brick would be yellow - which doesnt happen anymore).

It’s still amazing though, keep up the good work! :heart:


You’re planning on fixing this issue before the switch, correct?
Here’s a very common shape made of 2 parts, a rounded cylinder (sphere and cylinder):

with the old csg system, if you tried to union this it would look the same as the picture, but with the new system it still looks like this even in the newest version of studio:


Here’s a repro: repro.rbxl (12.7 KB)

UsePartColor is not enabled. Expected behavior is that the red part is grey where the grey part was cut out of the red part.


correct, fix for this issue is coming


Yeah, this is a real difference. The colors in CSGv2 currently behave in a volumetric fashion, so when you subtract, the colors reflect what was inside the volumes of the “positive” parts. We’ll need to support both in the future, but more work is needed on this front.


Begone, ERRORS!



Is this the right thread to report issues/bugs with CSGv2 or should I go to Bug Reports instead?

New csg system. :heart_eyes:

Reporting bugs/issues in this thread is ok. We’ll also find them in bug reports, of course, but it may be easier to avoid duplicates on a single thread.

Okay so someone had issues with his union not being smooth on the edges. After disabling CSGv2, the union’s bevelling worked properly.

Image below shows a beveled union on CSGv1:

Image below shows the exact same union on CSGv2 enabled:

Is it a bug or was the “smoothing angle” decreased?

1 Like

No smoothing is currently applied, which is of course why the above is happening.
There are a few other known issues and glitches when computing surface normals, for which smoothing is a reasonable remedy, so we should be able to address this soon.

1 Like

I’m unioning some of my triangle terrain and the new CSG causes unnecessary faces.

New(left): 1438 triangles

Old(right): 150 triangles

This makes unioning larger portions of my map impossible when it was very possible(and surprisingly reliable) before.

CSG Comparison.rbxl (32.0 KB)


May be off-topic, but are those “terrains” one union on each side of the image?

(I’m unable to check the file)

Yes, both sides are one single union.

It seems that some areas connected well, and some did not (on both CSG v1 and v2)

In v1, such faces are created when a part is not precisely placed in relation to the other part (partially due to Floating Point error).
It usually helps if you drag the [separated] part with your mouse on the other part, so their surfaces get sticked to each other. That should create a fine connection that will allow a Union to be unified properly. If that won’t work, fixing a part’s position should do the job.

You may try these techniques and maybe the faces will disapear, however I can’t say for sure since - after all - it’s a different system.

This is an interesting example because there’s such a large difference in favor of the old engine. We’ll experiment more to find out if simple changes would improve the situation.

So far in our experience, higher than necessary triangle counts on CSGv2 result from three kinds of problems.

One common cause is that while the parts being unioned are seemingly aligned along a face, they are numerically speaking slightly apart. In this case the result ends up having unnecessary triangles both in the regions between the parts and of course on the sides that were not joined due to the gap in between. These can be typically worked around by making sure that the parts really overlap, instead of trying to align them exactly on a face.

A second and also common reason is that seemingly planar regions are in fact not quite planar due to roundoff, and in the current system these don’t get simplified into a single region.

For the above two, we’ve been experimenting with some heuristics, but it is disappointingly diffcult to find a good one. Greedy in merging of similar faces tends to work for cases like this, but produces unintended geometric results in other cases. We’ll keep looking, but general reliability has to take priority over special case convenience.

A third reason is the presence of vertices with large valence, where the regions around the vertex are intended to meet at a single point, but don’t due to roundoff errors. An improvement for this last case is in the works, and should be out in the near term.

Thanks again for reporting this!

1 Like