Godot gets a brand new animation editor with cinematic support | Hacker News Reader

Godot gets a brand new animation editor with cinematic support

godotengine.org

260 pointsdoppp46 comments

Godot is one of those open source projects where all the pieces fall into place. The developers are doing an amazing job, the lead is sensible to the wishes of the community. The community in return gets involved deep enough that substantial funding and a lively ecosystem emerge. Everyone involved in this project should be really proud, Godot, much like Blender, is a true gem of OSS.

Yes, it really is. Although I had absolutely no intentions of creating a game, I tried it out a few months back just because it's such a well-made project with an active community.

Not to mention they have a pretty strong sustainability story: Massive success on Patreon combined with core developers who are able to sustain themselves with Godot contracting work.

It's shaping up to be quite the open source success story!

When I found it, my knee-jerk reaction was "it's like someone looked at Blender and said 'We should do that for Unity!'"

I'm super glad it's looking to be that and more!

Godot has consistently impressed me. I tried something with it a year ago, but I got stalled because the only supported language (then) was a custom language called GDScript. Support for C# was added in October [0], and there are a bunch of other exciting changes in 3.0 [1] that have happened. I can't wait to give Godot another try. (If anyone is wondering how all this development is funded, Godot appears to get a lot of funding on Patreon, and the C# support was funded by Microsoft.)

[0]: https://godotengine.org/article/introducing-csharp-godot

[1]: https://godotengine.org/article/godot-3-0-released

I got caught up on that a few times too but GDScript is actually pretty good. I actually enjoy using that more than C#. Great during the quick prototyping phase at least.

I tried C# in 3.0.2 and sadly it's not yet feature complete, which meant porting my GDscript was not possible, but I love what's in place right now and I can't wait for it to become more mature. On the other hand, GDscript itself has gotten a lot better, and it's getting types in 3.1!

Technically speaking though, thanks to their C APIs (GDNative) you can use any language now, I've seen bindings for D, Rust, Go, Haskell and a bunch others!

Note now it supports just about anything thanks to GDNative and related efforts. Including support for D, Rust and other languages (I only cared to look those two up but if those are supported I can only imagine what else is). Also people can make plugins that extend the editor altogether. Its amazing that without C# the installer is a tiny download. You download other game engines and you're in for 1GB+.

GDScript really is just a subset of Python and works really well. Remember Moonscript for Unity? Well GDScript is much better.

GoDot FAQ:

The short answer is, we'd rather a programmer does the small effort to learn GDScript so he or she later has a seamless experience, than attracting him or her with a familiar programming language that results in a worse experience. We are OK if you would rather not give Godot a chance because of this, but we strongly encourage you to try it and see the benefits yourself.

The official [languages] for Godot are GDScript and C++.

GDScript is designed to integrate from the ground to the way Godot works, more than any other language, and is very simple and easy to learn. Takes at much a day or two to get comfortable and it's very easy to see the benefits once you do. Please do the effort to learn GDScript, you will not regret it.

Godot C++ API is also efficient and easy to use (the entire Godot editor is made with this API), and an excellent tool to optimize parts of a project, but trying to use it instead of GDScript for an entire game is, in most cases, a waste of time.

>The short answer is, we'd rather a programmer does the small effort to learn GDScript so he or she later has a seamless experience, than attracting him or her with a familiar programming language that results in a worse experience.

The implication here being that all other programming languages used in game development are bound to be worse than GDScript?

I'm learning Godot and while I'm not an expert at either yet, by any means, GDScript has yet to live up to that degree of hype for me. The only advantage it has over other languages is its status as the default for the engine, but I don't see it as an objectively better language than, say, C, C++, C# or Lua.

I think they mean that GDScript is the best language for Godot. And at that time of writing it was, they tried several scripting languages(Lua, Python, Squirrel iirc) and none gave the 'seamless experience' that GDScript. Hell even the C# support at the beginning of Godot 3.0 was wonky.

But they listened to the community and added support for adding your own scripting language and Mono support. Which is still a big positive.

At first I didn’t want to try it but GDscript is actually not bad. I think they have some new features planned for it too like type annotations

I am h̶a̶l̶f̶ ̶w̶a̶y̶, q̶u̶a̶r̶t̶e̶r̶ ̶w̶a̶y̶ I am part way through a game in UE4 after having switched from Unity, and every bone in my body wants to switch to Godot because it's so consistently impressive as a project. I will stick to my guns for now, else I will never release, but I am definitely giving it a go next project.

Is your game 2D or 3D? How are you liking UE4 in terms of the engine's learning curve?

It is First Person 3D (no shooting). The learning curve was individually quite straight forward for each component, especially if you already have familiarity with the concepts. Blueprints were easy because I can code, and node based shaders aere quick to get started with because I knew the pieces of the puzzle so to speak.

There is just a lot of different concepts flying around so it's easy to get flustered at first. UE4 also has a lot of boilerplate around game modes and default world functionality. It's not hard to learn it's just arbitrary learning so not all that fun.

After the first week I found it surprising how quickly everything started coming together, it was more up front but once I was sped up I was good to go. Unity was a bit more of a constant grind of learning little bits here and there.

What I have found difficult and continue to find difficult is support for UE4. Someone has almost always asked the same question as you, it's just that no one has answered. I found there was always some level of discussion for Unity if not a solution. But for UE4 it just feels a bit baron, at least for the results Google offers me.

It also helps that many game development universities are focusing on Unity.

When reading about university projects on Making Games (http://www.makinggames.biz/), a German publication about game development, the vast majority of them were done in Unity.

I agree. I imagine Unreal is taken on by bigger companies where the Q and A happens internally, whereas Unity being used by a lot of solo developers and new developers, a lot of that QA happens in public forums.

I noticed the same trend in open source ecommerce software. More complicated issues are solved by companies internally but the myriad of smaller issues are still solved in public forums. My bet is that Unreal is a bit easier to figure out the smaller issues yourself, and more complex issues are solved internally at bigger companies, leading to it being a bit quiet for support online.

Why the switch from Unity to UE4?

I got tired of encountering graphics issues for seemingly simple concepts, like casting a shadow that doesn't look horrible, or light leaking through everything. Not post processing issues, genuinely painful to debug issues which seem like no brainers.

I hope you aren't too offended by this, but I chuckled a little bit while reading this because it reminded me how some of the hardest problems in a domain (like light propagation/global illumination/shadows) can seem trivial compared to things that are actually rather easy (most post processing effects).

It's a bit like someone being amazed that AI research solved chess before they solved object recognition or even walking.

Casting shadows with minimal artifacting in most non-raytraced pipelines is actually very, very hard. Different engines have different solutions to how they hide these issues, but they all have their edge cases (though some are better than others at this).

Likewise, the light leaking you describe sounds like an artifact of Unity's global illumination techniques. Again, this is a very hard problem. Unreal just happens to solve it in a way that works well for your use case.

If Unreal happens to be the right solution for you, then that's great, but it's important to realize that these issues aren't "no brainers".

Obligatory Xkcd: https://xkcd.com/1425/

That one is particularly funny now, as it was made before deep convolutional neural networks beat the ImageNet competition.

I'm not sure why you got downvoted, normally obligatory XKCD posts go over quite well. I enjoyed it.

Glad to see I'm not the only one that was surprised it wasn't popular :)

Oh, no I am self-aware of how that probably comes across haha. I know it's a really complex field but I guess the presumption is that these things would work out of the box because they are so core to the experience of the engine. I essentially changed not because I thought it was easy but because after digging into the issue I realised how complex the domain is, and I couldn't afford to be bogged down with it when another engine does seem to get it right out of the box for my use case.

I guess my categorising them as no brainers is just that the use case seems so obvious that it not working is surprising. It was just a door casting a shadow onto a floor plane, I may have done something wrong but, that it was even slightly problematic was a red flag to me.

How did Unreal compare regarding that issue?

It was much more straight forward to build levels that would be well lit with the standard tooling in my experience. I didn't have to change anything at all and there were fewer weird artifacts to clean up.

The asset workflow from Blender to substance painter to Unreal also had no hidden demons. It all just worked as expected.

Just to be clear as well, my concerns weren't about the post processing stack which I got working to good effect in Unity. But the lightmapping and material workflow is just a bit clunky in unity. To say nothing of the confusion that having more than one lighting engine causes in docs and online support.

I switched to Godot from Unity. Ya I lasted about 2 months and now I am back to Unity. Really depends on what you are doing but Godot has tons of bugs and it just gets old real fast, assuming you actually want to build a game. And trying to fix those bugs is not so easy in a lot of cases. Obviously depends on what you are doing though.

Switching from Unity to Unreal or vice versa is a wash imo as both those engines have proven themselves. Godot hasn't and still has a much longer way to go than the fanboys will have you believe. Maybe someday for some types of projects but I just don't see it ever having all the conveniences of Unity or Unreal.

What sorts of bugs did you encounter? (Not looking for full bug reports, just a flavor...) I've only toyed with each of them so far so I haven't really found all the gotchas but Godot's the only one I want to spend more time with. It also seemed to fit my mental model of how I want to build a game better than Unity did. But as I said, I just toyed with them, so I'm interested in hearing critical feedback.

I got unstable FPS when I used a KinematicBody2D and ran the game in-editor. This bug has tens of reports over 2 years, and needless to say, renders the engine impossible to work with. To be fair, it got fixed in master a month ago, but there's no reason to believe that this would be a one-off. In my opinion, the project is trying too hard to add fancy features instead of stabilizing and bugfixing core features. Not a fan of the contribution model as well, in which they basically accept all PRs and then fix the bugs later. They claim that it's faster than using regression tests or using a more thorough reviewing process.

The PBR shader has too many features and I'm convinced they all have "math" bugs. I can just drop a model into unreal or unity from substance painter and it looks close enough. Not so with Godot.

Lots of random Physics launches where out of nowhere my character is launching up into the air.

Random screen stuttering on a scene with no geometry and just basic movement code in the physics update on a gtx 1080 system.

Those are the bigger annoying ones but the more you hang out in the community you come to see there are tons of bugs in just about every system. You have to fix them yourself, work around them, or hope someone smarter than you fixes them. Most big bugs are stuck in the "hope someone fixes them" stage.

I spent a bit of time with Godot earlier this year and had a similar experience. I also found a lot of stuff (especially for 3D) undocumented or only very lightly documented, making learning pretty hard. Finally, the editor has UX problems: the layout and workflow is inconsistent and confusing (for example, Carl-s saves the scene always, if you’re editing a resource then you have to manually click a save icon because Carl-s doesn’t save it). Also, gdnative is/was still much too early to use in earnest, so a lot of the potential wasn’t yet fully realised (but strides were being made and those issues will be fixed if they aren’t already). I also had a ton of difficulty getting simple 2D tile maps to work properly (y sorting issues, performance issues) and the tile editor is quite lacking (you can import Tiled maps though, but I had some problems with that too). Finally, there were a few issues in the issue tracker where the devs seemed very dismissive of problems people were having. While I’m sure it’s just because developer time is limited and they need to prioritise, but it came across very ”I don’t have this problem so it’s not a problem” which left a bad taste...

With all that negativity aside, Godot does a lot of things well and seems to be picking up steam. I really like the scene tree system (although I’m much more interested in Unity’s brand new ECS and job system than Godots OOP approach, personally, but I’m a functional programmer at heart) and I learned a lot I out physically based rendering thanks to Godot <3

But the developer experience is very sub-par compared to Unity (which has a very smooth onboarding experience) or Unreal. I hope the devs dedicate some time to UX, because Godot would benefit greatly from it and now while it’s gaining traction is a good time to address those issues. Godot has a lot of potential and is a fantastic project.

The one thing I hope Godot can push towards is just a huge pass in usability, smoothing out UI bugs and just generally improving the look and feel of the entire engine and all of it's UI - stuff like the 'inspector' panel just doesn't feel as nice or as usable as something like Unity's - it has great features but in my opinion just doesn't "feel" quite as polished as it could be, but I really do hope for this engine to keep improving and getting better

They are actually going to be shipping a new inspector with the 3.1 release.

https://godotengine.org/article/godot-gets-new-inspector

I actually missed this, and the thing with Vector3s and such not being all in one was one of my main gripes, I'm super happy to see stuff like this

I personally find Godot's simple UI much less intimidating than Unity's. I have no idea what I'm doing in the latter without reading lots of documentation.

Unity is powerful enough that the UI learning curve didn't bother me too much. There are some really odd decisions reflected in the Unity UI, though.

I find the Unreal Editor UI to be a direct precipitate of the way the engine is designed and the way the code is organized, and that makes it a little bit harder to find what you're looking for than what an ideal UI would offer, and there is nothing that is really hidden and hard to find. That is not the case with Unity, and it seems to be getting better each and every release.

I've had consistent trouble getting Godot to play in debug/development mode on a Mac with an external monitor attached. As much as I want to use it, that's a non-starter for me.

The game window is hidden off screen on mac with an external monitor. At least for me it is. Thats another of the many bugs I ran into that took me forever to figure out.

Been playing with Godot since version 3 came out this year. It is a massive update but it is worth being aware that it doesn't feel complete. It was released because it is good enough to get people started on projects and the port them to 3.1 (which is what this editor is for)

3.1 seems more like the real release: * Massive cleanup of the UI (as people other people here complained about) * Full C# support * GLES v2 support (more hardware support)

I'm developing with 3 and looking forward to 3.1

Godot has a patreon page, in case you would like to help the project with money: https://www.patreon.com/godotengine

SimulaVR (a project to bring Linux Desktop to standalone VR headsets) is using Godot for its next version.

You can see our almost-finished Haskell bindings to Godot here: https://github.com/SimulaVR/godot-haskell

Does anyone know if godot can be used as a 3d engine from c# too? Specifically as part of an existing application instead of a game?

Godot is not a library. It's more like a development environment. You can use scripts and modules inside Godot (including c#). You can't use it as a library.

Been playing around since 3.0 added a bunch of features that piqued my interest. Very cool tech, the fact that it's open source is just icing.

Anyone using it for commercial games? I am really interested to use it for interactive 3D applications in Engineering.

I've been waiting for this....

Reply on news.ycombinator.com