I just want to say that using SubtractGeometry() doesn’t seem to work properly on Parts. I keep getting an error saying the function isn’t a valid member of Part. It might just be me, since in Simple Tools.rbxl it works perfectly fine on parts.
EDIT: It seems to work using the older version (with flicker). However, creating a new Part to replace the PartOperation is a bit odd. It says the CFrame values are the same (In Properties) when setting the new Part’s CFrame to the PartOperation when they’re not.
EDIT 2: The second method (with flicker), seems to be intended based on the document about it. My only problem is the error with not being a valid member.
The SubstituteGeometry API is limited to PartOperations and cannot be used with Primitives. This limitation exists because Primitives in Roblox are designed to represent only a specific set of basic shapes, making it impossible to substitute arbitrary geometry into them.
It is unfortunate that performing operations on Primitives can cause flickering. To work around this, you can convert a Primitive to a PartOperation before applying any operations, e.g. by subtracting a non-intersecting object from your primitive.
Yup, I basically stuck with SubstituteGeometry() and used it twice; First operation is if the instance is a Part, it “converts” into PartOperation to allow subtracting for the second operation. Thanks!
Will the GetClosestPointOnSurface API be parallel safe in the foreseeable future? Because it doesn’t seem to modify any data, it would make sense for it to be parallel safe.
Working on something performance heavy that works in parallel and I would love to use this API.
I have tried using BasePart:UnionAsync before to try to optimize on triangle counts on terrain generation, and I am so happy with how this new CSG system works! I just tested it out and the optimizations made are HUGE. The first image is with CSG making a union of each chunk which was made with 8^3 parts for each chunk, creating a total of 1 million parts total, and after it had finished loading, the game ran at a full 144 FPS, it took around 11 minutes but I believe that can be fixed when CSG can be run on multiple threads. For comparison, the 2nd image is without CSG, loading in 1 million parts just by itself.
With CSG, the triangle count total was 2 million and without it, was 12 million.
Though without CSG the 1 million parts loaded in 3 mins, so its a bit of a trade off, but this is just a large test, in reality we wouldn’t be loading this large of a world all the time.
This was also without greedy meshing, and I believe greedy meshing can also make the Unionizing faster as it has less parts to deal with overall. Literally can’t wait for more updates on this.
One major flaw I found however is that the new Occlusion Culling doesn’t work with Unions, it doesn’t hide unions if you are directly facing a union, and it works fine when it was used with normal parts, but that added barely any boost in performance when they were just normal parts.
Just added Greedy Meshing, and my goodness.
All of these tests were done at a world size of 16 chunks and each chunk were 8 blocks in size, making a world size of around 16^3 * 8^3 = 2097152.
This is 1 million parts, without Greedy Meshing and Unionizing Chunks. Took 208 seconds to load it. 12 Million Triangles WITHOUT Occlusion Culling.
Then this is 128k parts with Greedy Meshing but still no Unionizing Chunks. Took 74 seconds. 4.6 Million Triangles WITHOUT Occlusion Culling (1.5 Million with occlusion culling)
And last but not least, Greedy Meshing + Unionizing Chunks, gives a grand total of turning 128k Parts to 3.6k Unions. It took longer at 179 Seconds but it produced LESS triangles and parts, at 2.5 Million without occlusion culling.
Occlusion culling doesn’t seem to work with unions, but hopefully it will later on.
The performance boost that CSG adds, literally turning 1 MILLION parts to 3.6k “parts” is just insane. That is like 277 more times optimized in terms of parts, and 15 times more optimized in terms of triangles.
We’re pleased to announce an extension to the Roblox API. The GeometryService:CalculateConstraintsToPreserve() API now includes a new option called dropAttachmentsWithoutConstraints to control whether Attachments without Constraints are dropped or not.
New Option:
A boolean parameter to control whether Attachments without Constraints are dropped.
Default Behavior:
The default value is set to True, meaning Attachments without Constraints will be dropped, maintaining the current behavior.
Preventing Attachments from Being Dropped:
Setting the parameter to False will prevent Attachments that lack Constraints from being dropped. This feature was implemented in response to user requests.
This update provides developers with more flexibility and control over their use of Attachments within the Roblox environment.
For further details and implementation guidelines, please refer to the updated Roblox API documentation. A small hint: if you set this option to false, don’t forget to check if Constraint is not nil in your return table.
Thank you for your continued support and feedback!
Hello, I can’t seem to use this API in the command bar? I was planning on incorporating this into a plugin I’m working on, but as a workaround is it still recommended to use BasePart:UnionAsync?
