This mustâve been âscaledâ down
What happens if you modify a model in 2x scale? Can it âwork backwardsâ for instance?
I can see this particularly being useful for the old-school style of detailed model & weapon building, which used to traditionally be done with a large-scale model scaled down via a script. If you can start making a model at a high scale, then scale it down after, this could be interesting.
Though, Iâm skeptical of the âit just worksâ claim. Developers should be wary of ever using such bold terminology, lest they invoke the curse of Todd Howard.
1 Like
It would inevitably become a plugin tool eventually, and thatâs fine. I just think when this is released, it will be disruptive in normal use. I think including a toggle for a perfectly reasonable alternative implementation of the resize function (probably) wouldnât be too heavy a maintenance cost + would be tremendously more convenient being directly integrated with the draggers than a separate plugin would be.
E.g. I could reimplement my own dragger just to have plane handles, but it will be a pain to use because I would have to switch between the dragger and my plugin often, and my plugin button would not live in the same place as the dragger buttons. In the same way, nobody wants a separate scaling plugin just so they can resize a model without messing up e.g. fine tuned visual effects, light ranges, or textures that should stay consistent throughout the world, when this was previously how the built in dragger worked. Both methods of scaling have strong use cases and arguments for being the default way the scale tool should work. Scaling this way is already inherently opinionated.
In a nutshell, it would be fine as a plugin, but it would not be convenient to use with the way Studio currently shows plugins to the user, even with the quick access toolbar (extremely small button, or else a hotkey to memorize).
1 Like
Deciding whether or not to have some sort of modality in the API was actually the most difficult part of building it. Having the modality is actually a very expensive choice.
The dragger UX gets quite tricky, mostly around knowing what mode youâre in. Itâs not as simple as having a mode because a lot of the potential changes that the âscale everythingâ mode can be making arenât visual changes, or arenât that obvious even if they are (E.g.: Constraint limits). That means itâs really easy to scale something in the wrong mode and not immediately notice it, and especially if you scaled it further in the other mode later, unwinding from the situation can be basically impossible without manually fixing up each Instance.
Packages present friction with having two modes as well. Only having a single mode makes the UX and mechanics of how scale interacts with packages considerably simpler. Otherwise packages effectively have to have some sort of additional modality of what scaling behavior theyâre using. That or have packages just count as modified with one of the modes, which is an unfortunate outcome.
4 Likes
Great update! Will this work with tools as well or is it only models for now?
they recently did an update that made tools inherit from the model class as well. so the answer to your question is yes it also works for tools 
I remember reading about that change but I didnât know that tools would also get all of the same functions as models.
Does this support all âweldingâ types? (not sure what the right word for it is but stuff like motor6d, manuelwield, wield, etcâŚ)
Yes, Weld, WeldConstraint, and RigidConstraint should all work.
1 Like
The new Scale API is so useful. Iâve managed to make a cool item spawning system, where it animates it growing and dropping. This took use of using Tween Service, but due to it not supporting tween service for scaling, had to make my own work-around. Would be very useful for my new upcoming game.
However, this brings up the question; What is the E.T.A release date for this API to the public for live experience use?
1 Like
Could easily be a couple of months, because first we have to fix all the bugs and then weâre also going to include an opt-out period given the workflow changes with the scale tool.
3 Likes
Iâve experienced some issues with this in our game. We use vehicle models inside ViewportFrames and for whatever reason this has caused parts of the vehicle to have incorrect positioning when the model is scaled to anything besides the original import scale (1).
It works perfectly fine in studio but whenever in a live server this issue occurs.
As soon as I set the models scale property back to 1 everything is back to normal.
Also, it only seems to occur when using the :Clone() method on the specific model that is scaled up. Otherwise, it works fine if youâre just putting the model in the ViewportFrame manually even if itâs scaled differently.
Only way I found around this is to select only the parts and scale it that way.
There might be an easier way but this is what I found to work for a quick patch for our game.
Edit: ScaleTo(1) wouldâve worked but obviously its not enabled in live servers yet.
Maybe try using a WorldModel in the ViewportFrame? Joints dont work in normal ViewportFrames
Could you try to make a minimal repro which you can share so I can debug?
I donât have any guess as to whatâs going wrong there, since the only ingame impact of this change so far should be animation scaling (the rest of the changes are only under the beta feature which isnât live), and I donât imagine youâre playing AnimationController based animations on your vehicles.
Okay, that âNopeâ example was pretty funny. I did NOT expect that!
Jokes aside, this is SUCH an amazing feature. The ability to not just scale models but also particles, and possibly player models, and so much more is just so, SO exciting. This can bring SO MANY possibilities onto the table that previously werenât possible.
Props to the team who helped make this! This is such an amazing step forward.
We finally donât have to rely on a plentiful of calculations and other stuff to just scale down a character rig. FINALLY.
I think this has already been hinted at in this thread, but hitting upper/lower limits with part sizes can be a pain.
e.g. if I set the Scale property (or use ScaleTo()) to something really small or big (something that exceeds a childâs part size min/max), then set Scale back to 1, itâs all wonky. My general thought is that this should restore to the original size of the model.
Iâm not sure what the solution would be. Maybe limiting the scale to not cause these properties to exceed limits? At least an option to have that constraint?
A use-case might be tweening in a model from a 0-scale up to 1-scale.
2 Likes
Weâre actually considering changing this so that at least within a DataModel session if you x = GetScale(), ScaleTo(y), ScaleTo(x) you always get back where you started.
The tradeoff is that itâs a little bit less efficient that way, because the API has to ask the engine what the scaled property values are an additional time so that in the future it can tell the difference between a value that was limited by value limits (which should be ignored) and a value that was deliberately changed by the user (which should be taken into account), vs currently it just treats those two the same way which is why you see the âwonkyâ result.
Edit: Implemented this change, will update when it releases.
1 Like
That would be cool! I guess in the time being it wouldnât be too hard for us to write our own constraints for this. Thanks for working on this feature btw, super cool!
This is nice! Iâve recently had some issues while scaling characters, letâs see if this fixes it.
Hey, sure no problem.
Hereâs a place file with a minimal repro:
ModelScaleBugRepro.rbxl (244.6 KB)
Seems after further investigation that Model.Scale has conflict with PivotTo()
when parenting to a ViewportFrame.
1 Like