A “Merge Distance” property for the CSG operation methods could actually be pretty game changing! I always find it annoying that i am forced to jump into third party 3D modeling software just to fix broken geometry on super simple unions.
2 Likes
Hard to say if they had done anything collisions wise. From my testing collisions still seem to be pretty broken and buggy overall for anything that isn’t super simple CSG operations.
Small gaps and overlaps at a microscopic level make it impossible to create competitively optimized models, compared to blender. Blender can do so much… right now the only real benefit is the convenience of using integrated tools and modeling to make quick edits and modifications. But CSG does need work on things like this… there is no way developers can combat this at such a small scale.
Normal rendering, showing a microscopic overlap:
wireframe rendering, shows several unnecessary triangles on this single joint:
zoomed out view to get a sense of scale:
@BelgianBikeGuy
2 Likes
This is an excellent update, especially on lightning
Hi @DanBuildsTrains,
I imagine this is in studio modeling. The current improvements are for the GeometryService Async API. That being said, we are planning on rolling out the improvements everywhere. If you want to send that case (or even just the small part that causes the issues in this example), we can take a look at it.
~BelgianBikeGuy
2 Likes
any sights set for mesh csg implementation? I love these improvements
I’d like to report an error regarding this.
I have an ingame saving system that allows me to save unions. If i copy this same union a couple of times, save them all using my saving system, then load it all in, it randomly errors and returns error code -11.
broken union.rbxm (3.2 KB)
Here is a video of it in action
https://streamable.com/ksyo5f
and an image of a printed pcall error
https://gyazo.com/be861aa0b062129bf437e6c6804cbcb9
Whats going on?
2 Likes
Hey! Thanks for reporting this issue. Are you using a local script to load the saved unions?
1 Like
No, im aware of the fact that CSG api does not work on the client. But i still have no idea whats causing this. I get the same error if i try to make an extremely large union, but also if i try to make a lot of unions quickly one after another
Theres a pattern to this somehow since if i load in two of the same save using my save system, its the same exact bricks that refuse to union. Could this be caused by WeldConstraints inside of the unions themselves? Because those are the only instances parented to the unions components.
Sounds like you are using the old API then (the new API does work on the client). If you switch to the new API in GeometryService, the -11 errors should be fixed.
And how do i do that? Switch to the new API i mean
Generally, switching should be fairly straightforward. Instead of mainPart:SubtractAsync(otherParts) you have to call
local GeometryService = game:GetService("GeometryService")
GeometryService:SubtractAsync(mainPart, otherParts)
The new API has a bunch of cool features that the old API does not have (like the ability to be called in local scripts). Please take a look at the documentation here for more information.
Also, back when we introduced the new API, we provided some example place files. These files are also a great starting point for exploring some of the more advanced features the new API has.
I think someone is going to get a nice raise lol, awesome work guys. This update is probably one of the best updates Roblox CSG has ever received.
There’s an issue I’m getting with the PartOperation:SubstituteGeometry API. It seems the center of mass isn’t updating with the geometry and as a result the part is ‘standing up’ when it settles on the ground. All the operations are subtractions.
EDIT: RBXM of a glitched part:
BrokenPart.rbxm (44.3 KB)
Hi @Wallath_00 ,
The issue has been identified and a fix was merged in. Thanks for bringing this up!
~BelgianBikeGuy
1 Like
I’m having an issue where, if using Substitute to preserve a Decal, the Decal will resize itself with the new PartOperation. This doesn’t happen if I take small chunks out of the PartOperation, but does happen if I take larger chunks. This would seem to be caused by the actual size of the PartOperation getting smaller with larger chunks taken out of it, causing the Decal to become scrunched, so it might just be intentional Decal Behavior but… It is really, really, really not making the Decal preservation of SubstituteGeometry seem very useful.
Below are example gifs of a PartOperation + Decal that I’m attempting to Subtract + SubstituteGeometry. You can see how the Decal awkwardly resizes to match the new PartOperation size. You can see in the last part how this doesn’t happen if you’re simply removing smaller chunks, and how it’d be very useful if the Decal always stayed proportionally accurate like that.
Gif also showcases weird thing where the PartOperation gets very tiny briefly as it loads in. This seems to defeat the whole “doesn’t flicker” sort of mentality, but don’t know if that’s studio only or has been documented yet.
Hey, thanks for reporting this. The object shrinking looks surprising to me. Can you share a reproducer so we can look into this?
Sure. This was pretty thrown together code + a mix of command bar usage though so I’ll have to go through and see if I can get it to happen again/reproduce. I was recording the gif initially to make note of the Decal sizes not actually scaling with the cut part, the weird shrinking object happening was a complete coincidence to catch while recording.
On that note, do you have any thoughts on Decals conforming to cut Substitute Geometry operations more accurately, or is the concern here mostly with the part shrinkage?
The decal resizing one might not technically be a bug, but it does render the decal functionality only sometimes useful when it could be more universally so if it correctly stayed the right size despite cutting parts down smaller
1 Like
Right now we simply box map the newly created PartOperation. It might make sense to preserve the UVs to not have the Decal move/shrink. There are a few details to figure out, but I agree with you that the current behavor is often not very useful.
1 Like
If you can figure it out, I’ve got a pretty interesting 2D terrain destruction game I’d love to cook up, which heavily relies on those UVs remaining & the decals on them not shifting around.