CSG shadow problem

If you negate a small part that is rotated onto a larger part,i found that the new unions shadow is now really dark.

I found this when me and my friend were playing around with the new CSG API roblox added in, when making bullet holes in bricks for fun, this weird shading appeared,

Changing the collision type to box solves the problem, but leaves the block unable to be used in a map. (Holes in walls from explosions and other things)

I think this happens when the unions hitbox is rotated weirdly

repro file: weird shadows.rbxl (72.5 KB)

idk if this is just me or not please correct me


1 Like

No this is the worst thing to do. Some device will experience low framerate if you spam this method.


Sometimes I just remove the global shadows and mess around with lighting. Other times I just move the union-ed brick around.

moving the brick around doesnt do anything for me

Well luckily unions in general as they are right now should be mostly avoided.
And if nothing can fix this then I suppose the only option that does not mess everything up is to remove global shadows and mess with the lighting.

Could you add a repro file of the case you are discussing in the first post? This will help engineers reproduce the issue.

See also Steps to Report a Bug for anything else you may have missed in your thread.

alright ive added one

Great way to destroy any performance gains.


Please please please don’t do that. It’s awful for performance and it’s one of the things that were talked about in the performance talks at RDC as a joke, that people put humanoids in everything to make the shadows nicer.


@Neutre @Lightlimm @wravager Deleted the post. It’s not something I do but I completely forgot it was awful on performance. Very sorry.

1 Like

You will also find that when you go to make this union, if you select the large block first, then shift-select the negative part, you will not have the problem. The large shadow is sort of a consequence of the union having an oversized extents because of using the orientation of the rotated part, because it was selected first.

There are a few things about making unions that are sort of arcane knowledge, including that the order of selecting the parts matters, and that the orientation of the parts in world space determines how the resulting union is UV mapped (it gets box-mapped with world-axis projection last time I checked).

the thing is, this bug can still interfere with the CSG api, you cant choose what parts to select first, so in games, this can still happen

With the CSG API, you should be able to specify the first-selected part deterministically, it’s the one on which you’re calling the operation. That is to say, If you do this:

PartA:UnionAsync({PartB, PartC, PartD})

it should always be treating PartA like it’s the first-selected part. If this is not working this way for you, do you have a repro? I didn’t see any code in the rbxl you posted, so I assumed you were manually unioning things. The big shadow is another matter, and a shadow issue, not something we should change the CSG system to try and fix.

Im talking more about NegateAsync, not UnionAsync. you cannot choose which part to be selected first
since its just


see what i mean? the negative part is always going to be chosen