Godot 3D lack of polish

newmodels

@emo10001 said: To that point, and just fyi for everyone, this is a quote from the Github page:

"To get in touch with the developers, the best way is to join the #godotengine IRC channel on Freenode."

It will not last forever. If godot's user base gets big enough, they will have to shut out everyone except for some elect.

MagicLord

@emo10001 said:

@MagicLord said:

Some features are available from Godot 2 when i tried it, but they never got adressed. Most people didn't used it for 3D games and i think not enough people are pushing enough Godot 3 for 3D. Another bug i encountered was about a capsule collider unable to move on top of a plane surface, the answer was to make a cube; while [name your game engine] have no issues with planes collision. Or the car physics that are not stable and buggy. Those are only few examples among many; Godot fundation has never been adressed.

Hopefully more people will use it for 3D pushing 3D and perhaps it will get a better fundation.

I certainly hope so too. My main focus is definitely 3D. I know you say you reported bugs and that will definitely fall on us as the users, making sure we report bugs on Git, and really, on all the forums (to make sure it's seen).

I just feel this engine has so much potential and momentum right now, so I'm all in :smile:

-emo

Most information about how to use something are not in the Godot docs, instead you'll find something on internet. And there is no game starters, many people don't know how to do something in 3D and many just give up and won't search on internet. I didn't find any step by step tutorial how could i make some plugin with right panel and buttons with mouse interaction with objects in the 3D view. Why announcing features without demos ? without tutorials nobody will care. https://godotengine.org/article/plugins I guess the new CGS tool will be thrown as it is without any docs and any tutorials, this is the problem with Godot. For example i didn't know GIProbe should be baked, i didn't find anything and i had to ask it, while the docs should have covered how the settings and how to use it in the editor.

Others [your game engine name] have good docs, for each function you have a code example; for each editor panel and button you have a description or how to use it , they have game starters for anyone to right away make some level and test gameplay. With fundation, those needs are also lacking and why most beginners don't jump on Godot train. I hope they will slow down making new shiny things, instead work on things that are less enjoyable but more necessary.

richard-kain

@MagicLord said: Others [your game engine name] have good docs, for each function you have a code example; for each editor panel and button you have a description or how to use it. With fundation, those needs are also lacking and why most beginners don't jump on Godot train. I hope they will slow down making new shiny things, instead work on things that are less enjoyable but more necessary.

Documentation takes time, and it takes a different sort of expertise. And also, it is worth pointing out that Godot is an open-source project without corporate sponsorship. They don't have extensive funding. And they don't really get extra money if more people use Godot. Any impetus to make the software more user-friendly comes from idealism, not financial incentives.

The skills necessary to make effective tutorials and documentation are not the same as the skills needed to develop a game engine. Being able to code an engine does not automatically make you good at explaining how the engine works, or producing professional-quality documentation. And taking time away from development means that less gets developed.

You're not wrong in what you say. Godot would be easier to use with better documentation. But it is important to remember that there are finite limits. Things can't happen just because you feel they ought to. And ultimately, the best way that you can contribute is not to complain about the creator's lack of documentation. The best thing you can do is to create your own documentation based on your own experience. That is how a community grows.

Ace_Dragon

There's already a full FPS tutorial as part of the online docs. In addition, there's a lot of example projects you can download that you can pick apart and base your own game from (you can download them all at once here, but you might need a nightly build for a few of them).

In addition, code examples are already beginning to slowly make their way into Godot's built-in documentation, and people who know how functions work and have the source can contribute a patch to beef up the documentation in those areas (of course, you will need to use a nightly build to have the most up to date information, but rest assured that there have been many doc. related patches in the past months).

Also, another point to make about polish and quality-of-life, let me reiterate the fact that there have been many pull requests made centered around polish and bugfixing for Godot in general (though of a number of them are not related to 3D, they are still important for workflow whether it's 2D or 3D). Here's an example of what just recently into Godot (a nice new group manager).

MagicLord

@Richard Kain said: You're not wrong in what you say. Godot would be easier to use with better documentation. But it is important to remember that there are finite limits. Things can't happen just because you feel they ought to. And ultimately, the best way that you can contribute is not to complain about the creator's lack of documentation. The best thing you can do is to create your own documentation based on your own experience. That is how a community grows.

Why sponsors money matters for features instead of Godot echo system ? I don't complain, i know how to use 3D in Godot, but it has been lot of trials and errors, some times i just wanted to turn on [your game engine] because it was so more easy with docs and tutorials. This is why i think tutorials and game starters are more important than new features (CSG and new ones). I hope at least critical bugs will be worked on otherwise release after release it will become a mess like some few other open source engines.

@Ace Dragon said: There's already a full FPS tutorial as part of the online docs. In addition, there's a lot of example projects you can download that you can pick apart and base your own game from (you can download them all at once here, but you might need a nightly build for a few of them).

In addition, code examples are already beginning to slowly make their way into Godot's built-in documentation, and people who know how functions work and have the source can contribute a patch to beef up the documentation in those areas (of course, you will need to use a nightly build to have the most up to date information, but rest assured that there have been many doc. related patches in the past months).

Also, another point to make about polish and quality-of-life, let me reiterate the fact that there have been many pull requests made centered around polish and bugfixing for Godot in general (though of a number of them are not related to 3D, they are still important for workflow whether it's 2D or 3D). Here's an example of what just recently into Godot (a nice new group manager).

Tutorials should be made by the engine team, they are the best skilled to work on those. You are right , there is an FPS tutorial, and this is the only one , while there should be many to showcase how you can do other game genre in Godot, or game starters. Requests about polishing the editor are nice, but the engine features needs polish also.

SeaFishelle

@MagicLord said:

Tutorials should be made by the engine team, they are the best skilled to work on those. You are right , there is an FPS tutorial, and this is the only one , while there should be many to showcase how you can do other game genre in Godot, or game starters. Requests about polishing the editor are nice, but the engine features needs polish also.

We've been over this, an engine developer isn't automatically a good teacher.

The "if you made it, you're an expert of it" philosophy is incorrect. Look at eSports games; the developers of any given major game get their butts handed to them by professional teams. Why? Because those teams spend their time practicing the game and learning how to play it, while the teams spend their time writing code, making assets, and doing business things. When they play the game, they don't play it to practice, they play it to make sure it works.

On that same level, look at Godot's documentation. It's a mess. There's a lot of content, sure, but it's unpolished, vague in many areas, and an English grammatical nightmare. That's because it was written by a French engineer who's trying to explain a codebase he's partial to and knows too well to be able to describe to a total newbie.

Imagine having to explain the concept of a chair to an alien that doesn't have legs or knees. Not easy, is it? That's what you're asking the Godot guys to do.

richard-kain

@MagicLord said: This is why i think tutorials and game starters are more important than new features (CSG and new ones). I hope at least critical bugs will be worked on otherwise release after release it will become a mess like some few other open source engines.

I do agree that focusing on issues other than shiny new features would be the proper focus. Frankly, I think Godot's current feature set is far more robust than it needs to be. Since Godot doesn't have any tangible need to "compete" with game engines like Unity and Unreal, it doesn't need to sport the same level of graphical fidelity. Stability, bug fixes, platform reach, and performance are the areas that I would focus on if I were developing the core engine.

However, I can't agree that the priority should be on tutorials, and we'll get to why...

Tutorials should be made by the engine team, they are the best skilled to work on those.

This is the primary point that we disagree on. Developers do not necessarily produce good tutorials. While it can happen, it does not always work out that way. As SeaFishelle pointed out, having back-end technical knowledge is not the same as hands-on experience. And hands-on experience with a tool is what you are actually looking for. That's the kind of knowledge and experience that makes for good tutorials and documentation. Building a tool is not the same as using the tool. Someone who is good at making wrenches is not necessarily going to know how to use a wrench effectively. Making a good wrench involves carving out a good mold, and getting some solid metallurgy and smelting. It does not involve wrenches. It is entirely possible to know exactly how to make a really good wrench, while at the same time being piss-poor at using wrenches.

Expanded documentation and tutorials are usually better when they come from the community. This happens with other engines too. While some of the official documentation for engines like Unity and Unreal are decent, they are never the better options. I always end up looking to the community for answers, as opposed to the actual development teams. This is why the documentation issue is one that will sort itself out over time. Building a decent community will lead to more and better documentation. You mainly need more people using Godot, and sharing the experience they have from using it.

Ace_Dragon

About the idea of tutorials and documentation being done by the developers, pretty much every FOSS application in existence has relied on the community to create tutorials, documentation, and other forms of training to help new and existing users alike.

Granted, the result can and will vary, but it is also somewhat dependent on how the dev. team sets up the ability to edit the docs. (if it's easy enough, you get more contributors). The core team's job here is to mainly make the documentation process as approachable and as open as possible (because again, it attracts contributors who will eventually fill a number of things in).

emo10001

@MagicLord said: Most information about how to use something are not in the Godot docs, instead you'll find something on internet. And there is no game starters, many people don't know how to do something in 3D and many just give up and won't search on internet.

Yes there is a game starter, and it's in the official documentation. There are demos on the official website that can be picked apart. From the official docs...how to start your first 3D game in Godot:

docs.godotengine.org/en/3.0/tutorials/3d/fps_tutorial/part_one.html

I do agree with you, there needs to be tutorials that can be found. And they can be found, right here in this forum in the Tutorials section. All of these are "how to get started on your first 3D game in Godot" tutorials. Again...not having to go scour the internet, but right here.

https://godotdevelopers.org/forum/discussion/19165/game-tutorial-by-jeremy-bullock https://godotdevelopers.org/forum/discussion/19143/fps-tutorial-by-jeremy-bullock https://godotdevelopers.org/forum/discussion/19107/fps-tutorial-on-the-godot-docs https://godotdevelopers.org/forum/discussion/19292/godot-3-tutorial-series

And again. Godot is young. Give it some time to mature. More and more tutorials will come. I'm actually working on some myself.

Plus in this day and age, a youtube search of Godot 3 brings up a lot.

-emo

MagicLord

@Richard Kain said: Stability, bug fixes, platform reach, and performance are the areas that I would focus on if I were developing the core engine.

This is the problem, the fundation is not good if you push 3D, trying to make vehicles, collision problems and many others. While new features are pushed on, it's attractive, but when you start your gameplay you'll find critical problems. Godot 3 and 3D are not new, it had 3D on V2 but i think almost nobody used it for 3D.

About graphics, Gi Probe is something important but it's not optimized. A low poly scene with Gi Probe was running 4 fps at 1080p, it's not usable and there is not enough fine tuning settings. I disabled GI probe and increased the ambient light to get some similar lighting. Or the lack of culling solution in Godot, i had to create a very rough culling portals system.

I do agree Godot 3 is new on graphics and physics with other features have not been worked on. It lacks polish, there are still about 1500 bugs , some are minor other are critical. I hope this will get better after 3.1, because quality i think is better than quantity.

You must be right about tutorials, engine coders may not be the best people to make them; but why there is monthly tutorials and demos votes if nobody makes them :D

Ace_Dragon

I have to ask a couple of questions here to see if we're on the same page.

What is your definition of a "good foundation", what does that look like in a game engine, how do you know when the foundation is good and new features can be added?
What are your hardware specs, I ask because scenes with GI Probes can run at decent framerates on my humble AMD HD7700 1GB GPU at 1080p (not at 60 FPS, but decent)? If you are running Godot using an older iteration of Intel Integrated for instance, then you will have to pare down the graphics no matter what engine you choose.

MagicLord

@Ace Dragon said: I have to ask a couple of questions here to see if we're on the same page.

What is your definition of a "good foundation", what does that look like in a game engine, how do you know when the foundation is good and new features can be added?

What are your hardware specs, I ask because scenes with GI Probes can run at decent framerates on my humble AMD HD7700 1GB GPU at 1080p (not at 60 FPS, but decent)? If you are running Godot using an older iteration of Intel Integrated for instance, then you will have to pare down the graphics no matter what engine you choose.

Good fundation is not about graphics only, this is to be able to make the same gameplay as you do in [name your engine], this is the fundation, when it's not good , incomplete or buggy you can't make the same game. You can read previous posts.

About performance without Gi Probe Godot scene runs at 60fps, when you add the Gi Probe it's 4 fps. When your level has many materials and detailed textures this is what happens.The difference between 4fsp and 60 fps in 1080p is too huge to consider a feature as usable when your Nvidia 3D car runs all games. There is a Godot level demo to post process and Gi PRobe you can download, when you turn SSAO or Gi Probe the frame rate drops a lot.Some people said some optimisation will be done on Gi PRobe and SSAO, but we are still waiting.

I think most people doesn't push 3D because they are making 3D mobile games or not using 3D. Godot 3D has some incomplete features and some bugs not able to deliver the same gameplay as [your game engine]. I really hope after 3.1, critical bugs and some fundation features will be worked on.

Ace_Dragon

So in your view, the foundation has nothing to do with code that is clean, organized, and robust enough to not break in random spots when commits are made? That it is all about being able to make 3D games that work?

In actuality on that part, there are already 3D games being made that are in a fully working state. Here's what a simple YouTube search will give you.

Towards the beginning of the video, there are a sizable number of 3D games running at good framerates with fully functioning logic (which would not exist if the 3D functionality is broken). I do agree that Godot still has a long list of items it can use, but people are making games using the 3D engine as we speak.

MagicLord

@Ace Dragon said: So in your view, the foundation has nothing to do with code that is clean, organized, and robust enough to not break in random spots when commits are made? That it is all about being able to make 3D games that work?

In actuality on that part, there are already 3D games being made that are in a fully working state. Here's what a simple YouTube search will give you.

Towards the beginning of the video, there are a sizable number of 3D games running at good framerates with fully functioning logic (which would not exist if the 3D functionality is broken). I do agree that Godot still has a long list of items it can use, but people are making games using the 3D engine as we speak.

I do agree you can make mobile 3D games, but pushing 3D further it will be hard to achieve something bigger with bad pathfinding and physics bugs. Other Games are not possible in Godot while you can start one right away in [name your 3D engine].

There is lack of polish that i hope will be adressed after 3.1; and some very common features should be worked for non mobile games like terrain, water and time of day features, or vehicle physics. I don't want to be right about what i said, but this is how i perceive Godot for people that would want to push it further on it's limits and on some 3D fields almost unexplored or most people didn't used.

richard-kain

@MagicLord said: I do agree you can make mobile 3D games, but pushing 3D further it will be hard to achieve something bigger with bad pathfinding and physics bugs. Other Games are not possible in Godot while you can start one right away in [name your 3D engine].

There is lack of polish that i hope will be adressed after 3.1; and some very common features should be worked for non mobile games like terrain, water and time of day features, or vehicle physics. I don't want to be right about what i said, but this is how i perceive Godot for people that would want to push it further on it's limits and on some 3D fields almost unexplored or most people didn't used.

Yeah, what you are describing is not support for core features. You're describing highly advanced features, most of which are very performance intensive. I remember you mentioning GI earlier. GI is global illumination, an advanced lighting technique that tends to take a toll on any GPU you throw it at. Having high-quality lighting in your game, as well as extremely advanced physics simulations, fluids, etc... are all going to tax your system significantly. None of those are core engine features. All of them are advanced features used to make games with advanced, realistic graphics and physics simulations. All of them would require way, WAY more development and testing than the current Godot developers are capable of.

This isn't a matter of documentation. This is a matter of you wanting Godot to be comparable to Unreal Engine. That's just not going to happen, and certainly not anytime soon. Godot is designed to be small and flexible. It is an open-source alternative to engines like Unity, not an attempt to push graphical and simulation features. It started off with a 2D focus, for crying out loud. If you are planning on using Godot, you should be scaling back your scope to accommodate simple 3D graphics, or switching over to 2D development. If you are really that focused on advanced 3D support, you should really consider switching over to Unreal Engine, or possibly Lumberyard.

MagicLord

@Richard Kain said:

@MagicLord said: I do agree you can make mobile 3D games, but pushing 3D further it will be hard to achieve something bigger with bad pathfinding and physics bugs. Other Games are not possible in Godot while you can start one right away in [name your 3D engine].

There is lack of polish that i hope will be adressed after 3.1; and some very common features should be worked for non mobile games like terrain, water and time of day features, or vehicle physics. I don't want to be right about what i said, but this is how i perceive Godot for people that would want to push it further on it's limits and on some 3D fields almost unexplored or most people didn't used.

Yeah, what you are describing is not support for core features. You're describing highly advanced features, most of which are very performance intensive. I remember you mentioning GI earlier. GI is global illumination, an advanced lighting technique that tends to take a toll on any GPU you throw it at. Having high-quality lighting in your game, as well as extremely advanced physics simulations, fluids, etc... are all going to tax your system significantly. None of those are core engine features. All of them are advanced features used to make games with advanced, realistic graphics and physics simulations. All of them would require way, WAY more development and testing than the current Godot developers are capable of.

This isn't a matter of documentation. This is a matter of you wanting Godot to be comparable to Unreal Engine. That's just not going to happen, and certainly not anytime soon. Godot is designed to be small and flexible. It is an open-source alternative to engines like Unity, not an attempt to push graphical and simulation features. It started off with a 2D focus, for crying out loud. If you are planning on using Godot, you should be scaling back your scope to accommodate simple 3D graphics, or switching over to 2D development. If you are really that focused on advanced 3D support, you should really consider switching over to Unreal Engine, or possibly Lumberyard.

You looked at graphics in the video not at gameplay or animations.

I mentionned Gi Probe because i experimented with it and discovered it's not usable for a game because it lacks optimisation until your scene is made of low poly models without high res textures. Godot 3D graphics are pretty good and you don't need the Gi Probe, but this could be a winning feature for Godot if it was optimized. Why should Godot to be on par with Unreal, we don't need that and it's not possible. Read the previous posts to understand the fundations problems like bad pathfinding or critical physics bugs like capsule stuck on boxes corners or vehicle very unstable. People making 3D games in Godot will find those issues when they will push 3D gameplay beyond mobile games. I already make a game in [name your engine], but Godot is a good other one for smaller goal, it is open source, it's lightweight with a very good scene system. The discussion is about telling to people that would go beyond mobile and low poly 3D games, in Godot they will be stuck on some problems because some features are rough and never tested in a game or because there is some critical bugs. A simplistic game like Megaman 2.5D with good phycis or a diablo 3D game with good pathfinding are not possible while it's right away in [name your game engine].

This is an engine without shyiny features but it's polished on fundations

Things will get better and i really hope quality and fundation will get more weight over quantity and shiny features.

Ace_Dragon

If you have issues with basic physics that shouldn't exist, then report them in the issue tracker with an example project.

If they are as easy to produce as you claim, the devs. should have no problem identifying them so a fix can be done.

MagicLord

@Ace Dragon said: If you have issues with basic physics that shouldn't exist, then report them in the issue tracker with an example project.

If they are as easy to produce as you claim, the devs. should have no problem identifying them so a fix can be done.

This is what i have done ;)

Ace_Dragon

@MagicLord said:

@Ace Dragon said: If you have issues with basic physics that shouldn't exist, then report them in the issue tracker with an example project.

If they are as easy to produce as you claim, the devs. should have no problem identifying them so a fix can be done.

This is what i have done ;)

Okay, maybe they got buried among the many issues opened each day.

If you need a dev. to contact, the Godot physics guy is named AndreaCatania on Github (responsible for the Bullet Integration). Don't forget that his time could be limited due to being a volunteer dev.

newmodels

Do your problems happen with WIP or does it happen on release? It's possible that some of the bugs have been worked out in the WIP version.

« Previous Page Next Page »