Bring real world creation to your experience with Constructive Solid Geometry (CSG) improvements [Beta]

It just does not work at all :person_shrugging:I printed the spatial query api and it is printing every part correctly

2 Likes

Hey @lambarini, would you mind sharing the rbxl?

1 Like

This is incredible, is there a chance for us to see a similar feature be applied to imported FBX meshes?

1 Like

When csg live is implemented in experience games? I just tried to test it in experience game but it doesn’t show it…

1 Like

Soon ™. In all seriousness, we are making sure everything is setup properly once it’s in open beta. We want to make sure all the raised issues are handled properly

3 Likes

Will these lighting bugs be fixed before it’s in open beta? It’s been almost a year since I reported my issue, and it’s still not fixed, even though multiple admins have “invesigated” the bug.

A fix for the bug was waiting to be deployed.

An investigation was started (But a fix was previously waiting to be deployed?).

2 Likes

Hello, I’ve been developing a game for this beta feature and found a bug where the output of a PartOperation can become a ball. Said ball has its material only visible from the inside. I’ve also found that the balls that get created often have a very small piece of debris attached as the same PartOperation. My theory is that the vertices of the PartOperation are becoming negative because the input part is too small and gets handled incorrectly. I also managed to get Roblox Studio to crash twice while trying to record the bug, which I hadn’t managed to do before. I don’t feel comfortable sharing the RBXL file publicly, so if you need it, you can DM me. Here are two videos of the bug occurring (in both it happens roughly after 3/4ths of the video):

EDIT: I forgot to mention that this only happens while using GeometryService:SubtractAsync() and not when using BasePart:SubtractAsync()

4 Likes

Hi there, I keep getting the following issue when working with GeometryService:
Internal Dev only. CSG3 New API is not ready to be used externally

At line: local success, newParts = pcall(function() return GeometryService:SubtractAsync(mainPart, otherParts, options) end)

Why is this? I have enabled the Beta Feature. What is the reason for disabling this API?

1 Like

Interesting. The API is not currently disabled. That being said, we have noticed some issues with the beta feature system in general. Try toggling it off, restarting studio then back on again.

1 Like

Hey Zagusan,
Sorry for the long response delay. We’ve been looking at this issue (or a similar one). Feel free to DM me an example or just to discuss your particular case if needed. Thanks

1 Like

Yes, after restarting it a few times I got it work and have a bit of fun tearing apart this BasePart. When are you guys adding support for other objects like MeshParts? :slight_smile:

image

1 Like

Support for objects like MeshParts is already on the roadmap here.

1 Like

Sorry for the late reply. Anyways, are there any future plans to add a built-in cone type at all?

I’m not much of a modeler to begin with, but when I do I usually try to avoid using cones since, as I mentioned before, they can be annoying to implement into a build. This is further hindered by the fact that the smoothing angle property for unions doesn’t seem to work on cones created with the CSG system, meaning that no matter how many faces you have (unless it’s an obscene amount that is), each face always appear distinct from it’s neighboring faces rather than a smooth curve. A built-in part type could solve these issues and make implementing cones into a build a lot easier.

1 Like

Hello BelgianBikeGuy,
Don’t worry about the response delay. On that topic, I also apologize for not replying, I haven’t checked the devforum in a while. I’ve DM’ed you all relevant information. Thanks for checking out my bug report.

1 Like

image
First thing I thought of :rofl:

1 Like

Thanks zagusan,
I’ll take a look at it

1 Like

Maybe. Cone actually causes some interesting issues at the tip where a lot of triangles merge together. Basically it can be done but the performance penalty is severe. We are trying to find a way around it cleanly

2 Likes

I like this update

2 Likes

I have a question about performance. Let’s say that i generate 5 cube parts that i randomly place in a radius. I want to use them to make a hole in the part using substract but also create debris using intersect. So here is the question: would unioning the parts before doing any substract and intersect operations increase performance? Or would it actually make it worse? Or maybe there wouldn’t be any difference?

Hi everyone. Happy New year

Couple of updates:

  1. @zagusan We have fix for this coming soon (knock on wood).
  2. Following this bug fix, we should be ready for an open beta relatively quickly.
  3. @BubasGaming Many simple tools is much better for the API than unioned parts. Quick behind the curtain: When you do the union, you generate a convex decomposition, mesh and a network call. Additionally, when your tools are complex (ie, not primitives), they currently have to be recomputed in the same coordinate space as the main part. In other words. It is MUCH better to pass simple tools to the API. That being said, if there is a request for a combined subtract/intersect operation, it might be worth taking a look at it

BelgianBikeGuy

1 Like