What do I type inside the RenderStepped function to do something every 2 frames instead of every single frame? I need this because some things in the loop don’t need to be updated every single frame.
I’ve tried this, but maybe there is a better way?
local Frame = 0
game:GetService("RunService").RenderStepped:connect(function()
Frame = Frame + 1
if Frame == 2 then
Frame = 0
end
end)
runEvery = 2
count = -1
RunService.RenderStepped:Connect(function()
count = (count + 1)%runEvery
if count ~= 0 then
return
end
-- do stuff
end)
You can tweak runEvery to change how often it should run. Count keeps track of the amount of frames that have passed, and wraps around to 0 after runEvery frames.
Edit: Looks like what you tried is just as good, possible better because there’s not really a need for weird modulus ( % ) stuff
If you don’t need something to update for rendering, have you considered using Stepped, Heartbeat, or simple while true do + wait loop? I don’t think you should run non-rendering-tied things in RenderStepped.
That’s a rendering-related thing, yeah. I would stick that in RenderStepped, and I would run it every frame. Why do you want to run it only every 2 frames? It will look smoothest if you run it every frame.
RenderStepped is only really necessary when you need to synchronize something with the camera. Since you’re just animating a character and there doesn’t seem to be a camera involved, use Stepped or Heartbeat instead. It’s better for maintaining a high frame rate that way, since RenderStepped actually delays rendering until it is done running, while Stepped/Heartbeat run parallel to rendering.
(Besides, no one’s going to notice a single frame delay difference in an animation)
I would just run the animation every frame and figure out later if it’s something you need to optimize.
I would actually say that chief among most things to bind to RenderStepped would be character animations and character movement. Heartbeat and Stepped are visibly choppy, best saved for the things that you don’t need to move fluidly.
I can’t really relate to this. It also doesn’t make much sense for them to be visibly choppy since all of these signals run at 60Hz, the difference being the placement in the pipeline, not the frequency.
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
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:
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.
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.
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.
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