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! 
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):
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!
(…right?)
Is this the right thread to report issues/bugs with CSGv2 or should I go to Bug Reports instead?
New csg system. 
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?
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.
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!
That sounds right. Thanks for the explanation. I hope something can be done, or the v1 system remains as an option for a good while.
Another thing I’ve noticed that has changed is that when you union parts with the same color, the final UnionOperation’s UsePartColor property will default to false (while in the old system if the parts had the same color it would be true).
Not really a bug, but…
Good catch. I’ll file this as a bug, as it’s a an un-intentional difference in behavior.
