Yes, everything is using GeometryService. I’ll wait until a bit more confirmation that it’s a bug before reporting it, but there is a very noticable difference in calculation time between studio and in game.
1 Like
It could be because the CSG operations have to replicate from the server to the client; which can be expensive depending on the complexity of the model. If you use CSG on the client though does the calculation time difference still occur?
I’m doing it on the server, but I moved the same code to the client and the result is the same. Still has a much higher calculation time than it does in studio.
1 Like
Interesting. Have you tried timing the computation itself? I’m genuinely interested to see if this is a bug but having seen anything like that myself. At a glance it looks a) super cool but also b) like there is some replication delay.
If you want me to take a look at it, feel free to shoot me a PM (either joining a group or an rbxl file to test)
Are you using collisions on intersected parts?
Hey creators,
Thanks so much for the active feedback and we hope you have been enjoying playing with these new APIs
We are tracking a few recent issues that came up that might affect you:
- Due to this recently reported rendering issue, we had to turn off some fixes for flickering when using CSG operations. The team is actively working on resolving this issue and we will report back when it has been fixed.
- In some cases, you might face issues with box collisions due to parts having an off-center origin. This issue has already been fixed and should be rolling out in an upcoming release
- In some edge cases, you might hit an infinite load issue due to coplanar phase removal when performing CSG operations. Thanks to the dev that reported this via DM to us. This issue has also been fixed and should be rolling out in an upcoming release.
All of these issues were identified thanks to your active feedback. Please keep them coming!
5 Likes
Hey! The new system is great except for one issue regarding GeometryService:SubtractAsync().
If you resize a PartOperation and subtract it from another part, the PartOperation’s Size and PartColor are reverted. This is not the case for unions, which has its Size and PartColor applied in the subtraction function for Part:SubtractAsync(). Is this intended or would it be fixed in the future?
Attached is an image and place which explains this better. Thanks 
place.rbxl (56.4 KB)
2 Likes
Hi @HungryMangoes. Thanks for the bug report looking at it right now. This is very much a bug.
I have to say, I LOVE the repro file 
Thanks
~BelgianBikeGuy
2 Likes
Pretty Cool!
Finally a update to better physics in a roblox game!
Things that can be improved:
Would like to see a Substitute function for mesh parts.
Would love to see the documentation being easier.
Keeping a basepart as the main part when subtracting.
Bugs:
On creation of new part after subtraction the new part does not keep color on removed bits
2 Likes
Hi @Loiciboy123
Two bugs were found with scaling and color and are being worked on. In particular with the usePartColor property on PartOperation. You seem to have a slightly different error happening? I’m having some issues seeing the issue from the Gif, If you have an example repro place (or want me to join a group to show me something, feel free to shoot me a DM)
- Substitute on MeshParts: it’s definitely something we’re looking at (along with CSG on mesh and so forth). No set ETA but active development
- Documentation: If you could explain what your issue is/ was, we could try to make it better for future developers :).
- BaseParts unfortunately cannot support Meshes or PartOperation data. I’m not saying this will never be possible but this is a bit more of a fundamental problems. BaseParts are extremely optimized and light but it comes at a cost of a lack of flexibility
Hey @HungryMangoes ,
A quick follow up on your bug report:
- Color issue is a trivial fix and we should have that in extremely fast (look for release of bug fix sometime next week)
- the issue with scaling is a little more complex but should have a fix the week after that (hopefully in two weeks)
3 Likes
Oh alright sounds good. Thanks again! 
i commented out the code because it didn’t feel natural inside the game but if you want you can test some stuff inside the game, ill revert the code if youd like!
It would be appreciated to try to identify the problem. (and hopefully discovered I’ve fixed it with code change from yesterday )
Could :GetClosestPointOnSurface() potentially also return the surface normal, or could we get a way to retrieve the surface normal at that location? This would be useful for a variety of behaviours.
It would also be very useful to have e.g. :IsPointInsidePart() and potentially :GetClosestPointInVolume().
With the surface normal you could determine this for fully convex parts like so:
local function isPointInside(part: BasePart, position: Vector3)
local closestPoint = part:GetClosestPointOnSurface(position)
local surfaceNormalAtPoint = ???
return surfaceNormalAtPoint:Dot(position - closestPoint) < 0
end
Having the surface normal would essentially let you compute SDFs for arbitrary part geometry which is useful for a variety of things outside of raymarching but could be used to implement raymarching in luau. Another more practical usecase for deciding if a point is inside of a part is finding the closest point not just on the surface of the part but in the entire part’s volume.
I currently would like to be able to determine the closest point in a part’s volume to another part’s center so I can determine the two corresponding depths between two contacting or overlapping parts for computing this more accurately as it depends on the distance to the measured temperatures (which would be measured from the part’s centers)
c.c. @FGmm_r2
2 Likes
I was wondering if they could make CollisionFidelity changeable during runtime 
You can choose the collisionFidelity as a result of an operation. Changing the collisionfidelity directly is something we have (and still are) discussing. There are a couple of annoyances with it, especially related to processing time and supporting APIs in perpetuity.
In other words, we’re looking into it
1 Like
This is a massive point that needs to be addressed, how will the functionality of these systems work when we apply factors such as force, billboardGUI’s is it just totally incompatible?
1 Like
I was really hoping the decal support would be more accurate than… whatever this is 
Though it seems like on smaller chunks removed it’s working better. Getting some flicker on the decal with fast substitutions, but nothing too crazy.
Also, why does it say I can’t call this method from a plugin yet when I try to use it in Studio’s command prompt? Surely it should support in studio/plugin usage if it’s out in games already… lol
1 Like
I’ve been using this API for procedural generation as a polygon efficient solution for flat surfaces when previously I was using terrain.
First, I create the platforms and holes for the stairs, then merge the overlapping ones in real time in one efficient step. to create a solution for merging unions that I can use simply.
1 Like