This demo shows a traditional isometric view with depth sorting. A character can move around the level and will also slide around objects, as well as be occluded when standing in front or behind them. Language: GDScript Renderer: Compatibility

A demo showing how Godot seamlessly enables the use of localized resources and texts. Language: GDScript Renderer: Compatibility

A demo showing an example of a graphics settings menu. Included settings are: Video settings: - UI scale. - Resolution scale. - Display filter (bilinear or AMD FidelityFX Super Resolution 1.0). - Fullscreen. - V-Sync (traditional and adaptive). - Anti-aliasing (MSAA and FXAA). - Camera field of view. Effect settings: - Signed distance field global illumination (SDFGI). - Bloom (glow). - Screen-space ambient occlusion (SSAO). - Screen-Space reflections (SSR). - Screen-space indirect lighting (SSIL). - Volumetric fog. - Screen adjustments: brightness, contrast, saturation. Language: GDScript Renderer: Forward+

This demo showcases Godot's global illumination systems: LightmapGI, VoxelGI, SDFGI, ReflectionProbe and screen-space effects like SSAO and SSIL. Use the mouse to look around, W/A/S/D or arrow keys to move. Language: GDScript Renderer: Forward+

This is a simple game where your character must move and avoid the enemies for as long as possible. This is a finished version of the game featured in the "Your first 2D game" tutorial in the documentation. For more details, consider following the tutorial in the documentation: https://docs.godotengine.org/en/latest/getting_started/first_2d_game/index.html Language: GDScript Renderer: Compatibility

This demo shows how to use autoloads to change between scenes. Language: GDScript Renderer: Compatibility

A demo showing how to use scene instancing to make many duplicates of the same object. Language: GDScript Renderer: Compatibility

Demonstrates how to override GUI colors and styleboxes at runtime. Language: GDScript Renderer: Compatibility

This project demonstrates how to set up a project to handle screens of multiple resolutions and aspect ratios. This demo allows you to adjust the window's base resolution, stretch mode, stretch aspect, and scale factor (internally known as "stretch shrink"). This lets you see what happens when adjusting those properties. Make sure to resize the project window in any direction to see the difference with the various stretch mode and stretch aspect settings. The GUI can be made to fit the window or constrained to a specific aspect ratio from a list of common aspect ratios. On ultrawide aspect ratios, this can be used to prevent HUD elements from being too spread apart, which can harm the gameplay experience. For non-essential HUD elements, specific controls can be made to ignore this aspect ratio constraint when it makes sense (e.g. a list of players on the side of the screen). Additionally, a GUI margin setting is provided to better handle TVs with an overscan area to prevent GUI elements from being cut off. This can also improve the gameplay experience on large monitors by bringing HUD elements closer to the center of the screen. A DynamicFont with multichannel signed distance field (MSDF) rendering is also used. This allows for crisp font rendering at any resolution, without having to re-rasterize the font when the font size changes. This makes changing the various settings in this demo faster, especially when large font sizes are used as a result of the GUI scale factor setting being increased. Note that by default, Godot uses font oversampling for traditional rasterized DynamicFonts. This means MSDF fonts are *not* required to have crisp fonts at higher-than-default screen resolutions. Language: GDScript Renderer: Compatibility

This is a demo of Multi-channel Signed Distance Field fonts in Godot. The technique used allows the text to remain clear under arbitrary zooms and rotations. The "multi-channel" part refers to the font texture being generated in a way that allows for higher precision when rendering the font. This allows MSDF fonts to be more readable at small font sizes compared to single-channel signed distance field fonts. Language: GDScript Renderer: Compatibility

Navigation demo for 3D scenes, with a character able to pathfind around a static 3D environment. The navigation path is drawn using a line. Code is provided for polyline following in 3D. Language: GDScript Renderer: Forward+

GD Paint is a simple image editor made using Godot and GDScript. It supports different types of "brushes": a basic pen/pencil and eraser, as well as a rectangle and a circle brush. Language: GDScript Renderer: Compatibility

This project showcases the two main 3D text techniques supported by Godot: Label3D and TextMesh. Both Label3D and TextMesh exist in 3D space and can optionally be occluded by other objects, but they serve different use cases. Label3D: The Label3D node is a 3D node like any other. It draws text using one quad per character, which can optionally be set to work as a billboard. TextMesh: Unlike Label3D, TextMesh can optionally have actual depth since it generates geometry to represent the text. TextMesh is not a node, but a PrimitiveMesh resource you use within a MeshsInstance3D node. Therefore, you won't see TextMesh in the Create New Node dialog. Icons can also be displayed in Label3D and TextMesh using icon fonts, which can be generated from SVG files using serivces like Fontello: https://fontello.com/ Note that while Label3D supports colored rasterized fonts (such as emoji), only monochrome fonts can be generated from Fontello. TextMesh and Label3D with MSDF fonts are limited to monochrome fonts too. Both standard rasterized and MSDF fonts can be used in Label3D, while TextMesh will only support fonts that can be drawn as MSDF well. This excludes fonts that have self-intersecting outlines, which Godot currently doesn't handle well when converting them to MSDF. In most scenarios, Label3D is easier to use and can look better (thanks to outlines and MSDF rendering). TextMesh is more powerful and is intended for more specialized use cases. Language: GDScript Renderer: Forward+

Showcases various Control nodes with their names affixed for easy recognition. This demo is inspired by similar "control gallery" demos found in GUI toolkits such as GTK. The 3 main panels ("Basic controls", "Numbers" and "Lists") are separated using HSplitContainer and VSplitContainer nodes. This makes their individual size adjustable. Drag the empty space between panels to resize them. Language: GDScript Renderer: Compatibility

This is a demo for an OpenXR project where player movement is handled with a CharacterBody3D as a base node. This is based on the Character body centric solution as explained in the room scale manual page: https://docs.godotengine.org/en/stable/tutorials/xr/xr_room_scale.html#character-body-centric-solution How it works: With modern VR equipment the user is able to move around a large playspace. This is often refered to as roomscale VR. The position of the headset and controllers are tracked in reference to a fixed point within this playspace. This is often a point on the ground at the center of the playspace mapped out by the user when setting up their guardian. In Godot the center of this playspace is represented by the `XROrigin3D` node with camera and controllers being tracked through resp. `XRCamera3D` and `XRController3D` child nodes which can thus not be positioned by the user. The misunderstandings this causes in handling player movement is described in detail in the XR room scale manual page, a highly recommended read before continuing with this demo: https://docs.godotengine.org/en/stable/tutorials/xr/xr_room_scale.html This demo implements the character body centric solution to the player movement problem. Virtual movement by the player (e.g. movement through controller input) in this demo is handled similarly to a non-XR Godot game. Physical movement by the player will result in the character body attempting to move to the players new location. If successful the XROrigin node is moved in the opposite direction of the players movement. If unsuccessful the character body stays behind, the further the player moves the more we black out the screen. Action map: This project does not use the default action map but instead configures an action map that just contains the actions required for this example to work. This so we remove any clutter and just focus on the functionality being demonstrated. There are only two actions needed for this example: - aim_pose is used to position the XR controllers - move is used as the input for our movement "Move" being the hero here. This action is only bound to one of the two controllers, by default making it a right hand option. Godot will always associate the move action with the controller that is bound to it. The code example assumes either controller could trigger the move action. Switching from right to left hand is a separate topic out of scope of this demonstration. Also following OpenXR guidelines only bindings for controllers with which the project has been tested are supplied. XR Runtimes should provide proper re-mapping however not all follow this guideline. You may need to add a binding for the platform you are using to the action map. Running on PCVR: This project can be run as normal for PCVR. Ensure that an OpenXR runtime has been installed. This project has been tested with the Oculus client and SteamVR OpenXR runtimes. Note that Godot currently can't run using the WMR OpenXR runtime. Install SteamVR with WMR support. Running on standalone VR: You must install the Android build templates and OpenXR loader plugin and configure an export template for your device. Please follow the instructions for deploying on Android in the manual: https://docs.godotengine.org/en/stable/tutorials/xr/deploying_to_android.html Language: GDScript Renderer: Compatibility

This demo shows how to use compute shaders to populate a texture that is used as an input for a material shader. When the mouse cursor isn't hovering above the plane random "drops" of water are added that drive the ripple effect. When the mouse cursor is above the plane you can "draw" on the plane to drive the ripple effect. Technical description: The texture populated by the compute shader contains height data that is used in the material shader to create a rain drops/water ripple effect. It's a well known technique that has been around since the mid 90ies, adapted to a compute shader. Three textures are created directly on the rendering device: - One texture is used to write the heightmap to and used in the material shader. - One texture is read from and contains the previous frames data. - One texture is read from and contains data from the frame before that. Instead of copying data from texture to texture to create this history, we simply cycle the RIDs. Note that in this demo we are using the main rendering device to ensure we execute our compute shader before our normal rendering. To use the texture with the latest height data, we use a Texture2DRD resource. This is a special texture resource node that is able to use a texture directly created on the rendering device and expose it to material shaders. The material shader uses a standard gradient approach by sampling the height map and calculating tangent and bi-normal vectors and adjust the normal accordingly. Language: GDScript Renderer: Forward+

This demo is a minimal first-person voxel game, inspired by others such as Minecraft. How it works: Each chunk is a StaticBody3D with each block having its own CollisionShape3D for collisions. The meshes are created using SurfaceTool which allows specifying vertices, triangles, and UV coordinates for constructing a mesh. See documentation for procedural geometry generation: https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html The chunks and chunk data are stored in dictionaries. New chunks have their meshes drawn in separate Threads but generating the collisions is done in the main thread, since Godot does not support changing physics objects in a separate thread. There are two terrain types, random blocks and flat grass. A more complex terrain generator is out-of-scope for this demo project. See documentation for more information on using multiple threads: https://docs.godotengine.org/en/stable/tutorials/performance/using_multiple_threads.html The player can place and break blocks using the RayCast3D node attached to the camera. It uses the collision information to figure out the block position and change the block data. You can switch the active block using the brackets or with the middle mouse button. There is a settings menu for render distance and toggling the fog. Settings are stored inside of an AutoLoad singleton called "Settings": https://docs.godotengine.org/en/latest/getting_started/step_by_step/singletons_autoload.html This class will automatically save settings, and load them when the game opens, by using the File class. Sticking to GDScript and the built-in Godot tools, as this demo does, can be limiting. If you are making your own voxel game, you should probably use Zylann's voxel module instead: https://github.com/Zylann/godot_voxel Language: GDScript Renderer: Forward+

This is an example of Godot's volumetric fog capabilities with the Vulkan renderer. Showcased features are: - Positive/negative density volumes that affect albedo (incoming light) and emission. - Box/ellipsoid shapes, height falloff, and density modulation using a 3D texture. - Temporal reprojection for greater stability and avoiding flickering. The difference is demonstrated with a moving fog volume. - Global density adjustment. With FogVolume nodes that have a positive density, it's possible to apply volumetric fog only in specific areas. - Custom FogVolume shader with real-time 3D noise. Shader provided by alghost: https://godotshaders.com/shader/moving-gradient-noise-fog-mist-for-godot-4/ Language: GDScript Renderer: Forward+

This project showcases how to use variable rate shading (VRS) in 3D to improve performance: https://docs.godotengine.org/en/latest/tutorials/3d/variable_rate_shading.html Performance metrics are also displayed to evaluate potential performance gains. Language: GDScript Renderer: Forward+

This is a demo implementing different types of trucks of varying complexity using vehicle physics. Controls: - Up Arrow, W, Gamepad Right Trigger, Gamepad A/Cross: Accelerate - Down Arrow, S, Gamepad Left Trigger, Gamepad B/Circle, Gamepad X/Square: Brake/reverse - Left Arrow, Gamepad Left Stick, Gamepad D-Pad Left: Steer left - Right Arrow, Gamepad Left Stick, Gamepad D-Pad Right: Steer right - U, Gamepad Select, left-click speedometer: Change speedometer unit (m/s, km/h, mph) - C, Gamepad Y/Triangle: Change camera (exterior, interior, top-down) - Escape, Gamepad D-Pad Up: Go back to menu (press again to exit) On mobile platforms, the vehicle automatically accelerates. Touch the left and right edges of the screen to steer. Touch the middle of the screen to brake/reverse (this also temporarily stops acceleration). Language: GDScript Renderer: Forward+ on desktop, Mobile on mobile

This is a simple game where your character must move and jump to squash as many enemies for as long as possible. You gain 1 point for every enemy squashed. Controls: - Up Arrow, W, Gamepad Left Stick: Move up - Down Arrow, S, Gamepad Left Stick: Move down - Left Arrow, Gamepad Left Stick: Move left - Right Arrow, Gamepad Left Stick: Move right - Space, Right Mouse Button, Gamepad A/Cross: Jump This is a finished version of the game featured in the "Your first 3D game" tutorial in the documentation. For more details, consider following the tutorial in the documentation: https://docs.godotengine.org/en/latest/getting_started/first_3d_game/index.html This demo covers: - Handling player input. - Moving and jumping in a 3D game. - Spawning enemies randomly around the game arena. - Using the built-in animation editor to breathe life to your game. - Creating a complete game loop with lose conditions, score, and the ability to restart. Language: GDScript Renderer: Forward+

RigidBody character demo for 3D using a capsule for the character. Cubes as RigidBodies spawn in the map from above to show interaction with the player (jump on them, gently push them), which would be impossible with a KinematicBody. How it works: This demo uses a RigidBody3D node for the player, and StaticBody3D node for the level. Each has colliders, the player moves itself via `apply_central_impulse()` in `_physics_process()`, and collides with the level. The ShapeCast3D node is used to detect whether the player is able to jump (i.e. touching the floor). Compared to a RayCast3D node which is infinitely thin, this allows for more reliable checking if the player is standing over an edge or corner. Language: GDScript Renderer: Forward+

This project showcases various 3D particle features supported by Godot, for both GPU-based and CPU-based particles. This includes particle collision, attractors, trails and subemitters. Language: GDScript Renderer: Forward+

This demo showcases the use of occlusion culling and mesh level of detail in a 3D scene. The demo contains 1,024 identical rooms in a 64×64 grid. The room geometry is used as a basis for a baked OccluderInstance3D, which allows each room to be culled if it is hidden by another room's walls. Occlusion culling can provide a performance benefit in draw call-bound scenarios. However, since the Forward+ backend uses a depth prepass, the shading cost is already reduced by the depth prepass. As a result, occlusion culling will not always result in a tangible performance increase, especially in outdoor scenes that have fewer occlusion culling opportunities. Indoor scenes with no DirectionalLight3D casting shadows are a best-case scenario for occlusion culling. The blue spheres make use of automatically generated LODs, which reduce the number of triangles that need to be rendered each frame by the GPU. This provides a significant performance increase in scenes with complex geometry. In most scenes, this provides a greater performance benefit compared to occlusion culling. While running the demo, you can toggle the use of mesh LOD and occlusion culling to view the performance difference these features make in this project. Results will vary depending on your CPU and GPU model. WARNING: If you are using a engine build that is not fully optimized, you may notice that enabling occlusion culling decreases performance. This is because occlusion culling is a demanding process on the CPU, which needs all the build-time optimization it can get. Official builds are fully optimized, but self-compiled builds are not fully optimized by default (use the `optimize=speed use_lto=yes` SCons options). Language: GDScript Renderer: Forward+