I needed to move a model in my code using CFrame hence I looked up the GetPrimaryPartCFrame function only to find out that it has been superseded by PVinstance:GetPivot. Up to this point, I’ve never heard of PVinstance and have no idea what it is and does.
I have looked it up on the devhub and there isn’t much else to properly explain how to use it in replacement of GetPrimaryPartCFrame. (So please don’t reply if you’re just going to send me links to the devhub) What is the code format that I have to use to adjust the cframe of the model to where I want it and how does it compare to the code format of GetPrimaryPartCframe?
I’m just guessing of course. But after reading the docs, it seems to act just like a normal CFrame. The exception being that the pivot can be adjusted on objects. Essentially giving it an anchor position within the model/basePart. It looks nearly the same syntax as well just different naming convention.
local pivot = myModel:GetPivot()
myModel:PivotTo(pivot:ToWorldSpace(CFrame.new(0,0,-1))
--[untested]
Example on docs page
local currentPivot = character:GetPivot()
character:PivotTo(currentPivot * CFrame.new(0, 0, -10))
Comparison to get primary part on a model
local humanoidRootPartCFrame = character:GetPrimaryPartCFrame()
character:SetPrimaryPartCFrame(humanoidRootPartCFrame:ToWorldSpace(0,0,-1))
PVInstance is the abstract class for instances that have a physical representation in the world. GetPivot is there so that it can be used by all types of parts as well as models.
GetPivot can be used as a drop-in replacement for GetPrimaryPartCFrame. Check Pivot Editor: Full Release for more information. This is assuming that the pivot is positioned at the center of the bounding box though - if you’ve shifted the pivot you may need to consider that pivot when translating a model.
Here is my attempt to answer, after doing a bit of research. Unfortunately, floating point errors make this slightly less accurate than GetPrimaryPartCFrame(), so whether or not you want to use it may depend on what you plan to do.
I believe you also need to use PivotOffset. The term caught my eye when I checked the DevForum announcement, so I looked for its page on the DevHub. Using the info from there and my past experiences with CFrame, I determined:
Model:GetPrimaryPartCFrame() is approximately equal to
Model:GetPivot() * Model.PrimaryPart.PivotOffset:Inverse()
Here is the code I used in the command bar when messing with a model’s PrimaryPart’s PivotOffset. Please excuse my overtly simple variable names.
local a = game.Selection:Get()[1] --I selected the model in Edit Mode.
local x = a:GetPrimaryPartCFrame()
local y = (a:GetPivot() * a.PrimaryPart.PivotOffset:Inverse())
print(x == y) --Not always true given floating point errors
print(x * y:Inverse()) --This is always near the identity CFrame, hence x is approximately y.
Again, floating point errors may make this less than ideal, as CFrame multiplication and inversion are involved.
You’re matching the wrong explanation to the wrong function. It’s GetPrimaryPartCFrame and SetPrimaryPartCFrame that encounter floating point imprecisions and are being deprecated in favour of pivots in the future. Pivots do not suffer from the same issues because they cache CFrames. GetPivot/PivotTo additionally uses something similar to or directly implements the logic behind BulkMoveTo which makes it fairly performant.
Unlesss you meant your solution contains them, then that’d be my bad for misunderstanding.
Sorry, I meant the CFrame multiplication, if not the Inverse() function. At least one of those comes with the risk of floating point errors, which impacted the y variable in my code.