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
A demo showing how to build an input key remapping screen. - Click the buttons to change the bound keys. - Persists the keys to disk, so they are preserved after the project is restarted. Language: GDScript Renderer: Compatibility
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
A demo showcasing drag and drop functionality. - Drag and drop the color buttons to copy their colors over. - Click on the buttons to manually adjust their color. Language: GDScript Renderer: Compatibility
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
A demo showing BiDi text and BiDi overrides, line breaking and justification, and OpenType font features. 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 demo includes procedurally generated materials with 3 different techniques: - NoiseTexture2D: Built-in class that generates images on the CPU based on noise patterns (such as Simplex or Cellular). This is suited for static textures only. Texture generation is done asynchronously and is faster than using scripting, since the noise algorithms are implemented in C++ in the engine. - Scripting: Uses the Image class to procedurally generate an ImageTexture on the CPU. This is suited for static textures only. This approach is more flexible than NoiseTexture2D, but is slower to generate textures. Once the texture is generated, rendering performance is identical to NoiseTexture2D. - Shaders: Uses a 2D shader on a ColorRect node that matches a Viewport's size with the resulting ViewportTexture applied to a material. This is updated on the GPU in real-time, and is most suited for animated textures. This approach can also be used for static textures, with a lower performance overhead since the texture doesn't need to be updated every frame. Language: GDScript Renderer: Forward+
3D Platformer demo using a CharacterBody3D node. It uses similar code to the 2D platformer, but implemented in 3D. Language: GDScript Renderer: Forward+
This demo contains a series of tests for the 3D physics engine. They can be used for different purposes: - Functional tests to check for regressions and compare the behavior between physics engines - Performance tests to evaluate and compare performance between physics engines Language: GDScript Renderer: Forward+
This demo showcases a physical light and camera units setup: https://docs.godotengine.org/en/latest/tutorials/3d/physical_light_and_camera_units.html This allows you to use real world units for lights (lumen, lux, Kelvin) and cameras (shutter speed, aperture, ISO sensitivity). By default, Godot uses arbitrary units for many physical properties that apply to light like color, energy, camera field of view, and exposure. These properties use arbitrary units, because using accurate physical units comes with a few tradeoffs that aren't worth it for many games. As Godot favors ease of use out of the box, physical light units are disabled by default. If you aim for photorealism in your project, using real world units as a basis can help make things easier to adjust. References for real world materials, lights and scene brightness are wildly available on websites such as Physically Based: https://physicallybased.info/ 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+