If I understand correctly, this is an issue with V1 unions. Have you filled in a bug report for this?
Can you share more details? Is it happening for all V1 unions or only the ones created around a certain date?
It’s happening with complex unions like aircraft fuselage or aircraft wings made with CSG V1 before this month. According to my friend last month, those complex unions on his planes never had any -7 error until this month
As far as I know there’s been no changes to V1 lately. Please fill in a bug report and we will investigate that issue.
mesh unioning when 
its taking too long
1 Like
i just ran into the problem of when i try and union a corner wedge it says it supported but it wont merge with other parts
1 Like
Can you share the model with me? I will have a look.
1 Like
Forget about my comment. I didn’t read properly your message. Sorry.
Corner wedge should be supported but is not at the moment. It’s a miss on our side. I hope to have a fix for that soon.
2 Likes
I wonder if, along with the new engine, there could be a way to access CSG data, even if just read-only? I’m not sure if others think the same way, but I think there could be a lot of opportunities in being able to read the data. It most certainly is like that for me.
If not that, maybe raycasts could react to CSG changes, as right now, it appears they only react to the bounding box, not to the actual collision shape, which has caused problems in my game.
2 Likes
Hi, have you tried using PreciseConvexDecomposition as CollisionFidelity setting?
1 Like
Is this CSG engine fast enough to dynamically move around a hole in a wall for a window?
2 Likes
That’s what we aim for. There are quite a few improvements we need to do to reach that point though.
7 Likes
Hi, sorry for re-living this post but i have found a bug with this new beta.
Seems like you cant union corner wedges, although it says they are supported!
1 Like
Thanks for the feedback. We’re aware of that issue. This should be fixed soon.
3 Likes
Any information on when V3 will be available for in game use?
1 Like
We have a bug with spheres that’s turned out to be much harder than expected to fix. Once that’s fixed, we think we’ll be on a good track to release this in-client. (And thanks to everyone who’s expressed interest in testing it!)
10 Likes
pretty nice, still looking forward for the day we can use the csg api on client rather than server only.
3 Likes
Hi everyone, sorry for the lack of updates. That doesn’t mean we haven’t worked hard in the background. I will try to reach to each and every one who did share a model with us but I wanted to announce to everyone that most of the issues have been fixed:
- Corner wedge is now supported in V3
- Balls should now match correctly with cylinders
- Various fixes should improve the robustness of the approach
Please let us know if you still see some bugs or think that one issue you reported has not been fixed.
Thanks again for your feedback.
12 Likes
I posted this in Building Support but it may be more relevant here. I love CSG so much that I built a large portion of my game around it.
Use Case : In game player can insert windows or doors into walls they have placed from a set of predefined prefabs which I have specially modelled in Studio. These special models have negative parts in them to create passable areas through parts, snapping these into the workspace with. CSG. is. Amazing!
Problem Statement: I am experiencing geometry errors which is preventing game elements such as doors from opening or which stops a player from walking up a staircase or through a hole they have created.
Even when a union result is not that complex and it appears visually fine to the player, it may not be passable. I found by looking at the location with decomposition geometry visible there are corner wedge errors which sneak in after a CSG operation, sometimes the geometry error will make the entire space impassable and renders some game goals unachievable.
Problem Definition: I have attempted to quantify the ‘ error rate’ of the decomposition problem because parts do not need to be complex to get the error situation. My solution was to build a CSG Unit Test Place for SubtractAsync. You can download the code SubtractAsync Unit Test
When entering the place the algorithm immediately starts, it gathers error data by repeatedly subtracting several simple shapes from a larger but still simple shape and then tests for intersections across each; it does this over a volume of space and over a range of complexities, I do this because I was looking for positional clustering of errors. The position of the geometry errors in the workspace are consistent when playing the game. Change the position and get a different result?
Indeed, I found one way to reduce the error rate practically to zero was to introduce a wiggle retry loop. When it encounters the first error it will ‘wiggle’ the big part around a small 1/100 amount on each axis until the parts do not intersect and pass the test, or, until the doRetryLimit is reached.
The defaults for the unit test operations are:
Enum.CollisionFidelity.PreciseConvexDecomposition
Enum.RenderFidelity.Precise
It can use either of these for the intersection testing.
:GetPartsInPart *default
:GetTouchingParts
Conclusions:
After many iterations of the unit test design and execution I found the decomposition error rate to be about 0.023%. That may not seem like a lot, but it is consistent.
I think the geometry errors are less related to CSG and more related to the geometry decomposition algorithm itself. It can fail on even the simplest of operations and ironically decomposing more complex shapes is more accurate.
Error correcting retry loops can take upward of 50+ iterations of part wiggling to find solutions, while on the odd occasion it will timeout completely never finding one. The net result is an increase in the load time of in game models. I have considered making a ‘construction’ animation to hide the iterations and make it a ‘feature’ of the build process, although I cannot guarantee it will be error free.
1 Like
Hi there! There is a CSG3 spin-off project that we are currently engaged in which aims to do the precise convex decomposition as an intrinsic part of the CSG engine itself - using CSG engine data etc., rather than as a postprocessing step done on the result mesh (as it is done currently). Specifically we are aiming at an “incremental” decomposition - meaning instead of recomputing a convex decomp. from scratch after a csg op (from scratch = for the entire mesh of the result ) - which is the current way, we would instead modify the convex decompositions of the objects involved in the op, so as to produce a decomp for the result of the op. This kind of “local” modification should be significantly faster than what we have now. Also the fact that we would be using CSG data as our source of truth (instead of the result mesh) hopefully means that we would end up with a better decomposition - one which avoids artifacts like those you’ve observed (e.g. cavities sealed etc.).
3 Likes
Hey thanks for your response! This is great news I will keep my eyes open for updates and further speed improvements. Incremental re-use of CSG decomp datasets. I cant wait 