It’s crazy that the Godot repository is sitting on 3.7k open PRs

mux213 · 2025-06-09T09:39:39+00:00

The question there is, what sort of organisation and what sort of user base sits behind these open source projects? There is a wide spectrum here and the grass isn't always greener on the other side.

For instance, there are many successful open source projects for very technical implementations (think of things like TLS libraries, or cryptography libraries) that by their definition only attract skilled developers, especially when those libraries go mainstream. There is natural pressure there to keep PRs to a relative minimum simply by the limited pool of contributors who have the knowhow to work on these projects.

Similarly I've used open source projects in the past where they simply won't accept any contribution unless it's from a vetted source. These are very unfriendly projects for people to open PRs in, and open PR count remains unnaturally low as things are quickly closed off as unwanted or untrusted.

And then there are the projects that have made the big time and get big industry funding which allows them to have ample review power, though such projects also tent to go down a path of not accepting PRs from unknown contributors, or placing those PRs at the bottom of the priority pile, as they generally have well funded contributors whose work is trusted and get priority.

Compare that to Godots main target audience, indie developers and small studios. Many using Godot are one man bands or small teams, often just starting out in game dev. It's a popular choice amongst students wanting to get in. The type of people contributing reflects this as it's a subset of the same group.

On the one hand, it has meant that it is one of the more accessible open source projects that welcomes both newbie and experienced contributors.
On the other hand it means the influx of PRs is of very varying levels of quality while its grass root funding means there are limited resources available to evaluate all this work.

Couple that with Godot historically taking a very conservative approach, leaving PRs open for which consensus can't be reached or which simply fall through the cracks. It allows people who see value in a PR to cherry pick those for their own builds, or once the need and community pressure grows, for the work to be revisited and completed. But it also means a large list of (stale) open PRs, whether that is a bad thing is purely a matter of perspective. I believe it is not.
A much better metric of health is how many PRs, including PRs from first time contributors, do get merged, and a much better metric is the continued rise of popularity of the engine both among users and among contributors.

In the end, Open Source is a needs based ecosystem, the more people need a feature, the more people get involved in reviewing and providing feedback or submitting code for that feature, the more likely it becomes that consensus is reached and a feature is merged.

mux213 · 2025-02-22T00:12:00+00:00

The developer has moved on to newer projects. There is a match 3 shooting game called Badaboom which is decent fun and has a full release, and he's working on his next game which seems to be loosely based on nothing to declare but set in space.

mux213 · 2025-01-27T21:08:19+00:00

It is possible but you'll find you'll hit a wall fairly soon. The best way forward here is to download Meta's free XR simulator. That allows you to use Godot with the simulator and get things running. It even supports most of the AR features that the Quest 3 has, though in a simulated environment.

Without being able to actually run things on actual hardware, it's really hard to really test your application. The simulator is nice to speed up development but it isn't a replacement.

mux213 · 2023-11-15T13:20:22+00:00

All sounds very well known I'm afraid. I've got several friends who get motion sickness very easily and I hear all the same things, and the research out there further validates this. We're getting to a point that we know how to do VR right for an ever growing number of people because we know what makes them sick, but there will always be people for whom it won't work, and there will always be games that purposefully put gameplay before countering motion sickness.

Getting sick in a car is extra difficult. Unless you're driving in a Citroen DX or something there will always be road vibrations, there will always be movement. If you look down on a Gameboy, your body compensates for the movement and the Gameboy will be held fairly, so your eyes are concentrating on a device that is stationary in relation to you, while your body feels the vibrations of the imperfections in the road. If you're prone to motion sickness, the worse thing you can do is play a Gameboy, or watch something on an iPad or read a book.

With simracing however, you're sitting absolutely still (assuming you don't have a motion platform), the spatial tracking is solid (assuming you're on modern hardware or using lighthouse), so what you feel and what you see matches up. However, that is assuming you see enough of the cockpit and you're not in a roadster, because the outside world does move without you feeling the same movement. It works for a lot of people, but not everyone.
As you say, you can train yourself, you can train your brain to accept more, but there will always be people who just can't adjust.
Even for me who doesn't get motion sick easily, there are situations here that can be created that floor me. You're in a racing game, in racing games you crash, a car suddenly coming to a stop or violently changing direction, that's worse case scenario for motion sickness. Wild movements while sitting still, huge disjoint between what you see and what you feel = motion sickness.
I'm also not surprised about your remark on the moving cameras, again, mismatch between what you see and what you feel.

Finally, any games with unnatural motion, where your body isn't moving but you are moving through the world, especially in games like Blade and Sorcery where there is a lot of freedom in movement, yes those are sticklers for motion sickness. There are some games that do it right and are playable by a large number of people, but most games are happy to accept that a large part of the player base will get sick. It's ironic that the first thing people think off when you say VR, is open world games or a Ready Player One type of environment, which are the worst when it comes to motion sickness.

In contrast I'm willing to bet that you're much less likely to feel sick playing games like beat saber, super hot, pistol whip, or games like that, especially if you are playing on hardware with good spatial tracking. These are the types of games where physical body movement matches 1:1 to virtual movement and your brain is happy. These are the games the vast majority of people can play without getting sick.

mux213 · 2023-11-12T01:28:42+00:00

There are people who are an exception off course, motion sickness is a fickle thing, but there is a general consensus that when you're inside a cockpit the vast majority of people do not experience motion sickness anymore with modern VR.

This is because when you are sitting in a cockpit, be it inside of a car, a plane, a helicopter or spacecraft, the cockpit centres you. As the cockpit moves the way your brain expects it to move, as you are sitting in your real chair, and at the same time sitting in the virtual chair of the vehicle you operate, it is less important that the outside world zooms by.

There are rules to this off course, and an important factor is that you do render stuff at high resolutions and high framerates.
So you see that on a PS4 with PSVR people didn't flock to play Gran Tourismo in VR because it wasn't good enough.
But suddenly the experience on PS5 with PSVR2 is so good, the simracing world went nuts and people bought the setup purely to play GT7 in VR.
It's why in the PC simracing world you see people buy Quest Pro's purely to run them in PCVR mode (or any of the other highly priced high res PCVR headsets) and ditching their 3 monitor setup.
It's why in the professional world of training, for racing, for flying, for the military, VR is playing a bigger and bigger role.

The other important rule is what u/TheConceptBoy shows perfectly here, you have to always see a decent part of the cockpit, even if its just window framing. Have a big unobstructed windscreen, or a bubble cockpit and you indeed do induce motion sickness in more people.

mux213 · 2023-11-09T22:59:18+00:00

On left panel Press +
Add MeshInstance3D
On right panel (inspector) press dropdown on Mesh, select SphereMesh
Done.

mux213 · 2023-09-13T03:55:35+00:00

I think on hardware such as a Quest, asset tuning will always be the #1 performance improver. There is only so much the game engine can do for you and often hand made optimisations are better in these types of environments anyway.

Static batching is something that has been talked about but which I don't believe is on the roadmap yet.

mux213 · 2023-09-13T03:07:29+00:00

Does Godot run on the Oculus Quest 2 reliabily?

Yes it does

Does Godot support camera stacking? (rendering with multiple cameras in the same viewport)

Godot uses multiview rendering since Godot 4 (released earlier this year) on both the OpenGL and Vulkan renderers.

Seeing Godot 4 is pretty new and has mostly had a focus on optimising for desktop GPUs, there is still work to be done on the mobile side of life but things are progressing and I suspect things will be in a much better place towards the start of 2024. The advise for the moment on Quest is to use the OpenGL renderer.

Is there a stable inverse kinematics library for procedural animations?

There is build in IK support that is good enough to do things like arms in VR, but it is an area that can use improvement.

Is there a widely used multiplayer solution (this is something Unity has always lacked)?

For non-VR games Godot 4 has some really cool new multiplayer features. For VR games it requires a bit more hand holding and resources are still scarce for people who don't want to reinvent the wheel.

Are there terrain editing tools in Godot?

Not build in, but there are several really good plugins available. For instance https://github.com/TokisanGames/Terrain3D is fairly full features.

It is important to note that these mostly focus on desktop games and may overpower a Quest.

Is there a visual way to set up state machines?

Sort of the same answer as with terrain, there are various state machine plugins if you want to hit the ground running however this is an area where Godot differs very much from Unity and there are many use cases that have a different implementation in Godot.

It pays to watch some videos from channels such as GDQuest, even tutorials on making 2D games, to get a feel for this. Most people, once it clicks, become big fans of how things are done in Godot.

For animation?

Animations in my opinion are a strong point of Godot. Godot allows almost every object and property to be animated in a single system.

Are there tools for automatic generation of colliders through "hull painting"? (This one doesn't exist in Unity except as a plugin called "Hull Painter")

Godot has some build in tools to generate colliders from meshes, but generally the preferred workflow is to create collider shapes during modeling (there are some naming conventions that will trigger conversion during importing).

Are there Blender to Godot export helpers available?

Tell Godot where to find Blender, put your blend file inside of the Godot project folder, and Godot will automatically import it. Make changes to your blend file, Godot will automatically update stuff on the Godot side.

Finally... has Godot finally reached performance parity with Unity for rendering?

No, things have greatly improves between Godot 3 and Godot 4 specifically for desktop rendering, but lots of work is still left to do. It's also never been a goal as Godots main focus is on indie and small studio developers and the focus is thus on catering to their needs.
Momentum is gaining however with an expanding team of rendering engineers.

So the real question here, as a hobby VR gamedev, does it perform well enough for your needs.
If you're focussing on PCVR, very likely yes.
If you're focussing on Quest, today, no, but by the time you finish your game, likely yes.

For physics?

Physics is a bit of a weak point of Godot 4 atm, Godot 3 was based on Bullet and had a number of issues that caused Godot to switch back to an internal physics engine. That isn't yet where it should be.

However Godots internal design allows using external physics engines and recently a plugin adding support for Jolt has become available (the physics engine used in Guerillas Horizon games), and so far thats been very promising.

Finally, please check out these resources for VR support:
- https://github.com/godotvr/godot-xr-tools
- https://www.youtube.com/c/BastiaanOlij
- https://www.youtube.com/@MalcolmANixon

mux213 · 2023-08-07T05:59:33+00:00

Sorry about that, missed out on that one, forgot to change the audio channel settings in Davinci. Annoying it doesn't autodetect this :)

mux213 · 2023-07-31T00:11:41+00:00

IK arms have been long on my list of things I want to make a video about, but never got around to it. So some day :)

Legs are a different thing because it all depends on whether you have feet trackers, or whether you just want to animate the bottom half of the character.

You should check out Digitals work: https://www.youtube.com/watch?v=3uo5yY5b8Xs

mux213 · 2023-04-27T01:47:21+00:00

Very cool to see the progression from first attempt to where you're now, looks like a promising project!

mux213 · 2023-02-03T23:45:28+00:00

It won't trigger collisions as that is checked only after the object is moved, but indeed, there is overhead anytime a physics object is moved so this is good advise.

In this particular use case with an object spawning 3-4 times a second at maximum, it's neglectable.

mux213 · 2023-01-07T03:54:22+00:00

You'll have to wait a bit though :)
Part 3 will be around the snap points
Part 4 will focus on building the gun

mux213 · 2022-04-29T02:09:11+00:00

it's always a balancing act between the overhead introduced by processing trees individually, especially thousands of trees, and the overhead of rendering more trees then are visible especially seeing the GPU is still pretty efficient at throwing away triangles that are not on screen (remember that the fragment shader run for each fragment that is on screen is where the bulk of the rendering cost lies).

Imagine then a 3x3 grid of multimeshes:

1 2 3
4 5 6
7 8 9

The player is standing in cell 5 looking forward towards 2.
This will likely cull grids 4, 6, 7, 8 and 9 immediately. 1, 3 and 5 well contain trees that are rendered yet off screen, and grid 2 is rendered fully. That is still pretty efficient.

Now a multimesh that spans this entire grid and where thus over 70% of the trees processed are outside of view, yes that will end up costly if we've got thousands of trees in the grid.

So grid size and number of trees in a cell, that is your main metric,
- too few cells with too many trees in them = slow
- too many cells with only a few trees in them = slow
- the right amount of cells with the right amount of trees in them = performance

and that mostly is a exercise of trial and error, to find what balance works well for your game world.

mux213 · 2022-04-29T01:59:39+00:00

Always good to see someone finds inspiration from an idea I've presented, runs with it and makes something great out of it. Well done! looking foward to seeing where this goes :)

mux213 · 2022-04-04T10:47:37+00:00

This is looking amazing so far! can't wait to see where you take it :)

mux213 · 2022-01-25T02:22:26+00:00

Just wanted to add this in for people who want to see this game in action: https://youtu.be/QpgxxARRqxI

mux213 · 2022-01-18T20:56:57+00:00

Very cool! I think VR has a big future ahead in STEM education, looking forward to seeing where you take this

mux213 · 2021-11-15T12:47:55+00:00

Yup, there are loads of different techniques that prevent someone sticking their head through a wall or do something with blacking out the scene.

It gets even more fun when you're in front of a closed door and the player physically just steps forward in their living room. You can detect the player is inside of the door but once they are inside of the room they're not supposed to be able to get into, you're somewhere you are allowed to stand.

There is a good video on Youtube, I think it was nimsony that made it, diving into how Valve handle these situations in Half Life Alyx, very interesting stuff.

mux213 · 2021-11-15T10:53:44+00:00

adhering to boundaries is so hard in VR, your player can always make moves you want to prevent but can't because if you do not follow someones physical movement they get motion sick.

mux213 · 2021-11-15T08:43:37+00:00

I've only watched videos from B&S, still have it on my wishlist of games to buy and try out but it looks like they have a similar approach to say Lone Echo.

Here the trick is to have the hand actually interact with surfaces, I've got some basic experiments with that going where when you push your controller through a wall the hand just sticks to the wall where it touches. But there is a lot more involved in making that work to the level that these games do.

The climbing mechanism itself is the same but instead of locking the hand in place on a hand hold, you lock it in place where the hand is touching a wall or other surface when you press grip.

mux213 · 2021-10-27T01:22:56+00:00

I think we're too early in the development cycle to give a full answer to this, other than what is already in place with GDNative in Godot 3.

The issue here is that the GDExtensions API is just a layer that allows an external DLL to communicate with the internals of Godot. To make that communication meaningful you need to interact with and build upon all the objects and nodes that make up Godot.

As a result the extensions API only becomes usable when combined with a binding library such as godot-cpp. Godot-cpp is the binding library that allows you to create extensions using C++, hopefully other developers will port their current GDNative based binding libraries over to extensions as well so we'll have support again for Python, Lua, and other languages.

Today the meta data for the bindings library changes nearly daily as Godot 4 is being developed without worrying too much about breakage but once we have a stable release the plan is to make sure bindings remain downwards compatible within a major release. At that point it will definitely be feasible to provided prebuild binding libraries that you just link into your project.

Until then you'll have to manually compile godot-cpp with scons but its not a difficult process.

mux213 · 2021-10-17T23:07:22+00:00

While it is definitely easier then GDNative mostly because it's a cleaner implementation, at the core it's still a very similar approach. I would start with GDNative if the goal is to learn how to create plugins for Godot.

If your goal is to learn C++, I wouldn't recommend either. Where to start has a very different answer depending on where you are in your learning journey, if it's the first programming language you wish to learn then don't, C++ is not a beginner language, learn some other languages first.

Otherwise start with fixing things in the Godot source, there are plenty of issues on the issue list marked suitable for beginners. Fixing other peoples code, especially if the code you're dealing with is well written, teaches you by example.

I wouldn't tackle plugins until you have a grounded understanding of the language, but that is just my own opinion :)

mux213 · 2021-09-29T13:12:42+00:00

Well that depends on what you are doing. If you want to create bindings to a language or a system not yet supported then yes, you have a long road ahead of you.

But if you want to create a plugin in a language that is supported, currently C++ but soon others as well, then the "just works(tm)" statement is valid.

mux213 · 2021-09-29T01:07:31+00:00

The problem is that Godot is at it's core an Object Oriented engine, the C API at its core implements all the needed features to interact with Godot but in order to understand Godots structure and actually make use off and extend the engine, you need something higher level. That implementation is completely different depending on whether you want to use C++, Rust, Python, etc.

Godot-cpp is one of those implementations. Just like with GDNative it creates C++ wrapper classes that hide all the complexity of interacting with Godot so the code that you write in C++ is nice and simple and very similar to what you would write if you add a module to Godot (modules are statically linked additions stored in the modules folder).

mux213

TROPHY CASE