Introducing an Engine-Level Model Scale API [Beta]

This update is another super useful addition! Massive fan of these type of improvements that make common tasks much simpler. :smiley:

A couple bits of feedback:

  • A Model:ResetScale() function that sets Model.Scale back to 1 without resizing the model would be useful for situations where you want to refresh the model’s scale (e.g. updated what’s in the model)

  • Setting Model.Scale in studio doesn’t respect Collisions (in the Model tab)


It’s a fairly deep discussion, but because the core architecture of the Roblox engine doesn’t support “dependent properties”.

Every property in the engine is supposed to be something that can “freely” be changed without impacting any other property directly. Downstream consumers of the properties like rendering may combine multiple properties to figure out what to do, but the properties are all fundamentally independent from one and other.

A lot of the engine architecture relies on this. Replication takes a advantage of the fact that it can freely change properties in whatever order on whatever timeline to be performant and robust even over a very questionable internet connection. Serialization takes advantage of this, not caring what order properties are written into the file in. Etc.

For that reason you can’t have a property like scale that sets other properties when you set it, a method is needed instead. The “Scale” you see in the properties pane in this case isn’t really a property, it’s a fake for editing convenience.


Oh wow, does this mean we can now just scale R6 avatars in-game without having to re-adjust or recreate all the joints, scale accessories and whatnot?


Yes, scaled rigs (R6, R15, or entirely custom) will just work including accessories, animations, etc.

Tools are the only caveat, if you want a tool to adjust to the size of your character you’ll have to do it explicitly by calling tool:ScaleTo(character:GetScale()) when picking it up since Tools don’t have a contract of automatic size adjustment.


For now we’re seeing how things play out without these to avoid complicating the feature unnecessarily. The current solution is to ungroup and re-group the model if you want to change the canonical factor. If that’s too awkward or artists need more control in Studio we’ll see about more affordances.


Love QOL things like these. Makes development process so much more… enjoyable. More times than I can count this would’ve been a godsend just yesterday.


Is this mainly due to technical reasons? Compared to pretty much any other game engine, Roblox Studio seems to be extremely behind when it comes to lighting. It creates a lot of difficulty when lighting other than world lighting is needed and constrains what you’re able to do when it comes to realism.

The Scale API is otherwise a great unexpected update, thanks!


Thank you so much for this. These have been some features I’ve been wanting for years and now they are actually real. This is amazing work! :slight_smile:

1 Like

I’ve been waiting for this one - solid release!

1 Like

Can you scale certain properties of a part such as Height, Length, or Width without scaling the entire thing?

1 Like

What it comes down to is that Roblox strives to be more dynamic than other engines.

When you’re willing to say “this is exactly what the level will look like” and precompute a bunch of lighting information, it gets way easier to have rich performant lighting. But we aren’t willing to say that: A lot of Roblox power comes from striving to be an accurate dynamic simulation of reality that doesn’t rely on precomputation and visual trickery to make things work. If we take the “be an accurate simulation” approach then that naturally creates a lot of forwards compatibility where Roblox content keeps working and automatically becomes better over time.

And that’s the TL;DR: If we implemented various lighting precomputation approaches you could create higher fidelity content on the platform now, but you would sacrifice future potential.

Think: Is it a good idea to push the ecosystem towards a bunch of rasterization centric lighting hacks when 10 years from now everything may well be using raytracing which is incompatible with those hacks? These are hard tradeoffs to make a decision on, and so far our choice has been to prioritize being dynamic over being as high fidelity as possible.


I hope that this new scale APL lets me to actually scale anything.

1 Like

That’s literally the entire point of scale? :face_with_raised_eyebrow:


Amazing update. Glad I don’t have to install a plugin for this anymore. So smooth. Might be an obvious question but, just to know for future reference, if I try to scale a 300 part model in real time, the game will crash, correct? (thinking about implementing the ant-man giant oil rig throwing animation)

You thanked yourself in third-person… lol


The particle scaling is a god-send. I cannot stress enough just how fantastic this update is going to be for work flow. Seriously, this is SUPER, SUPER useful. Thank you.

For my feedback, I’m fine with everything, but I do think instances shouldn’t scale when resizing a part, since parts don’t always scale uniformly. If someone wants to scale the part and its properties, they could just group the part, scale it, and then ungroup the part, which is super fast still with keyboard shortcuts. That would result in both functionalities being usable as opposed to just one.

Overall, incredible update. You guys outdid yourselves with this one, and I also really appreciate you reaching out to the community for further feedback on it.

1 Like

There’s nothing fundamentally wrong with calling :ScaleTo every frame. It does have the same caching as :PivotTo so you won’t run into floating point issues. You’ll just have to use your judgement because resizing physical stuff in the world is still significantly more expensive than moving it.

The big caveat is that you probably don’t want to scale stuff per-frame on the server because the operation will still replicate to clients as a bunch of separate Instance property changes, not as one atomic scale operation.

Per frame resizing of:

  • 3 MeshPart model? Reasonable use case.
  • 30 part prop? Still probably okay but you might want to reconsider if you’re considering doing it on multiple of these props.
  • 300 part house… questionable, might still work if you do it on the client only but would immediately throttle replication if you did it on the server.
  • 3000 part lobby? Things will definitely start exploding.

Sorry to bother, but I would like to know what is an engine level API? What’s the difference between it with the current state of the scale tool?

The old Scale tool was just a bespoke collection of Lua code which was written to work on specific types of Instances. You could copy this code out of the Scale tool and reuse it in a game or community plugin, but this would come with a lot of caveats. For Instance, there’s no guarantee that that code would continue to work on new types of Instance we add in the future.

Having an actual API in ScaleTo is us providing you some guarantees: That when you call ScaleTo on a Model, it’s going to scale that model in a consistent predictable way regardless of how the engine evolves in the future.

The other aspect is that when you call that API the engine can be a lot more clever about how it handles things, for example allowing packages to scale without modification. With the old scale tool Lua code it’s very difficult for the engine to figure out that what’s going on is actually a scale operation: All it sees is a bunch of separate property changes happening and the best it could have done was make an unreliable educated guess on whether a scale operation was happening.


Is this contemplated?

1 Like

That’s (almost) exactly what this is!

Though with the caveat that the content has to be in a Model (or temporarily be moved into one). This is a reasonable restriction because models are the Instance that has a 3d reference location in the form of their pivot, and you need some 3d reference location to do the scaling around.

Another reason for this restriction is that the model caches the “original” sizing for the extent of the session, such that you can rescale the model as many times as you want in the session without introducing a bunch of floating point error in object positions. It’s better to have only model pay the cost of supporting this caching rather than every Instance type.