5 ms·

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?

speeder 6y ago
Godot wasn't intended to be used for 3D at all, it started as purely 2D engine. 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.
- lewispollard 6y ago
  > 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. 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). https://github.com/Zylann/godot_voxel https://github.com/Zylann/godot_voxel
hn8788 6y ago
It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.
- krapp 6y ago
  GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.
  - follower 6y ago
    The Godot docs[0] describe the relationship as: "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/scripting/gdscript/gdscript_basics.html#introduction https://docs.godotengine.org/en/stable/getting_started/scrip... [1] https://docs.godotengine.org/en/stable/about/faq.html#what-is-gdscript-and-why-should-i-use-it https://docs.godotengine.org/en/stable/about/faq.html#what-i...
    - alpaca128 6y ago
      You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense. > The default language in the engine is basically python, so it could cause a performance bottleneck.
      - follower 6y ago
keyle 6y ago
Architecturally it's perfectly fine, designing the 3D world is just as capable as the 2D world in terms of tooling. It's more a performance concern. The biggest pain is the lack of proper face culling. It does object culling, meaning if you don't see it at all, it's culled. However faces, not quite. 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.
- meheleventyone 6y ago
  AFAIK neither Unreal nor Unity will frustum cull the triangles of a model out of the box and although both offer some other forms of occlusion culling they also only operate at the whole model level.
  - ganonm 6y ago
    This is wrong. Unity has frustum culling enabled by default. You are correct that it only operates at whole model level though. 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.
    - meheleventyone 6y ago
      I’m not wrong just being more specific. All three engines frustum cull by default and all three do it at the level of the complete model. I said Unity and Unreal don’t frustum cull at the level of the individual triangle which was the factor the person I was replying to insinuated Godot lacked.

speeder 6y ago

Godot wasn't intended to be used for 3D at all, it started as purely 2D engine. 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.

lewispollard 6y ago
> 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. 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). https://github.com/Zylann/godot_voxel https://github.com/Zylann/godot_voxel

hn8788 6y ago

It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.

krapp 6y ago
GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.
- follower 6y ago
  The Godot docs[0] describe the relationship as: "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/scripting/gdscript/gdscript_basics.html#introduction https://docs.godotengine.org/en/stable/getting_started/scrip... [1] https://docs.godotengine.org/en/stable/about/faq.html#what-is-gdscript-and-why-should-i-use-it https://docs.godotengine.org/en/stable/about/faq.html#what-i...
  - alpaca128 6y ago
    You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense. > The default language in the engine is basically python, so it could cause a performance bottleneck.
    - follower 6y ago

keyle 6y ago

Architecturally it's perfectly fine, designing the 3D world is just as capable as the 2D world in terms of tooling. It's more a performance concern. The biggest pain is the lack of proper face culling. It does object culling, meaning if you don't see it at all, it's culled. However faces, not quite. 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.

meheleventyone 6y ago
AFAIK neither Unreal nor Unity will frustum cull the triangles of a model out of the box and although both offer some other forms of occlusion culling they also only operate at the whole model level.
- ganonm 6y ago
  This is wrong. Unity has frustum culling enabled by default. You are correct that it only operates at whole model level though. 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.
  - meheleventyone 6y ago
    I’m not wrong just being more specific. All three engines frustum cull by default and all three do it at the level of the complete model. I said Unity and Unreal don’t frustum cull at the level of the individual triangle which was the factor the person I was replying to insinuated Godot lacked.