Rémi Verschelde

I opened a PR for Godot to add a Trail2D node. github.com/godotengine/...

GodotCon Amsterdam - Save the date! – Godot Engine Want to join? Amsterdam 23-24 of April. Get your tickets now! (Call for speakers and sponsors open)

GodotCon Amsterdam here we go!

📅 23-24 of April

🎟️ Get your tickets: tickets.godotengine.org/foundation/g...

📣 Submit your proposals: talks.godotengine.org/godotcon-ams...

havent posted much in awhile, here's a semi old gameplay greybox prototype, everything subject to change, except the missiles+custom gpu trail rendering, i'm kind of a fan how they turned out :) #godot #gamedev #prototype

some prototyping this morning for a loot collection ui. Could try even more vfx even based on rarity.

#gamedev #godot

GodotCon 2026 is happening soon and it is time to submit your proposals!

🇳🇱 Amsterdam
📅 23-24 of April
📍Pathé Amsterdam Noord

The ticket shop up yet, but you can start submitting your proposals for talks or workshops using this link:
🔗 talks.godotengine.org/godotcon-ams...

YouTube video by Vulkan Vulkanised 2026: Integrating Vulkan Ray Tracing into the Godot Engine

The recording of my Vulkanised 2026 talk is now live 🎥

In this talk, I walk through the journey of bringing a Vulkan RT pipeline into Godot.

www.youtube.com/watch?v=HddS...

Thanks to LunarG for the opportunity and to the @godotengine.org community for the reviews and feedback.

Please open a proposal with examples of why it's problematic for you.

This is Dejah2, my long in development motion graphics synthesizer, party generator, and madness simulator, created with the Godot game engine. Music is Strut, by KMFDM.
#GameDev #SoloDev #MotionGraphics #demoscene #Godot #Blender #TechArt #NoAI

Maintenance release: Godot 4.6.1 – Godot Engine The first 4.6 maintenance release has arrived!

It's only been three weeks since Godot 4.6, but hotfixes stop for no-one! 🔥

This first maintenance release, #GodotEngine 4.6.1, features several regression fixes to ensure a safe and seamless experience!

godotengine.org/article/main...

Honestly, AI slop PRs are becoming increasingly draining and demoralizing for #Godot maintainers.

If you want to help, more funding so we can pay more maintainers to deal with the slop (on top of everything we do already) is the only viable solution I can think of:

fund.godotengine.org

Which would likely also be a problem for Codeberg which FOSS people often recommend.

We'd need to come with our own CI runners, and likely reduce the build matrix even more than it is now (I keep pushing back when folks want to add more variants to validate edge cases).

Last I checked GitLab drastically reduced the resources they offer for free to open source projects: about.gitlab.com/pricing/

400 compute minutes per month would be spent in Godot in... one or two PRs?

GitHub self-evaluates our (free) spending at $90k for 2025.

Thanks for the offer!

We'll look into it and see if the checks implemented there make sense for our use case.

I'm monitoring how the situation evolves and we'll see.
I also don't expect GH to shield projects against AI slop its parent company actively facilitates.

But there's also a lot of pros for Godot being on GH which aren't easy to replicate elsewhere (e.g. network effect, free CI).

So ideally a system like this would be built into the Git hosting platform (GitHub, GitLab, Codeberg, etc.).

So the UX would be better and would show users something like: "You can't open PRs directly as your account is new/untrusted/whatever. Do <thing recommended by maintainers> instead."

It's been brought up internally, I haven't looked at it much yet.

I dislike raising the barrier to entry, but we might have no other choice.

Since vouch is reactive, I assume it happens after the fact and closes issues/PRs. That's not great for enthusiastic newcomers who get the boot right away.

But the flip side is being on a less popular platform, which increases the barrier to entry not just to AI slop, but also to genuine contributors or even Godot users who just want to report issues or participate in discussions.

Maybe, it's something I ponder.

We don't fully grasp the incentives for AI slop PRs but I assume a big part of it comes from trying to farm contributions on GitHub to look like an experienced software developer.

On a less popular platform, the problem might be less.

It is required by our contribution guidelines: contributing.godotengine.org/en/latest/pu...

It could be added to the PR template, but that's just placeholder text that can be removed/ignored and would be a bother to regular contributors who send PRs daily.

But yeah, that's an option we consider.

There's a bit of everything from AI generated garbage that makes no sense and doesn't compile, to PRs which may actually work, but may not be the right fix or well-understood by their author.

The latter can be genuine and may not disclose AI because they see it just as a tool they used.

I assume most folks are aware of how controversial AI-authored PRs are, especially if they haven't bothered testing the changes themselves.

So they see if it gets merged on a misunderstanding (and then it's not their problem if a project has to revert it because it's broken).

There is indeed growing concern about fully autonomous agent sending AI slop PRs, so maybe that could help.

But so far what we're seeing seems to be humans using AI coding assistants to generate code, which they then PR.

So there's still a human in the loop, just very misguided or disingenuous.

Godot prides itself in being welcoming to new contributors, letting any engine user have the possibility to make an impact on their engine of choice.

Maintainers spend a lot of time assisting new contributors to help them get PRs in a mergeable state.

I don't know how long we can keep it up.

I've seen some things being suggested, but it seems horribly ironic to have to run an AI on our CI to detect AI slop...

We might have to do this eventually if some good solutions emerge, but I'm really not keen on feeding the AI machinery.

- Is this code wrong because it was written by AI, or is it an honest mistake from an inexperienced human contributor?
- What do you do when you ask a PR author if they used AI because you're suspicious, and they all reply "yes I used it to write the PR description because I'm bad with English"?

We find ourselves having to second guess every PR from new contributors, multiple times per day:

- The description is verbose LLM output, is the code written at least partially by a human?
- Does the "author" understand the code they're sending?
- Did they test it? Are the test results made up?

Honestly, AI slop PRs are becoming increasingly draining and demoralizing for #Godot maintainers.

If you want to help, more funding so we can pay more maintainers to deal with the slop (on top of everything we do already) is the only viable solution I can think of:

fund.godotengine.org

Godot's GitHub has increasingly many pull requests generated by LLMs and it's a MASSIVE time waster for reviewers – especially if people don't disclose it. Changes often make no sense, descriptions are extremely verbose, users don't understand their own changes… It's a total shitshow. #godotengine

Grass, water and Glass UI shaders are now available on godotshaders too!

Link: godotshaders.com/author/binbun/

#godot #godotengine #shader #gamedev

Vector3 is a type, not a property name. The `object.property` syntax expects a proper name.

You may have multiple Vector3 properties in an object/class so it doesn't make sense to access it by type.

If the docs show you `Vector3 position` in a Camera node, you do `mycamera.position` to access it.