Upcoming Potential Property Name Conflict: "Pivot"

Updates Announcements
#41

So Pivot would be an offset of some kind. I can see this going a few ways:

  1. Pivot will offset the graphics and physics of a part from its CFrame.
  • Would be convenient, but doesn’t add any new functionality.
  • This could improve performance in cases where many parts need their CFrame’s updated regularly with an additional offset. However, it has the potential to slow things down by requiring extra ToWorldSpace operations internally.
  • When rescaling models or parts, Pivot would need to be adjusted along with Size. Pivot could be applied after the Size matrix transformation when rendering, but this might be less intuitive.
  1. Pivot will offset the graphics and physics of a part relative to its parent.
  • This would prevent matrix creep when copying or dragging models.
  • This is standard in other engines but I can’t really see this happening in Roblox.

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.

5 Likes
#42

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.

1 Like
#43

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.

1 Like
#44

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.

2 Likes
#45

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.

#47

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.

2 Likes
#48

Or you could just like, you know, not call it Pivot?

4 Likes
#49

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 ;(

3 Likes
#50

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.

1 Like
#51

“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?

4 Likes
#52

That’s a nice feature for animating stuff or just do advanced moving platforms maybe. I personally like it.

#53

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
4 Likes
#54

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”.

2 Likes
#55

I personally only use FindFirstChild() if I’m checking if an object exists or not as to prevent erroring.

5 Likes
#56

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.

3 Likes
#57

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.

#58

It doesn’t really make sense to have children and properties accessed the same way since any new property can potentially cause bugs out of nowhere. FindFirstChild and WaitForChild should have been the only way of accessing children from the start.

It wouldn’t be an issue in other engines, but Roblox forces updates, so you cannot stay on an older version for stability.

5 Likes
#59

I do agree with you to a point. Accessing children and properties seems like it needs to be separated, but saying that FindFirstChild and WaitForChild should be the only ways of accessing children from the start.

#60

No property name is free. In this very thread TheAmazeman gives a code example where he has Instances called PivotPoint.

2 Likes
#61

If there’s no reason an instance shouldn’t exist, it’s unnecessary. (i.e if the model was cloned locally from ReplicatedStorage or something). If I want to quickly index an object under a safe model’s hierarchy I’m not going to chain together 4 FindFirstChilds

9 Likes