Will floating points still be an issue since PivotTo will act as a replacement for SetPrimaryPartCFrame?
The issue SetPrimaryPartCFrame had was that after a while or loading a certain way, floating point errors would occur leading to separation or displacement of parts.
Will that mean that humanoids will not use PrimaryPart anymore?
Yes, for now. I would like to make PivotTo (and SetPrimaryPartCFrame) do some internal magic to prevent this in the future but that won’t come with the initial release. You’ll still have to weld your model together to avoid floating point error issues if you intend to move it every frame for a long duration.
They will still have PrimaryPart = the root part. And using PivotTo on them will have the exact same effect that SetPrimaryPartCFrame used to.
One of the key pain points with rapid mesh modelling iteration is that whenever the mesh bounding box changes after an import, the mesh its origin point typically moves around too. Usually, when I (re-)import a mesh, I want to make sure the mesh origin doesn’t move from where it was previously.
Seems like this change makes it possible to create a simple plugin that moves the MeshPart around after a mesh import so that the pivot point (now equaling the mesh origin) is in the same world space position as it was before the import, and thus locking the mesh origin in place while rapidly iterating meshes. If so, that’d significantly improve my workflow.
Would in my eyes even be worth it to build this into Studio directly assuming this is a common enough workflow: instead of moving the pivot point after each import, optionally have a way to move the MeshPart its position instead so that the mesh origin will be at the original world space pivot point position.
Yup, that’s one of the ideas behind this, that long term you’ll be able to update a MeshPart while keeping the origin point in place.
I don’t know at the current time if we’ll be able to do that initially (it may have to wait for the Mesh workflow improvements that we’re doing this year), but even if we can’t, by having the origin information available through the pivot you could easily write a plugin to get that kind of rapid prototyping cycle.
thanks its working by rotating around the pivot but its not using the script that the wind shake plugin uses and seems to only go along one axis. is there a way to just set its point without effecting other movement stuff?
This will be really helpful for when i have very long parts. I used to have to zoom my camera all the way out.
Will also help me a lot for making models move. At least I think that’s how it works.
This will be very handy for future developments. Since It can create very nice accuracy for placing parts.
Cheers, Roblox
Excellent update, and long over due.
However, do you think that we could add multiple pivots onto 1 part, and use them similarly to nodes? Could be an interesting alternative to filling your place up with attachments and parts.
I’m not sure if someone already said this but I’ve that noticed this beta has been sort of intrusive on my building work flow due to where the move handles have been moved.
Beta disabled:
Beta enabled:
With the beta enabled, I now have to move my camera in a way that sacrifices precision in order to look at the center of the part where the move handles are now located. The handles being closer to where you’re looking and moving a part is very important because you’re not trying to move your camera in such a way that fits the move handles inside of your camera viewport and look where you’re trying to move the part at the same time.
I’m interested how you run into this a lot. When you’re lining up the edges of objects, aren’t you normally freeform dragging or resizing the object as opposed to axis moving it?
No, I only ever freeform drag objects to roughly place them somewhere or to have its position relative to another part and I always use the dragger to finish moving the object. In complex builds with a lot of angles and imperfect / inconsistent object sizes, the precision of the dragger is pretty much always superior to fumbling around with freeform dragging, in my experience.
A good example as to why the dragger is better than freeform dragging when it comes to lining up edges is when you’re trying to line up multiple edges at once. Freeform dragging resets where you last dragged as soon as you start dragging it again.
Is :PivotTo immune to matrix creep?
I wish 
We want to do a future project where we make PivotTo automagically keep local positions if possible, but that will also apply to the other movement APIs if we pull it off, so even then PivotTo wouldn’t be unique in that regard. PivotTo is more of an incremental improvement to SetPrimaryPartCFrame than a paradigm shift.
Though PivotTo will use the BulkMoveTo infrastructure internally (it doesn’t yet), so you won’t need to use BulkMoveTo for maximum perf anymore if you’re not in a scenario where floating point drift would be a problem.
Since this update released, my shortcuts for moving/scaling/rotating don’t work anymore.
(Ctrl+1/2/3/4)
Could this be related?
No, probably not related, post a separate bug report.
I can’t since I’m not a regular.
I will try reinstalling studio.
EDIT: Reinstalling fixed the issue. Thanks for the quick reply.
I noticed the pivot point properties are appearing under the Terrain class.
They should probably be hidden since the Terrain class won’t be using pivot functionality.
Will there be a way to disable this feature once it leaves beta? I am personally not very fond of it; it really gets in the way sometimes
These changes really were a massive help immediately the first time I started using them. It’s way easier to get things rotated the way I want, and the Model properties for moving the whole model are a lifesaver, they let me do some things yesterday that I wouldn’t have been able to do without programming.
However, there are indeed some cases where they get in the way with respect to moving the transform handles to the pivot instead of having them clamp around the bounding box of the edited selection. It’s sometimes too hard to grab the handle and finely move the selection since it’s now often offscreen. I wonder if it might be better to provide a bool toggle in the ribbonbar alongside the tools to switch between editing from the pivot and the selection, or else some faster way to edit the pivot so the handles are onscreen (e.g. hold a hotkey to edit pivot only, and freeform dragging of pivot to the closest hotspot).
I do this exact same thing:
