Is there a use case for optimization of randomly generated stuff, ie maps made out of random arrangements of parts? I don’t exactly want to write up a bunch of code to consolidate a whole mountain of bricks into a union if it winds up being less performant than just said parts by themselves.
5 Likes
That’s fine, it’s extremely useful for effects as it is. Great job!
1 Like
Just out of curiosity, what is the advantage of this over the standard UnionOperation and IntersectOperation?
Does this allow deconstruction of the new meshes back into the original parts? I ask because I find that capability would be useful in explosion effects where unions and intersections are deconstructed into their component parts and sent flying for effect purposes. There is a feature request that I submitted some time ago requesting this exact feature for this exact use case.
If I’m reading and interpreting this correctly, this API allows the creations of new, coherent meshes similar to Unions and Intersection which are formatted differently (possibly irrevocably) internally for performance and storage efficiency reasons.
EDIT:
After doing some digging, it seems that this is the implementation of my feature request. Since there’s a split apart option, we get all the parts back. Furthermore, the parts in question do not have to be parented to the Workspace, which allows background processes to construct these meshes by script. This raises a couple of follow up questions though:
- What is the API’s compatibility with Parallel LUA in performing operations on these constructs?
- Can these methods be called from an unsynchronized thread?
In any case, I want to wait a little bit before this is finalized before I start playing with it.
2 Likes
This is awesome but, there is some issues with coding. Even though code is pretty much correct and no errors popping up, code still denying to work. I wish this coding problems will be fix soon as possible 
1 Like
Do you have any plans to add support for meshes? Fewer and fewer games are designed around parts, and supporting something like this would allow for some really interesting mechanics 
1 Like
Says here in the previous topic that these are for the BasePart object, which means that MeshPart support should be included in it. I’m not sure if MeshPart support is released, but it is definitely planned if not.
1 Like
Someone please make an epic pirate ship game with this.
Now I will have a reason to use parts instead of meshes in all my games. This looks very cool!
That’s the release I’ll be waiting for. It would be really nice to be able to make fruit ninja with CSG operations on meshes
If I am not mistaken they have announced in their roadmap “CSG on Meshes”, no idea when this will come but pretty sure it will.
Very excited to see someone make a teardown styled game with this (if I dont do it)
1 Like
Additionally, the new returned objects are now in the same frame as the input part. This means that you can actually substitute the CFrame of the original object into the new ones (in case it has moved while the operation has been executing)
For the ParallelLuau, It’s not been validated against it but it is something we’re looking into.
2 Likes
Not yet. There are a lot of issues to work through to add mesh support. I promise it’s being worked on
3 Likes
This update has come in clutch for future projects I’m planning. Great job, Roblox.
1 Like
It’s about draw calls, no amount of weld constraints and anchoring is going to fix that, that will only fix physics-related performance issues.
Draw calls are an low-level engine issue.
Having lots of unique models and unions in a game is going to bottleneck the CPU regardless of if parts are anchored or not.
At some point the CPU can’t send draw calls to the GPU fast enough and starts dropping frames.
1 Like
why don’t you simply apply the result to the original? this is called double subtraction btw, or intersection
1 Like
I ended up using the intersect function to do it, it would just be nice to do it without a second calculation.
On another note, the entire CSG system seems multiple times slower in game compared to studio. I don’t see anywhere to enable a beta property so I’m not sure if I can’t find the enable button or if its just worse in game. If anyone can tell me if I’m missing something that would be great.
Are you using the new GeometryService APIs? If you think it’s a issue with Roblox you should file a bug report.
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?