Prevent unanchored parts pushing (clipping) into each other

So I built a tower out of blocks (only the bottom row is anchored). I hit play and the top drops a few studs then continues to sink until it settles. I also have a curved wall and the middle of it blows out due to the topmost bricks dropping about 0.2 studs onto those below. Weird because I figured a wall of 30 x 2 stud bricks would be 60 studs tall. It’s not.

This seems to be because every level of stacked brick enters the one below it just a little bit when the physics kicks in. This is obviously most noticeable at the top. In Studio the bricks are all 2 studs tall and are exactly 2 studs apart on the Y axis.

As a test I stacked one brick on another brick (which was anchored). Hit play and the position of the top brick drops a fraction into the bottom brick, i.e. the bottom surface of the top brick should have been sitting at 2Y but when simulating it drops to 1.992Y. The top surface of the brick below is still achored at 2Y.

I’m assuming this is normal and parts are somewhat squishy? Is there any way to stop this compression under gravity? I tried upping the density but that didn’t help…

I don’t really want to anchor each row of bricks. Kinda defeats the purpose of what I want to do if they can’t be moved by an external force.

Thoughts?

4 Likes

You can use a weld surface in properties. If you’re trying to make something where you can shoot it with a rocket launcher per say check out this Video. For more information I’d recommend YouTube and Google. Also you could use a Weld script maybe the one by Quenty.

3 Likes

Cheers for that. I hadn’t looked into surface welds before for this purpose. However when applying using SurfaceType it seems to have no effect whatsoever. I’ll defs check out the Quenty weld plugin tho.

I’m a bit confused as the SurfaceType doco (https://developer.roblox.com/en-us/api-reference/enum/SurfaceType) for Weld says:

"Makes the side appear with thick diagonal “X"s. Creates a join to any surface except for Unjoinable.”

And yet this update (Changes to Part Surfaces) seems to contradict that:

“After this change, SurfaceTypes will have no absolutely no impact on building, and only exist as a visual aesthetic (with exception for Hinge and Motor). Auto-welding can still occur if turned on, but the SurfaceType will have no control on the type of joint or weld being created.”

Seems like that should be mentioned in the doco if it’s true.

My blocks are unions, though they are completely flat top and bottom. Maybe that makes them unjoinable? How does one tell…

Maybe I need to add WeldConstraints to every block (that’s a lot of welds) since old fashoined welds seem to be on the way out… (that same blog post again):

Further down the road, you can expect more changes that will slowly phase out Surface Joints all together, so you should refrain from relying on them for your new games.

1 Like

So I tried qPerfectionWeld. Pretty cool. Nothing moved but my castle jumped out of the hill it’s half in and rolled off the map :stuck_out_tongue:. I might just have to redo it without terrain touching it at all.

I’m guessing that parts sitting on top of each other will always just clip a little bit due to minimum collision distance? i.e. the height of a wall of 10 unnchored parts will not be the sum of the individual part heights (even if the bottom is anchored), it’ll be just a smidge less. This is pretty annoying since the wall will instantly be in motion, bounce a bit and probably fall over.

I noticed an interesting (if old) thread here that seems to highlight some of the clipping issues: Unlock scaling of all BaseParts under 0.2

If this is expected then that’s fine. Just need someone to say that the physics just works that way. i.e. vertical positioning is unreliable by design unless anchored/welded.

Have you tried using a Weld for the blocks?

1 Like

Yep, that’s what qPerfectionWeld does. Just weld everything together. I was trying not to weld. Just place block on top of block. Other engines like Unity handle this fine and nothing moves… If Roblox doesn’t, it doesn’t.

Alright! Have you fixed the issue?

Haha, no. :slight_smile: but I might have to resort to welds.

As an experiment get 10 x 1Y blocks and stack them up. The hit play and take a look at the Y position of the topmost block.

I see, well until you find a solid solution, I suggest to stick with welds :laughing:.

1 Like

So it seems the mimimum part size is now 0.05. Noting that, I stacked the same 10, 1Y tall parts, overlapping by 0.05 on the Y axis, so the topmost part’s Y position should have been 9.5 (instead of 10).

After hitting play it dropped to 9.499. So, I guess that’s one (if fairly dumb) way to stop the bounce, i.e. just pre-clip your parts! :face_vomiting:

This post (Part Size Min 0.05 is now enabled) says:

There are some known problems with physics stability for non-anchored parts under 0.2.

… but plainly this happens to parts of all sizes when calculating collisions.

I think this evolved into a physics engine question, so I’ll mark your answer as the solution :wink: I might pose a query in a different category.

The surface join change means you can use surface welds on your part without needing to change all their SurfaceTypes, you can just turn on “Join Surfaces” (next to the Move tools) and parts that are touching will weld together one moved/dragged/created. You can tell if a weld was made because it will show up as in instance in the Explorer. The documentation needs to be updated.
WeldConstraints though would be more reliable, and faster to insert. Simply select all the parts, and choose “Weld” from the Create dropdown in Model>Constraints. It’s the same number of welds either way.

Your actual problem with the parts “clipping” though is something else, and a bit more difficult to solve. It’s true that the collision system allows for small interpenetrations between parts for stability reasons, with a maximum of 0.05 studs. The amount something will actually interpenetrate can depend on how heavy the parts are, and your gravity setting, so changing those around to make things lighter could give you better results.

Understanding more details on how your tower is set up (along with mass and gravity), and more about your intended use case (why do they need to move?) can help me figure out some better solutions for you. I’m hesitant to say that using WeldConstraints would be your solution right away.

I didn’t find the auto SurfaceWeld thingy very helpful so I turned it off. Shouldn’t it be creating WeldConstraints anyway if plain old Welds are destined for the bin?

Interpenetrate! Nice. Triple word score. I was trying to think of how to describe it. My wife suggested “overlap.” Pish posh I say. Far too pedestrian for us smart people.

So as a test, I welded everything together with WeldConstraints. I used GetTouchingParts() and added them for every touchpoint. This initially returned 0 touches as I guess all my parts were only “adjacent,” not “intersecting” (i.e. interpenetrating!), as per https://developer.roblox.com/en-us/api-reference/function/BasePart/GetTouchingParts

Parts that are adjacent but not intersecting are not considered touching.

That line makes sense now thanks. I didn’t get it initially. Maybe a little diagram would help slow peeps like me. :stuck_out_tongue:

…so I added a fudge to my tower builder script to overlap rows of blocks by 0.01Y. That did the trick, touches detected, welded tower complete. So many welds. e.g. Part A has a weld to part B and Part B has a weld to Part A. Feature request: detect redundant welds like that.

So the point of my tower is… to knock it down :slight_smile:. This is tricky when its welded. You can knock bits off given enough force for sure, but you end up with whole sections hanging, suspended by one lone weld someplace else, e.g. the top’s not going to fall off the tower unless you blow away all the blocks with welds in a clear ring below it. Then when it does finally fall it just rolls off the map like a garbage can on a windy day instead of falling to bits when it hits the ground.

Now I reckon I can probably do some trickery with destroying welds in a radius on hit or maybe by detecting the weight of what it’s supporting (like a load bearing limit, hey that would be a nice enhancement to WeldConstraints) and also maybe breaking if they drop x studs below their starting point (though I’d probably have to do that on a RenderStep?)… but if I didn’t have to weld in the first place and could just rely on the physics realising the blocks should be at rest… anyway, this isn’t supposed to be a winge, I just want to work within the constraints of the physics. I know if it was easy then you guys would have coded it to be more realistic.

Like I mentioned before, unless you specifically need to generate the WeldConstraints at runtime, you can just select all the parts in the tower and choose “Weld” from the Constraints menu. I believe it’s more forgiving than GetTouchingParts, and will instantly weld all the touching parts together. Should save a lot of time. This also will not create duplicate welds between the same two parts. If your script made two welds between each part, then that’s an issue with your script… Additionally, you can tell if a WeldConstraint is a duplicate because it will have Active disabled. They show up grey when you have WeldConstraint visualization on.

For now, if you want these parts to break welds on impact and other forces, you’ll need to implement a system for this yourself.

I’m still curious though, how did the part interpenetration impact your goal for your game? Do they need to remain at a specific height for some other mechanic? Did you try making parts lighter the higher up on the tower they are, or reducing gravity? I experimented with this a bit and was able to get them to overlap less.

1 Like

I’m generating the whole thing procedurally so I used the Active bool to delete the redundant welds. Thanks for the tip. Interesting that all bar one weld to the anchored base was made inactive.

The interpenetration affects the game because parts move when they should be at rest and tower falls over by itself. Players are meant to destroy it themselves. Not too worried about the height being exact. I get it’s not a CAD tool. If I just stack up blocks then the entropic byproduct of the physics engine (i.e. parts that should be at rest fall 0 - 0.05 because they are adjacent not overlapping) will knock it down without the player doing anything at all.

I imagine this will all be a bit less dramatic once the mimimum distance gets to 0.01, maybe. I think what would be really super would be an inertia or dampening attribute we can set. Watching the collisions it’s the ripple effect of small movements through the structure that kills it.

The only way I’ve managed to get it to not fall down every time without welding (only about half the time now) is to set every block:

  • Massless
  • Zero Density
  • Maximum Friction
  • Zero Elasticity

So it’s like a tower of sandpaper feathers. Works ok but if a Roblox bee runs into it it’s toast.

Without knowing anything… it looks to me like the phyics goes something like this:

  • apply forces (e.g. gravity, BodyForces)
  • move part to new position
  • check for collision
  • repeat

Checking for collision needs to be first. Then if I overlap my flat parts they shouldn’t move, i.e. they can’t accelerate as the force of gravity is perpendicular to their contact surface. Ideally it would be also be a check for adjacent as then I don’t have to overlap them.