Torso.CFrame is incorrect when in first person (in RenderStep)

[rokoblox5 (roko)]

My framerate is not laggy, Torso.CFrame is just not smooth, look at the mouse and the part, you will notice that the mouse is not aligned with the part even though both of them should be in the middle of the screen, but in third person it works perfectly fine. (The part is perfectly aligned in front of the Torso)

[waves5217 (waves)]

battattack is right, because RenderStepped is capped at 60 Hz, the part position refresh rate is limited as well. Works perfectly fine in third person, however, in first person, the positional changes on screen are much bigger and quicker. Consider the awkward drawing below as an example. The longer the path, the bigger the segments. When the distance from the torso/root part is 0, 60 Hz update is enough for the human eye not to perceive stutter.

Perhaps use welds or weld constraints instead. Roblox physics is updated at 240 Hz (and with adaptive time stepping by default).

local player = game:GetService("Players").LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local rootPart = character:WaitForChild("HumanoidRootPart") -- torso in R6

local part = Instance.new("Part")
part.CanCollide, part.Anchored = false, false

local weld = Instance.new("Weld")
weld.Part0 = rootPart
weld.Part1 = part
weld.C0 = CFrame.new(0,0,-5)
weld.Parent = part
part.Parent = workspace

[rokoblox5 (roko)]

I understand what you mean (and thanks for the effort), but the problem isn’t about unnoticable stutter at all, see this video for yourself.

My intention was to move the arm (which can’t simply use welds), not a part,
I just used a part for demonstration.

[jasperagent_dev (StillSyriarting)]

Just tested the code myself, and everything is working fine for me. Can you explain your problem in more detail? I’m not seeing any errors/difficulties here.

[rokoblox5 (roko)]

Could you show me a video? It just doesn’t work for me.
Also try moving the camera fast enough.

[jasperagent_dev (StillSyriarting)]

Unfortunately I cannot send a video at the moment but I still see no issue other than it stuttering a bit. It is being centred, and I don’t see what you’re complaining about

[rokoblox5 (roko)]

I’m complaining about my FPS arms stuttering, I think it’s clear why that would be an issue.

[jasperagent_dev (StillSyriarting)]

…

@jasperagent_dev

If you’re annoyed about it being “laggy” try using TweenService instead of just setting the position, RenderStepped is based on FPS and so it can randomly jump from .2 seconds to .5 seconds, for example.

@waves5217

battattack is right, because RenderStepped is capped at 60 Hz, the part position refresh rate is limited as well. Works perfectly fine in third person, however, in first person, the positional changes on screen are much bigger and quicker. Consider the awkward drawing below as an example. The longer the path, the bigger the segments. When the distance from the torso/root part is 0, 60 Hz update is enough for the human eye not to perceive stutter.

Perhaps use welds or weld constraints instead. Roblox physics is updated at 240 Hz (and with adaptive time stepping by default).

local player = game:GetService("Players").LocalPlayer
local character = player.Character or player.CharacterAdded:Wait()
local rootPart = character:WaitForChild("HumanoidRootPart") -- torso in R6

local part = Instance.new("Part")
part.CanCollide, part.Anchored = false, false

local weld = Instance.new("Weld")
weld.Part0 = rootPart
weld.Part1 = part
weld.C0 = CFrame.new(0,0,-5)
weld.Parent = part
part.Parent = workspace

We’ve already explained some reasonable solutions for you, also try using CFrame:Lerp too if you don’t want to use something like TweenService. Don’t say it’s not what you’re complaining about previously when it is.

[rokoblox5 (roko)]

I cannot use a weld.
Again, I’m trying to move the player’s character’s ARM, it has it’s own Motor6D attachment which I want to keep in order to preserve animations, and basically not delete an organ. (It will probably fall into the void on server)
I have to change the RightShoulder (Motor6D) C0 value to position the arm where I need, and since it’s relative to the Torso, the issue has to happen, unless I update it in the right timing, AFTER the torso updates and BEFORE the game renders the next frame. (Not sure about this timing, but that’s what I came up with)

[waves5217 (waves)]

Now I’m thinking it would be easier to create a separate view model. The arm’s CFrame is still away from the camera, which will always make the stutter appear like the frame rate is lower than 60 Hz. Most first person games, especially shooters, have a view model completely separate from the character everyone else sees. Then the root of the view model can be updated each render cycle to the camera’s CFrame. Because the distance between camera and root is 0, the update is seemingly smoother too. And the rest of the model is connected using Motor6Ds.

I’m talking about what EgoMoose created in this neat FPS tutorial.

The First Person Element Of A First Person Shooter

This guide was originally written for scriptinghelpers. The original can be found here. In this post we will be talking about creating our very own filtering enabled friendly first person shooter (FPS) game. I do want to make clear though that I won’t be covering how to actually make the weapon shoot in this article. All we are going to be covering is the visuals meaning having the character aim down sights, look up and down, etc. Maybe we’ll talk about shooting another day. Things to take …

[jasperagent_dev (StillSyriarting)]

Completely agree with @waves5217 here- why are you using the Player’s actual arm? Just use a viewmodel, that’s what most games do.

[rokoblox5 (roko)]

Thanks, I want to avoid creating a ViewModel to simplify other things though.
I will have to make one if I’m unable to fix this anyways.

But again the problem is not with framerate at all, it’s just that the Torso.CFrame is inconsistent with the camera, although it should be.
In first person, the torso’s direction should always be the same as the camera (on the Y-axis), while in third person it doesn’t have to.
This means that when I rotate the camera in first person, the torso isn’t actually pointing towards the camera’s direction when my onRender function is called.
BUT in third person, even when I rotate the torso while moving the camera, there is no stutter.

[jasperagent_dev (StillSyriarting)]

@waves5217 has already explained this, you keep on repeating the same thing and I don’t quite think you understand. It basically in short is stutter because RenderStepped is capped at 60 Hz, first person mode has larger distances because your mouse moves faster, meaning faster the mouse moves, the less it will keep up. A potential fix is to check if the LocalTransparency of the RightArm is 0 while other parts have it at 1 so that you can check for if the player is in first person, and potentially use Camera.CFrame but that will most likely also have the same issue.

[rokoblox5 (roko)]

You don’t understand me.
If the problem is with larger distances, then moving the camera fast in third person should have the same problem, no?

But hey, guess what:

Very smooth in third person, very jittery in first person.

[jasperagent_dev (StillSyriarting)]

This is because in first person your character model moves/rotates with your camera, and that is where the CFrame is coming from, but when you’re in third person the movement of camera doesn’t affect character movement/rotation…

[rokoblox5 (roko)]

Yet when I rotate the character in third person the arm AND the part still move fine and smoothly.

[rokoblox5 (roko)]

I found the solution, all I had to do was force rotate the character towards the camera’s direction myself before modifying the arm or the part, thanks for the help though =D

local rx, _, rz = Root.CFrame:ToEulerAnglesYXZ()
local _, cy = Camera.CFrame:ToEulerAnglesYXZ()
Root.CFrame = CFrame.new(Root.Position) * CFrame.fromEulerAnglesYXZ(rx, cy, rz)

Here is a video if you want to feel the sweet victory with me

[waves5217 (waves)]

Oh dear, you beat me in timing. I just actually built a similar view model for the testing and was coming to a similar conclusion that auto rotation might have to be overridden. I’m very happy that you found the solution. Bonne journee!

[rokoblox5 (roko)]

Well thank you for all the effort, I wish you a good day