In-experience CSG Performance and Robustness Improvements

Hello Creators,

Hot off the heels of the recent in-experience Constructive Solid Geometry (CSG) GeometryService API release, we’re excited to announce improvements to the performance and robustness of those APIs.

You don’t need to do anything special to enable these improvements. Continue using the APIs just as you are today and you should see the following improvements.

Please note that these improvements are currently only available in server scripts for published experience. We are currently rolling out these features for both local and server scripts in studio and they should become available in the next few hours. We will also enable local scripts support in published experiences in the next few weeks, once most clients are updated.

Improved Performance

Complex Shapes and Interactions

We’ve made several improvements to how our CSG engine handles complex shapes and interactions. For example, when two objects meet along a flat surface, or when they overlap significantly, our system now processes these intersections much faster. We ran a number of tests on internal benchmarks and we see improvements across the board. In some especially difficult cases with complex CSG geometry we recorded operations being orders of magnitude faster.

Improved “Cold Start” Performance

When performing CSG operations for the first time on complex objects, we previously had to re-evaluate the entire CSG tree before performing the operation. With the recent improvements, these “cold start” cases are now much faster. Take a look at the example below of doing a SubtractAsync operation on this tank turret.

image2

Faster Complex Tools

Performing CSG operations with simple tools on complex objects got a lot faster in our original release. Now, we’ve vastly improved the speed of CSG operations when using complex tools as well. In the example below, you can see a CSG “axe” being used to perform a subtract operation on the tree. The axe itself is a complex object that is made up of a number of CSG operations. With the new improvements, you can see how much faster the Subtract operation now runs.

image3

Lower Memory Consumption

Using CSG has always been a delicate balance of complexity and memory use. The more complex the inputs of the CSG operation, the more memory was used. In some use cases, chained operations would use more and more memory. With the new improvements, memory usage is greatly reduced, especially in the case of chained operations. In the “axe” example above, memory usage would normally build over time as more and more CSG operations were performed. With the improved CSG engine (shown in red below), memory usage stays much more manageable as the number of operations grows.

Improved Robustness

Reduced CSG “Invalid Operation” Errors

One of the most common complaints when using CSG APIs was cryptic internal errors that would prevent the operation from completing successfully. We improved the reliability of the engine to vastly reduce the cases that could result in an invalid operation. This should allow you to be much more confident in leveraging the CSG system in your experiences. We are committed to stamping out every possible “invalid operation” error remaining so please drop us a note with an RBXL example if you do face one in the future.

Improved Normals For Better Lighting

Thanks to your feedback, we have also identified and resolved a long standing problem with the way CSG operations were handling normals. In the example below, you can see how the light hitting the walls created with CSG is much more realistic since the normals of the resulting operations are now fixed.

Sphere Alignment Between Studio and In-experience

Another issue we have heard loud and clear is with alignment issues. Previously, when using the sphere primitive with CSG in Studio, creations could look slightly different when the experience was eventually played at runtime. This was due to performance optimizations that were made to the sphere geometry to ensure CSG creations ran performantly in-experience. With the recent performance improvements, we can now use the exact same sphere geometry between Studio and in-experience to ensure your creations are faithfully recreated. In the example below, you can see how the seam between head and the droid created using CSG within Studio is not faithfully recreated currently but with the new improvements, it looks exactly the same.

Looking Ahead

We are introducing these improvements first in the recently announced GeometryService CSG APIs but are working hard to also introduce these improvements to the CSG operations available within Studio and to Plugins. These will take a little longer since we want to make sure we do not break any existing workflows you might have.

We hope these improvements help you create much more complex and interesting CSG scenarios in your experiences, or at least enhance the robustness and stability of your existing experiences. As always, please let us know if you notice anything funky with these changes and we will do our best to fix them.

Thanks,

@pho01proof, @BelgianBikeGuy, @syntezoid and @FGmm_R2, on behalf of the entire Geometry team

285 Likes

This topic was automatically opened after 10 minutes.

This is what I’ve been waiting for! Thank you all for your hard work!

25 Likes

These improvements are absolutely massive - thank you so much for improving CSG in essentially every category once again! Big kudos to the whole team.

11 Likes

What about saving and recreating PartOperations or separating existing PartOperations in-experience, especially with EditableMesh coming soon, is this planned?

11 Likes

Thank you… now i can more precisely abuse CSG…

14 Likes

sick, now I can create realistic organs popping out of the player.

10 Likes

This is actually awesome, looking forward to more awesome improvements.

6 Likes

i do not understand anything here but it looks like a big update

7 Likes

This is honestly fascinating and something that has been needed for a long time

4 Likes

The memory numbers are pretty crazy, though can we also see the performance numbers? I’m very curious about those.
In the memory benchmark, what do the “Time Points” actually represent? Seconds? Minutes?

9 Likes

Time-points is not the best term. The x-axis actually represents the number of CSG operations performed.

9 Likes

I don’t recall if its a think currently but would their be a way to bake unions? Basically what I mean is dumping any previous memory pretty much converting it into a meshpart?

When baking a union you cant

  • Undo the operation to previous states
  • Make new changes to it ex; make more modifications through the csg service
8 Likes

I dont have anything worthwhile to say aside from the before clip being the funniest thing ive seen in a while

10 Likes

Any plans to have parallel luau support for unions? Been trying them out and the performance differences compared with what we had before are quite crazy. However i do also think having the ability to run union operations in parallel could increase performance even more while also allowing for larger scale union operations to take place!

2 Likes

Currently, all CSG operations run on the same thread. As a result, even with parallel Luau, you won’t notice any speed improvements. It probably makes sense to lift this restriction and utilize more resources for CSG operations when available. We will investigate this possibility in the future.

11 Likes

The ability to compute CSG within different cpu threads would be game changing and actually open the door to the CSG engine to be utilized in actual real destruction, modeling or other kinds of high profile systems around games.

Also this is a smaller gripe i have with the system but any plans to do something about the 20k triangle limit for unions? Like potentially adding a “IgnoreTriangleLimit” boolean property for the GeometryService methods. I know trying to run CSG operations on unions with like 50k+ triangles isn’t going to be exactly fast but i think it would still be neat to have. Something that can be done instead is maybe let us set our own triangle limit with each CSG operation. Default could still be the standard 20k.

Another more crazier idea could be GPU compute for the CSG engine! Not sure how viable this is within the roblox engine but would be cool (and FAST) to have.

5 Likes

This is a big update not just for Meshes and other but for Lighting too

2 Likes

and also why not load the Triangles whenever the player is looking at it this will make the mobile players gain more frames and less lag

2 Likes

Tysm for actually pushing a good update unlike the past 10 ones!

3 Likes