This is an example of something that’s really problematic in practice: That behavior is almost never what you want. If you set a pivot point to some point of interest on your car, you probably don’t want it to shift out of place when you resize one of the parts at the front or back of the car (which it would, because where the center is shifts when you resize stuff at the edge).
I’ve got you covered, please wait for the beta details!
This is not worth the change. Why are you adding a new property to instances for something that’s used exclusively by studio’s tools? Isn’t this what attributes were made for
Is it really necessary to add a property to models and parts for studio functionality? It’s reminiscent of old build-related properties like FormFactor and surfaces. Parts are the most common instance type in practically all games, so it’s very important that they stay lightweight and don’t get too much more bloated. If this is added, it should have absolutely no performance or memory impact on live games. Studio features should never hurt game performance.
We’d need more details, but so far I don’t see how a feature like this would improve the development experience. Pivots are very useful, but I’m not sure if this is the right way. Part pivots also seem less useful than model pivots.
The property will be used for much more than dragger behavior. It will be substantially useful ingame and tie into things like the mesh importing workflows as well. If it were only being used for the draggers then yes, we would use some thing like an Attribute or supplemental instance.
Also, don’t worry: If you don’t set Pivots on your parts, then this feature will not add an entire CFrame worth of memory to every part, I made sure of that.
So Pivot would be an offset of some kind. I can see this going a few ways:
Size matrix transformation when rendering, but this might be less intuitive.I’m mostly worried about BasePart:Clone() and Instance.new("Part") performance. It’s important that we can create as many parts per millisecond as possible, and every new property potentially affects this. Perhaps old features should be cleaned up first, like the 24 rarely-used surface properties: LeftSurface , LeftSurfaceInput , LeftParamA , LeftParamB , RightSurface , RightSurfaceInput , RightParamA , RightParamB , TopSurface , TopSurfaceInput , TopParamA , TopParamB , BottomSurface , BottomSurfaceInput , BottomParamA , BottomParamB , FrontSurface , FrontSurfaceInput , FrontParamA , FrontParamB , BackSurface , BackSurfaceInput , BackParamA , BackParamB.
It would certainly help if Instance.new("Part") was smooth by default. The need to set part.TopSurface and part.BottomSurface to Enum.SurfaceType.Smooth to create a “clean” part hurts performance and has always been tedious. If removing the 24 surface properties isn’t possible, it might still improve performance to internally group these properties as extended legacy data that works a bit like CustomPhysicalProperties/Tags/Attributes. Locked is also practically studio-only and would fit with this.
Remember all those changes to surface joining that broke building tools?
Removing these BasePart properties or changing their behavior is going to break even more old games.
Yes, and I am in full support of these changes. I joined in 2008 and what Roblox used to be is very nostalgic for me, but this was necessary to help Roblox transition into a proper game engine. These design decisions were made 15 years ago when building was core to Roblox as a game. Instead of bloating parts with building-related properties, building tools should instead use a custom abstraction. FormFactor was the first to go (being replaced by studio’s move increment), and won’t be the last. This is why I’m also skeptical of a new Pivot property if it’s only meant to improve building workflow in studio.
BasePart is a performance-critical instance with 24 surface related properties that aren’t used in 99.9% of cases. Games easily reach tens or hundreds of thousands of parts. As an alternative I’m also proposing that legacy properties are grouped together internally as extended data, so that they have practically no overhead on games that don’t use them. I have old projects from my childhood that rely on SurfaceTypes, and I would still be comfortable with these properties being removed someday (the same way FormFactor was) if it will improve how the engine performs.
These are already grouped. Unless you set one of the SurfaceInputs on a part to a non-default value the entire surface type information only takes up 8 bytes.
There’s also still lower hanging perf to pick as far as cloning and instance creation code goes than straight up having less properties, asking for that perf specifically as a feature is something you could do.
A Pivot property? Does this mean we can basically just change the origin/center of mass of a object so we don’t have to use offsets and do a CFrame * CFrame for everything? That’s neat stuff, I’m a big fan of that.
That’s a relief. Should just be a few hundred kb for my game.
Good point. Clone is strangely much slower than creating new simple instances.
This seems most likely. My biggest concern is whether this offset should be relative to BasePart.Size. It’s convenient to just resize parts and place them down without needing to also rescale the Pivot cframes. It’s pretty efficient to multiply a model’s cframe by CFrame.new(0,0,0, scale,0,0, 0,scale,0, 0,0,scale) before applying offsets to achieve a different size model, but would simpler to just change the size and have it offset automatically.
Or you could just like, you know, not call it Pivot?
Personally, I avoid using FindFirstChild because it doesn’t work with intellisense; the system doesn’t predict properties/methods for things that have been FFC’d but works fine with dots.
Since my variables rival Bangkok’s traditional name for “longest name”, this can get really annoying.
Still waiting for this to be fixed ;(
As I pointed out in another reply, my issue with intellisense is that it often breaks even with indexed children. I feel like this is even worse as with FindFirstChild you know you won’t get any predictions, while indexing sometimes works completely, sometimes it only offers properties and sometimes it does nothing.
“PivotPoint” is still short and convenient though. In fact, it tells me more about the property than “Pivot” does.
The only other property for models is “PrimaryPart” and that’s still longer than “PivotPoint.” Is it really worth breaking people’s projects to save a minuscule amount of time writing a few extra characters?
That’s a nice feature for animating stuff or just do advanced moving platforms maybe. I personally like it.
For anyone else that’s replacing tons of parts.
for i,v in pairs(workspace:GetDescendants()) do
if string.lower(v.Name) == "pivot" then
v.Name = "PivotPoint"
end
end
I would like to warn with anyone from doing this to avoid a clbuttic mistake of replacing things such as a variable or object named “Points” (Points system) with “Fulcrums”.
I personally only use FindFirstChild() if I’m checking if an object exists or not as to prevent erroring.
Or replacing “joint” with “connector” and forgetting to check capitalization so you replace BallJoint with Ballconnector at 3:30 AM and your brain is too fried to figure out when and why you typed Ballconnector and what Ballconnector is supposed to mean.
But, yeah haha, gotta add enough stuff so its not too vague. Something like IntelliJ’s variable renaming system would be really awesome.
Some old game that is no longer being updated is about to break seems relevant right about now.
Very cool to see new futures coming regardless, especially ones that can help with model rotation/movement.