Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 3.3

godotengine.org

Post reply on HN
Print view View original

51–60 of 138 posts

Re: Godot 3.3

#51

Post by alkonaut »

keyle wrote: post #37
trinovantes wrote: post #18

Earlier quoted context omitted.

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?

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 r…

> 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.

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.

Re: Godot 3.3

#52

Post by badsectoracula »

jay_kyburz wrote: post #43
kumarvvr wrote: post #41

Earlier quoted context omitted.

> 3D open world / large landscape, and console development. Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?

There is no built in occlusion system. So I would say no.

FWIW it depends on the environments. Oblivion also doesn't have occlusion culling at all yet it ran on the original Xbox 360.

Re: Godot 3.3

#53

Post by blensor »

stolen_biscuit wrote: post #22
keyle wrote: post #13

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo. There are only two caveats: understand what Godot is not good at, 3D open world / large landscape…

I've had a similar experience. Godot is a fantastic 2D engine, and a capable 3D engine. If your goal is shipping a fully featured 3D game I'd still recommend Unity or Unreal over Godot, unless you're comfortable with it not being an industry leader. For 2D however, I'd recommend Godot above anything. Godot 4.0 still has a long way to go before it's ready for everyday use fortunately, not even in alpha state yet so I…

It's also slowly, becoming an alternative for VR development. They even had hand tracking on the Oculus Quest before Unity and UE

Re: Godot 3.3

#54

Post by mekkkkkk »

aroman wrote: post #44
Hammershaft wrote: post #26

Earlier quoted context omitted.

In my experience Godot is a significantly more coherent 2d engine. In Unity a 2d game is running in its 3d engine, and useful functions will often be limited to operating on different pairs of dimensions ((x,y) (x,z) (y,z)).

Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there. Are there other examples of it being better for 2d?

One thing that makes Godot smoother in my experience is its project structure. It doesn't use traditional ECS, but relies on inheritance and composition. Combined with the "everything is a node" mindset, it makes it much easier to maintain a mental map of the game. The node hierarchy tree is much more revealing than in Unity atleast (I've dabbled in both).

EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.

Re: Godot 3.3

#55

Post by aflag »

keyle wrote: post #13

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo. There are only two caveats: understand what Godot is not good at, 3D open world / large landscape…

Which language did you use? GDScript?

Re: Godot 3.3

#56

Post by tekni5 »

keyle wrote: post #13

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo. There are only two caveats: understand what Godot is not good at, 3D open world / large landscape…

I enjoyed the challenge of figuring out what game you made, by deciphering your profile. :)

Re: Godot 3.3

#57

Post by mekkkkkk »

lattalayta wrote: post #48
keyle wrote: post #13

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo. There are only two caveats: understand what Godot is not good at, 3D open world / large landscape…

What kind of game did you ship? Was it 2D or 3D? I was starting to make a 3D game for mobile and was planning on using UE4, but I've heard a lot of good things about Godot. Are there any pain points or blind spots in Godot's feature set?

In general I'd say Godot is excellent for the average indie game. It might not be the best choice for cutting edge AAA rendering or performance. In my experience the most important aspect of an engine for a solo/hobby developer is the ergonomics and the workflow. I've found Godot to be a breeze of fresh air in this respect compared to the much more clunky Unity or UE.

Re: Godot 3.3

#58

Post by follower »

krapp wrote: post #31
hn8788 wrote: post #28

Earlier quoted context omitted.

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# su…

GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.

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/scrip...

[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...

Re: Godot 3.3

#59

Post by ganonm »

meheleventyone wrote: post #42
keyle wrote: post #37

Earlier quoted context omitted.

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 r…

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.

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.

Re: Godot 3.3

#60

Post by follower »

keyle wrote: post #13

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4. All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo. There are only two caveats: understand what Godot is not good at, 3D open world / large landscape…

> console development.

Curious if you had a direct experience with the console side of things with your game?

Also, can I provide you an opportunity to promote your game by asking you to tell us more about the game you shipped? :)

(The rest of this isn't directed at you but more trying to clarify the Godot console situation for anyone else interested.)

I've noticed there seems to be a lot of misunderstanding (particularly by "less commercially experienced" game devs) in relation to Godot's "console support" or apparent lack thereof.

Godot do now at least have a page[1] to directly address the issue and clarify the situation which can be mostly summed up with:

"... there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer."

and:

"Console ports of Godot are offered by third-party companies (which have ported Godot on their own)."

I seem to recall there was one FLOSS game engine that got a grant or something to incorporate support for some XBox initiative (that wasn't "full devkit support" level) but for every other major console there's no engine that has FLOSS code supporting it--and if it did then no one could probably tell anyone about it because of NDAs. :D

As a side note[0]:

"Additionally, there is some unofficial third-party work being done on building for some consoles. However, none of this is included in the default build scripts or export templates at this time."

The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":

https://github.com/rust-gamedev/wg/issues/90

https://github.com/EmbarkStudios/rust-ecosystem/issues/18

https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...

Hope your game is selling well. :)

[0] https://docs.godotengine.org/en/stable/about/faq.html#which-...

[1] https://docs.godotengine.org/en/stable/tutorials/platform/co...

Post reply on HN