That's why I integrated manifold into godot engine for constructive solid geometry!
https://github.com/godotengine/godot-proposals/issues/9711
In Show HN: Formally verified 3D CSG: Trust 93 lines spec, not 1000 lines AI codegodotengine
godot-proposals
OPEN SOURCE2020–2026
godotengine / godot-proposals
godot-proposals
Godot Improvement Proposals (GIPs)
26Distinct people
29Mentions
0Explicit recommenders
1.5KGitHub stars
What to know before exploring
What it is
Godot Improvement Proposals (GIPs)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- godotengine/godot · linked in 2 of the same discussions
- openstreetmap/id · linked in 2 of the same discussions
- stashapp/stash · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year29 dated mentions
Observed mentions: 2020-01-29 19:13:19 UTC to 2026-07-28 13:45:17 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 0 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Godot Improvement Proposals
Welcome to the official Godot improvement proposals repository!
Here, the Godot community shares and discusses
ideas to improve the engine.
Everyone is welcome to participate. If you have an idea, please read the introduction below
to get started. We also encourage you to browse existing proposals and participate in their discussions.
TipUse the Godot proposals viewer
to browse proposals, and the discussions tab
to browse ideas.
Bug reports are not a subject of the proposal process. If you experience
an issue while using Godot that cannot be attributed to a missing feature,
please file a bug report instead.
How to suggest improvements
You have two options to suggest improvements for the engine: issues and discussions.
To create a proposal issue,
you should have a well-developed idea of the change you're suggesting, and put effort into a highly
detailed description of it. Please read the rules below before
you create a proposal issue. You may also wish to read about our evaluation process
to improve the chances of your proposal being accepted.
If you have a more general idea for an improvement without specific details, please start
a discussion instead.
We also encourage you to iterate and expand upon ideas of other contributors and try to formulate
proposal issues (with appropriate attribution to those other contributors). This helps
the ideas come to fruition by giving the community something specific to discuss or implement.
All proposals, both issues and discussions, will be discussed and evaluated by the
community, and may even end up being implemented by a fellow motivated Godot contributor.
Keep in mind though that all changes need the approval of Godot maintainers before they can
be merged.
Rules for proposal issues
Note: The following points describe requirements for a proposal issue.
A discussion,
on the other hand, can be started in any form.
Do your research. Before you post, discuss your idea with the community,
to find if other people are experiencing the same problem and brainstorm solutions together.
Search existing proposals and
ideas for potential duplicates.
And search the internet and asset library for
addons that can solve your problem without an engine change.
Use your own words. You are not allowed to use AI / an LLM to write your proposal.
AI-written proposals are hard to read and often invent facts and solutions that won't work.
If you aren't comfortable with English, write your proposal in your mother tongue and use
dedicated translation software (not a chat bot) to translate it into English.
Give context to your problem. To give an example in cooking: Say you wanted to bake
a cake and found a recipe. Don't write your problem as "I need flour", write "I want to bake
a cake". To add flour is the proposed solution. You should also describe which workarounds
you tried and link related proposals. If you do not provide a well-founded motivation, your
proposal will be closed.
Be specific with your solution. It is not enough to describe just the idea; your proposal
should make all the necessary design decisions such that they can be discussed by the community.
Include images, mock-ups, diagrams, code, if applicable. If your solution lacks in detail,
is ambiguous, or otherwise unactionable, your proposal will be closed.
Use one issue per proposal. Do not cram multiple feature requests into a single proposal,
as this makes it harder to discuss features individually.
Have patience. Godot is community-driven: if no other users are interested in
your proposal, it will not be added to Godot. Remember that the more effort you put into your
proposal, the more likely it is to gather attention. You could also share and discuss it in
Godot's community channels to draw attention to it.
What to do if your proposal is closed
We usually only close invalid, duplicate, and rejected proposals. We do not close proposals
lightly, but we can make mistakes: If you think we should re-open it, please join us in the
contributor's chat and describe the situation.
If your proposal was closed as invalid, please review the rules above and put more
effort into your next proposal.
If your proposal was closed as a duplicate, please review the linked proposal. If it is
truly duplicate, or more detailed than yours, we encourage you to support that proposal and
contribute to its discussion. If you think your proposal is sufficiently different to stand
on its own, please appeal this decision by making a comment.
If your proposal was rejected, please review the stated problem and see if you can find
another solution. Often, solutions that are rejected for Godot can be implemented as a
plugin or
GDExtension.
How we evaluate proposals
The following is a list of considerations that Godot maintainers use when deciding to
accept,
close, or leave a proposal open.
These considerations are in balance; no one is more important than another.
Godot maintainers have discretion to weigh the factors as they see fit.
In addition, consider reading this article
which describes technical considerations of Godot maintainers for new features.
1. Does the proposal comply with the rules?
Read the proposal and check to see that it complies with the above-stated rules.
If it does not, close the proposal.
2. How much support is the proposal receiving?
Evaluate the amount of support the proposal is receiving. This is an ongoing
analysis. If a proposal receives little support at first, it may receive
additional support later on.
3. Can this proposal be implemented with an addon or GDExtension?
Evaluate whether it is possible for the solution to be implemented as an addon
or GDExtension.
If it is possible for the proposal to be in an addon, it is less likely to be
accepted.
4. Does this proposal benefit most users?
Determine whether this proposal benefits all users, or just certain users.
For example, a feature that can only be used for 3D FPS games is less
likely to be accepted th
Read the full README on GitHubWhat Hacker News says
29 sourcesIt's a really tricky one, but I think it's the right call for Godot, but probably not for other projects. I'm the current maintainer of GodotJS (TypeScript bindings for Godot). LLMs can generate genuinely useful solutions for Godot e.g. a functional WebGPU implementation for Godot — https://github.com/godotengine/godot-proposals/issues/6646.
However, as a senior engineer with fairly deep technical knowledge in these areas, I'm now using AI in my own projects. Frankly, before even touching Github, I'm already drowning in code reviews generated by my own use of an LLM!
There are meaningful, generally good PRs waiting for my attention against GodotJS, and other projects I (somewhat) maintain e.g. MoonSharp, C# Lua runtime. It was already extremely difficult to stay on top of PR code reviews for reasonably technical projects. When you're alre
Read the rest
ady somewhat burnt out from reviewing LLM code all day, it's so much more exhausting than it used to be.
https://github.com/godotengine/godot-proposals/issues/7842
For starters. Read through this thread and be appalled.
In Godot 4.6 Release: It's all about your flowMm.
I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough.
“Fully supports”? I’d say more like “works mostly”.
/shrug
Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative.
I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script.
What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions.
Anyway. Godot did have any good excuse;
Read the rest
gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard. Other options existed. …but, instead the time and effort went to building a new language.
One thing you can look back at in Unitys history that is interesting is their aborted attempt to have js, c# and boo as scripting targets.
…but over time, it became clear that having feature parity in all of them wasn’t plausible.
I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest.
The only language they are committed to is gdscript.
[1] - https://docs.godotengine.org/en/stable/tutorials/scripting/c...
[2] - https://github.com/godotengine/godot-proposals/discussions/4...
Not for shaders while the game is running? https://github.com/godotengine/godot-proposals/issues/5269
In Leaving Rust gamedev after 3 yearsGodot was fine, for the most part, it's a good engine for small games. The main issue was around working together and resolving conflicts with git (Godot isn't really working and constantly kept changing IDs in resource files), and it kept losing data in scenes when the code changed so we had to rebuild things several times. On previous test games we also ran into huge performance issues in the editor when we wanted to do too much work in scenes, so we had to switch to doing most of the work in code.
The worst part was when I had to rip out a bunch of testing code that used @tool for release as it seemed to cause issues when doing a release build. The engine is generally not great when you want to follow clean software engineering (e.g. dependency injection is not possible, I opened a proposal to that end here[1]).
[1]: https://github.com
Read the rest
Looking at the interactive changelog on github [1] it looks like there was a lot more work merged in already, some 811 pull requests. And yet this results in only 4 bullet points on their write up?
I think one of the problems Godot suffers from is the inability to market themselves properly. A big highlight of that is their logo. In terms of design, it does not have a "serious" or "professional" feel. Of course, there is a subjective nature to the conversation, but it has been discussed [2] in the past, and dismissed entirely as if it was not an important conversation, because of personal attachment.
I hope that when 4.3 is released, they will be able to add a little more to their write up to highlight all the important changes. Otherwise it feels like there are no important changes.
[1] - https://godotengine.github.io/godot-interactive-c
Read the rest
> The issues are luckily quite easy to fix, both by creating more LOD variants and by improving the culling system
How many polygons are there with and without e.g. AutoLOD/InstaLOD?
An LLM can probably be trained to simplify meshes and create LOD variants with e.g. UnityMeshSimplifier?
Whinarn/UnityMeshSimplifier:
https://github.com/Whinarn/UnityMeshSimplifier :
> Mesh simplification for Unity. The project is deeply based on the Fast Quadric Mesh Simplification algorithm, but rewritten entirely in C# and released under the MIT license.
Mesh.Optimize: https://docs.unity3d.com/ScriptReference/Mesh.Optimize.html
Unity-Technologies/AutoLOD:
https://github.com/Unity-Technologies/AutoLOD
"Unity Labs: AutoLOD - Experimenting with automatic performance improvements"
https://blog.unity.com/technology/unity-labs-autolod-experim...
InstaLOD: http
Read the rest
s://github.com/InstaLOD
"Simulated Mesh Simplifier": https://github.com/Unity-Technologies/AutoLOD/issues/4 :
> Yes, we had started work on a GPU-accelerated simplifier using QEM, but it was not robust enough to release.
"Any chance of getting official support now that Unreal has shown off it's AutoLOD?" https://github.com/Unity-Technologies/AutoLOD/issues/71#issu... :
> "UE4 has had automatic LOD generation since it first released - I was honestly baffled when I realized that Unity was missing what I had assumed to be a basic feature.*
> Note that Nanite (which I assume you're referring to) is not a LOD system, despite being similar in the basic goal of not rendering as many polygons for distant objects.
"Unity: Feature Request: Auto - LOD" (2023-05)
https://forum.unity.com/threads/auto-lod.1440610/
"Discussion about Virtualized Geometry (as introduced by UE5)" https://github.com/godotengine/godot-proposals/issues/2793
UE5 Unreal Engine 5 docs > Rendering features > Nanite:
https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Na...
Unity-GPU-Based-Occlusion-Culling:
https://github.com/przemyslawzaworski/Unity-GPU-Based-Occlus...
This looks amazing, and I really hope it gains some traction.
That being said, one of the biggest annoyances I had trying to switch to Godot from Unity is that their Scene view doesn't reflect the Game view at runtime (you can see the hierarchy, but there's no visuals, no gizmos, no debug raycasting or colliders)[1]. It seems this engine has the same missing feature?
[1]https://github.com/godotengine/godot-proposals/issues/7213
In Show HN: Unity like game editor running in pure WASMProposal: Expose a zero allocation API to Godot C# bindings
5 points · Open discussionHere is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... .
One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:
> As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).
It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.
Further down though somebody po
Read the rest
ints out:
> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.
This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:
> C# is faster, but requires some expensive marshalling when talking to Godot.
I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".
EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.
Doesn't support C#(this is being worked on but possible waiting for .NET 8 with AOT but then it still needs work).
Doesn't support the new 4.0 renderer, this is being worked on too. Webgpu support: https://github.com/godotengine/godot-proposals/issues/6646 .
Main issues right now that I'm aware of.
In Unity Engine to Godot Engine ExporterGodot's issue tracker is very popular! There have been ~4700 issues created this year, more than half of which have been closed, with ~2000 currently open.
Also of note, there's an open proposal[0] 'Automatically close old issues in a way everyone should be happy with' attempting to deal with the significant backlog.
[0] https://github.com/godotengine/godot-proposals/issues/3481
In Godot 4.1Working on Godot Engine, in a team adjacent to things like Unicode fonts (with left to right languages etc.) and multiple windows support was watching an uphill struggle for Godot Engine 4.0.
I have no idea how other team succeed at it either.
<edit>
Recognize every item on this list. EVEN THE WEBVIEW ONE https://github.com/godotengine/godot-proposals/issues/960
Unicode variables names https://github.com/godotengine/godot-proposals/issues/916
In So you want to write a GUI framework (2021)Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.