Godot's 3D Visual Fidelity

Godot doesn't do filmic tonemapping by default. However, the world settings allow you to change the grading to a filmic curve for a more realistic look.

It is true though that Godot's 3D is behind the major engines, but there is a focus on the 3D side coming after version 3.1 is released.

@DiegoBM said: Hi everyone, I'm trying to make a call on which Engine should I invest from now on, and so far Godot seemed to be the best choice in terms of freedom, general vision, projection and community but:

I mean absolutely no disrespect since I reckon that the work conducted with Godot is amazing in general, but I've spent the last month running through the documentations and the base 3D demos for most engines (in my case Unreal, Xenko, Armory and Godot, I refuse to use Unity) and for some reason, Unreal, Xenko and Armory base demos have a pretty similar look (and smoothness) that just feels good, but for Godot the basic examples as well as setting up a basic demo just feels off in terms of visual fidelity compared to the aforementioned engines. So I just wanted to know why could this be?

Well, one thing to remember is that the majority of the demo projects included with Godot were originally made with Godot 2.0 and just updated to work with Godot 3.0. Because of this, many of the demos do not use a PBR workflow and therefore do not benefit too much from Godot’s new 3D render.

Could it be because of Godot's default tone map? (I know that this can be changed, maybe to filmic?). Is it because Godot is not implementing some sort of advanced 3D technique that those 3 are implementing? Is it because of the shadow's implementation (they look like made of stripes in the the FPS tutorial and most demos)? Is it because of the assets that those engines provide with their demos? (I would discard this one since in general they are quite flat and dull). I just cannot pinpoint this really noticeable difference in visual fidelity for the base demos and it's a little bit off-putting when you are in that step of choosing a 3D engine.

Good question. Obviously engines like Unreal engine and Unity have much bigger development teams and funding, and so they generally look better by default because the teams working on them have more resources, time, and money to put into making it look good.

For Armory and Xenko, it is hard to say. One big thing I think Godot is missing is soft shadow support. Currently all shadows in Godot have the same kinda look and while you can customize how much blur is applied in the project settings, it doesn’t really give that polished, soft shadow look (in my opinion).

As you mentioned, tone mapping could be a contributing factor as well. The default Godot tone mapping is a little washed out for most projects, so generally you have to tweak the tone map and make some additional adjustments to things like contrast and saturation to get a look that works with each individual project. Granted, it depends on the visual style you are going for.

Another thing that could be contributing is simply because of how new Godot’s new 3D rendering engine is. Nodes like the GI-Probe and WorldEnviroment really can make a game look great, but I do not think that too many people, myself included, know how to really use them to their full effect just yet.

Though to be honest, I think it is really depends on the assets, textures used, and how much post processing is applied. I have found that one of the biggest things that contributes to better looking visuals is picking a style and making game assets to fix that style as best you can.

Also, I've been struggling to obtain solid knowledge on how to do 3D with Godot. I've gone the extra mile on researching and I've read and seen plenty of tutorials. I've seen Jayanam's, Jeremy Bullock's tutorials (both are great), Bastian Olij's, as well as the official documentation for FPS (which I felt was giving too much knowledge for granted) among many many others, but somehow I don't have the feeling that I'd know how to go on from there.

On a total aside, I wrote the FPS tutorial on the Godot documentation. It was one of my first publically released tutorials, hence some of the issues. Since then I’ve learned quite a bit more about tutorial writing, and one day I’ll probably rewrite/remaster the entire FPS tutorial again.

I reckon that I'm missing something like a presentation to all the nodes provided and their potential application in games (why were they all created? I presume each one of them was trying to solve one or more problems) as well as other types of utilities like those for obtaining the camera basis which seems to be essential to most games an yet it seems to be missed from a key part of the documentation that provides it with such importance.

Which nodes are you confused about? I am just curious because personally I have found that many of the nodes are more or less standard across game engines, with a few exceptions.

As for obtaining the camera basis, it is a little hidden and hard to find. You can access the basis of a Spatial based node by getting its Transform class. It is a bit confusing to be honest, and I only happened to stumble across it one day when I was looking through the documentation.

Though recently-ish someone made a page on the documentation explaining how matrices and transforms work in the Godot documentation. I have not gone through the entire page myself, but maybe it will help?

I guess that in general I'm missing more core level tutorials on how to do 3D in godot? But maybe I'm also missing really relevant sources. I reckon that GDQuest is about to release some basic tutorials that will more accurately describe the task, but do you know any other sources where I could get such information?

Well, personally I had already used Unity and knew the basics of 3D game making before I came to Godot back when Godot was in version 2.0. I have used several 3D game engines, and most of the time, you can use what you learn in a tutorial made for one game engine in another, you may just need to change the code slightly so it works with the differing programming langauge(s) and APIs.

If I was needing to learn 3D game making again, I’d probably go through beginner 3D tutorials that look interesting, and if the tutorial is not in Godot, I would see if I can translate the code to Godot. Many of the biger game engines have plenty of beginner focused tutorials that may be able to help and as a bonus using different game engines tutorials can help you learn the basics without being tied to one specific game engine.

GDQuest does plan to make some 3D tutorials and I have heard that his tutorials have been great. I know a little bit of what is coming and I can safely say that I think it will help beginners make 3D games. :smile:

As for others resources, I do not know of any beginner focused resources right off outside of the ones you have mentioned. I make tutorials on RandomMomentania.com, but unfortately I had to take the majority of them down due to Patreon related issues, so there is not a whole lot on there right now, for beginners or otherwise. That said, I do have more introductionary focused tutorials for Godot planned in the future, I just haven’t found the time to make them yet.

Hopefully this helps! :smile:

@DiegoBM said: Thank you for your reply Ace Dragon. I was of course expecting Unreal to be way ahead of Godot in terms of default visual appearance, but I was surprised when it was also the case for Xenko (maybe still not that surprising considering it's mother company), and even for armory which is at a very early stage and is a one person's project and still looks gorgeous by default.

There's a good reason for Armory having such good graphics despite it being a fairly new engine. The reason is that the graphics engine was worked on over a period of up to several years before it even saw a formal release (with a lot of help from feature creep).

Godot's new rendering engine has seen just a bit of off and on work over the last year and is currently not a popular area targeted by user patches.

@DiegoBM said: Thank you @TwistedTwigleg for taking the time to provide with such an elaborate answer, it's actually really helpful.

First of all thank you for taking the time to write the FPS tutorial in the first place, you didn't have to and yet you did, for free and for all of us to use it, and I can tell that there is a massive amount of work behind it. We really appreciate that. Part of my sin is that although I'm a seasoned developer, I'm utterly new to modern 3D engines, so I cannot extrapolate that non-existent knowledge to Godot.

No problem, and my apologizes if I gave the impression that I was upset, as that was not my intention!

I was just trying to explain why the tutorial is awkwardly written. To be honest, I know I can do things differently/better and so that makes me a little anxious to rewrite/redo the tutorial so it is better and can hopefully serve as a better educational reference.

But I did not mean to sound like I was upset with you or anything. My apologizes if it seemed that way!

I've done video games in the past but those times they were done using "brute force", programming directly OpenGL, and without so many abstractions for vectors, etc. So now I feel a bit lost with all those functional nodes, mostly in thinking that something could be done better with a different node that I didn't know it was there, like the vehicle physics ones or the raycast. Also using the mesh instance with all the possible combinations of collisions, kinematics/areas/rigid bodies confuse me a bit.

Having done some direct OpenGL work in the past, I’m impressed that you were able to get any game programming done, as at least for me, I found OpenGL to be very confusing and ultimately I gave up trying to learn it. If going from a game engine to direct OpenGL is anything to go by, I can totally see how the opposite would be confusing!

I have to admit, it can be very overwhelming to see so many nodes. When I first moved to Godot, I remember getting very little done in the beginning simply because I didn’t know what any of the nodes did, and especially on the 3D side there was next to nothing and the documentation was at best minimally helpful.

Thankfully at least for the documentation things have improved. Hopefully in a few years there will be enough resources out there so Godot is easier to pick up and learn, especially on the 3D side of things.

I'd definitely appreciate having a reference guide, like a documentation page going one by one through all of them indicating what problem were they intended to solve when they were created, and their possible applications. For example the raycast, which if I hadn't seen Jeremy Bullock using it for the slopes, I'd have never guessed that usage, or what to do with it in the first place (probably I'd have done some over-complicated vector math to solve the same problem), not knowing that raycast was there or not initially thinking that it could be a potential usage. I know that many problems can be solved in many different ways, and hence why it would look counterproductive to give specifics, but I reckon that having that kind of guide could be useful, where for each node people could indicate which kind of problems they solved with that node.

That is a really good idea! I think that would be really useful and would serve as a handy guide. As long as it is okay with you, I may add making a guide like that to my RandomMomentania TODO list, as I think that would be really useful :smile:

I'll look forward reading your new tutorials, and hopefully soon I'll be up to speed so that I can create my own ones and give back to this awesome community.

Thanks! Best of luck learning, and I look forward to seeing your tutorials :smile:

@DiegoBM said: @TwistedTwigleg I wasn't under the impression that you were upset at all! If anything I thought that you took my comment with an impressive elegance and politeness. I thanked you for your tutorial because I reckon that this kind of selfless work some times goes under appreciated, even though there is a lot of time and work put on that, and it's not easy. So I felt like saying thank you.

Oh! My apologizes for the misunderstanding then, and thank you! I really appreciate it!

It was actually a variation of OpenGL used internally by Nintendo DS (matched it at 95% or so), and yes, it was kind of terrible, but I loved the fact that you really needed to know how everything worked to the metal level in order to create stuff. That's why I'm really keen to finally choose the right engine in order to get into it's source code, since it's always a massive investment.

That sounds both really cool and frustrating. I didn't know the Nintendo DS have OpenGL like support, though I suppose thinking about it that makes sense given it had some 3D rendered games.

Hopefully you can find a game engine you like.

Not only I'd be okay with that, but I'd highly appreciate it :). It sure will become a documentation reference in no time for all Godot newcomers (and probably also a go-to guide for most seasoned Godot developer), since I reckon that documentation on the building blocks of Godot games (nodes) is an absolute must for Godot that it's not covered yet

Thank you again for your time, and I sure look forward to see that guide

Thank you! I'll add it to my TODO list :smile:

Unreal, Xenko and Armory base demos have a pretty similar look (and smoothness) that just feels good, but for Godot the basic examples as well as setting up a basic demo just feels off in terms of visual fidelity compared to the aforementioned engines.

The PBR formulas used in Godot are actually off compared to other software like Substance or Blender's Eevee. This will eventually be fixed (as one of PBR's selling points is to offer more consistent visuals across engines).

@DiegoBM said: I actually thought that there was only one formula for doing PBR (that one from Disney?).

Nah, thats just what the industry has started standardizing around in the last 5 or so years. In game engines PBR shading basically just implies that your shaders and lighting try to strictly follow physically based concepts such as conservation of energy. And implement reflections on everything since other than a singularity I guess, everything reflects light. etc.

Hmm, yes I would consider shadows Godot's weak point.

I am a recent user moved from Unity. I'm really enjoying Godot, but it's true 3D workflow news and improvement. Glad to know it's the next goal after 3.1 :)