Not sure if I understand. IF in 3d this helps by seperating the mesh from the object that is moving, what is it doing in 2d? What are you seperating? the collision objects? (e.g. collision shape?) just confused.
@@felineentity Yes I realize that, but that is used in almost no 2D projects. the above commentor mentioned sprites are equivelant to meshes. This confused me as if he was somehow seperating his sprite and coll. to gain performance which doesn't make sense. Obviously if you are using meshes in 2d which are really just 3d meshes this would apply. The inference above is that they are using this in another fashion with 2d which is what i was asking about.
I've been trying to figure it out. I'm pretty sure, different calls to physics_process overlap and one step gets resolved before the previous one. I had this problem with 2D jittering. It's NOT the answer, but if you're desperate, try adding some "processing" to the physics_process so it doesn't end so quickly. My game had that problem, again, it's NOT a solution, just a quick fix. I added these lines before calling move_and_side() and it worked: for n in range(0, 20000, 1): velocity.y = velocity.y; I hope this comment can help someone in distress.
This reminds me of techniques used in online multiplayer games. Interpolation plays an important role in smoothing the client-side animations regardless of low/laggy update packets coming from the authoritative server. Btw, you should definitely talk about multiplayer synchronization techniques! Things like client-side prediction and server reconciliation, etc. :)
@@garbaj I feel like people don't talk much about it because it's a complex subject. However, it's quite interesting and very useful for making socially appealing games.
This is one of the things that Godot REALLY needs to improve; stuff like this should be handled automatically like in Unity. Recommending setting your monitor to 60hz or using a smoothing-addon is not good, especially for a beginner.
i really like the format of these Godot engine tutorials, very concise and well presented information relevant to specific tasks that game devs need to code their own projects using this platform. Many thanks @Garbaj
I am from Russia and do not speak English well. It is better to use get_physics_interpolation_fraction () for interpolation rather than get_frames_per_second (). If you use get_frames_per_second (), it is impossible to remove ALL the jitter/support/hangs. You have a special case, because fps ratio of physics and graphics 1/2 Try your code at different fps ratios of physics and graphics. For example - physics: 47fps, graphics: 60fps, etc. A slight tug will appear. --- var fraction = Engine.get_physics_interpolation_fraction() player_body.global_transform.origin = last_physics_pos.linear_interpolate(global_transform.origin, fraction)
@@garbaj Here is an example of the code that solves the problem with the appearance of a small model jitter when the fps of physics drops slightly relative to the fps of graphics pastebin.com/fqkCZphi P.S. player_body - Is a mesh. I.e. a visual representation of the player that is not a child node to KinematicBody.
To reduce visual lag you can do a projected position. position + (position - prevPosition). The tradeoff would be a "glitch in the matrix" when a prediction is too different from the actual next physics position (should be minimal).
Interesting! I'll have to try this out. Your feedback has helped me learn so much about Godot over the past few months. I always look forward to your comments
@@garbaj And I'm always looking forward to your videos because you show stuff I haven't done yet. :D Also there's a Godot addon to do this, but it somehow didn't work for me. And you did what I suggested to that creator - set_as_toplevel to lift his limitations.
This worked for my fps camera great, thanks so much. For this wondering how to achieve the jitter fix for a first person camera, here's my current working code for Godot 4.2.2, which sits on the camera itself. A couple of notes: - linear_interpolate() has been shortened to lerp() -If you rotate the camera directly, your code will probably look more like Garbaj's. I had to modify it because of the way my player is set up. extends Camera3D @export var player_controller:PlayerController # The node with the script containing the player's direction var @export var player_eyes:Node3D # The node that rotates my camera. You might not need this. func _process(delta): self.global_basis = player_eyes.global_basis var fps = Engine.get_frames_per_second() var lerp_interval = player_controller.direction / fps var lerp_position = player_eyes.global_transform.origin + lerp_interval if fps > 60: # The value here should be the same as the project's physics ticks per second, as Garbaj said, # because the jitter comes from the game outputting higher FPS than physics ticks. self.set_as_top_level(true) self.global_transform.origin = self.global_transform.origin.lerp(lerp_position, 20 * delta) else: self.global_transform = player_controller.global_transform self.set_as_top_level(false)
Im making a fps too and my controller (along with the hands and weapon of the character) is so good that its similar to Rainbow 6 "feel". So when I saw the jitter above 60frames I dropped my project completely and I was waiting for Physics Interpolation to be implemented in Godot 4. I will try your code, next week, and if it works I will continue my project! (I was asking a Godot contributor, and from what he told me Physics Interpolation, for 3D, wont be implemented soon..Im guessing probably in around a year or more maybe .. so lets hope we wont need it)
My solution: If you are on a more modern version of godot, you can just go project settings>common>set physics fps from 60 to the refresh rate you need, you will need to re adjust your player speed but after that it's a definitive solution, then, from the inspector, check your camera process from idle to physics as well, jittering causes when stuff is not called simultaneosly, so assuring that player and camera updates are synchronized in my case removed the problem completely
Yep, by the same reason, higher frame rate are more expensive, you should be doing this only if you intend a game running above +60 fps, if you're having jittering on a game running at 60 fps then I'll asume that this is not a solution
@@benjaminborja5029 It depends on how complex the scene is I guess. Your CPU is doing a lot more work simulating physics than the GPU is rendering the scene. So even if you can pull 144fps on your game, your physics rate shouldn't be 144Hz; interpolation is better for that.
Hmmm...the real question will be by how much it affects performance, as a game intended to be only for pc (in my case at least), if that means jumping from 2% to 3% cpu usage to getting rid of this will be a gladly cost to pay, at least until I find an interpolation method that works for me :(
THANK YOU!!!! Exactly what i was looking for! Really needed it for my 2d game... But i didn't want sprites to be set toplevel obviously, so a made a little change. I made a Vector2 "globals_sprites_position" variable that will replace global_transform.origin var FPS = Engine.get_frames_per_second() var lerp_interval = velocity / FPS var lerp_position = global_position + lerp_interval globals_sprites_position = globals_sprites_position.lerp(lerp_position, 20 * delta) Sprites.position = globals_sprites_position - global_position works just fine
Hi, thank you for the snippet! I ran into some issues with your code where if you have some movement the moment game starts, the character jitters all over the place because FPS is set to 1 for the first second of the game, and also it caused issues with lower or dropping frame rates (like < 60 FPS), so I modified the code you provided to not interpolate if FPS is lower than physics FPS: var FPS = Engine.get_frames_per_second() if FPS > Engine.physics_ticks_per_second: var lerp_interval = velocity / FPS var lerp_position = global_position + lerp_interval globals_sprites_position = globals_sprites_position.lerp(lerp_position, min(delta * 50,1)) sprite.position = globals_sprites_position - global_position else: globals_sprites_position = global_position I hope this helps someone!
Just wanted to say that I was really struggling with interpolating my first person camera to get rid of the insane jitter it has by default being a child node of my player. You explained this fantastically well and within 5 minutes I fixed my camera jitter
If anybody's running into this issue with Godot 4 go to Project Settings > Physics > Common and tick 'Physics Interpolation.' I do not know why it's not turned on by default
Isn't the physics jitter fix option right below the physics fps at 0:25 meant for that? I thought I had read something like that about it, but idk if and how it works.
This just helped me solve the mystery of why, after upgrading to a gaming monitor with a 144Hz refresh rate over my old 60Hz monitor, Godot suddenly seemed to have "broken" physics! Thank you! Your content is not such "garbaj" after all!
Can you do a video about viewmodel rendering. separating the viewmodel fov and the main fps camera fov is something ive been looking around for. its possible to do using two cameras, one rendering the viewmodel to a separate viewport and then extracting that texture data and overlaying to the main camera. Ive been trying to implement this but have faced problems.
you could do alllllllllll of that or do this project > project settings > common (under physics make sure advanced settings are on) and set physics jitter fix to 0 this worked for me in godot 4.2.2!
I see. Yes, you would use a viewport texture for that. I don't quite understand how it works yet, but here's the docs about it docs.godotengine.org/en/stable/tutorials/viewports/using_viewport_as_texture.html
I believe they will be fixing this in Godot 4. I hope they make it transparent and automatic to the user, so we don't have to do this madness! thanks for the explanation.
Coming from Unity to Godot and Godot C# feels like there is no thought process or design behind implementation! everything feels like a mess & work-around.
He did a tutorial on making something like a wall you can just use that but replace the wall with a rock model then maybe animate it so it looks like it’s coming from the floor
Your _physics_process() function has a minor bug, your object speed is not independent of update cycles. At the moment if you increased your physics to 60Hz, your object would move twice as fast. I recommend you use the delta passed in: direction = direction.normalized() * speed * delta ; This will ensure the object moves at a constant rate of 5 units per-second irrespective of your physics update rate. Interpolation will always lag behind the true state of the game world, the only way to get closer to the actual state of the game world is to increase the rendering rate, however you'll never reach the actual current state. In my own game-engine I built the interpolation into my 'draw' objects, this way the developer can update the position/scale/rotation of an object and leave the render to deal with the interpolation and frame rate passing.
1:14 It's probably not the correct solution but while I was trying to figure out how to fix jitter, I eventually just gave up and moved all my move_and_slide() code into the _process function and just multiplied all my movement vectors by 'delta' and defined my speeds for movement in terms of 'm/s'. Delta is always the length of time that has passed since the last frame. No matter how fast or slow the framerate gets, everything moves at the correct speed. Again probably not the correct solution for various reasons but after pulling my hair out for 2 weeks trying to fix the problems I had with jitter and sliding and other issues, doing that simple change just fixed everything so I said screw it and went with it.
The main issue I came across when splitting move and slide into process was that sometimes things like is_on_floor() would not work properly, which could mess with your ability to jump among other things. Highly recommended that you move everything into physics_process
I am using process delta for move and slide. I read that we should be using physics process. But there’s the frame rate issue. I will try to fix the issue with your suggestion
so if anyone is interested what I did is far less complex that doing a code based solution:Frame rate lock your games FPS to match the Physics FPS. Why? Well, even the suggested solution by this video suggests that collision shapes may not be in synch with animation. So it's not perfect. The best solution is to wait for Godot to release 2D/3D interpolation, or frame rate lock your game. Zelda is locked at 30FPS and is an amazing game.
i think i saw a video about how delta work and you just need to actualise half the value before moving the target and the other half after or something like that. Might be completely useless and not what you're searching for tho. idk
Would I need to regulate my animation speed to match with this added interpolation? Since the jitter and timesteps are very minute, I assume it wouldn't be necessary.
I still wonder if this method can fix my projectile bullets that sometimes didn't register collision issue or not, maybe I'll take some time to do this if I have time to spare.
It will, but there is an edge case. 0 and 360 degrees is the same position, if you were to linear_interpolate from 270 to 0 it would traverse the full 270 degrees instead of 90 degrees that's actually required. The below example is in radians, and deals with rotation on the x-axis, but the same logic can be duplicated to apply to y and z too. var diffX = abs( rotation.x - newRotation.x ) if( diffX > PI ) { rotation.x += (newRotationX > rotation.x) ? PI2 : PI } Note: PI2 = PI * 2
While I don't necessarily agree that an engine "should" take care of it for you, because not every game needs the extra complexity, I can certainly understand the frustration of those who just want their game to look good right out of the box. Godot's developer is looking into adding built-in physics interpolation to the engine, but I think knowing ways to deal with it manually is also extremely useful.
@@garbaj it should take care of it in every game that uses physics, 144hz+ gaming monitors are pretty common these days and playing a game that feels like it is locked at 60fps doesn't feel good at all. Having to hack a solution just so your game can feel smooth on modern gaming setups isn't right.
Nice vid but can you make one on a toggleable third-person and first-person viewer, like in minecraft? If that's possible. Or maybe just a ladder tutorial lol
Vhy would you create 3 variables for a single line command, you dont need that. The code will look messier, but it is no needed to befair. Would look messy but creating 3 new vars in scope and then destroying them when scope ends ir kind of redundant. Or have them as globals... creating variables every FPS if you have hunderds is kinda wasteful...
Hmm.. I wonder world you save a lot of resources cutting the physics to say 20 and having process lerp at 60. It's collision that kills frame rate after all. I guess it depends on the game and you're best off playing with it. Nice tip, thanks!
Yes this is correct. Of course the lower you go with physics fps, the more input lag you'll have to accept, but that's just a matter of tuning/balancing
What about a 3D segmented snake tutorial? I am thinking about adding a snake boss (like in Risk of Rain or Terraria) to my game. I know how to implement similar thing in GMS2, but I have no clue how to make it in Godot with all three dimensions. I can't find any information about segmented "snakes", but this demo video: ua-cam.com/video/9Iqo2ieiTFI/v-deo.html
A plugin exists for just this. lawnjellys fixed timestep interpolation plugin for godot. github.com/lawnjelly/smoothing-addon you should check it out. Although the problem with working with it is you need to restructure your scenes.
I have also taken a shot at making something that can be used as a plugin, although might not be tested enough. here is mine github.com/2nafish117/godot-interpolation-demo
I am aware of this plugin. I dunno if it works better than my solution or not, all I know is that my version uses 10 lines of code, while the plugin has over 100 lines of code.
@@garbaj By using a function like this to move the mesh. var physics_fps = ProjectSettings.get_setting("physics/common/physics_fps") func change_pos(target_pos:Vector3): var tween = Tween.new() add_child(tween) tween.interpolate_property(self, "translation", translation, target_pos,1.0/physics_fps) tween.interpolate_callback(tween, 1.0/physics_fps, "queue_free") #Delete the tween node tween.start()
This actually helps me with my jitter problem in my 2D game! Thanks!
Nice, glad I was able to help you
whats the 'mesh' equivalent in 2d?
Not sure if I understand. IF in 3d this helps by seperating the mesh from the object that is moving, what is it doing in 2d? What are you seperating? the collision objects? (e.g. collision shape?) just confused.
@@trevoC132 You can use meshes in 2D.
@@felineentity Yes I realize that, but that is used in almost no 2D projects. the above commentor mentioned sprites are equivelant to meshes. This confused me as if he was somehow seperating his sprite and coll. to gain performance which doesn't make sense. Obviously if you are using meshes in 2d which are really just 3d meshes this would apply. The inference above is that they are using this in another fashion with 2d which is what i was asking about.
I like the explanations, I get a better grasp if I get the why instead of a "it's common standard"
I've been trying to figure it out. I'm pretty sure, different calls to physics_process overlap and one step gets resolved before the previous one. I had this problem with 2D jittering.
It's NOT the answer, but if you're desperate, try adding some "processing" to the physics_process so it doesn't end so quickly.
My game had that problem, again, it's NOT a solution, just a quick fix. I added these lines before calling move_and_side() and it worked:
for n in range(0, 20000, 1):
velocity.y = velocity.y;
I hope this comment can help someone in distress.
This reminds me of techniques used in online multiplayer games. Interpolation plays an important role in smoothing the client-side animations regardless of low/laggy update packets coming from the authoritative server. Btw, you should definitely talk about multiplayer synchronization techniques! Things like client-side prediction and server reconciliation, etc. :)
I'm a noob at multiplayer stuff right now, but I hope to make videos on those subjects soon
@@garbaj I feel like people don't talk much about it because it's a complex subject. However, it's quite interesting and very useful for making socially appealing games.
This is one of the things that Godot REALLY needs to improve; stuff like this should be handled automatically like in Unity.
Recommending setting your monitor to 60hz or using a smoothing-addon is not good, especially for a beginner.
i really like the format of these Godot engine tutorials, very concise and well presented information relevant to specific tasks that game devs need to code their own projects using this platform. Many thanks @Garbaj
I am from Russia and do not speak English well.
It is better to use get_physics_interpolation_fraction () for interpolation rather than get_frames_per_second ().
If you use get_frames_per_second (), it is impossible to remove ALL the jitter/support/hangs.
You have a special case, because fps ratio of physics and graphics 1/2
Try your code at different fps ratios of physics and graphics. For example - physics: 47fps, graphics: 60fps, etc.
A slight tug will appear.
---
var fraction = Engine.get_physics_interpolation_fraction()
player_body.global_transform.origin = last_physics_pos.linear_interpolate(global_transform.origin, fraction)
thanks, I'll check it out
I tried it out and unfortunately it seems to make the jitter even worse. I'll keep testing it out though
@@garbaj Here is an example of the code that solves the problem with the appearance of a small model jitter when the fps of physics drops slightly relative to the fps of graphics
pastebin.com/fqkCZphi
P.S. player_body - Is a mesh. I.e. a visual representation of the player that is not a child node to KinematicBody.
I did almost exactly as you suggested with these two lines of code and my movement is literally smooth as silk now thank you XD
"i do not speak english well"
comments in perfect english...
To reduce visual lag you can do a projected position. position + (position - prevPosition).
The tradeoff would be a "glitch in the matrix" when a prediction is too different from the actual next physics position (should be minimal).
Interesting! I'll have to try this out. Your feedback has helped me learn so much about Godot over the past few months. I always look forward to your comments
@@garbaj And I'm always looking forward to your videos because you show stuff I haven't done yet. :D Also there's a Godot addon to do this, but it somehow didn't work for me. And you did what I suggested to that creator - set_as_toplevel to lift his limitations.
This worked for my fps camera great, thanks so much. For this wondering how to achieve the jitter fix for a first person camera, here's my current working code for Godot 4.2.2, which sits on the camera itself.
A couple of notes:
- linear_interpolate() has been shortened to lerp()
-If you rotate the camera directly, your code will probably look more like Garbaj's. I had to modify it because of the way my player is set up.
extends Camera3D
@export var player_controller:PlayerController # The node with the script containing the player's direction var
@export var player_eyes:Node3D # The node that rotates my camera. You might not need this.
func _process(delta):
self.global_basis = player_eyes.global_basis
var fps = Engine.get_frames_per_second()
var lerp_interval = player_controller.direction / fps
var lerp_position = player_eyes.global_transform.origin + lerp_interval
if fps > 60: # The value here should be the same as the project's physics ticks per second, as Garbaj said,
# because the jitter comes from the game outputting higher FPS than physics ticks.
self.set_as_top_level(true)
self.global_transform.origin = self.global_transform.origin.lerp(lerp_position, 20 * delta)
else:
self.global_transform = player_controller.global_transform
self.set_as_top_level(false)
Im making a fps too and my controller (along with the hands and weapon of the character) is so good that its similar to Rainbow 6 "feel". So when I saw the jitter above 60frames I dropped my project completely and I was waiting for Physics Interpolation to be implemented in Godot 4. I will try your code, next week, and if it works I will continue my project! (I was asking a Godot contributor, and from what he told me Physics Interpolation, for 3D, wont be implemented soon..Im guessing probably in around a year or more maybe .. so lets hope we wont need it)
Thank you so much for this tutorial, I was having such a headache trying to fix this
My solution: If you are on a more modern version of godot, you can just go project settings>common>set physics fps from 60 to the refresh rate you need, you will need to re adjust your player speed but after that it's a definitive solution, then, from the inspector, check your camera process from idle to physics as well, jittering causes when stuff is not called simultaneosly, so assuring that player and camera updates are synchronized in my case removed the problem completely
Bro you are a legend lool. Thanks so much for the comment. Fixed my problem!
This is a lot more expensive though, because physics will be simulated at the rate you enter
Yep, by the same reason, higher frame rate are more expensive, you should be doing this only if you intend a game running above +60 fps, if you're having jittering on a game running at 60 fps then I'll asume that this is not a solution
@@benjaminborja5029 It depends on how complex the scene is I guess. Your CPU is doing a lot more work simulating physics than the GPU is rendering the scene. So even if you can pull 144fps on your game, your physics rate shouldn't be 144Hz; interpolation is better for that.
Hmmm...the real question will be by how much it affects performance, as a game intended to be only for pc (in my case at least), if that means jumping from 2% to 3% cpu usage to getting rid of this will be a gladly cost to pay, at least until I find an interpolation method that works for me :(
THANK YOU!!!! Exactly what i was looking for! Really needed it for my 2d game... But i didn't want sprites to be set toplevel obviously, so a made a little change.
I made a Vector2 "globals_sprites_position" variable that will replace global_transform.origin
var FPS = Engine.get_frames_per_second()
var lerp_interval = velocity / FPS
var lerp_position = global_position + lerp_interval
globals_sprites_position = globals_sprites_position.lerp(lerp_position, 20 * delta)
Sprites.position = globals_sprites_position - global_position
works just fine
Hi, thank you for the snippet! I ran into some issues with your code where if you have some movement the moment game starts, the character jitters all over the place because FPS is set to 1 for the first second of the game, and also it caused issues with lower or dropping frame rates (like < 60 FPS), so I modified the code you provided to not interpolate if FPS is lower than physics FPS:
var FPS = Engine.get_frames_per_second()
if FPS > Engine.physics_ticks_per_second:
var lerp_interval = velocity / FPS
var lerp_position = global_position + lerp_interval
globals_sprites_position = globals_sprites_position.lerp(lerp_position, min(delta * 50,1))
sprite.position = globals_sprites_position - global_position
else:
globals_sprites_position = global_position
I hope this helps someone!
You read my mind, I've been struggling with this this past week.
that's a good method. I had done something similar in the past by measuring the time between frames, honestly...your method is cleaner.
Boi for 3d iam just waiting for Godot 4.0
And now Learning 2d
why wait?
@@garbaj probably because the move_and_X functions don't play nice with slopes and/or jumping, depending on how you set them up
slope sliding has been fixed, and won't be changing in 4.0. I'll do a video on it soon
@@garbaj boi ur becoming the brakeys of Godot :D
@@garbaj ua-cam.com/video/_VR-xHsio78/v-deo.html
Just wanted to say that I was really struggling with interpolating my first person camera to get rid of the insane jitter it has by default being a child node of my player. You explained this fantastically well and within 5 minutes I fixed my camera jitter
godot lately have an explosion of high quality tutorials.
Finally I found the right tutorial for what I want. But actually, I will still write my own way of jitter reduction for my intention specific.
If anybody's running into this issue with Godot 4 go to Project Settings > Physics > Common and tick 'Physics Interpolation.' I do not know why it's not turned on by default
That option only works in 2D. We need to wait for the 4.4 version to get the same for 3D
@@yusarimahubara Are you sure ? The option is there in Physics > Common with advanced options turned on.
Just want you to know. I've been faced with this problem all over years and now everything has been resolved. Million Thanks!!!
Thanks! Garbaj Sometimes My player would just j-j-jitter everywhere at this fixed it!
Amazing Video!! Keep the hard work buddy!
Isn't the physics jitter fix option right below the physics fps at 0:25 meant for that?
I thought I had read something like that about it, but idk if and how it works.
doesn't seem to work
There's a really useful Smoother plugin for Godot 4 that can do this automatically just by adding a Smoother node to your scene tree!
Thanks this really made things a lot easier. Can also study the script it uses too for educational purposes.
This just helped me solve the mystery of why, after upgrading to a gaming monitor with a 144Hz refresh rate over my old 60Hz monitor, Godot suddenly seemed to have "broken" physics!
Thank you! Your content is not such "garbaj" after all!
Can you do a video about viewmodel rendering. separating the viewmodel fov and the main fps camera fov is something ive been looking around for. its possible to do using two cameras, one rendering the viewmodel to a separate viewport and then extracting that texture data and overlaying to the main camera. Ive been trying to implement this but have faced problems.
you could do alllllllllll of that or do this project > project settings > common (under physics make sure advanced settings are on) and set physics jitter fix to 0 this worked for me in godot 4.2.2!
Hey..! Uploaded good stuff man....I came here after my final term and I think you will be going to make cod or valorant like game from godot....
Using _physics_process instead of _process already helped a lot, thanks. Jitter is so annoying.
Can you make a complementary video (or text) showing how to do this on the camera like you talked about in the end?
ive been trying to figure out how to do that too
i was using the _process function before this, even just moving my movement to the physics process function has fixed the problem
I always had this Problem, now everything ist super smooth
Can you make scopes with magnification? Probably do like a viewport in a mesh or something. I don't know. Would be nice
this video should get you most of the way there ua-cam.com/video/K53bAYLXKDw/v-deo.html
@@garbaj I meant something like this: ua-cam.com/video/GaKSdkVcSRo/v-deo.html
But in clean 3D
I see. Yes, you would use a viewport texture for that. I don't quite understand how it works yet, but here's the docs about it docs.godotengine.org/en/stable/tutorials/viewports/using_viewport_as_texture.html
@@garbaj Thx sm Garbaj. U are super helpful :)
Thank you for the tutorial. Can you please do a tutorial on 3D fog of war ?
thanks bro it helped Alot
Even though the interpolation causes input lag I think it gives the feeling of weight with the the character like there is some velocity to it
gold like always
I believe they will be fixing this in Godot 4. I hope they make it transparent and automatic to the user, so we don't have to do this madness! thanks for the explanation.
There is a plugin for both Godot 3 and 4 that adds physics interpretation. I forget what it's called, but it should be easy to find.
Coming from Unity to Godot and Godot C# feels like there is no thought process or design behind implementation! everything feels like a mess & work-around.
Thx it helped 🙏
can you do a tutorial on "earth bending"? So like raise the ground and take a piece out of it or something
He did a tutorial on making something like a wall you can just use that but replace the wall with a rock model then maybe animate it so it looks like it’s coming from the floor
@@Icessien yesh, but i want it so its actually the floor coming out the ground, so i can rock jump myself in the air if u know what i mean
@@grindx1292 lmao trying to think of a way..... maybe elevate the rock from the floor using a defined height range
Your _physics_process() function has a minor bug, your object speed is not independent of update cycles. At the moment if you increased your physics to 60Hz, your object would move twice as fast. I recommend you use the delta passed in:
direction = direction.normalized() * speed * delta ;
This will ensure the object moves at a constant rate of 5 units per-second irrespective of your physics update rate.
Interpolation will always lag behind the true state of the game world, the only way to get closer to the actual state of the game world is to increase the rendering rate, however you'll never reach the actual current state.
In my own game-engine I built the interpolation into my 'draw' objects, this way the developer can update the position/scale/rotation of an object and leave the render to deal with the interpolation and frame rate passing.
Godot 3s move_and_slide method automatically multiplies the vector by delta, so his implementation is correct
Hey do potato laptop make games??😩😩😩
It doesn't look like a perfect solution, but a solution nonetheless. I'll save this tip for later if I ever need it.
1:14
It's probably not the correct solution but while I was trying to figure out how to fix jitter, I eventually just gave up and moved all my move_and_slide() code into the _process function and just multiplied all my movement vectors by 'delta' and defined my speeds for movement in terms of 'm/s'. Delta is always the length of time that has passed since the last frame. No matter how fast or slow the framerate gets, everything moves at the correct speed.
Again probably not the correct solution for various reasons but after pulling my hair out for 2 weeks trying to fix the problems I had with jitter and sliding and other issues, doing that simple change just fixed everything so I said screw it and went with it.
The main issue I came across when splitting move and slide into process was that sometimes things like is_on_floor() would not work properly, which could mess with your ability to jump among other things. Highly recommended that you move everything into physics_process
Does it mean that you have to copy paste the interpolation code in _process() for every "interpolated" node?
I am using process delta for move and slide. I read that we should be using physics process. But there’s the frame rate issue. I will try to fix the issue with your suggestion
so if anyone is interested what I did is far less complex that doing a code based solution:Frame rate lock your games FPS to match the Physics FPS. Why? Well, even the suggested solution by this video suggests that collision shapes may not be in synch with animation. So it's not perfect. The best solution is to wait for Godot to release 2D/3D interpolation, or frame rate lock your game. Zelda is locked at 30FPS and is an amazing game.
what about for rotation for a first-person controller?
pretty simple, if you're doing this on a camera it would be something like camera.rotation.y = body.rotation.y
@@garbaj could you please elaborate if you have the time thanks!
@@garbaj I am making fps, but when I rotate the camera, the weapons Lag sometimes, how to fix it?
thank you :)
i think i saw a video about how delta work and you just need to actualise half the value before moving the target and the other half after or something like that. Might be completely useless and not what you're searching for tho. idk
I thought delta is used for this?
Hey garbaj... Can u make a tutorial on adding hands to the fps gun.... I want but I am finding it hard...
Would I need to regulate my animation speed to match with this added interpolation? Since the jitter and timesteps are very minute, I assume it wouldn't be necessary.
it probably wont cause noticeable issues
I still wonder if this method can fix my projectile bullets that sometimes didn't register collision issue or not, maybe I'll take some time to do this if I have time to spare.
Nvm I just found a solution from the godot community, I just need to add a raycast in my projectile bullet, will test if I'm not busy.
Can you please make a video on destructible terrain like minecraft but not blocky ?
ua-cam.com/video/mqlQ06hjtl8/v-deo.html
@@ejoojoo thanks
hello friend It would be great if you could do a quake style bunny jump tutorial if you have time greetings!
Would a formula similar to this also work for updating rotational values rather than position?
It will, but there is an edge case. 0 and 360 degrees is the same position, if you were to linear_interpolate from 270 to 0 it would traverse the full 270 degrees instead of 90 degrees that's actually required.
The below example is in radians, and deals with rotation on the x-axis, but the same logic can be duplicated to apply to y and z too.
var diffX = abs( rotation.x - newRotation.x )
if( diffX > PI )
{
rotation.x += (newRotationX > rotation.x) ? PI2 : PI
}
Note: PI2 = PI * 2
🤩🤩🤩🤩🔥🔥
Great video! However, things like this should be taken care of by the engine and not be fixed with hacky workarounds by the user.
While I don't necessarily agree that an engine "should" take care of it for you, because not every game needs the extra complexity, I can certainly understand the frustration of those who just want their game to look good right out of the box. Godot's developer is looking into adding built-in physics interpolation to the engine, but I think knowing ways to deal with it manually is also extremely useful.
I'm pretty sure this same fix is coming in 4.0 as an optional feature.
@@garbaj it should take care of it in every game that uses physics, 144hz+ gaming monitors are pretty common these days and playing a game that feels like it is locked at 60fps doesn't feel good at all. Having to hack a solution just so your game can feel smooth on modern gaming setups isn't right.
the ones that don't have monitor to see whats the diference =/
PS: btw the video is good :P
intrepid on steam is a godot game which clearly has this jitter issue on camera.
Couldnt this also be fixed by turning VSync on? Godot Physics rate is set to 60 fps by default. VSync locks the framerate at 60 fps.
No cause if you would have a higher refresh rate monitor for example 144hz VSync would lock it to 144fps.
can you make a tutorial about portals? like in Portal 2?
Now that's a tough one, but maybe not impossible...
ua-cam.com/video/_SmPR5mvH7w/v-deo.html
not godot specific, but talks about how you'd go about making a portal in any game engine
Is it the same process for 2D as well? Wish I could have a solution for 2D.
It should be the same
@@garbaj Great, thanks for feedback! I have been struggling with jittering since 2.1!
Nice vid but can you make one on a toggleable third-person and first-person viewer, like in minecraft? If that's possible. Or maybe just a ladder tutorial lol
Yes, it's a bit more complicated than this video, but it can be done
Pog. Looking forward to it
Vhy would you create 3 variables for a single line command, you dont need that. The code will look messier, but it is no needed to befair. Would look messy but creating 3 new vars in scope and then destroying them when scope ends ir kind of redundant. Or have them as globals... creating variables every FPS if you have hunderds is kinda wasteful...
so good and tasty
Hmm.. I wonder world you save a lot of resources cutting the physics to say 20 and having process lerp at 60. It's collision that kills frame rate after all. I guess it depends on the game and you're best off playing with it.
Nice tip, thanks!
Yes this is correct. Of course the lower you go with physics fps, the more input lag you'll have to accept, but that's just a matter of tuning/balancing
i wasn't able to translate this into a 2d fix, someone plz help, what do i put in place of the "mesh"?
My guess would be sprite
@@garbaj thanks!!
What about a 3D segmented snake tutorial?
I am thinking about adding a snake boss (like in Risk of Rain or Terraria) to my game. I know how to implement similar thing in GMS2, but I have no clue how to make it in Godot with all three dimensions.
I can't find any information about segmented "snakes", but this demo video: ua-cam.com/video/9Iqo2ieiTFI/v-deo.html
A plugin exists for just this. lawnjellys fixed timestep interpolation plugin for godot.
github.com/lawnjelly/smoothing-addon you should check it out. Although the problem with working with it is you need to restructure your scenes.
I have also taken a shot at making something that can be used as a plugin, although might not be tested enough.
here is mine github.com/2nafish117/godot-interpolation-demo
I am aware of this plugin. I dunno if it works better than my solution or not, all I know is that my version uses 10 lines of code, while the plugin has over 100 lines of code.
Is there a reason not to use tweens ?
How would you use a tween for this?
@@garbaj nvm what I was thinking to do with tween is basically lerping so what you have done is much easier
I've never had this issue but also my PC is shit so...
orrrrrr just use the smoothing node
4:50 was that 69 intentional?
ummm...yeah..let's go with that
@@garbaj aight lol
I have a 2D project with a jittering problem, if I copy and pasted the code for my player would this help?
No, a simple copy paste will not work. I don't know what the 2d equivalent of global_transform.origin is, but that will need to be changed
Copying and pasting doesn't help - understanding the problem does :-)
Can you make a tutorial for a fortnite style build system
Gonkee did it....
@@abbasimaaz7223 it’s not finished
It's way too complicated for me right now, but hopefully I can figure out a way one day
@@garbaj do you think I could maybe snap the deployable wall that you made to a grid and scale it
That's the basic idea. Getting the grid to work with the different wall types is difficult
нифига не андерстенд, но лайк поставлю
Shouldn't the engine take care of this?
At the moment no (same with Unity), but Godot's developer is looking into adding it as a built in feature.
@@garbaj it does in unity actually, you just tick the "interpolate" option in rigidbodys component
please throwing ax (by spinning) tutorial
(like god of war)
I'd use tweens instead
I'm curious to know how you use a tween to do this?
@@garbaj
By using a function like this to move the mesh.
var physics_fps = ProjectSettings.get_setting("physics/common/physics_fps")
func change_pos(target_pos:Vector3):
var tween = Tween.new()
add_child(tween)
tween.interpolate_property(self, "translation",
translation, target_pos,1.0/physics_fps)
tween.interpolate_callback(tween, 1.0/physics_fps, "queue_free") #Delete the tween node
tween.start()
Why don't you just change the physics FPS and don't write all that extra code and all that stuff ?
I imagine you'd want to keep your physics fps low for performance reasons. Especially in multiplayer games
Just turn on Vsync.
Joking btw
Or you can use delta
Yeah unity is awesome
@@cristianjuarez1086 what?
@@tengkuizdihar delta is the change in time between frames. Unity has Time.deltaTime and returns how long took the last frame to load
@@cristianjuarez1086 i know that, but what's the connection between that and "unity is awesome"?
for me work with disabling v-synce