Pivot Points - Studio Beta

[BuilderBob25620 (BuilderBob)]

Darn. I need to start learning C and it’s branches. At least I partially know Java, so that should make it quasi-easier.

[BuilderBob25620 (BuilderBob)]

OH MY GOD!!! You added an Orgin Position Property! Gone are the days of having to create your own functions just to move an entire model! Now we can simply edit this property to move it!!!

EDIT:
Now that my high has worn off I realized what this means…
I have to edit all of my already written code because it has become obsolete. But also really
useful!!!

EDIT 2:
Your dark sorcery has made ALL my code that uses CFrames to teleport a character obsolete. Now I can just edit the Orgin Position property of the character model and it will move the character without killing it! Now I no-longer have to account for rotation of the player when teleporting them unless I want to set it!!!

EDIT 3:
WHYYYYY!!! I jumped to a conclusion too fast! Your only able to edit the PVInstance | Roblox Creator Documentation and PVInstance | Roblox Creator Documentation properties from the properties window. It has the tag notscriptable . This has ruined all my hopes and dreams.

[tnavarts]

You can script using the pivot, just not using that property.

Using the pivot: You use the :PivotTo(target) call to move the object to some location via the pivot, and the :GetPivot() call to ask where the pivot currently is in world space.

Changing the pivot: You set where the pivot is on an object using .PivotOffset for parts and .WorldPivot for models.

[12mrcool (NorthernCanuck)]

This update is what we needed, Blender you can change an objects origin point basically acting as the pivot point. just a few weeks ago I was wishing there was some way to do this, but had to create a part and weld my model to it so it would pivot/move around it, once animated, it was a tree and using the WindShake Editor plugin.

I guess the reason for my comment is, will this make it so we no longer need to do this, and just move the pivot point, or would we need to do these steps mentioned above, if I’m being honest it was a bit of a headache to get it working right.

edit: testing right now

[tnavarts]

@12mrcool

will this make it so we no longer need to do this, and just move the pivot point

You just move the pivot point where you want it using the Pivot Editor, and then use :PivotTo(target) when you want to move it based on that pivot.

[12mrcool (NorthernCanuck)]

ok, how would I go about doing this, as I only know basic beginner scripting. is there anything else I need to do other then :PivotTo

[tnavarts]

You need code to figure out what the CFrame you want to move the pivot to is, but that’s it. :PivotTo(target) will move the model and all of its contents such that the pivot is now at the target CFrame.

[12mrcool (NorthernCanuck)]

@tnavarts

:PivotTo(target)

do I need a script inside of the targeted object? sorry for the simple questions I have not really done anything like this before

Edit: ill wait to see what the community puts out for videos on how to set this stuff up

[tnavarts]

Yeah, at its simplest you could put a script in the object something like this:

local InitialPivot = script.Parent:GetPivot()
while true do
    local change = CFrame.fromEulerAnglesXYZ(math.sin(os.clock()), 0, 0)
    script.Parent:PivotTo(InitialPivot * change)
    wait()
end

[3rdhoan123 (Future Noob)]

@tnavarts

Not sure what you mean by “reliable”, but it is more convenient since you can call it on any model and not have to worry about whether it has a PrimaryPart or not.

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.

@tnavarts

Yes, as stated in the “Other API Changes”, SetPrimaryPartCFrame will be deprecated after the full release, since PivotTo is a drop-in replacement for it.

Will that mean that humanoids will not use PrimaryPart anymore?

[tnavarts]

@3rdhoan123

Will floating points still be an issue since PivotTo will act as a replacement for SetPrimaryPartCFrame?

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.

@3rdhoan123

Will that mean that humanoids will not use PrimaryPart anymore?

They will still have PrimaryPart = the root part. And using PivotTo on them will have the exact same effect that SetPrimaryPartCFrame used to.

[Den_S]

@tnavarts

• We plan to set the pivot of imported MeshParts to be initially equal to the mesh origin, so that the mesh origin information that is currently lost is preserved in the form of the pivot. This should be coming soon later in the beta period.

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.

[tnavarts]

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.

[12mrcool (NorthernCanuck)]

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?

[camomileex0]

@tnavarts

The Move tool now shows its handles directly around the pivot of an object rather than out at the extents.

This will be really helpful for when i have very long parts. I used to have to zoom my camera all the way out.

[camomileex0]

@tnavarts

model:PivotTo(CFrame.new(...))

Will also help me a lot for making models move. At least I think that’s how it works.

[MagnetarArtist (Magnetar)]

This will be very handy for future developments. Since It can create very nice accuracy for placing parts.
Cheers, Roblox

[thyrxir]

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.

[r_r]

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.

[tnavarts]

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?