Thanks to the previous Studio beta and all your feedback and questions, we are ready to announce that the CSG APIs and capabilities are now available in published experiences!
We’ve also made the following changes and fixes since releasing the Studio beta:
Fixed box decomposition which was not matching the visual output of the operation (it was offset to the origin of the CFrame as opposed to the physical center of part). This was causing incorrect culling of certain parts of the scene.
Fixed issue where fully disconnected surfaces were being considered as different bodies. This meant subtracting a sphere from the inside of another sphere would actually create 2 bodies when split apart was enabled.
Fixed interaction causing sporadic crashes during fast substitution updates (related to flicker removal with substituteGeometry).
Miscellaneous small bug fixes
We are still actively fixing a few recent bugs and will push out fixes as soon as they are available but we wanted to get this out to you as soon as possible.
As a reminder, the following CSG APIs are available. Learn more about them here.
APIs:
GeometryService API to easily access all current (and future) CSG Async Operations from your scripts
CSG Async APIs that can return multiple parts instead of just one
New “warm start” engine that speeds up in-experience CSG operations through caching
Incremental re-meshing through localization techniques to greatly improve performance
Our main goal with this release is to get real-world, in-production usage of these APIs so we can further tweak performance and fix any new bugs. At this point, we do not expect any breaking API changes so it should be safe to publish experiences with this new feature set, even though performance will continue to improve and bugs will continue to be fixed.
We look forward to all the amazing experiences you will make with these new capabilities. Please keep the feedback coming!
“Thats one small step for physics, one giant step for developers alike!” — Me
Physics is really fun to play around in so having more physics building blocks to play with will keep me occupied for months to come! I can’t wait to use this to get home
I’m interested, how did you guys think about making this in the first place?
This is awesome!
I have one huuuge question though.
Having lots of unique geometry often causes a drastic increase in draw calls and whatnot.
Are there any ways or methods for optimizing this?
I could imagine in a destruction game where you want debris to lay around for a long time it’s eventually just gonna lag because of the draw calls.
High poly count might be unlikely since modern hardware can handle it pretty well nowadays but it’s still a very minor concern.
Will the lighting bug when using the SubtractAsync function ever be fixed? I’ve reported it many times since 2022 and haven’t received much information. In fact, I’m not the only one, as shown in this post. It’s amazing to see improvements being made to CSG while ignoring existing bugs with the old and even the new API. bug_report.rbxl (47.9 KB)
In all honesty, I’ve been waiting for BasePart:GetClosestPointOnSurface for a while now as well as plenty of other folks, and I’m glad it’s been released to the public. This’ll accelerate my workflow even more!
To add onto this actually, may we ever get to see accurate points inside a MeshPart and union operations with CollisionFidelity.PreciseConvexDecomposition?
Oh come on, don’t tease me! There’s a laser gun in your inventory and you didn’t even use it for this demo?!
Jokes aside, being able to protect Constraints inside of affected parts is a huge step forward. Will this also apply to other Instance types, like decals, lights, and audio?
Does the CSG engine have any sort of parallelization support? Or are we forced to run each operation in serial?
I think these are 100% great improvements though i still don’t exactly feel confident in using the CSG engine past simple infrequent operations. I still fear that frequent complex operations will lag out to even freeze the server or even crash the server outright due to some sort of internal CSG errors. While i do understand that these issue’s aren’t exactly easy to fix for this kind of system i do also dislike the fact that there aren’t any specific ways we could properly optimize these things ourselves (like running the CSG operations in parallel) nor could we change some sort of precision/accuracy value in order to save time and resources for simpler operations that don’t require maximum precision. Right now sadly the CSG system is the only real option most developer’s have when it comes to real-time geometry manipulation within their experiences. While DynamicMeshes for example are a thing, theire still in beta and even then their use is mostly delegated to small niche things (plus the fact DynamicMeshes use their own specific instance rather than letting you throw this system any BasePart instance).
This is a good way to step in creation of the physics game of Roblox.
