Get the free and open-source demo here: github.com/GDQuest/godot-demos-2022 (please star the repository too to help people find it!) We have more demos and guides available there, and more in preparation! You asked us to make it easy to download our open-source demos, so we listened. You can now easily download each individual project on this website: gdquest.github.io/godot-demos-2022/
You saved me tons of head scratches... :) The signal does not work if the whole node itself is not visible. So I set the visibility of my node to false, if it is outside the screen. And it didnt get visible if the screen reentered. Butif the object is on screen while visible, the signal works. My solution is to set only the sprite visibility on false. Now it works totaly fine
An other way to gain performance is to change the frequency of the audio files of the game to around 22050hz in audacity, it works great on low end platforms like mobile and co
You can also do this in engine by ticking "Max rate" in the import settings on the files (provided they are wav files of course). Another thing I'd suggest is if you have to lower the sample rate, is that you try using 24000hz instead of 22050hz. It's not much, but in my experience it can sound much much better.
I don't see how reducing the audio sample rate of input files would meaningfully affect performance, especially for WAV files which require almost no CPU to be decoded.
@@Calinou even if there is no decoding going on, the playback frequency itself can consume more CPU as there is twice the amount of points to process in the same timeframe. though indeed with encoded files it's even worse. my tests were mostly done with OGG files as I mostly referred to background music as an example. When I played around with godot on 3DS playing an OGG at 44100hz reduced the fps of around 10 frames and simply setting it to 22050hz made the fps loss of around 1-2fps which was more acceptable
YOOO!! You just saved my game! I was creating an open world RPG game but canceled it due to performance issues, now with this trick I can get back into the project. Thank you so much! You guys are the best
For an open world, you will likely have to create and remove sections of the map as the player walks around, Like only load sectors of the map that are close enough to the player, up to 4 at a time. Though you could well use a visibility notifier to easily know when a section of the map is too far from the player and ready to queue_free()! Also, check the VisibilityEnabler2D node to automatically toggle processing on ais and whatnot.
@@AxisCoords yea, think, you can also use fog to reduce the draw distance to reduce a bit popping, also use it in c++ so you got good perfomance, as gdscript is not the best at deleting and drawing stuff every frame. Also there are possibilities streaming mesh textures, will come at 4.1.
Also check out InstancePlaceholder/"Load As Placeholder" in the nodes. You can combine that with VisibilityNotifiers to load and unload entire scenes. Probably best to wait 30s or so for the unloading after "screen_exited" signal so it doesn't happen prematurely.
We used to do this stuff with quad trees etc.. works well for collisions as for creating a tree that tells what branches to draw. Obviously requires one to have their entities in orderly fashion in a data structure :)
This seems like an optimization that should be built into the engine. I can see that it might not be trivial (building a list of nodes sorted by size or size of all their nested children), but it seems doable. Are there any reasons why this optimization can not realistically be built in?
You'd need to know about sprites that move and those that don't on top of the bounding boxes + nodes that draw to the canvas, and so on. And how do you decide how high or low in the node tree you place the notifiers? There's no one size fits all way to do that. So that'd be why. Even for Unity I remember back in the day, I used a plugin to batch things together and save performance. By default, it was the same as Godot. Making a mini plugin/editor script like that for Godot should be much easier than for Unity.
@@Gdquest A hash-grid is actually very easy to do for figuring out what to render, both for moving or not moving nodes. That's what physics does, and I swear I saw a setting in the 2D engine mentionning a grid too, unless I mixed it up with something else. There are other options as well such as quadtree (One Lone Coder made a video about it)
It's good to know, thanks. I checked and there's a spatial partitioning setting in the project settings, and I tried changing them but saw no difference on the framerate in 2D. So may it be 3D-only in Godot 3?
@@Gdquest It might be wrongly designed then if framerate still goes down for visible nodes outside of the screen. Or used for something other than avoiding to iterate everything. Or maybe what you found is not actually used for 2D: there is "cell size" in 2D physics so it's not used for rendering. There is "thread safe BVH" in Rendering/Threads but I think that only applies for 3D. I can't seem to find anything for 2D.
I had been using a similar node but this one also freezed scripts and physics, i noticed a great performance gain, but i didnt knew i should set the visibility to false at the ready function. Great tip.
I would need someone who has experience with this to tell us about their findings, e.g. one of the persons who worked on rhythm games. Like we could make a demo where we step through frames and show how the input system works, or how for instance an area might need an extra frame to update or how call_deferred() can affect your game. But that's not exactly input latency I think?
Measuring input lag should be done like with any other engine: a high-speed camera pointing at the screen with your input device visible :) As for reducing input latency, it's the same as in other engines: disable V-Sync and set the framerate cap (`Engine.target_fps`) to the highest value you can sustain in all scenes, without bottlenecking the GPU. (If you can't cap framerate for some reason, set the low-latency mode to Ultra in the NVIDIA Control Panel.)
This method should not be used in Godot 4! The VisibilityNotifier uses the culling system's outputs and so it won't detect visibility if your node is invisible. If 2D culling is a performance issue for you, you should use a proximity-based solution to change the visibility of nodes.
And I thought Godot used a hash-grid to partition space occupied by sprites... I thought it then gathered only CanvasItems in chunks of the grid intersecting with the screen, and then draw them. A trick like that would mean it wouldn't matter how many sprites you have in the scene, the only limit being memory. It's such a simple idea I am really surprised that it's not what Godot does according to this video (But maybe that idea can be used in game code anyways). Or maybe it does, but backward: iterating first everything and then check the partition structure, which is wrong because the point of the structure is to NOT waste time iterating everything in the first place^^"
Yeah I was surprised too. I didn't check the servers but when testing you can clearly see that adding sprites outside the screen, even far away, increases CPU usage proportionally and starts to hit the framerate. You can test that in the demo by increasing the generated room count - it's only sprites and tilemaps, there's no processing or other logic tied to the nodes. And so yeah if there was some space partitioning, you would expect to be able to add tons of rooms without hurting the framerate in this demo.
This is not work in godot 4 visibility notifier need to work that note visible need to set true otherwise not work So one time it's show and hide next time the didn't show
This trick is so useful it should almost be the default behavior if you add a VisibilityNotifier2D as a child. Or it could be an optional feature that you can turn off and on with property called something like "HideParentWhenOffScreen" or something. If this was built into the VisibilityNotifier2D node you would not have to add your own script.
The thing is one visibility notifier per sprite doesn't give you a performance boost. You need to use them on groups of nodes to really benefit. And Godot can't know how you want to group nodes, which move through the world, and so on. That's why by default Godot checks each sprite, probably like most other game engines.
@@Gdquest Yes but I didn't intend for this to be the default behavior for all 2D nodes. My suggestion was only to eliminate the need for adding the code manually and only for nodes with child VisibilityNotifier2D node. I imagine that it would be a minimal addition. I don't know if it is technically possible. I just assumed that it would be.
Ah gotcha, having the thing just toggle visibility automatically, so you don't have to connect manually. Makes sense. If the VisibilityEnabler2D node (not VisibilityNotifier2D shown in this video) doesn't do that automatically already then it'd be good to add. But perhaps it already does that.
@@TastyMysteryMeat VisibilityEnabler.process_parent and other properties handle that stuff, it looks like doesn't need connect signals but not sure rn.
Phrases like "200% faster" always bug me, so I have to ask what the majority of people think: What is 200% bigger than a 4 meter stick: an 8 meter stick, or a 12 meter stick? I'm of the mindset that comparative adjectives like, bigger, faster, etc add that value. In this video's case, I would say "100% faster," or "200% as fast." My reasoning is if you were to say 100% faster, the opposing logic would mean it's the same speed. A neat trick, though. I'm now wondering if it's possible to do this for areas of the game world that may not be broken up into rooms, or how it could work with a time map. Maybe I would have to break tile maps into chunks to be able to take advantage of this?
For the tile map, you would likely use this more for the sprites that sit over it. We'd have to check the tilemap, but I'm pretty it's optimized to instantly calculate the region it has to render, so it shouldn't have this check cost of individual sprites. Say you have many patches of grass you can cut like in old Zelda, and they're individual sprites, then you'd want to group those along with all the other surrounding sprites perhaps.
yup I agree, the title isn't correct, a doubling in performance would be 100% faster or 200% as fast. this becomes very apparent when you go below 100%: imagine the title saying "make your game 50% faster" by the logic the author is using currently, that would mean a reduction in performance, when of course its supposed to be an increase.
@Deea A. yes, 200% increase in fps means trice the previous value. that is how anybody who understands percentages would interpret the title - no need of any world to adapt.
@Deea A. Yes, _"200% framerate"_ *indeed* means 2x original framerate, but *not* _"200% faster (framerate)"._ Put it in a clearer way, _"0% more/faster/bigger"_ means *no increase.*
I’m using a VisibilityNotifier for my 3D project. It seems to be able to see through walls, but I want objects show in front of camera, I don't want objects show in behind the walls, what I will do?
I tried it on godot 4. It did hide the entity of screen, but when they reentered they're still invisible. I think it was because when the parent got hidden, the notifier2d node also got hidden
@@entei6736 so how did you do it? Weirdly enough eventhough the onscreen notifier got hidden, it still tracks whether or not it's parent are on screen if i'd print something every time the node went in and our of the screen it'll work. But not toggling visibility on or off tho :/
So if the visibility turns off do they still continue there tasks? Like if I have an animal that keeps on wandering in the wild. If I turns its visibility off while its not on camera I still want it to keep updating its position and wander off.
Could this trick be used for parts of a 3D map as well (like on hallways or specific sections of a larger area), or would it be more beneficial to just rely on frustum and occlusion culling with LOD optimization? For context, I want to create a map similar to the 2.5D Pokemon games on DS. Just without any transition/loading screens for each route, town, or city.
I was going to do this anyway, awesome to see the performance increase How much increase might we expect from pausing the processing of scripted objects in the same way?
I think your math is wrong. Going from 1900 fps to 2800 is only a 60% increase, not 100%. You had to get 3600 fps to double the frame rate. No monitor can show 3000 fps anyway. If you disable vsync you also make your game consume way more energy. Especially if you are going to play it on a phone or Steamdeck or similar devices running on battery.
Is this test quadtree based? I'm not a Godot user and I just saw this on my feed. I wouldn't use a tree-based test for a static tiled 2D/2.5D world myself(since there's a better way) but still an interesting approach. I did use a quadtree for polygon based level rendering though.
It's not tree based, it's like splitting the game world in a "grid" the way I've done it in the demo, and depending on your game it's more like culling large rectangular areas with a single check.
Where does the "parent-child" system come in? For simple grids, you shouldn't need a parent-child relationship. A tree structure(like a quadtree), lends itself to that.
@@igorthelight Vsync is also notorious for causing FPS drops (usually it gets cut in half during the drops). The way it is typically implemented, it is worse than just setting an FPS limit equal to your monitor refresh rate. So removing vsync and then adding a slider for the user to change their FPS limit is much better in terms of performance.
This is not work in godot 4 visibility notifier need to work that note visible need to set true otherwise not work So one time it's show and hide next time the didn't show
IMO, just by surrounding the nodes you want to hide by a Visibility Notifier. It's more about showing only needed node (the on screen ones) than using rooms.
My question is, while this seems similar to occlusion culling in theory, are there any major differences between these two processes? Like, does this process only work while the node is completely out of the viewport, etc.
Occlusion culling is mostly a 3D thing, it's about figuring out what's on-screen but hidden behind something else (for example, a character walking behind a house in a 3D game). This trick is about helping the engine take a shortcut for things that are outside the screen. The engine could have this optimization built-in according to other comments and well I hope that Godot 4 would get something like this, at it can make a substantial difference in maps with many sprites.
Feels kinda stupid that the default engine behaviour is worse than what the developer can tediously cobble together from tools offered by that same engine. You're basically creating a hash grid. Something the engine should be doing instead of iterating over every single sprite
it shouldn't, visibility is purely rendering. an exception is that hidden UI elements don't receive input events iirc. I hope there are no other exceptions, positional audio comes to mind. will have to check.
How may it be used if, for example, my whole level is one big tile map? Is it possible to hide a parts of tilemap using visibility notifiers, or even maybe individual tiles? Or do I need to split my level into several individual tile maps and use the trick on them?
Yes though if your tilemap covers the whole level, I wouldn't recommend breaking it down. Tilemap drawing should be optimized out of the box, that is, it shouldn't even check if it needs to draw anything outside the screen as it can calculate the region of the tilemap that is on screen (tilemaps are like infinite grids).
Never un-cap your fps, if you do it, if some one is playing your game on a stream, it will cause the stream to lag, cuz the gpu and cpu are giving all the resources to your game, yo update it 30000 per second!!!! And in general, it will make your client computer GO slower if he have other program open in the computer :/
but it does check if a sprite is on screen or not and hides it if its not visible. but it becomes a problem if you have hundreds of sprites in one scene with multiple instances of that scene in the world. then the engine has to check every single sprite. Vissiblity Notfier node solves this problem.
It is culling them, but frustrum culling works by checking each object's bounds every frame (true in both 2D and 3D). What this video is about is grouping many sprites together to do just 1 bounds check for a whole group of objects at once instead of checking each individually. But nothing gets drawn outside the screen, the check Godot (and any game engine) does in the first place is to figure out what's on screen.
@@lizardrain You don't understand. Godot is culling them but if you have 100 spirites in one parent node. Engine will check all 100 nodes. Making 100 calls. But if you add notifier to your parent node. Engine will check parent and hide him (and children will be hidden automatically). So the difference is if Godot needs to check 100 nodes or only 1 node. Thus it will be ⏩⏩⏩ faster ☺️
Get the free and open-source demo here: github.com/GDQuest/godot-demos-2022 (please star the repository too to help people find it!)
We have more demos and guides available there, and more in preparation!
You asked us to make it easy to download our open-source demos, so we listened. You can now easily download each individual project on this website: gdquest.github.io/godot-demos-2022/
is there a simular trick for tilemaps?
IMPORTANT NOTE : for anybody in godot 4.x this is now done automatically so the signals dont work if the object is not visible , its also in the docs
ua-cam.com/video/lsoUQOpd3Yk/v-deo.html
This is not accurate for me. I'm on Godot 4.0.3 and I had to explicitly add notifiers and enablers.
Automatic how to check or find it
No this not automatically work
You saved me tons of head scratches... :)
The signal does not work if the whole node itself is not visible.
So I set the visibility of my node to false, if it is outside the screen. And it didnt get visible if the screen reentered.
Butif the object is on screen while visible, the signal works.
My solution is to set only the sprite visibility on false.
Now it works totaly fine
An other way to gain performance is to change the frequency of the audio files of the game to around 22050hz in audacity, it works great on low end platforms like mobile and co
You can also do this in engine by ticking "Max rate" in the import settings on the files (provided they are wav files of course). Another thing I'd suggest is if you have to lower the sample rate, is that you try using 24000hz instead of 22050hz. It's not much, but in my experience it can sound much much better.
I don't see how reducing the audio sample rate of input files would meaningfully affect performance, especially for WAV files which require almost no CPU to be decoded.
@@Calinou even if there is no decoding going on, the playback frequency itself can consume more CPU as there is twice the amount of points to process in the same timeframe. though indeed with encoded files it's even worse. my tests were mostly done with OGG files as I mostly referred to background music as an example.
When I played around with godot on 3DS playing an OGG at 44100hz reduced the fps of around 10 frames and simply setting it to 22050hz made the fps loss of around 1-2fps which was more acceptable
though tbf the 3ds to begin with is *super* low end, even worse than most low end smartphones
@@SeleDreams You should test with WAV, because what Calinou meant, OGG requires decoding and WAV don't, it is most likely just send to hardware.
YOOO!! You just saved my game!
I was creating an open world RPG game but canceled it due to performance issues, now with this trick I can get back into the project.
Thank you so much! You guys are the best
For an open world, you will likely have to create and remove sections of the map as the player walks around, Like only load sectors of the map that are close enough to the player, up to 4 at a time. Though you could well use a visibility notifier to easily know when a section of the map is too far from the player and ready to queue_free()!
Also, check the VisibilityEnabler2D node to automatically toggle processing on ais and whatnot.
@@Gdquest oh very interesting, will definitely try it out.
Does this trick also work on Entities? Like NPC and stuffs?
@@AxisCoords yea, think, you can also use fog to reduce the draw distance to reduce a bit popping, also use it in c++ so you got good perfomance, as gdscript is not the best at deleting and drawing stuff every frame. Also there are possibilities streaming mesh textures, will come at 4.1.
@@saul8510 Oh alright, thank you so much.
Also check out InstancePlaceholder/"Load As Placeholder" in the nodes. You can combine that with VisibilityNotifiers to load and unload entire scenes. Probably best to wait 30s or so for the unloading after "screen_exited" signal so it doesn't happen prematurely.
Thank you SO much for all your amazing tutorials.
This really helps a lot!
this is actually pretty useful! thanks for sharing
We used to do this stuff with quad trees etc.. works well for collisions as for creating a tree that tells what branches to draw. Obviously requires one to have their entities in orderly fashion in a data structure :)
This seems like an optimization that should be built into the engine. I can see that it might not be trivial (building a list of nodes sorted by size or size of all their nested children), but it seems doable.
Are there any reasons why this optimization can not realistically be built in?
You'd need to know about sprites that move and those that don't on top of the bounding boxes + nodes that draw to the canvas, and so on. And how do you decide how high or low in the node tree you place the notifiers? There's no one size fits all way to do that.
So that'd be why. Even for Unity I remember back in the day, I used a plugin to batch things together and save performance. By default, it was the same as Godot. Making a mini plugin/editor script like that for Godot should be much easier than for Unity.
@@Gdquest A hash-grid is actually very easy to do for figuring out what to render, both for moving or not moving nodes. That's what physics does, and I swear I saw a setting in the 2D engine mentionning a grid too, unless I mixed it up with something else. There are other options as well such as quadtree (One Lone Coder made a video about it)
@@Gdquest Nah I definitely think this should be very doable for the engine
It's good to know, thanks. I checked and there's a spatial partitioning setting in the project settings, and I tried changing them but saw no difference on the framerate in 2D. So may it be 3D-only in Godot 3?
@@Gdquest It might be wrongly designed then if framerate still goes down for visible nodes outside of the screen. Or used for something other than avoiding to iterate everything.
Or maybe what you found is not actually used for 2D: there is "cell size" in 2D physics so it's not used for rendering. There is "thread safe BVH" in Rendering/Threads but I think that only applies for 3D. I can't seem to find anything for 2D.
I had been using a similar node but this one also freezed scripts and physics, i noticed a great performance gain, but i didnt knew i should set the visibility to false at the ready function.
Great tip.
Could you guys make a video on input latency? Is there a way to measure it or make it better on Godot?
I would need someone who has experience with this to tell us about their findings, e.g. one of the persons who worked on rhythm games. Like we could make a demo where we step through frames and show how the input system works, or how for instance an area might need an extra frame to update or how call_deferred() can affect your game. But that's not exactly input latency I think?
any video about how the input system works on godot would be pretty helpful
Measuring input lag should be done like with any other engine: a high-speed camera pointing at the screen with your input device visible :)
As for reducing input latency, it's the same as in other engines: disable V-Sync and set the framerate cap (`Engine.target_fps`) to the highest value you can sustain in all scenes, without bottlenecking the GPU. (If you can't cap framerate for some reason, set the low-latency mode to Ultra in the NVIDIA Control Panel.)
What a masterpiece i saw . i hope all tutorials is like you
What a perfect timing for the game I'm developing RN. Awesome!
This would make a nice little utility for the asset library
I will try it today. Thank you
Did you know there is a node called VisibleOnScreenEnabler2D that auto hides and shows nodes
Edit: It enables and disables nodes
it does actually the same thing?
This method should not be used in Godot 4! The VisibilityNotifier uses the culling system's outputs and so it won't detect visibility if your node is invisible. If 2D culling is a performance issue for you, you should use a proximity-based solution to change the visibility of nodes.
thank you very much! this is a great help
And I thought Godot used a hash-grid to partition space occupied by sprites... I thought it then gathered only CanvasItems in chunks of the grid intersecting with the screen, and then draw them. A trick like that would mean it wouldn't matter how many sprites you have in the scene, the only limit being memory. It's such a simple idea I am really surprised that it's not what Godot does according to this video (But maybe that idea can be used in game code anyways). Or maybe it does, but backward: iterating first everything and then check the partition structure, which is wrong because the point of the structure is to NOT waste time iterating everything in the first place^^"
Yeah I was surprised too. I didn't check the servers but when testing you can clearly see that adding sprites outside the screen, even far away, increases CPU usage proportionally and starts to hit the framerate. You can test that in the demo by increasing the generated room count - it's only sprites and tilemaps, there's no processing or other logic tied to the nodes.
And so yeah if there was some space partitioning, you would expect to be able to add tons of rooms without hurting the framerate in this demo.
This is not work in godot 4 visibility notifier need to work that note visible need to set true otherwise not work
So one time it's show and hide next time the didn't show
This trick is so useful it should almost be the default behavior if you add a VisibilityNotifier2D as a child. Or it could be an optional feature that you can turn off and on with property called something like "HideParentWhenOffScreen" or something. If this was built into the VisibilityNotifier2D node you would not have to add your own script.
The thing is one visibility notifier per sprite doesn't give you a performance boost. You need to use them on groups of nodes to really benefit. And Godot can't know how you want to group nodes, which move through the world, and so on.
That's why by default Godot checks each sprite, probably like most other game engines.
@@Gdquest Yes but I didn't intend for this to be the default behavior for all 2D nodes. My suggestion was only to eliminate the need for adding the code manually and only for nodes with child VisibilityNotifier2D node. I imagine that it would be a minimal addition. I don't know if it is technically possible. I just assumed that it would be.
Ah gotcha, having the thing just toggle visibility automatically, so you don't have to connect manually. Makes sense. If the VisibilityEnabler2D node (not VisibilityNotifier2D shown in this video) doesn't do that automatically already then it'd be good to add. But perhaps it already does that.
@@TastyMysteryMeat VisibilityEnabler.process_parent and other properties handle that stuff, it looks like doesn't need connect signals but not sure rn.
Thank you!
Have to try. Thank you..
Phrases like "200% faster" always bug me, so I have to ask what the majority of people think:
What is 200% bigger than a 4 meter stick: an 8 meter stick, or a 12 meter stick?
I'm of the mindset that comparative adjectives like, bigger, faster, etc add that value. In this video's case, I would say "100% faster," or "200% as fast." My reasoning is if you were to say 100% faster, the opposing logic would mean it's the same speed.
A neat trick, though. I'm now wondering if it's possible to do this for areas of the game world that may not be broken up into rooms, or how it could work with a time map. Maybe I would have to break tile maps into chunks to be able to take advantage of this?
For the tile map, you would likely use this more for the sprites that sit over it. We'd have to check the tilemap, but I'm pretty it's optimized to instantly calculate the region it has to render, so it shouldn't have this check cost of individual sprites.
Say you have many patches of grass you can cut like in old Zelda, and they're individual sprites, then you'd want to group those along with all the other surrounding sprites perhaps.
yup I agree, the title isn't correct, a doubling in performance would be 100% faster or 200% as fast.
this becomes very apparent when you go below 100%: imagine the title saying "make your game 50% faster"
by the logic the author is using currently, that would mean a reduction in performance, when of course its supposed to be an increase.
Bigger the number, higher the views 🤣
@Deea A. yes, 200% increase in fps means trice the previous value. that is how anybody who understands percentages would interpret the title - no need of any world to adapt.
@Deea A. Yes, _"200% framerate"_ *indeed* means 2x original framerate, but *not* _"200% faster (framerate)"._ Put it in a clearer way, _"0% more/faster/bigger"_ means *no increase.*
I’m using a VisibilityNotifier for my 3D project. It seems to be able to see through walls, but I want objects show in front of camera, I don't want objects show in behind the walls, what I will do?
My game has a static camera so I’m already not drawing beyond screen bounds, but this is super good information for future projects
I tried it on godot 4. It did hide the entity of screen, but when they reentered they're still invisible. I think it was because when the parent got hidden, the notifier2d node also got hidden
yes apperantly they changed it in godot 4.0. I tried for a while to find a way around but I can't get it to work the way it was like in godot 3.5
@@entei6736 so how did you do it?
Weirdly enough eventhough the onscreen notifier got hidden, it still tracks whether or not it's parent are on screen if i'd print something every time the node went in and our of the screen it'll work. But not toggling visibility on or off tho :/
@@MrBlitzpunk I did the same thing on this video ua-cam.com/video/LZzCMWxg5a4/v-deo.html
@@MrBlitzpunk Godot 3.6 beta 2 added this feature.
Quick solution:
Time.scale *= 2
Hi. Thanks for the video. How does what you say work now in Godot 4.1? Is it still relevant?
Shouldn't this happen automatically with frustum culling?
That's really impressive
So if the visibility turns off do they still continue there tasks? Like if I have an animal that keeps on wandering in the wild. If I turns its visibility off while its not on camera I still want it to keep updating its position and wander off.
Could this trick be used for parts of a 3D map as well (like on hallways or specific sections of a larger area), or would it be more beneficial to just rely on frustum and occlusion culling with LOD optimization?
For context, I want to create a map similar to the 2.5D Pokemon games on DS. Just without any transition/loading screens for each route, town, or city.
cool! was wondering lately how sprite visibility affected performance, thanks!
I was going to do this anyway, awesome to see the performance increase
How much increase might we expect from pausing the processing of scripted objects in the same way?
I think your math is wrong. Going from 1900 fps to 2800 is only a 60% increase, not 100%. You had to get 3600 fps to double the frame rate. No monitor can show 3000 fps anyway. If you disable vsync you also make your game consume way more energy. Especially if you are going to play it on a phone or Steamdeck or similar devices running on battery.
excellent tip.
Is this test quadtree based? I'm not a Godot user and I just saw this on my feed.
I wouldn't use a tree-based test for a static tiled 2D/2.5D world myself(since there's a better way) but still an interesting approach. I did use a quadtree for polygon based level rendering though.
It's not tree based, it's like splitting the game world in a "grid" the way I've done it in the demo, and depending on your game it's more like culling large rectangular areas with a single check.
Where does the "parent-child" system come in?
For simple grids, you shouldn't need a parent-child relationship. A tree structure(like a quadtree), lends itself to that.
how would you increase performance in 3D games? would VisibleOnScreenEnabler3D work in conjunction with occlusion culling?
Could you teach me how to draw the floor? is it 32x32?
Is this still current with Godot 4.1? It seems that's something that could have been optimized directly in Godot by now.
nice.i was actually wandering how godot draw stuff when they are not in screen.
Does it work for 3D too???
Does all this still work for godot v4.0?
Does this apply to 3D aswell, or is that handled differently?
Differently.
Google "Godot 3 portals" or "Godot 4 occlusion culling"
Another tip for the other way around games (all in the same screen) is turning off vsync.
What it does for the performance?
You will get 2000+ FPS, higher power consumption, louder fans, screen tearing and for what? Smaller input lag? ;-)
@@igorthelight Vsync is also notorious for causing FPS drops (usually it gets cut in half during the drops). The way it is typically implemented, it is worse than just setting an FPS limit equal to your monitor refresh rate. So removing vsync and then adding a slider for the user to change their FPS limit is much better in terms of performance.
@@_ByteBlaze_ Fair point!
Woo thanks
does this still apply for Godot 4.1?
If you already getting 1000 fps then why do this
visible_notifier.connect("screen_entered", self, "show"). What would it be like in Godot 4?
This is not work in godot 4 visibility notifier need to work that note visible need to set true otherwise not work
So one time it's show and hide next time the didn't show
@@successspotu Can you show it with an example code snippet?
How can I use this method on tile maps or games wich have not separate rooms?
IMO, just by surrounding the nodes you want to hide by a Visibility Notifier. It's more about showing only needed node (the on screen ones) than using rooms.
My question is, while this seems similar to occlusion culling in theory, are there any major differences between these two processes? Like, does this process only work while the node is completely out of the viewport, etc.
Occlusion culling is mostly a 3D thing, it's about figuring out what's on-screen but hidden behind something else (for example, a character walking behind a house in a 3D game).
This trick is about helping the engine take a shortcut for things that are outside the screen. The engine could have this optimization built-in according to other comments and well I hope that Godot 4 would get something like this, at it can make a substantial difference in maps with many sprites.
Hola, ¿dónde puedo ver el documento que se muestra en 3:52?, gracias.
github.com/GDQuest/godot-demos-2022/tree/main/2d-rendering-optimization#readme
how to use this on tile map
Feels kinda stupid that the default engine behaviour is worse than what the developer can tediously cobble together from tools offered by that same engine. You're basically creating a hash grid. Something the engine should be doing instead of iterating over every single sprite
Yup, I dunno if it's still the case with Godot 4 as they're working a lot more on performance optimization there.
More 3d in godot 4 please, i am planning to leave unreal and unity since they are too much for normal games. Doesn't make sense for indie developer.
This is one of those programming tricks that is really obvious in hindsight, but someone had to find it first.
I'm definitely going to use this! :)
Will it stop any logic updates for these objects?
No, for that you need to use the VisibilityEnabler2D node, which inherits from VisibilityNotifier.
it shouldn't, visibility is purely rendering.
an exception is that hidden UI elements don't receive input events iirc.
I hope there are no other exceptions, positional audio comes to mind.
will have to check.
Can you do a battle royals tutorial
That's a great optimization. It's really noticable when games dip below 2000fps, really going to change the industry with this one
Is it possible an implementation like this in 3d?
Yes!
Google "Godot 3 portals" and "Godot 4 occlusion culling".
Gonk!
How may it be used if, for example, my whole level is one big tile map? Is it possible to hide a parts of tilemap using visibility notifiers, or even maybe individual tiles? Or do I need to split my level into several individual tile maps and use the trick on them?
You will have to work with chunks
does a 3d version of this exist
Yes!
Google "Godot 3 portals" and "Godot 4 occlusion culling".
Will this works for tilemap too?
Yeah, every single node in Godot has a visibility option.
@@rienafaire9286 thanks for reply
Yes though if your tilemap covers the whole level, I wouldn't recommend breaking it down. Tilemap drawing should be optimized out of the box, that is, it shouldn't even check if it needs to draw anything outside the screen as it can calculate the region of the tilemap that is on screen (tilemaps are like infinite grids).
@@Gdquest oh ok. In the video, there were many rooms shown. Does all are inside a tile map or grid of sprites( node2d) ?
Aren't you just describing culling?
No
2:14
It's great, but didn't developers discover this trick like 25 years ago? I'm sure all of the early 3D games use something similar.
They did!
3D uses occlusion culling and fruustrum culling. Godot 4 has that too.
Isn't this the same thing as culling? Godot can't do this by default?
Nice
I though that I saw SCP:9999 instead of PFS:9999
hi there my fellow unity refugee, you have found a great channel.
Never un-cap your fps, if you do it, if some one is playing your game on a stream, it will cause the stream to lag, cuz the gpu and cpu are giving all the resources to your game, yo update it 30000 per second!!!! And in general, it will make your client computer GO slower if he have other program open in the computer :/
Removing the cap is just a temporary change to benchmark with the FPS on, as in this video.
If you delete the game then minecraft should crash pretty fast
When a parent is invisible, all of its children are invisible.
Community college biology.
Really no one knew about that?
You would be surprised ;-)
So you just stole someone else's video, essentially?
Godot is garbage for drawing things off screen to begin with. I'm pretty sure every other game engine is smart enough to not do that.
but it does check if a sprite is on screen or not and hides it if its not visible. but it becomes a problem if you have hundreds of sprites in one scene with multiple instances of that scene in the world. then the engine has to check every single sprite. Vissiblity Notfier node solves this problem.
Godot doesn't draw things that are off-screen, it culls those objects both in 2D and 3D.
@@Gdquest It's obviously not culling them since that's what this whole video is about.
It is culling them, but frustrum culling works by checking each object's bounds every frame (true in both 2D and 3D). What this video is about is grouping many sprites together to do just 1 bounds check for a whole group of objects at once instead of checking each individually.
But nothing gets drawn outside the screen, the check Godot (and any game engine) does in the first place is to figure out what's on screen.
@@lizardrain You don't understand. Godot is culling them but if you have 100 spirites in one parent node. Engine will check all 100 nodes. Making 100 calls. But if you add notifier to your parent node. Engine will check parent and hide him (and children will be hidden automatically). So the difference is if Godot needs to check 100 nodes or only 1 node. Thus it will be ⏩⏩⏩ faster ☺️
Thanks!