Rotate a CFrame orientation like a vector

[screenswitch1 (ScreenSwitch)]

if you wanted to use degrees you would have to use math.rad() because this constructer takes in radians

[01_0101100 (SuperUser)]

I do use math.rad else it just breaks as it try to interpret degrees as radians.

[screenswitch1 (ScreenSwitch)]

so if you use math.rad it breaks?

[01_0101100 (SuperUser)]

No, if I don’t use it, it breaks.

[McThor2]

I guess you didn’t try and tweak it then or try this:

@McThor2

Now if you have issues with axes not being what you expect you can replace RotCFrame.Rotation with something like CFrame.Angles(x, y, z) * RotCFrame.Rotation where you’ll need to figure out x, y, z.

[01_0101100 (SuperUser)]

I did try it multiple times but it only piles them on top of one another ( add ).
This is the pile up behaviour I’m talking about.

[ 1, 0, 0 ] +
[0, 1, 0 ] =
[ 1, 1, 0 ]

What I’m trying to do is rotate the “axises” themself as if they were directions vectors ( UpVec, RightVec … ) on a part which gets rotated so maybe the up vector will become ( 1, 0, 0 ) and so on. You can see the behaviour I want if you do :
CFrame.Angles(math.rad(45), 0, 0):VectorToWorldSpace(Vector3.new(0, 90, 0))

It is close to what I need but it returns weird values as in this case ( 0, 63, 63 ) instead of ( 0, 45, 45 ).

[McThor2]

CFrame.Angles(math.rad(45), 0, 0):VectorToWorldSpace(Vector3.new(0, 90, 0)) is the same as CFrame.Angles(math.rad45), 0, 0) * Vector3.new(0,90,0).

Your explanation in terms of adding vectors makes no sense to me as that is not how rotations with cframes work.

[McThor2]

To clarify further if you want to rotate between axis you can multiply by CFrame.fromAxisAngle( Vector3.new(1,1,1).Unit, math.rad(120) ) and that should send x → y, y → z z → x (or the other way round).

[01_0101100 (SuperUser)]

This is maybe what I need. Though if it is, It will still need a bit of modifications.

[01_0101100 (SuperUser)]

When you say multiply, what are you saying to multiply?

[McThor2]

Some other CFrame. Like the head CFrame or device CFrame.

[01_0101100 (SuperUser)]

I tried it but I doesn’t really works. I’m going to try explaining what I’m trying to do with images. Hopefully, it should be clearer and you would be able to help me.

My goal is to rotate a CFrame rotation using another CFrame rotation.
In this example, I’m going to be rotating ( 90, 0, 0 ) by ( 0, 90, 0 ). In the images, the rotation being rotated ( first one ) will be represented as the red line ( the part.CFrame RightVector ).

We start with the red line pointing toward the part RightVector ( 1, 0, 0 ) which is the equivalent to 90 degrees on the X axis for us.

If we now turn the part by 90 on the Y axis, the red line will still be pointing toward the part RightVector but it will now be equal to ( 0, 1, 0 ) which in our case means 90 degrees on the Y axis.

This is how I’m trying to make the rotation work. In the previous examples, I tried explaining it as CFrames vector as it is the easiest way to visualize what is happening.

I hope this helps.

[McThor2]

@01_0101100

which is the equivalent to 90 degrees on the X axis for us.

What does this mean though? 90 degrees from the axis? 90 around the x axis?

This is just a discussion about the terminology of rotations though at this point.

[01_0101100 (SuperUser)]

@01_0101100

ich is the equivalent to 90 degrees on

On it, Imagine the RightVector as a rotation which in our case is ( 90, 0, 0 ).

[McThor2]

Yeah my point is that what you’re saying doesn’t make sense and you just repeated the statement. I think you would receive more help if you used more standard language when referring to the rotations.

[01_0101100 (SuperUser)]

Yeah but if I use standard language, you tell me the wrong thing over and over.

[sylwek1100 (Rocky)]

You have to use ToWorldSpace Function, and use CFrame.Angles

[01_0101100 (SuperUser)]

Yeah but it doesn’t work. I’m gonna try again and yes you are right it should work as I am using it to fix the same problem earlier in the code.

[dthecoolest]

The vocab being used here is confusing.

From my understanding isn’t this all about doing rotations in world space or object space?

If so then order of operations matters a lot and I would recommend trying all permutations of CFrame and it could be the difference between the perfect working formula vs non working one, as seen in my tutorial below for there examples.

Also the C0 formula seems off it should the the Part0 being inversed first then multiplied by your desired rotation CFrame like in my CFrame tutorial derived from the weld CFrame equation from the understanding CFrames article:

Neck.C0 = CFrame.new(Neck.C0.Position)  * NeckConnect.CFrame.Rotation:Inverse() *CurrentRotation

@dthecoolest

weld.C1 = attachment1.CFrame

weld.Part1 = attachment1.Parent

weld.Parent = attachment1.Parent --any parent under workspace to make the weld active

World CFrame relative to Motor6D/Weld space

Ok, now that we have understood what a weld can do, so now the question is how do we manipulate it via script without breaking the weld? The answer is to modify the offsets C0 and C1. Unfortunately this goes into CFrame:Inverse() territory which is a bit more complex and not accounted for in this tutorial however I will just point out the math properties during the derivation

--Starting from the weld equation

part1.CFrame * C1 == Part0.CFrame * C0

--Apply Part0.CFrame:Inverse() to the left hand side of both equations

Part0.CFrame:Inverse()*part1.CFrame * C1 = Part0.CFrame:Inverse()*Part0.CFrame * C0

--Apply CFrame:Inverse() * CFrame = CFrame.new(), CFrame Inverse property
Part0.CFrame:Inverse()*part1.CFrame * C1 = CFrame.new() * C0

--CFrame.new() *anyCFrame = anyCFrame, Identity CFrame property
Part0.CFrame:Inverse()*part1.CFrame * C1 =  C0
--Rearrange equation, swap sides
C0 = Part0.CFrame:Inverse()*part1.CFrame * C1

--We want part1 CFrame to equal some CFrame like CFrame.lookAt()

C0 = Part0.CFrame:Inverse()*CFrame.lookAt(part1, part2) * C1

Using this knowledge, we have derived one very useful CFrame formula.

Here is what it looks like in function form and an example when applies to a common Motor6D rig like R6:

local motor = script.Parent
local target = workspace.Target

local function worldCFrameRotationToC0ObjectSpace(motor6DJoint,worldCFrame)
	local part1CF = motor6DJoint.Part1.CFrame
	local part0 = motor6DJoint.Part0
	local c1Store = motor6DJoint.C1
	local c0Store = motor6DJoint.C0
	local relativeToPart0 = part0.CFrame:inverse() * worldCFrame * c1Store
	
	local goalC0CFrame = relativeToPart0
		
	return goalC0CFrame
end

while true do
	task.wait()
	motor.C0 = worldCFrameRotationToC0ObjectSpace(motor, target.CFrame)
end

[01_0101100 (SuperUser)]

I didn’t test your solution but in mine the only thing that didn’t work was the fact that some axises where swapped when the torso rotation was not 0. Maybe you are right but I don’t think so. By the looks of it, the glitched behaviour is very similar from when applying a 90 degrees offset to the phone rotation so the camera would face the right way. I fixed it using ToWorldSpace() but it doesn’t work here. We will have to see if your thing works.