@Wallath_00 Turns out it was a bad interaction with some other feature. This should be fixed now.
its the LOD, meshes closest to the player would have an LOD of 0, aka unchanged, meshes very far away from the player would have an LOD of 4, aka very low detail, does that help with explaining it?
I’m still experiencing the issue. Is the fix not rolled out to everyone yet?
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
1 Like
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)
I thought I could correct this by just switching the face but when I do it stretches the image to wild proportions. (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)
2 Likes
Is there any chance of additional shapes being added? Like a torus? (Unless I’m stupid and there’s a way to import your own.)
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.
2 Likes
This is very interesting! More efficient
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?
2 Likes
I have also experienced this issue with applying decals when the beta enabled.
Here’s a video showcasing the problem.
It also showcases how much quicker the new system is, so wonderful job on that 
Hey, thanks for letting us know! A fix for this is already deployed and I hope to turn the fix on in the next few days.
3 Likes
Both plugins aren’t working properly.
May I get an update if it’s released or at least now usable now for Plugins? 
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
This image is showing it’s close to the origin point of the world, after reading that above, so that isn’t the issue
This is without the beta enabled, expected behaviour for that
Here’s the union and the part
problem.rbxm (11.9 KB)
1 Like
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.
No, I just do that manually as needed. I prefer my objects to be precisely the size I expect.
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.
1 Like
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?
1 Like
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.
1 Like