Correct, it has been around for a while, and we are aware that several people have been using it for a while. This post is mostly to get a wider audience, and to have a place for defect reports.
Ah alright
While I don’t really use unions at all anymore, I was able to test awhile back and noticed that spheres caused a noticeable amount of polys made compared to what was needed. Has this been fixed?
There have been significant improvements in polygon count since earlier this summer, and there are more improvements coming on that front.
The sphere primitive itself remains more complicated than it needs to be, which is something to be addressed, but the polygon count on unions is better than it used to.
@Spookhi
Funny you should mention this. I’ve been working on a small project that imports maps from Half-Life 2 using the new CSG engine.
Half-Life 2 uses the Source Engine, which uses the VMF file format.
Map geometry in Source is defined by the intersections of planes in a group.
- Where 2 planes intersect, it forms an edge.
- Where 3 planes intersect, it forms a vertex.
Visual example:
I’m a little incompetent when it comes to math like this, so I decided to do some workarounds using Roblox’s CSG engine. I generate a rough bounding box of the solid using the points defined by the planes, then I compute the directional vector of the plane using (B-A):Cross(C-A).Unit
. Finally, I create a negative part that is capable of slicing out everything that is in front of the plane, and I repeat that for all of the defined planes.
The end result looks a bit like this:
This project pushes the new CSG engine to the ultimate test of 100% reliability, and so far I’d give it a 99.9% on that reliability scale. It’s rare, but I do periodically get the -7 error and some inconsistent crashes.
In this video where I show off the map being imported in real time, you’ll notice that Roblox crashes at the very end before it can complete everything:
I’m not sure what exactly is triggering this crash at the moment, but I can provide some crash dump files if that would be of any help.
(Here is the plugin itself:
VMF Importer [Beta] - Roblox)
you’re too good, oh my god.
So long as I don’t get spammed with errors that shouldn’t be errors, I’m alright with any kind of CSG engine.
CSGv2 doesn’t seem to be handling spheres right. I made two spheres flush with a cylinder. In CSGv1, the resulting union is also flush (left), but in CSGv2 the spheres seem to expand a little (right):
CSGv2 Bug.rbxm (193.4 KB)
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).