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.
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).
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:
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.
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.
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.
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.
