I'd like to know more about what you mean by "Godot is not good at 3D open world". Is it just a matter of performance or something more architectural?
So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.
You can mitigate that to some degree by breaking up objects, but even the shell being plain would still cause massive issues.
For first person, open world, or large environment type game, I'd recommend Unreal. For 3D isometric style games, it's perfectly suitable with knowing the caveats and minimal adjustments from an asset creation perspective.
Occlusion culling in Unity is fairly straightforward. Simply requires a bake. It also supports 'occlusion areas' where you can give it a hint to do a higher resolution occlusion bake e.g. if you think the player will likely be in that area.
Edit: originally misread parent as stating Unity didn't frustum cull by default. Parent comment is correct.
There is limiting of overdraw (not rendering the same pixel multiple times) which is easy with Z-buffers. There is frustum culling (not rendering triangles that are outside your FoV or facing away from you) already of course.
The final type of culling is occlusion culling which is avoiding rendering that starship because it's on the other side of a planet from your viewpoint (for example). That's not a feature of 3.X but it's a feature of 4.0. The technical details are pretty interesting, it uses Intel Embree (the raytracing library) to do a low-res raytrace to find the occlusions.
The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.
Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
I mean, yes and no? In that the 3D renderer is a completely separate system to the 2D renderer. But, that means that the 3D renderer... was designed from the ground up to do 3D. Unlike the other direction with Unity, where 2D support is a hack of the 3D engine.
I've been using Godot 3's 3D features for quite a while now, and obviously as a single indie developer I'm not using it for AAA features, but it's still as competent as any other renderer I've used for my use cases.
> Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.
You're going to have to be more specific about "advanced 3D scene editing features", as the editor is actually very good, besides which, I compose most of my 3D scenes in code. Meanwhile, Godot supports everything needed to stream assets at runtime, from multi-threading support, to async resource loaders, LOD, and so on. Granted, you have to kind of roll your own.
The main issue people bring up for large, open world 3D games (which may be a dream of most developers who've not really made a game yet, but in any engine quickly becomes a "one day" project and not something feasible for most people) is the 3D renderer itself, which doesn't have occlusion culling, but again in most realistic cases you wouldn't ever notice this (and it has been added as a feature to Godot 4 already).
For example, recently I was messing around with voxels, and recompiled the engine with a C++ module called "Voxel Tools"[^1]. This supports level streaming and movement throughout large levels without floating point errors (ie, you have a VoxelViewer node that gives the illusion of moving through a large space, while actually not moving further from the origin than you can see).
"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."
And[1]:
"If you've ever written anything in a language like Python before then you'll feel right at home."
So it's more than just whitespace.
I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.
[0] https://docs.godotengine.org/en/stable/getting_started/scrip...
[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...
> The default language in the engine is basically python, so it could cause a performance bottleneck.
If "basically python" means "scripting language" vs "C++" then I can see why by that standard "performance" could be a concern to someone.
But, yeah, doesn't seem to be a Python/GDScript specific concern.
this doesn't have anything to do with the syntax. we could completely replace python syntax with e.g. pyc bytecode or serialised AST data but the language would still be challenging to execute efficiently as the language is still exactly the same
one can get a few ideas of how python could perhaps be made faster by reading about all the restrictions that rpython imposes
https://docs.godotengine.org/en/stable/about/faq.html#what-w...
It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.
Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.
Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.
You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.
Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.
You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.
The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.
I'm curious as to what actually felt rough to you in C#?