Godot

Hello, everyone! Last time, we created a fairly interesting fire effect that works well in 2D games. This time, we’ll try transforming it into a 3D shader, put it on the surface of a cylinder, and observe the results.

Essentially, I have some Area2Ds in which I'm changing the direction of gravity. I only want this to happen if the player has enough speed. So, I was checking for that condition and setting gravity_space_override = Area2D.SPACE_OVERRIDE_DISABLED when the player was too slow. That's when I ran in to this issue...

Here is a minimal amount of code to reproduce my issue. On an Area2D, when my player enters it:

func _on_body_entered(body: Node2D) -> void:
    if body is Player:
        print('enter')
        gravity_space_override = Area2D.SPACE_OVERRIDE_DISABLED
        gravity_space_override = Area2D.SPACE_OVERRIDE_REPLACE

I see "enter" printed multiple times. If I comment out the last two lines, "enter" is printed once, as I'd expect.

How might I modify gravity_space_override without having the body_entered signal firing off again?

Edit: Solved by instead of toggling the gravity on/off with gravity_space_override, I'm storing these

var default_gravity: float = 980
var default_gravity_direction: Vector2 = Vector2.DOWN
var default_gravity_point: bool = false

and toggling between the default/downward gravity and the alternate gravity that I want in the Area2D.

Recently I created a Godot proposal to change VoxelGI nodes so they can use a sub-thread to bake their VoxelGIData. This allows baking more than one VoxelGI node at once, but also to observe the bake progress and show it in, e.g. a progress bar.

https://github.com/godotengine/godot-proposals/issues/14243

I also created a proposal to expose the bake progress via signals, since it is currently not visible to non-engine code.

https://github.com/godotengine/godot-proposals/issues/14242

I have already completed the implementation:

Expose VoxelGI bake progress via signals #116600

Allow baking VoxelGI nodes off the main-thread #116833

If you are interested in these changes, please give a thumbs-up to both the proposals and the pull requests. The maintainers already let me know that they will most likely only merge if other people express interest in this.

Please also share it with others that you think might be interested in these changes.

cross-posted from: https://feddit.nl/post/52370482

Hey everybody,

I'm looking for a tool stack that is FOSS as much as possible, running on linux.

Currently:

• 2D Art: Krita / GIMP / InkScape
• 3D Modeling: Blender
• Engine: Godot
• Content creation: Kdenlive

All this works great, but I'm looking for a more general world editor.

I was watching this video from Blizcon 2016 and their editor, WowEdit, is just the dream. No way there is something like that right now.

What I'm mostly looking for is a tool where I can paint terrain, with a pen, like they do in the video. It needs to be able to export heightmaps and splatmaps. Do any of you have a good suggestion for this? I've looked at TerreSculptor, but that is mostly generation of heightmaps, which is cool in it's own right.

It's okay if it isn't FOSS, but being FOSS would be preferable. I try to support such projects anyway, so Free as in Libre, haha.

At FOSDEM 2026, members of Element’s VoIP team - Robin Townsend, Timo Kandra and Valère Fédronic - presented a deep dive into the future of real time communication on Matrix.

Their talk gave an update on MatrixRTC, Matrix’s framework for bringing voice, video, and other live, interactive experiences directly into rooms. Their contributions to Matrix enable everything from large-scale calls and collaborative tools to multiplayer games, virtual worlds, and entirely new ways for people to interact in real time.

Watch the whole presentation Advancing real time communication on Matrix

We’ve been working on MatrixRTC as part of our work at Element, to build the foundations for large-scale, secure VoIP solution into matrix. This work is done by the same team that is behind Element Call. Element Call, the VoIP part of Element, sits on top of MatrixRTC.

Matrix has traditionally focused on persistent, asynchronous messaging. Real time communication (sub 100ms), however, introduces a very different set of requirements. It demands low latency, flexible participation, and should be ephemeral. At the same time, it must preserve Matrix’s core principles of decentralisation, federation, and security.

Historically, Matrix clients only supported 1:1 peer-to-peer WebRTC calls, using Matrix rooms primarily for call-oriented signalling and persisting what was effectively ephemeral state into room history. As calls grew larger and use cases expanded beyond simple voice and video, it became clear that real time communication needed first-class support in the Matrix protocol itself, with the flexibility to support multiple use cases beyond 1:1 calls.

MatrixRTC is our attempt to make real time applications native to Matrix, striking a balance between decentralisation and the practical demands of scalable, low-latency, end-to-end encrypted media and data exchange. Through concrete demos and implementation details, we showed how this approach enables entirely new classes of applications, including calls, games, virtual worlds and collaborative tools. Introducing slots for interactive rooms

MatrixRTC introduces the concept of slots, which allow room administrators to add real time communication features to their rooms. These slots can be anything from voice or video calls to 3D virtual worlds or multiplayer games. Each slot combines an application - which specifies the type of data participants exchange - and an identifier, allowing multiple parallel sessions in the same room.

The first application we’re adding to the specification is m.call, which covers basic voice and video calls. But third-party apps are fully supported, enabling developers to create custom experiences like virtual simulations or collaborative games.

Slots are managed via state events, ensuring that they are persistent, authorised, and can be moderated by room admins. When participants want to join a slot, they connect by sending membership events and publish their media over a chosen transport. A transport in this context is a WebRTC SFU (Selective Forwarding Unit). Currently supported is the LiveKit SFU. FullMesh WebRTC or a websocket solution are also considered while designing with MatrixRTC.

Other features, like delayed events, notifications, and encryption, are also part of the specification. For deeper technical details, past Matrix Conference talks and the Matrix Spec Proposals repository are excellent resources. Sticky events: reliable, ephemeral data delivery

It is essential to provide a good experience before joining a session. A client should be informed immediately via sync about any ongoing MatrixRTC session. To avoid polluting room state with this information, sticky events are introduced. These events are ephemeral, low-privilege, and can be encrypted. During a limited lifetime (for example around an hour), their delivery is guaranteed over sync. They are stored in the room timeline rather than in the authoritative room state that is subject to state resolution. Sticky events are ideal for real time session participation, letting clients join ongoing calls or sessions and immediately receive the necessary data, even if they missed some events earlier due to gappy-syncs (more on sticky events here). Transports: keeping real time communication decentralised

Each participant chooses their transport, which can be a home-server resource or a peer-to-peer connection. For Element Call, we currently use LiveKit media servers, which handle the heavy lifting of fan-out for media streams. This approach allows large calls to scale gracefully while keeping the system federated, decentralised and efficient. For example, in a typical office environment, many users converge on the same homeserver, minimising connections needed to participate in a large call. A MatrixRTC SDK for developers

With these protocol improvements, we also refactored our codebase, creating a MatrixRTC SDK that simplifies building real time applications. The SDK handles the complexities of connecting to multiple SFUs, authenticating with Matrix, managing sticky and delayed events, and exchanging media. Developers can now use this SDK to build applications, such as games or collaborative tools, without having to handle the underlying real time infrastructure directly.

For instance, we demonstrated a simple HTML template application using the Godot game engine, leveraging the MatrixRTC SDK. Through this setup, developers can access observable real time data to integrate it into games. The MatrixRTC SDK is used as an abstraction for core capabilities such as user identity and account setup, device verification, encryption (not shown in the demo), media connectivity via an SFU, and the existing Matrix backend infrastructure. Building on MatrixRTC: live demos

To showcase what’s possible, we built two multiplayer games using MatrixRTC. Players communicate over federated servers, exchange real time events, and interact seamlessly despite network variability. Although live demos sometimes face latency challenges, the system handles rollbacks and syncing to ensure a smooth experience.

We showed Godot-MatrixRTC-FlappyRoyal, a game similar to FlappyBird, and Godot-MatrixRTC-Keyboard-Kart, a racer-like multiplayer game.

Games and other applications can be run as widgets, providing an added layer of security. The trusted Client handles encryption and key management, so users never expose their full Matrix account or keys to external real time apps running inside the Widget.

Currently, the MatrixRTC SDK is available in JavaScript, but the widget architecture allows the low level Matrix responsibilities to be done in other SDK’s. The Matrix Rust SDK, for instance, supports the widget postmessage api. Widgets are based on iFrames. With Wasm becoming more mainstream, this opens the door for real time applications beyond the web stack, from Godot-based games to custom simulations.

MatrixRTC represents a significant step forward for Matrix, enabling decentralised, real time, and interactive experiences in rooms while maintaining the federated, secure principles of the ecosystem.

Hi everyone! We’ve already created several 2D fire effects here and even one or two 3D ones. This time we’ll return to two dimensions and show how to make a slightly different kind of fire using a few layers and a somewhat different technique.

You play as a test subject escaping from an underground lab. You have two phase abilities - phase-dash and phase-wave. Phase-dash is a forward semi-teleport which also damages enemies and negates damage while active. Phase-wave is a projectile attack. As the game progresses, more defences will spawn in each room, including laser tripwires, mines, turrets and drones - and, of course, there's always the omnipresent laser grid advancing from behind, getting ever faster. The goal is to reach room 100, beat a final wave of defences, and escape.

Now pretty much all the core mechanics are in place, I thought I'd share some footage and ask the community for your thoughts on the look of the game as it is. You know how it is: you stare at your own project so long, you lose sight of what might be glaring issues to an outside observer.

So, Godot lemmy - what do you think? 😅

EDIT: we've decided to share a build with you guys, if you're interested in testing it out. We have Windows, Linux and Mac builds. Have fun! https://irmoz.itch.io/phase-killer

The Godot Engine team recently posted about more issues with "AI slop", including various pull requests that have become a big drain on resources.

You've likely seen other projects talking about this across the net, because AI agents and people who use various generative AI tools are generating code and submitting it to lots of projects to pump up their numbers - often while having no clue what the code does and not even testing it. This is becoming a bigger problem as time goes on.

Nous sommes en train de préparer une installation pour la #NuitBlanche de #Montreal, en utilisant le moteur de jeu @godot et les contrôleurs midi de chez Intech Studio. C'est la première fois qu'on utilise leur matériel #OpenHardware et on a beaucoup de fun. On a hâte de vous montrer ça !

#opensource #interactivity

cross-posted from: https://lemmy.ca/post/60381611

Hi everyone! We have another effect on the agenda whose code fits on a single line. This time it will be a simple edge detection, which we can also use as an original way to fade out a scene, for example, after finishing a level in our game. So let’s go ahead and program that one line.

Hi everyone! We’ve already covered several shaders that simulate fog, but they were mostly side effects of technologies that aren’t primarily designed for fog. This time, we’ll finally create a true fog shader and take a look at what options Godot 4 offers for this type of effect.

I'd like to contribute what i can to this sub, but not beeing able to post gif showcasing my things isn't really helpful, any idea why it doesn't work ?

(Photo is irrelevant)

With the stability gained over the past five releases, it's time for polish and quality of life improvements for everyday development.

Hello, everyone! This is a continuation of the previous tutorial, in which we created a simple dithering effect that can be used to simulate, for example, low-quality film or interference in a TV signal on an old screen. And as I promised, this time we’ll finish the topic by programming a shader for classic dithering with a regular structure.