Well, a simple test would be to make an army of about 50 cubes moving on Heartbeat versus 50 cubes moving on RenderStepped, and testing in a true server (not playtest), the difference is tangible to say the least, and I know which I prefer 
1 Like
Put this in a LocalScript in StarterPlayerScripts and try for yourself, there really is no visible difference because again, all of these signals run at 60Hz.
local SIGNAL = "RenderStepped"
--local SIGNAL = "Heartbeat"
--local SIGNAL = "Stepped"
----
local parts = {}
for i = 1,50 do
local p = Instance.new("Part")
p.Anchored = true
p.Parent = workspace
parts[i] = p
end
local t = tick()
game["Run Service"][SIGNAL]:connect(
function()
local dt = tick() - t
for i,v in pairs(parts) do
v.CFrame = CFrame.new((i-25)*5,20,dt*5)
end
end
)
Deficit of RenderStepped is that it holds up the pipeline, nothing else can run while it is being executed. Here’s an outline of what happens where in every two consecutive frames in the engine:
4 Likes
Here is a prime example of why I use RenderStepped for things like Cinematics versus Heartbeat or Stepped. It’s not just a couple lost frames- it’s a lot of em:
Cinematic on Heartbeat:
Same cinematic on RenderStepped
They’re both ~60hz, yes, but if that’s not tandem to your refresh rate then it can produce an awful stutter.
It’s true that it comes first “down the pipeline”, but if you’re not abusing the number of things to do on RenderStepped then you’re alright, and I wouldn’t let it dissuade you from using it.
Looks pretty deprecated >_>
Now we’re just talking in circles, that’s not what we were discussing about. In the post of mine that you first replied to I already point this out at the start:
In the reply you argue that “Heartbeat and Stepped are visibly choppy, best saved for the things that you don’t need to move fluidly”, which is not correct in all situations. That’s what I was replying to.
In the cutscene you linked, you are indeed synchronizing something with camera movement, so you should use RenderStepped.
Easy, easy
So be it that my cutscene has the camera moving- let’s pause for a second and suppose that the camera is completely static as OP’s might be when viewing their character performing an animation.
I’m saying that RenderStepped should be used when visual choppiness cannot be tolerated, and character animations are included in my book.
The purpose of my linked examples was to demonstrate that, without RenderStepped, the objects on the raft, the raft itself, the NPC boats, and the birds in the sky would still clearly be stuttery- just as stuttery as would be the motion of his character. If he’s rejecting Roblox’s default animations and using the Motor6Ds to his own intent, we can’t rule out that he may also want to do very delicate visual effects like custom foot planting, idle breathing, etc.
Aren’t Roblox default character animations performed on RenderStepped in the first place? 
The root of my advocation is that Stepped or Heartbeat are not as visually smooth as RenderStepped , as we both know, and so for something as imporant as Character animations I would advise that RenderStepped be used, and I’d challenge the claim that Stepped or Heartbeat is unnoticeable.
Stock animations are updated right before Stepped fires.
That is, after the camera renders stuff to be seen?
If they are truly updating synchronously with Stepped and after cam then I suppose I have to eat my words
Yeah, it happens in the Humanoid block in the image of the pipeline I shared above.
Can also see here for confirmation by a former client intern from 2017:
https://devforum.roblox.com/t/new-property-motor6d-transform/46813
The idea is that animations don’t need to be synchronized with the camera, because you won’t notice a frame of delay in an animation (since if you run on Stepped, the animation frame is only rendered on the next frame, but this is not noticeable).
Aight, how is it then that the character animations seem fine, but my cutscene on .Stepped is jittery even with a static camera? The same visual result is produced on .Stepped as in the .Heartbeat demo
:GetRenderCFrame has just redirected to .CFrame for a year or so. Don’t use it for new work.
1 Like
this is how i do it, to change the frequency just change the number after the modulus(%)
local ScanTick = 1
RunService.RenderStepped:connect(function()
ScanTick = ScanTick + 1
if ScanTick % 2 == 0 then
ScanTick = 1
--do wurk, guuuuuuuurl
end
end)
while true do
wait()
doStuff()
end
This will give you every other frame.
Wouldn’t wait always do 1/30th of a second, no matter the fps? If you use a wait() loop, wouldn’t it only be every 2 frames if the user has a solid 60 fps?
No, all the timing is in the frames. See this picture:
A loop yielding using wait() would run exactly once every two frames.
Ah, alright.
This is actually correct, wait yields for a fixed period.
My diagram is just an approximation at 60 fps.
1 Like
There’s been a few good solutions here, but I wanted to share a variation of OP’s solution using a simple boolean variable.
local x = false
RunService.RenderStepped:connect(function()
x = not x
if x then
-- code
end
end)
7 Likes