AAAAAAAAAAAA LETS GO
Glad to see that you guys are focusing on more optimization stuff. It’s greatly needed especially now as more games gravitate toward bigger and more detailed maps. Hoping to see more stuff like this in the future so that games like these (including mine) can be a lot more performant
“Large maps” - I assume you mean large maps with moving parts? From what I understand, the update isn’t very impactful for games where almost everything is anchored, correct?
Nope, at least, I don’t see how it could. As mentioned in the post, this effects remotely owned mechanisms, its basically just reducing the frequency that physics for remote objects is smoothed from my understanding.
What the? This is a pretty cool feature and all but why does it create a significant lag spike with unanchored parts outside of the client’s radius?
Is this intended to happen? The lag is quite noticeable.
Switching to default or disabled poses no issues with lag and runs as normal.
Oh, never mind i think I understand why.
The feature doesn’t seem to be that smooth. The difference is very noticeable. Why not step it at something higher then 30Hz, or is there any way to improve the flexibility of it?
That’s… the whole point. To have it be ““laggy”” outside of the client’s radius.
Read through the whole thread please.
I’ve enabled this in one of my games, this definitely sounds like it’ll be a big help 
thanks!
Will be monitoring the game to see how impactful it is.
What? Just because it’s not impactful for games where everything is anchored doesn’t mean it’s worthless, it means it’s designed for different kinds of games that do rely on physics. Games like Destruction Simulator will benefit significantly from optimizations like this.
Please don’t rag on a feature just because you don’t understand it or because it doesn’t apply to you.
If your game has everything anchored, then the section of the frame this feature is intended to speed up, is already fast. The only thing being updated from the server is other players. So you could still see improvement in games with very high player counts.
The diagrams in this old article does not give you the full picture, and aren’t totally accurate anymore. Check out the microprofiler for a full picture of the work occurring per frame and per thread.
This feature does not impact the frequency of the physics step or the game loop, nor will it impact scripts in any way.
All it does, is it takes the positional updates from remotely owned parts (which occurs after the physics step), and updates them less frequently (throttles them) on your client, in order to boost performance.
When this occurs, you may notice those remotely owned parts appearing a bit “jittery”, like they are running at 30FPS, while everything else is 60FPS.
As we continue to work on this feature, we might try things like only throttling parts the client can’t see and other methods to make it less noticeable.
The point is, if your game is taking a vey long time to update remotely owned parts - its already “laggy”. So by throttling those parts that are taking up a bunch of time, your game speeds up as a whole.
If you are observing a “lag spikes”, as in, you get sudden major slowdowns of your entire game’s framerate for like a second or so, then that certainly sounds like a bug.
Otherwise, it might just be working as intended (for now). Read my reply above for more info ^^
Is there any chance of more steps, such as 45, 15, or even 7-8?
Could developers have control of this beyond toggling it as a service?
If yes, could certain models also eventually be prioritized, say 60 on a boat deck and 10 on some large glacier collapsing in the background? (could those parts even interact, then)
If a developer could set the interpolation throttle rate for groups of parts, if they choose to have the client render deterministic motion with a local model being CFramed, or choose to have custom replication, this would make a convenient way to finally hack off vestigial replication of the inbuilt client and physics replication by setting those throttles to 0 principally.
personal extra:
My personal interest is to stop wasting sent data on unused inbuilt replication and divert it to custom replication. It’s a far shot from what’s stated, though I figured to give it chance before making that a request.
I enabled this on my game but there doesn’t seem to be any difference. Does this feature reduce the network traffic as well or is that the same and the updates are just throttled locally for rendering?
EDIT: I do see slight stuttering of foreign owned parts so it is working, the network traffic for all the moving parts is still high though, even when the setting “Show Enemy Ore” is off which deletes the parts locally.
Im hyped for this, it could help people with a low end device to play larger games without lagging a lots. But will there be more feature about it? (changing the 30Hz to 15Hz and stuff like that)
I am using it in a sandbox tycoon that has a 500 ore limit per plot there are four plots. This works very well.
Since we’re making updates to the interpolation/extrapolation of the physics engine, can you consider adding methods/events/functions so we can bind/get interpolation data.
This would be sooo incredible helpful. Plus, it’s basically just asking for you to let us get data from the physics engine… data that is already there.
so for example players with 10fps on for example jailbreak kind map will get, how mcuh FPS?
K so i am making a game where lot of stuff are not anchored and use Physics but my game is in a close type of area. Will it improve the performance of physics in general or just stuff that are out of that radius? cause usually when there are a lot of stuff on the ground and someone walks into it there is a huge lag.
There are too many unknown variables for an outsider to give you an answer to that.
You can check for yourself on the microprofiler how long your client takes over the interpolateNetworkedAssemblies task. As the article states, only when this task takes more than 1ms on average the interpolation throttling will kick in (assuming you opted in) to reduce the frequency (from 60Hz to 30Hz) of remotely owned mechanisms that are outside of your client’s simulation radius.
The article literally says;
It is safe to assume that it will not update the frequency of mechanisms within the client’s simulation radius and your game would not gain any benefit from this assuming all physics related actions happen within your players their simulation radius.
does it increase performance when using terrain water?