Unions Rendering Strangely (CSG API)

Help and Feedback Scripting Support
, ,
#1

Hello, I’ve been dealing with a frustrating issue with the in-game CSG API (which was talked about in this dev-forum post from 2018: New Roblox In-Game CSG API is now available)

I’d only come across the UnionAsync and SubtractAsync API’s recently, but I was really excited at the thought of how much cool things I could try to implement with this functionality. An idea I’d wanted to try for my mini-project, was to use SubtractAsync to make a large hole in the ground, and then to have a chessboard appear by flying up through that hole. (Using UnionAsync later to cover up that hole when the chessboard eventually goes away)

So far, what I’d came up with seems to work fine inside Studio testing: in-studio clip - Album on Imgur

But, when I’d tried publishing the game and trying it outside of Studio, there’d seemed to be some odd rendering behaviors: in-game clip - Album on Imgur (The first chessboard had some weird stuff happening below it, and the creation of the third board caused the entire union to turn transparent)

I’d tested with two players; sometimes one player would see rendering defects while for the other player there wouldn’t be any. And sometimes the creation of another board (another SubtractAsync operation) would cause the whole union to become visible again. In contrast, I haven’t been able to reproduce any rendering defects while inside studio

I guess this specific usage of the CSG API shouldn’t really be that important for my own mini-project, but it could potentially be used for so much cool things! Which is why I really want to use it. I don’t know yet how universal this occurrence is; maybe for me I’d just did something wrong. For those curious, the code I’d wrote which was relevant to this was:

local to_subtract = Instance.new("Part")
to_subtract.Size = Vector3.new(64, CreationAnimation.Depth, 64)
to_subtract.CFrame = board.PrimaryPart.CFrame + Vector3.new(0, CreationAnimation.Depth/2)

local union = workspace.Ground:WaitForChild("GroundPart_Center"):SubtractAsync({to_subtract})
GroundTextures.Add(union)
union.Parent = workspace.Ground

delay(1, function()
	workspace.Ground.GroundPart_Center:Destroy()
	union.Name = "GroundPart_Center"
	
	-- and then moving the chessboard up
end)

Maybe this is a bit niche, but I would appreciate any kind of feedback. I probably should try testing the issue some more

2 Likes
#2

Wow, that’s really weird and sounds frustrating. I don’t really know a solution to this, but it could be because of how you’re only using one baseplate and then creating multiple unions on that one baseplate.

It’s really cool what you’re trying to do, I hope someone can help you or that you figure it out.

2 Likes
#3

Hey, thanks! I did consider the possibility of it being from the creation of multiple unions, but sometimes in-game the rendering defects do happen on the creation of the very first union. (Another thing I’d also tried, was making the ground-part smaller; instead of being 2048x2048, I’d made it 1024x1024, though it still didn’t seem to help…)

2 Likes
#4

I’ve encountered this issue myself when I tried making bullet holes in walls and I’ve seen this happen to other people too. It seems to work flawlessly in studio, but in-game after like 2-3 operations the whole union just becomes transparent

3 Likes
#5

I’m somewhat glad to hear it’s not just me having the issue. It sucks, with it being such a cool feature if it worked without turning things transparent. Is there any way to try to get this issue more known about so that it can be fixed?

1 Like
#6

I looked through the comments, I didn’t see anyone else having this problem. But I did find a post, that possibly might help you? New Roblox In-Game CSG API is now available - #10 by wravager

2 Likes
#7

Similar bug report:

One workaround is to delay parenting the result of Subtract/UnionAsync, but that’s not really 100% reliable and there’s really no way to tell exactly how long you have to delay parenting… I’m guessing the delay in parenting gives the client just enough time to download the rendered mesh data? I don’t know. In the end, I ditched using the CSG API for my project and went with a different solution.

Since all the cuts in your game are axis-aligned, you can probably get away with doing the cutting math yourself.

Alternatively, you can just have the entire baseplate be subdivided into a NxN grid (where N is the size of each chessboard) and have the chessboard placer snap to each cell in the grid. You’re missing out on being able to place the chessboards freely, but maybe that’s not important for your players.

5 Likes
#8

That was a relevant concern for me when I was trying out the API at first, but I think the main thing is that what I’ve implemented seems to work completely fine in-studio; it just has those weird rendering bugs when it’s published

1 Like
#9

I might try that – delaying parenting the union result – but I agree in the current state it seems better off to try a different solution. I’d also thought of doing the cutting math myself, as you said, though it does seem a bit daunting. I might have to take away board rotation to make that feasible for myself, haha

4 Likes
#10

This bug has been fixed relatively recently :slight_smile:

No need to delay parenting anymore.

1 Like