Thanks for reporting.
This is a known issue with the current geometry generators in CSGv2, and will be addressed in the near term.
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
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
This
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.
CSGv2 does not employ any perturbation to resolve coplanar cases. Unfortunately, however, the result above is the correct outcome for the transformation parameters for the parts. In this case, the offsets are coming from rounding errors in the transform tools.
The best way to work around this currently is to make the negative parts are a bit bigger than necessary, to make sure that the small rounding errors are covered.
Thank you, we’ve seen error 21 in the statistics, but lacked a repro for it. We’ll get to this right away.
I’ve been using this since it first came out. This is perfect i really like it there is no errors. Just a small issue when I want to apply a texture to a CSG with this new system sometime the texture don’t appear.
Glad to hear you like it!
I believe the texture problem has been fixed in the latest release. The issue was that texturing only worked properly if instancing was enabled. Let us know if you still see problems (this or other).
Plugin support for CSGv2 should be in the latest release, which I’ve just been informed isn’t quite out yet. Soon ™.
Will keep an eye out for it.
Is the change flagged, or should it just be automatic with the new version?
Will be automatic, given you have the UseCSGv2 checkbox enabled.
CSGv2 has been working wonders for me so far, but today I encountered my first issue. I have a part that I modeled below and I needed to stretch it out to be much longer so I stacked a bunch of them together in order to do so and that’s what I’ve always done with CSG to do that.
This has never given me any issues before and I assumed it wouldn’t as it shouldn’t be creating many more triangles than are already in that part, just stretching the existing ones out if I understand it correctly. But as you can see below, it is creating many more triangles than expected. This isn’t the behavior I expected so I don’t know if this is an issue that should be addressed or not.
Dropbox - CSG Curve.rbxmx - Simplify your life (sorry the file was apparently too large to upload to Discourse)
Have you tried unioning them bit by bit?
It only allows me to union ~8 and then continues to give me the error. I tried everything I learned from v1 but to no avail.
The reason so many triangles are produced is due to the fact that the duplicated elements, while apparently in the same orientation, are in fact not, thanks to rounding errors in computing the coordinate frames. Due to these small differences in the orientations, CSGv2 sees the individual faces as separate and so won’t join them into larger ones.
We’re working to address this issue, but it won’t be a quick fix.
Meanwhile, one way around this is to make the initial model “long enough”, and then cut it shorter using negative boxes.
I may have added several hundred thousand operations to the UseCSGv2 stats over the weekend, since my importer sped up about 10x when v2 started working with plugins.
(srry lol)
I’ve been seeing some issues related to UsePartColor and NegativeParts. I’m not sure if it’s because I’m rapidly doing operations or because there’s an actual bug, but sometimes negative parts aren’t applying their color to the operation.