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
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.
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.
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).
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.
