As a developer of small-scale model trains, especially ones for public consumption as free models, CSG is an important feature to create the complex shapes required of the models as well as optimizing the models for decreased brick count.
The issue is that CSG V2 creates size offsets that are quite noticeable compared to CSG V1.
All the parts are built on a grid of 0.05 studs. There is a tiny tiny gap between the stairs and the part with the red sides, which is extremely aggravating. In fact, the tiny shifts in sizes and positions continue happening even at 10x the scale.
Below are the aforeshown part, scaled up 10x. The one on the left was created with CSG V1, and the one on the right was created with CSG V2:
The V1 part is sized as expected. It’s width is exactly 13 studs. But the V2 part is sized oddly; its width is 13.065 studs and its position shifted by 0.001 studs on that axis. After some testing, I’ve determined that the cylinder piece is creating the issue, somehow. Whether I CSG the cylinder before unioning the rest of the parts, or union all the parts in one go, the result is the same.
EDIT: Although the cylinder creates the misbehavior in this small example, there’s larger issues. When the part is rotated 180, translated along the axis, and unioned with the other one, it still creates offsets in size and position.
One of the ways V2 fails less often than V1 is by automatically shifting the parts about by small amounts until the operation works. That’s why you rarely get the annoying failure messages of V1, but you sometimes get these discrepancies.
Apologies, I was misinformed. See reply from linearcomplex.
This is not how CSGv2 works. There is no perturbation involved in its solver. However, its representation of geometry is different from CSGv1, and due to this it has its own version of geometry generators. Unfortunately spheres and cylinders are slightly different between the two, which causes the difference here.
Another known source of position/size discrepancies is the difference in representation, which means floating point roundoff will cause different kinds of deformation for CSGv2 than it does for v1 when objects are far away from the origin.
We have improvements for both of these issues coming up, but even in a perfect world, results from the two systems aren’t ever going to line up perfectly.
As a final thing, I do want to remind everybody that CSGv1 is going to go away relatively soon. Normal smoothing is coming soon to CSGv2, after which we should still have some time to at least minimize some of these position/size kinks… but the time is coming closer.
Existing CSGv1 assets will continue to exist and work in-game after we drop the library. You just won’t be able to use CSGv1 to create new assets anymore.
You’ll be able to separate CSGv1 objects using CSGv2 though. Some amount of manual adjustment is sometimes necessary due to discrepancies. We’ll try to minimize it, but unfortunately can’t completely eliminate them.
