Improvements to Part Shape & Size

Updates Announcements
#1

Hey everyone,

We have made a number of quality-of-life fixes to the BasePart.Size and Part.Shape properties over the last few weeks.

Let’s dive in!

Improvements to Size

Before, Size was supposedly locked so that X=Y=Z when Shape was set to Ball.
This behavior was broken in a way that could lead to clients and servers disagreeing about the size of the sphere. The Y and Z axes would only snap every other time Size was set to a new value.

This restriction has been lifted: Spheres can be given uneven sides, and the real diameter is the minimum of all three sides.

1104×712 63.8 KB

The new behavior has a few benefits:

  1. You can scroll through the shape menu without the size snapping to a weird value.
  2. Size behaves consistently for all part shapes.
  3. Size will be synchronized correctly between the client and servers.

We believe this is fully backwards compatible because the new behavior is a more predictable subset of the old behavior.

Improvements to Shape

Part.Shape can now be set to Wedge and CornerWedge from the properties window and scripts. You no longer need a class conversion plugin to turn a part into a wedge.

image

The Shape property was previously limited to Ball, Block, and Cylinder; developers had to insert explicit WedgePart and CornerWedgePart instances.

WedgePart and CornerWedgePart still exist and will continue to work. This change only adds Wedge and CornerWedge to Enum.PartType.

Finally, the Studio “Insert Part” button inserts wedges as standard Part instances with Shape = Wedge rather than inserting WedgeParts.

Please check out the following docs for more information:

We hope these quality-of-life improvements will make your 3D workflows easier. Please let us know if you have any questions or concerns below.

Enjoy!

484 Likes
CSG V3 Shading and Texturing Issues
Expansion of available Enum.PartTypes
ResizeAlign v1.3 - Rounded Join + Dragger Mode
Exporting OBJ non-uniform ball part produces wrong results
#2

This topic was automatically opened after 10 minutes.

#3

This restriction has been lifted: Spheres can be given uneven sides, and the real diameter is the minimum of all three sides.

Have there been any thoughts about allowing a version of the sphere that can stretch to fill the dimensions? SpecialMeshes with spheres can do this, graphically at least.

WedgePart and CornerWedgePart still exist and will continue to work.

Seriously glad to see this small bit of unification of the Wedge and CornerWedge. I don’t see any mentions that WedgePart and CornerWedgePart are deprecated though. Are there plans to mark these as deprecated so that people are more aware of this change?

124 Likes
#4

Will this possibly see the deprecation of SpecialMesh in the future if other block types such as Head or Torso get merged directly into the Part.Shape property.

That or the SpecialMeshes get converted to equivalent MeshPart objects so we can get proper collision geometry on them instead of a box.

80 Likes
#5

Not the best in terms of performance afaik, but a temporary solution would be to union your sphere & stretch it.

61 Likes
#6

I believe the next step for improving this feature is allowing ellipsoids.
I want to make a stretched sphere without having to resort to SpecialMeshes, or UnionOperation tomfoolery.

basically like what everyone else so far is saying.

Edit: Wanted to draw some attention to my recent post about feature requesting: Improvements to Part Shape & Size - #124 by MinerB4

85 Likes
#7

Yeah we wanted to avoid deprecating these too fast before there was any community awareness or adoption of the replacements. These will be deprecated eventually.

I’ll reiterate that WedgePart and CornerWedgePart will always continue to work - Deprecation will only give them a “deprecated” tag in the API to inform intellisense/etc.

Ellipsoids are a separate thing; today’s change is focused on making the existing behavior more consistent. Can you file a dedicated feature request or bump an existing one?

88 Likes
#8

Awesome!

I’m stoked that wedges/corner wedges will finally be easier to access, as previously I was unable to duplicate a part into a wedge whilst maintaining its properties.

Will we be seeing more basic parts, like cones, added soon?

IMG_1979
IMG_19791200×675 21.1 KB

Thanks!

113 Likes
#9

With all these QoL improvements for parts, it’s a shame that different icons for different part shapes didn’t make the cut. Merging Wedge and CornerWedge into the Part instance will just make it harder to differentiate the two in the explorer.

image image

71 Likes
#10

Ah, we missed this. We will make sure they get dedicated icons.

97 Likes
#11

Default shapes aren’t symmetrical (a cylinder and a ball). I struggle to create custom shapes that will fit default ones, because edge length isn’t equal for all edges.

image
image1293×900 38.7 KB

image
image1131×975 77.1 KB

112 Likes
#12

Will there be non-uniform spheres/cylinders in the future? The only way to make non-uniform cylinder or sphere is to turn it into a CSG/Union shape or make it a mesh part

47 Likes
#13

You can achieve stretching spheres with correct approximate collisions using MeshParts, as shown below:

image
image1342×579 29.5 KB

(White spheres are parts, black spheres are mesh parts with collision fidelity as hull.)
Spheres Demo.rbxm (11.3 KB)

However, I agree it would be much more convenient (and physically accurate) if this behaviour was built into parts set as spheres. :smile:

56 Likes
#14

Do NOT do that.

I have code in my game that creates mesh parts on the fly. Because of this, SpecialMesh must be used because you cannot set the meshId on a MeshPart at runtime because the collision data is determined when the engine starts up. Even if you create it in the script and haven’t parented it yet like this:

local part = Instance.new("MeshPart")
part.MeshId = "rbxassetid://2444943159"

That second line will throw an error in a running game. I can live with a box collision type on a SpecialMesh. The two classes exist for different reasons and have different capabilities. SpecialMesh enables us developers to do things that we can’t do with MeshPart.

52 Likes
#15

I never suggested removing SpecialMesh. This is a valid usecase for SpecialMesh that I too acknowledge, this is more of a suggestion of moving out the non-FileMesh types in SpecialMesh back into the Part.Shape property

Deprecation and Removed mean two different things. Not being able to generate CollisionGeometry on the fly is a bit of a weakness of MeshPart that could technically be possible now that DynamicMesh exists

40 Likes
#16

Even deprecated has a negative consequence for SpecialMesh. Now if Roblox merged the two and removed the collision limitation with MeshPart so that we can set the MeshId via script, then there would be no issue.

As for DynamicMesh, there is no mention of it in the documentation. Beta feature maybe?

41 Likes
#17

I- What?!? How?!? Yeah, I’m really hoping that gets fixed

37 Likes
#18

I’ve ran into this too. Best solution that I have found is to use a mesh for those parts so they will line up.

39 Likes
#19

Upstream on a beta channel release, should be merged later this week (though probably not enabled)

35 Likes
#20

Note that a triangle mesh can’t correctly model a round ellipsoid.

Roblox physics treats spheres as perfectly round with no triangles or edges. You can test this by rolling a sphere along a baseplate - it rolls for a long time without losing much energy besides some losses from the integration of motion.

If we add ellipsoids, we would treat them the same as spheres, and they would have correct quadric collisions. This is probably the main reason we would add an ellipsoid type besides convenience.

It would make sense for feature requests about this to focus on the use cases for “correct” ellipsoid collisions.

45 Likes