How can you be so sure that your simulation code isn’t the problem? I think it would really help if you can get several pairs of eyes on your code.
As @XAXA said, you never know if it is a contributing factor to the speed. Why don’t you test it several times and report back with the results?
Have others look over the code as well.
Because the problem is in the Update rate, not the physics simulation itself.
This phenomenon is called Collision Tunneling and for the max performance that I can get out of LUA, raycasting is not an option. The only solution left is to increase the Update rate that my Physics framework runs at and that is what I initially asked for.
I’m not the right person to say why the script updates at this frequency, but physics is definitely still updating at 240hz (not at 60hz like the solution answer is stating here).
3 Likes
There is a lot of confusion in this thread.
local step = game:GetService('RunService');
while true do
local total,t = step.Stepped:Wait();
print(1/t);
end
The above code sample NEVER returned 240. There is no mechanism in the engine to allow a Lua script to fire in the internal 240Hz physics steps. .Stepped specifically fires on the 60Hz job that encompasses the internal 240Hz physics steps, and it always has regardless of which solver you used in the past.
12 Likes
RunService.Stepped runs at the frame rate, same as RenderStepped. The frame rate itself is capped at 60 Hz. If your frame rate drops below 60 Hz, so does Stepped.
After every Stepped we then do multiple physics engine steps. Typically 4 world steps per frame. Sometimes more, sometimes less.
Currently there is some DataModel state that we do not update between those 240 Hz steps that we do update before Lua executes again. Allowing Lua to execute between those 240 steps means doing more work to make sure the DataModel is synchronized before Lua executes more often. There’s a lot of serious consequences to supporting this.
We sometimes talk about adding some kind of physics step callback but we’re being very cautious about this. We know it’s basic functionality in other engines… Here it’s extremely performance sensitive and Lua is often a major bottleneck to achieving 60 Hz on many devices. Once we add something like this we’re stuck supporting it forever. We know it’s useful for some kinds of controllers, but we’re taking our time considering the best way to solve these use cases.
Also comparing the update rates of the old and new solver is a bit of an apples to oranges comparison. Very different algorithms. Even for each of those 240 steps there’s multiple internal solver steps.
18 Likes
I am VERY sure that game:GetService(“RunService”).Stepped:wait() used to run at 240hz if you put it in a while loop. I have tested it myself a couple of months ago because I found this thread:
That example is set private or has been deleted.
Do you have access and if so could you save it and put a link up for us?
As a matter of fact, you have said it yourself, that this piece of code runs at 240hz
while true do
local totalT,t = game:GetService('RunService').Stepped:wait();
print(1/t);
end
Here you have said (from my understanding) that Stepped:wait() runs on the Physics step
And on the post right after it, that the Physics step runs at 240hz.
Thus the code written above should output 240.
And it actually has 100% for a while now outputted 240 until the day I wrote this thread, when I initially noticed that it was changed.
1 Like
No. The render loop runs at 60 hz maximum. Physics runs at 240 hz maximum. RunService.Stepped has always been 60 hz maximum.
2 Likes
You’re ignoring what he said the sentence after that.
I think it’s really possible that you’ve misremembered. Stepped has pretty much run at 60hz for as far as I can remember. Two staff which work on the engine + a bunch of other people in the thread have vouched for this.
4 Likes
Please do not take my poor wording (physics step vs internal physics step was a bad choice to elaborate on the topic on my end) for how the underlying code works. Just to give you the benefit of the doubt I launched an older version of studio to verify that the code you posted in fact could never had run at 240Hz.
There is no mechanism in the engine to allow RunService::Stepped to trigger more than the rendering frame rate.
The only way
while true do
local totalT,t = game:GetService('RunService').Stepped:wait();
print(1/t);
end
could ever return 240 is if you were playing with a framerate unlocker of some sort, which is very much not supported.
6 Likes
Ok, sorry for using your wording in this context.
Is there any way I could access the older launchers?
How about doing this?
RunService.Stepped:Connect(function()
for i = 1, 4 do
-- do stuff
end
end)
It would simulate 240hz – in a choppy way – but you’d still be getting 240hz mathematically. (Something near it at least, if you consider the code inside the for loop to take time t = 0)
1 Like
That’s what I use but I was wondering if there was any other way to access the 240hz physics step
It is impossible right now.
1 Like
One thing you can do is look at the delta time step value passed as the second parameter to the Stepped callback. That tells you how many steps we’re about to do that frame. Due to various numerical reasons or extreme throttling cases it’s not always 4.
RunService.Stepped:Connect(function(time, step)
local stepCount = math.round(step / (1/240))
-- ...
end)
Worth noting this is only accurate for unthrottled bodies. When throttling is in effect some bodies are stepped less frequently, while high priority bodies continue to simulate as fast as possible (the rate given by above code). We don’t currently expose which bodies are in the high priority set directly, but really it’s just Humanoids right now.
7 Likes
I know this is old but I don’t really care.
It really doesn’t justify to resort to hacky tactics like this (which doesn’t actually do 100% of what you claim) just to have a fake glimpse of 240hz step when other engines give you direct or at least a function to sync with the true physics step which makes physics based character controllers far more reliable and efficient. What I’m baffled is that this has been the status quo for years and I’m surprised nobody had commented about this.
There is no excuse for Roblox to not offer a system like this especially when new features such as Shape-Casting giving developers more ways to accurately detect parts and Adaptive Stepping (making it merely possible at the cost of no way of the developer to manually change the HZ per part) yet despite that there’s absolutely no way to make a character controller that has proper and accurate floor/wall detection regardless of whatever Raycast Approach you take because Heartbeat sucks and is almost interchangeable with Renderstep (Hell, Renderstep is better in more physics related cases, pretty ironic.)
After scrolling through dozens of posts from other engineers loosely tying up what was now been completely obsolete 2018 replies of the time, I have come back to ask. Will you guys ever re-consider giving developers the ability to synchronize with the true physics step with all of the new physics related stuff being released?
11 Likes
I’d like to vouch on this as well; in our game, A revamp of our fundamental systems to work on RunService loops makes things like player humanoids impossible to utilize due to the physics step as a whole, and it’s gotten to the point where we’ve considered completely rebuilding Roblox’s physics from the ground up in a separate system, just so that we can hook it up to our engine without any instability.
The fact that we LITERALLY HAVE TO make our own physics system to alleviate this is completely absurd. Roblox has well advanced in improvements and changes over recent years, and the fact that the physics stepping is still being held back like this is baffling to the development side of the platform.
1 Like
If you want some code to run faster than the physics loop I think you just gotta pull off something like:
while script.Parent ~= nil do
task.wait(1/240)
-- Code
end
Though personally, if I needed fast moving projectiles for a game I’ll probs just script my own raycast-based physics engine for it.
Raycasts don’t go through walls as far as I know as long as the raycast doesn’t take place inside a wall so theoretically if you implemented bouncing ball physics that entirely rely on raycast you could have it move at “infinite” speed.
1 Like