Pivot Editor: Full Release

Current Pivot Status: Rolled out to 100% of users, opt-out still available

We’re excited to announce the full release of pivot functionality in Roblox Studio! Over the next couple weeks we will be rolling the pivot functionality out to all Studio users:

  • We will begin with a small 10% rollout. If you don’t see the pivot editor, don’t worry: You aren’t part of the rollout yet but you can still enable the pivot functionality yourself by turning on the “Pivot Editor” beta feature.
  • Is the pivot functionality disrupting your Studio experience? For the time being you can opt out of the rollout by disabling the “Pivot Editor” beta feature. We will eventually remove the beta feature and the ability to opt out, so if you opt out, please reply with the issues that caused you to do so.

Here’s a link to the DevHub documentation, and the following is recap of the key pivot functionalities for those who weren’t following the beta progress:

The Pivot Indicator

Each part and model now has its own configurable “pivot” around which modeling tools and some Lua APIs manipulate it. When you select tools that manipulate the position of objects (Move, Scale, Rotate, or any community plugin that sets DraggerService.ShowPivotIndicator = true), you will see pivot indicators drawn on top of those objects showing where their pivots are:


Changes to the Draggers

This release brings a couple changes to the visuals of the Move, Scale, and Rotate tools. The handles of these tools will be shown around the pivot. The Move tool’s handles have also been moved inwards, such that they display directly around the pivot, rather than out at the edges of the selection.

Alongside that change, you can now “summon” the handles of the Move, Scale, and Rotate tools directly to your cursor by holding down the Tab key. This allows you to manipulate the selection easily regardless of where your camera is looking and adds additional functionality to the Rotate tool:

Okay, that sounds great, but how do I actually set where the pivot is…?

Editing Option 1: The Edit Pivot Tool

There is now a “Pivot” section in the Model tab, with an “Edit Pivot” tool which allows you to set where on a given part or model the pivot is located:


When you select an object with the Edit Pivot tool, you will be able to modify the pivot in 3 different ways:

  1. Moving the pivot with a set of Move handles.
  2. Rotating the pivot with a set of Rotate handles.
  3. Freeform dragging the pivot by dragging the pivot indicator directly.


When the “Snap” toggle in the Pivot section is turned off, the pivot can be freely moved. When it is turned on, the pivot will snap to “key points” on the bounding boxs of objects:


Editing Option 2: The Properties Pane

You can also edit where an object’s pivot is numerically via the properties pane. Models and parts work slightly differently in this regard:

  • Parts have “Pivot Offset” properties, which specifies the local offset of the pivot from the CFrame of the part.
  • Models without a PrimaryPart have “World Pivot” properties, which specify the location of the model’s pivot in world space.
  • The pivot of models with a PrimaryPart is exactly equal to the pivot of their PrimaryPart (The Properties panel shows the “Pivot Offset” properties of the selected model’s PrimaryPart for convenience in this case).


As seen above, we’ve also added “Origin Position” / “Origin Orientation” properties to models and parts which let you move a part or model around via its pivot.

Editing Option 3: The Lua API

NOTE: These Lua APIs are already live on production, you can begin using them whenever you want!

Finally, there are Lua APIs to both change where a part or model’s pivot is, and move that part or model via the pivot point:

For example, to move a model 2 units “up” relative to its pivot, you could to the following:

local model = ...
model:PivotTo(model:GetPivot() * CFrame.new(0, 2, 0))

This means that :PivotTo() now provides a uniform API for moving both parts and models around. :PivotTo() also has a few advantages over the other APIs that could be used for this before such as :MoveTo() and SetPrimaryPartCFrame():

  • :PivotTo() operates on the pivot, which can be configured to whatever reference point on the object is the most useful, such as the hinge location on a door.
  • :PivotTo() does not require you setting a PrimaryPart.
  • :PivotTo() uses the BulkMoveTo infrastructure and some other internal optimizations, so it has better performance than the other methods.
  • :PivotTo() preserves part and model offsets, so you will not experience floating point drift when using it to repeatedly move an object!

Simulated vs Static Models

We mentioned but glossed over the statement "the pivot of a model with a PrimaryPart is equal to the pivot of that PrimaryPart" above, but it’s actually a very interesting point to discuss! Why would we make models with a PrimaryPart behave like this?

The main thing to observe is what happens for models without a PrimaryPart: What happens to the pivot of those models when parts underneath them get moved individually or thanks to physics simulation? The pivots of those models will actually stay in the exact same place rather than attempting to “follow” any of the parts under the model.

This is quite useful for editing purposes. If you have a static model containing some of your level geometry, you can move around things within that model without worrying about messing up the location of the pivot.

But what do you do if you have a model that does get physically simulated, such as a car that people are going to be driving around, and you want the pivot to move along with it? You set the PrimaryPart! Since the pivot of a model with a PrimaryPart is equal to the pivot of that PrimaryPart, setting the PrimaryPart effectively tells the engine which of the parts in the model the pivot should “follow” when the model gets moved.

Incidentally, this behavior also makes :PivotTo into a drop-in improved replacement for :SetPrimaryPartCFrame: The default pivot of a model with a PrimaryPart is equal to the pivot of the PrimaryPart, which is by default equal to the CFrame of that PrimaryPart, so the two will behave exactly the same for existing models.

Mesh Importing

When importing meshes through the Properties panel, or through the Avatar Importer plugin, the pivot of the imported MeshParts will be set to the origin of the coordinate space that you were importing from so that the offset information of those MeshParts is no longer lost. EDIT: You will only get this behavior if the “Set Pivot of Imported Parts” setting in the Studio settings is set to true.

You will not get this behavior with the Bulk Importer, but we’re currently working on asset import workflow changes that will extend this behavior to all imports and provide it more detailed options.

The Future


  • Model:GetPrimaryPartCFrame and Model:SetPrimaryPartCFrame() will be deprecated at some point in the near future. Model:GetPivot() and Model:PivotTo() act as drop-in replacements for them (i.e.: You can directly find-replace your calls to SetPrimaryPartCFrame with calls to PivotTo without changing how your code works)

  • Along with the release of the pivot API, we soft-removed Model:SetIdentityOrientation() and Model:ResetOrientationToIdentity() – These functions no longer do anything. This had no noticable impact as we contacted the couple potentially affected devs ahead of time.

Package PrimaryPart Requirement

The reason you need to specify a PrimaryPart when creating a package is to provide a reference point around which that package will be updated when applying updates.

But wait… pivot is also a reference point, and every model has a pivot. Couldn’t we use that as the reference point? Yes! We will be using it for that! We will be updating packages soon to use the pivot as the reference point instead of PrimaryPart, meaning we will be able to drop the PrimaryPart requirement. (This will be a backwards compatible change for the same reason that :PivotTo() is a drop-in replacement for :SetPrimaryPartCFrame())


Can I turn the pivot indicator off?

  • We decided not to offer a way to turn it off for now, as we think that only showing it when you have a tool that makes use of it selected is non-intrusive enough. We’re open to feedback on this.

Is :SetPrimaryPartCFrame() going away?

  • No. Deprecated doesn’t mean something is going to be removed, being deprecated is usually a standardized way to point people at the better modern alternative to an older API. Almost all deprecated APIs continue to function like they did before to support legacy scripts, and in the rare case where we do actually remove an API we’ll make sure that the affected devs are aware.

Why aren’t the Origin Position/Orientation properties scriptable?

  • You use GetPivot and PivotTo to move the object from Lua code. The reason we used these methods instead of a property is that property changes from Lua in the Roblox engine are supposed to be simple independent operations, but moving a model involves setting many properties of many objects. Thus methods fit better than a property.

Can you give back the old multi-selection pivot placement?

  • Earlier in the beta, we treated the pivot of a multi-selection as the pivot of the most recently selected of those objects. Later on we changed the pivot back to being the center of the bounds of the multi-selected objects. If you liked the earlier behavior, let us know, we could add an option for it in the future.

Can I get the move handles out at the edges of the object again?

  • Give handle summoning a try! So far the feedback indicates that handle summoning is very successful in supporting effective editing without the need for the Move handles to be out at the edges of objects.

What happened to Setting the pivot of imported parts, it’s not working!

  • It is still working, it’s just been moved behind a default false option for the time being, change “Set Pivot of Imported Parts” in the Studio settings to true to enable the behavior. It will be coming back in a more configurable form by default with our future unified asset importing process.


If you read to the end, thanks for your patience reading this exceedingly long announcement post, and thanks to @tnavarts, @LuckyKobold, @wengawenga, @4thchamber, and @JoshSedai for their hard work on this feature.


This topic was automatically opened after 16 minutes.

This is extremely cool, and thanks to the wonderful Roblox employees working hard everyday on new features for Roblox Developers! :grin:


I’ve been using physics and welds to hold models together for moving them as a whole, specifically for animation and tweening, and I believe :PivotTo will allow me to do this more efficiently in the cases where I don’t strictly need physics. Really excited about this!


Wow this will be extremely useful!! Great new addition!


Woohoo! I thought this was useless when the beta for it was announced; that Roblox was wasting our time. But I fell in love when I realised how useful this could be.


Pivots and handle summoning are probably the most useful additions in recent times. These features let me construct parts in ways that previously would’ve been a very long tedious process. I would love to see the ability to scale around a rotated pivot, which would possibly be difficult to implement, but maybe that’s something for the future.


These features are extremely useful!!! Thanks to Roblox Team!


This will be such a useful update and think many builders/modellers with take advantage from this.


I’m going to be looking at this very soon. We made some Scale “improvements” recently that turned out to be a bit problematic and were turned off, so I need to untangle the good parts (E.g. scaling around the pivot) from the bad parts (E.g. forcing Spheres/Cylinders to scale uniformly).


Very useful stuff!! Thanks roblox!!!


YEAHHHH, LET’S GOOOOOOOOOOO :tada: :tada: :tada: I can now officially discourage their use, even though I have for a while and have instead suggested welds or implementing these functions yourself with cached CFrames. This, to me, is the best part of the update.

Of course though, credit is due and pivots have been a really useful tool for me when building and even just coding. I’ve been using them in a production-level game to randomly generate some rooms for a caverns map so that each run can be as unique as possible. :slight_smile:

Highly recommend looking into pivots ASAP for those who haven’t. They’re a big life saver.


Finally the full version is released!!! :partying_face:

First of all, many thanks to the engineers and employees who developed it. :wrench:

Features look nice. Although I don’t think the ability to move parts is overly good, there are changes and I think it’s nice. :+1:


Yes! I can’t wait for :SetPrimaryPartCFrame() to FINALLY be deprecated! I really wish people stopped using it a long time ago!

Also, when it does become deprecated, can we get a message kind of like if you try using Wait() and Spawn()?
This is what I am talking about:
Because devs that don’t use the DevForum will probably not even use Pivots unless they have this message.


Yes, you’ll get such a message. I want to give people some time to naturally move over to the new API before I bother them with squiggly lines though. Likely I’ll actually mark them deprecated a few months from now.


I’ve always wanted something like this! This is a very neat feature and looks easy to use. This will help a lot with rotating parts from certain points and stuff like that.

I sure will miss Model:GetPrimaryPartCFrame and Model:SetPrimaryPartCFrame, though. I used them a lot to move entire models without setting all of their CFrames individually.


You could have just used some trigonometry and CFrame work


You don’t need to set their CFrames individually. You use :PivotTo() instead of :SetPromatyPartCFrame(), and :GetPivot() for :GetPrimaryPartCFrame(). Simple stuff :wink:, and a lot more reliable too! Parameters are the same.


Great! This will defenitely be useful for making rings! Since you can now rotate a part around another part, do that many times with different positions, then you’ll have a ring!

am I the only one who thought this was useless lol

1 Like

These are extremely useful, but I really wish there was a way for when we summon pivots for it to always be on one of the main corners/positions of the part we’re summoning pivots on (instead of just the purple indicator), this’d be extremely useful and much less tedious then specifically setting the pivot.