Hey @Wallath_00 mea culpa. Looks like there were actually two bugs interacting each other. There was an issue related to the computations directly (that was addressed earlier when I mentioned it). There is also an issue in substitute that was fixed but has not gone out yet. Basically, it comes down to an interaction with the new Inertia calculations.
If you want substitute to do the proper thing In the meantime, feel free to shoot me your placeIds and I can disable the Inertia calculation usage for you
Hopefully we’ll be able to get the fix out before the holiday season
~BelgianBikeGuy
Would be really exciting to see unions support multiple materials/textures as they can only support one material, however a union can have multiple colors at once.
This makes me question why materials cannot be applied in this same effect, maybe the material sizing on the union is an issue they are trying to solve.
I’ve noticed there is a major issue with decals and textures on unioned parts that is most likely related to this drop.
I haven’t been able to isolate the issue exactly but seemingly at random when unioning, decals could be placed on the wrong face. The orange decal outline is on the front face yet the decal its self is appearing on the side as indicated by the arrow. (See image below)
It appears there is a larger audience of people experiencing the same issues on this forum post
I’m also attaching a download to the model, albeit with a different texture, If you want to try to understand it more. Issue.rbxm (15.4 KB)
Hey! Right now there is unfortunately no way to do this. We are planning to release CSG on Mesh in the near future and that will enable you to import any watertight mesh you want and use it for solid modeling.
Hello, apologies for responding to an old reply however I am still experiencing this issue - funnily enough while attempting to do the exact same thing.
I’m trying to add a paint design to a CSG vehicle. My method, which has worked for the past few years, is to intersect (or prior to intersect being added, negate) around the area I want the decal on and apply the decal to the resulting union.
However, since this update I have noticed that my decals are broken in the exact same way. When applied to the face that I want them to show on they’re invisible. Applying them to (usually) the left side results in unexpected, stretched imaging. Without knowing how the backend works in the slightest, it seems to me like the engine is incorrectly assigning faces in this case?
After using it (not that much in general) for the past few months, I’ve come across this.
Wedges still leave very thin lines when using them as negatives and you have a part pushed right up to it
Hey, thanks for sharing this file. Unfortunately fixing these kinds of issue is not in scope of this update. That being said, we are aware of this issue and hope to address this in the future.
There is a bug with unions in general, such as if I have a part of size 2, 2.75, 3.5, after unioning the final mesh will be 2, 2.75, 3.499999 or something. I would prefer if the vertices in unions were exactly where they should be, and not ever so slightly off.
The union is done in the cframe of the first object, so all the other objects have to be transformed into the first cframe. Applying this transformation leads to floating point rounding errors, which is probably why you are seeing these small differences. Unfortunately, I don’t think there is a way to avoid this.
What is confusing is even if I am very careful to ensure all positions, sizes, orientations, CFrames of all constituent parts are dyadic rationals that can be perfectly represented in a float (so like 3.5, but not 3.4), this still happens sometimes. I could understand precision errors happening if I were using non-dyadic numbers that cannot be represented in a float precisely, but otherwise, where could these rounding errors be coming from?
Even if the cframe itself can be represented exactly, to compute the csg in the local frame of the first object we need to invert every “tool” cframe and premultiply it with the cframe of the first object. Both inverting the cframe as well as the cframe multiplication typically introduces small floating point errors. But even if the result cframe can be represented exactly, the result of applying the cframe to every position of the union can introduce floating point error as well.
If you have an example where you are suspicious that something else is going on, feel free to send me the file and I can step through it and check where the error is introduced.
I have made a simple vault door handle here. All the parts are exact, as demonstrated by the provided script, but if I union them, then not so any more. The final mesh size I get for those parts is 3.000000238418579, 18.500001907348633, 18.500001907348633 instead of 3, 18.5, 18.5.
