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.
10 Likes
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!
4 Likes
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! 
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.
14 Likes
I hope that this new scale APL lets me to actually scale anything.
1 Like
That’s literally the entire point of scale? 
3 Likes
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
2 Likes
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.
7 Likes
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.
6 Likes
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.
2 Likes
I love you
- love maple hospital dev team
3 Likes
Not quite friendly, right? If I have, like my example, a folder of distinct objects, and I want to scale them all proportionally, exactly like in studio, will I need to create a temporary model, move the folder as child of this model, scale the model, move back the folder again out of the model, delete the model? And will I first need to know the total size of the model to put all objects inside first?
1 Like
The idea here is that if you want to scale something geometrically it should be a Model, since Models are the geometric container that we put geometric operations such as movement, bounding box calculations, and now scaling on.
And will I first need to know the total size of the model to put all objects inside first?
No, the size doesn’t have to be involved. All you do need to do is set the WorldPivot of the model to the point you want to scale around. And you’d have to specify that point regardless even if there were an API not associated with Model.
If you are in editor then you can just use the scale tool. If you’re not in editor it should be easy to write the code to use a temporary model. Or a permanent one… if you really need something to be a Folder for editing convenience you could even have Lua code turn it into a Model at place startup time if you plan to scale it / move it around at runtime.
5 Likes
How come this means that light ranges can’t be extended? This staff reply made it seem like it was being looked into, not that:
Did something major prevent an extension from being possible? There are many things that make longer light ranges important (e.g. even a moderately tall structure can’t have lights reach from the top to the bottom, a lamppost can only light up a tiny area).
2 Likes
Sorry for the confusion with the mixed messaging, but there is a method to the madness, edited the post to have less mixed messaging
Short story: Some extension of light ranges (even a fair amount) may be possible but not enough to make it play nice with the scale API.
Long story:
Given how extremely conservative the current limit is, and just because of how lighting works, even if some extension of light ranges happens, developers are still likely to set the light ranges right up against the cap most of the time.
The scale API still needs to respect the underlying limits, so if you scale something that’s already up against the limit up, it won’t increase. But when you scale that thing back down it will decrease. That means with light ranges that are already always up against the limit, scaling them is actually counterproductive because it would actually decrease light ranges more often that it would handle them properly.
Add this to the general mechanics of lights, where range is a weird property. You’re incentivized to set it as high as possible regardless of whether you actually need the range so that you don’t have to fiddle around with it again as you move the light. That means no matter how big we make the range limit people are likely to often stay right up against it.
Light ranges are just a really weird case for the scale API.
5 Likes