Nonuniform Unions: Now Available on Production

Updates Announcements
,
#1

EDIT 24/01/2023: The rollout of this feature has now been completed. All unions on Roblox now scale nonuniformly. If you still need to migrate legacy content in the future use this plugin which has the same migration code switching the rollout flag originally did.

Overview

Currently, if you resize a Union and a MeshPart with similar contents, you will find that they have different scaling behavior. Specifically, Union scaling is letterboxed such that the union contents only scale uniformly.

With Nonuniform Unions, Unions will instead have identical scaling behavior to MeshParts, allowing non-uniform scaling of the contents.

This is a feature that has been in beta for some time and is now ready for full release.

The Changes

We are introducing a three-phase rollout property UnionsScaleNonuniformly under Workspace. This rollout property replaces the “Nonuniform Unions” beta feature.

If you were using that beta feature, enable the rollout property to continue using the functionality.

  • If UnionsScaleNonuniformly is set to Disabled:
    • When you resize a Union and MeshPart with similar contents, you will find that they have different scaling behavior. Specifically, Union scaling is letterboxed such that the union contents only scale uniformly.
    • Union visuals/collision geometry are clamped at 0.05 studs in size even when the union is smaller than that. This is due to a bug that we are currently aware of.

image

  • If UnionsScaleNonuniformly is set to Enabled:
    • When you resize a Union and a MeshPart with similar contents, they will have identical scaling behavior, both expanding nonuniformly to fill their bounds.
    • The bug with minimum part size has been fixed, and union visuals/collision geometry will exactly match the part size all the way down to 0.001 studs in size.

image

  • If UnionsScaleNonuniformly is left as Default, then the scaling behavior will depend on what phase the rollout is in, initially being treated as Disabled and then later being treated as Enabled (see the Rollout Schedule below).

Auto-Migration Behavior

Many will recognize that this constitutes a breaking change.

While not all places use unions, and the vast majority of unions out there are uniformly scaled currently (so won’t be affected during the transition), any unions which were manually resized to proportions where letterbox scaling was applied to them (through the properties pane or community plugins) will be affected:

  • Any previously letterbox scaled unions will expand to fill their bounds rather than being letterboxed (compare the Disabled → Enabled transition in the above screenshots).

  • Any uniformly scaled union smaller than 0.05 studs on every axis will visually shrink to exactly match the part size instead of being limited to 0.05 studs in size.

To ease the transition, we have introduced an auto-migration behavior which will optionally resize the unions in your place for you when changing Workspace.UnionsScaleNonuniformly from Disabled or Default to Enabled. When you do so, you’ll see the following popup offering you a chance to run the one-time migration:

image

As the popup suggests, the migration should only be run on old content created under the previous scaling behavior. If you’ve already been working on something under the Nonuniform Unions Beta you should decline to use the migration.

The auto migration cannot help with script interactions that depend on the size of particular unions or resize unions at runtime, so double-check your behaviors after setting UnionsScaleNonuniformly to Enabled if you think you might be doing those things.

Rollout Schedule

1) Workspace Flag Available - August 15, 2022

The UnionsScaleNonuniformly property is available under Workspace, please set it to Enabled and run the migration as soon as possible if your place makes use of Unions! (Or Disabled if there’s something nontrivial in your code that you need time to adjust).

2) Workspace Flag Enabled by Default - August 29, 2022

On August 29th, 2022, any place which has not explicitly changed UnionsScaleNonuniformly and still has it set to Default will automatically begin to have its unions scale nonuniformly. As mentioned above, this will constitute a breaking change for some places but can be resolved by performing the auto-migration in Studio in almost every case.

3) Workspace Flag Removed - January 24th, 2023

Eventually, once everyone who explicitly disabled the feature has had time to deal with the issues preventing them from migrating, the flag will be removed and unions will scale nonuniformly forevermore.

New Union Property MeshSize

In order for plugins to effectively operate on unions that have been scaled nonuniformly, the MeshSize property which was previously only available on MeshParts is now also available on unions and will be equal to the size that the union was when it was first created.

Plugins can set union.Size = union.MeshSize before separating to have a guarantee that the union will separate cleanly. (The “Apply Scale” behavior will be used to resolve things in the case where a plugin uses Separate on something that cannot be cleanly separated)

FAQ

Will my experience break?

  • Most likely not. Even if you don’t run the migration, from our beta feedback and analytics, the vast majority of unions either won’t be affected or will only change slightly in ways that don’t impact gameplay. If you want to be safe, run the migration.

I’m not seeing the migration popup. Where is it?

  • If you changed the property to Enabled and did not see the popup that means none of your unions required migration, nothing to worry about!

Why not automatically do the migration?

  • This is a path we could have taken, however since the migration can actually do more harm than good in rare circumstances, and we do not expect many places to be negatively impacted in the first place, we opted for manual migration instead. A reasonable number of unintentionally letterbox scaled unions actually getting fixed by the change also played into the decision.

Can I use the migration more than once?

  • Yes, if you set UnionsScaleNonuniformly back to Disabled, the migration will be offered again when you re-enable it.

What about migrating after the rollout goes away?

Thanks to @tnavarts, @tnavarts, and also @tnavarts for their hard work on this feature! - Yes I’m thanking myself :sunglasses:.

168 Likes
Unions shrinking/ Unions break
Non-Uniform Union Scaling Beta
Meshes Scaling Improperly
Roblox Studio Distortion
Nonuniform Unions Release Rollout has caused some models to morph / scale
Decals are "squished" and look different on spheres
#2

This topic was automatically opened after 10 minutes.

#3

Interesting change. Is anything planned to change for how the UnionOperations themselves will be generated? Currently, the use of unions is quite bad as they offer poor performance and MeshParts are considerably more favourable.

14 Likes
#4

There’s lots of other work being done on the CSG system. Things like reducing the amount of extra unnecessary verts / edges in Unions (one of the main reasons for the poor performance you’re referencing) are on the team’s radar.

22 Likes
#5

Ooh, that’s great news. Thank you :smiley:

5 Likes
#6

I should also note: There’s nothing fundamentally “lower performance” about Unions. If you’re careful with how you do your union operations, you can actually get a union with identical runtime performance to the comparable mesh because they use the same TriangleMeshPart rendering / physics at runtime.

However, that unfortunately may require creating your unions in some less than obvious ways. In order to get optimal unions you should generally never union things in a way where you have two exactly coplanar faces that touch or intersect. For example, if you want to add a bump to the surface of a part, you should make sure that you “sink” the bump into the surface slightly before unioning it to the part it’s on otherwise extra vertices may be created at the plane where they exactly touch.

There’s additional work we could do there to make it so you don’t have to do such things to get the performance you want out of unions, but it technically is possible to squeeze out that performance already if you’re willing to put in extra effort.

25 Likes
#7

This is very interesting news. You mentioned CSGs being comparable to meshes - would this apply in terms of memory usage also? Since as far as I understand, CSGs must store the components which they are made up of, compared to meshes which do not need to do so.

3 Likes
#8

Yoo, finally! Very useful changes :smiling_face_with_three_hearts:

4 Likes
#9

it’s about time this crap happened, should have happened way sooner

4 Likes
#11

CSGs store that child information as a cloud asset!

That’s why you see unions flicker when you publish your place, the child information getting converted from working copies and hidden away in a cloud asset. At runtime that cloud asset is never actually loaded, so you’re not paying any additional cost for the child info at runtime, only at edit time. (Okay, you’re paying some additional cost, but literally just a dozen bytes worth for the unused asset reference, not the significant extra cost many developers expect they would be)

19 Likes
#12

Yay! Excited for this update, great job!

4 Likes
#13

Is anyone else besides me getting the broken images in this thread?

image
image954Ă—522 104 KB

24 Likes
#14

Been noticing a lot of announcement posts getting the broken images. :thinking:

Regardless, very nice that its an option to have it be on or off :+1:
Being able to keep it is always a plus.

4 Likes
#15

I had a question, when I export a union into and obj and load it into blender, it is crazy, with all sorts or random seeming verts and faces, just a real mess.

Is this the way it actually is in the roblox game, after its been constructed from the cloud parts? or do unions just not export accurately into an .obj

1 Like
#16

Unfortunately what you see is what you get: That extra geometry is where unions get the reputation for being low performance. As I mentioned above you can carefully do your unions in such a way that you don’t end up with the extra geometry, however most people aren’t interested in putting in that extra work or don’t know how (no fault of their own, we don’t exactly have a guide on how to do so).

9 Likes
#17

since the introduction of non-uniform scaling beta, I have experienced major issues with unions not scaling and subsequently shrinking in production. This shrinking behavior is only applicable to live versions. This supposedly was shared with the engineers, but It effects 1 in every 3 unions of mine.

This thread shows images of the shrinking. The unions in my games are shrinking

1 Like
#18

Could you PM me an example of an affected model?

2 Likes
#19

Please correct me if I’m wrong but, would it be accurate to say that a Union will perform exactly the same as a Mesh with an identical TriangleCount?

Ever since CSGv3, it’s become much easier to create simple (but important) unions like rhombus and non-scale triangles that are often needed when building at an angle with TriangleCounts as low as 12 (which as far as I can tell, is as low as you can possibly go).

This ability to create such efficient Unions, and now this new nonuniform scaling feature has really empowered me and my team to use CSG far more, where we would have had to use MeshParts before.

2 Likes
#20

I have almost every post that not mine with this images, instead of normal ones. It’s weird.

Also, new nonuniform unions are just awesome. But I think mesh parts are still better?
Also, I have 1 question - will be unions nonuniform scale with script changes?

1 Like
#21

I love this. I’ve been waiting for ages for an update like this, and I can’t be the only one.

2 Likes