All the cons of Godot explained in one video. Maybe we can use this to make Godot better

[Zerokami]

https://www.youtube.com/watch?v=-k0toP5Qiz8

A Middle School Game Dev teacher explains why he went back to Unity for 3d.

He step by step describes the things that are annoying about 3d in Godot, especially for young students.

This is really good constructive criticism which we can use.

I will edit this issue to point out the main thing he mentioned and I agree with.

Also, I will try to create issues for these if there isn't always one.

1) No FBX support. Blender can directly export to FBX. However Blender's default Collada exporter is wonky. So, you have to go through the steps of installing the better Collada exporter which is hard to do with so many students. 2) Imported some 3d models and they look a better by default.(They look flat in Unity and in Godot the light interferes more). Too metallic, instead of flat in Godot I guess. 3) Shadows look really bad by default. They look like pixelated blurred shadows. 4) Unity's default materials are a lot better. In Godot they are too metallic I guess. 5) The Transform for meshes is used commonly, but it is folded and hidden in Godot. 6) Once you create a mesh like a cube Unity automatically adds colliders. You have to manually add it in Godot. 7) Choosing Materials for mesh is really hard in Godot. (This one got me for a long time. It needs to be simplified. It's really hard to create a material or set it) 8) Prefabs are really easy to drag into levels in Unity. It's fun. In Godot, it's really hard to drag things into levels. Scale, inheritance, root and other problems. 9) Multiple scripts for single prefab in Unity. 10) Built in Terrain object in Unity. 11) Asset store

[PetePete1984]

https://www.reddit.com/r/godot/comments/94zlwn/discussion_choosing_unity_over_godot_for_3d/e3pce8p/

[Zireael07]

@PetePete1984: That video is about using a game engine in schooling context, not in general.

[Zerokami]

Copy paste from Reddit thread @reduz

I think some of the issues in the video are right, and here is my personal take on it:

1. Upcoming Godot 3.1 has CSG primitives, which include collision. If you want to create a simple cube/sphere/polygon/etc, put a material to it and make sure it collides, this workflow should be a huge improvement over what is described in the video.
2. Yes, default materials are a lot more complex and have plenty more features in Godot (and are well documented). The use case of someone who is learning 3D programming and feels threatened by this complexity does not make much sense to me. You are supposed to learn how a 3D DCC works anyway if you want even know what you are exporting.
3. FBX support is impossible, but eventually should be doable via asset library thanks to GDNative. One of our contributors is working on this, and may be ready for 3.1
4. The case of a terrain editor is difficult. The one in Unity is practically useless for a production game, but it definitely helps beginners try out stuff. This will probably be looked at in more depth after 3.1 is out.
5. Multiple scripts per object does not make much sense in Godot's context. In 3.1, though, thanks to named classes it will be possible to create a better alternative workflow to this using custom nodes.
6. We have an asset library, so it's really up to the community to fill it with more useful stuff for beginners. I am sure there is plenty open artwork out there, so we could organize a hackathon at some point to create more test content.
7. There is definitely a lot more work to do in the 3D engine to improve usability compared to the 2D one. In fact, when I worked in the new TPS demo, I noted down a lot of stuff. Hopefully with 3.1 a lot will improve, and even more so afterwards.

[PetePete1984]

It's the same video though

[ghost]

10. The Heightmap terrain asset by Zylann is already working pretty great in Godot 3.1. That tool should not be part of the core engine anyway to not bloat it with features many people will not use either way.

[slapin]

Well, these are not really exclusive list of problems I observe, also some of these problems are minor (like FBX) some a matter of taste (viewport look)... Some problems are not possible to resolve directly (i.e. multiple scripts per node - Godot have different concepts, but I think some of it can be simulated).

3.1 is so much better than all previous versions in 3D it is insane. Of course it is a long road for full-featured 3D engine, but still, the results are amazing. I just hope Godot will not lose momentum and will increase speed of adding new features.

[slapin]

And moving all the core features to assets make it easier for developers but harder for users. So Godot will never get spatial searching, proper navigation for 3D, heightmap splat-mapped terrain, etc. out of asset library or some custom repositories. Which wil always make Godot inferior to Unity and other engines in eyes of other people whi can compare, so I think there is no much reason to pay attention to these comparisons. Godot way is different and comparison is pointless.

[Zerokami]

https://github.com/godotengine/godot/issues/20782

Issue about default material being too shiny and also unrealistic.

[Zerokami]

@slapin

These are the main things I agree with.

1) Shadows look like blurred pixels by default. 2) Default materials too shiny and ugly. Not suitable for walls, floor or boxes. 3) Understanding scene inherintance for putting one scene in another. 4) Applying texture to a mesh is really cumbersome.

[PaulHMason]

I think a lot of problems could be solved by supporting real custom reusable nodes (custom scenes) that hide their script implementation and provide an api that instance level custom scripts can use. This is been discussed elsewhere, but I think it would be a very valuable addition. It won't make it easier for new users, but it will make Godot a lot more productive for more experienced users.

[Zylann]

1) People want FBX because it just works (tm) in other engines. Collada is buggy and GLTF isn't there yet. But I think if one the the latter formats gets bug-free out-of-the-box support, that would help a lot (as in, no need to download a plugin for making it usable, that's ridiculous).

2) Default materials should not be that shiny indeed. When making games, rough materials are often preferred instead because that's what environments are most of the time (for walls, terrain, platforms etc).

3) The default parameters of lights could be improved. I also proposed #11587 a while ago for helping with initial sun orientation, but it had some issues with serialization. I still think it's a relevant tweak to do for the editor, though.

4) Same as 2)

5) Putting the transform on top of the inspector might be a nice exception. But if we do, it would require this to be compact enough: #20423

6) There is a difference between Unity's primitive objects and Godot objects. In Unity, there are in fact two ways of creating objects: the first one with the simplified Create menu is in fact instancing pre-made, built-in prefabs that come with the editor, which effectively makes it easier to get started for things people do very often. The second way is by creating an empty GameObject, then you add components one by one on it, and assign their properties. Turns out, Godot only has the latter, and that's why the video shows it is more cumbersome. We just don't have premade shortcuts. One could say "use the asset lib" but as I saw mentionned on Discord, "nobody will use the assetlib just for that". It's not a sensible thing indeed, but it's a fact. Many people just won't do it and have a negative impression for having to do this all the time in their projects.

7) Not sure if assigning materials is this bad, for me it's quite okay. If drilling down through inspector properties is an issue then 3.1 alleviates this by making them foldable. Dropping a material on the viewport sounds cool too.

8) Instancing scenes should be doable by dragging them in front of you and having then appear in front of you. Empty scenes don't help because they have no root nodes indeed, 3.1 comes with an indicator for that but you still have to choose a root node yourself before anything else. IMO auto-creating a Spatial/Node2D/Control root depending on what you drag would be even faster and easy to change later on with change type. The video also show the vertex snapping feature, which is a bit hidden under its shortcut but so handy to align things up in 3D.

9) Multiple scripts per object is already a long-discussed topic in Godot, doing like Unity would be a breaking change and the closest is to use nodes. Not sure what to add here.

10) Built-in, simple terrain system sounds great. Only concern is, half of devs may ditch it for their own, or will ask to add countless features to it. Also this is an actual engine feature, not just an editor enhancement... to bloat or not to bloat?

11) The asset store is another beast, we can't have that on the short/medium term I believe. Also Unity's one has totally different mindset that our free one.

[slapin]

For me (I use git master) there are 2 very serious issues - a) putting a mesh to scene via drang and drop produces unpredictable placement b) there is no quick vertex snapping. With almost everything else i can cope with (or add code which does the required feature) but not these. So big no-no for designing levels in Godot editor yet.

On Tue, Aug 7, 2018 at 4:18 PM, Marc notifications@github.com wrote:

1.

People want FBX because it just works in other engines. Collada is buggy and GLTF isn't there yet. This status also gets into people's minds as much as MP3 did. But I think if one the the latter formats gets bug-free out-of-the-box support, that would help a lot (as in, no need to download a plugin for making it usable, that's ridiculous). 2.

Default materials should not be that shiny indeed. When making games, rough materials are often preferred instead because that's what environments are most of the time (for walls, terrain, platforms etc). 3.

The default parameters of lights could be improved. I also proposed

11587 https://github.com/godotengine/godot/pull/11587 a while ago

for helping with initial sun orientation, but it had some issues with serialization. I still think it's a relevant tweak to do for the editor, though. 4.

Same as 2) 5.

Putting the transform on top of the inspector might be a nice exception. But if we do, it would require this to be compact enough:

20423 https://github.com/godotengine/godot/issues/20423

6.

There is a difference between Unity's primitive objects and Godot objects. In Unity, there are in fact two ways of creating objects: the first one with the simplified Create menu is in fact instancing pre-made, built-in prefabs that come with the editor, which effectively makes it easier to get started for things people do very often. The second way is by creating an empty GameObject, then you add components one by one on it, and assign their properties. Turns out, Godot only has the latter, and that's why the video shows it is more cumbersome. We just don't have premade shortcuts. One could say "use the asset lib" but as I saw mentionned on Discord, "nobody will use the assetlib just for that". It's not a sensible thing indeed, but it's a fact. Many people just won't do it and have a negative impression for having to do this all the time in their projects. 7.

Not sure if assigning materials is this bad, for me it's quite okay. If drilling down through inspector properties is an issue then 3.1 alleviates this by making them foldable. Dropping a material on the viewport sounds cool too. 8.

Instancing scenes should be doable by dragging them in front of you and having then appear in front of you. Empty scenes don't help because they have no root nodes indeed, 3.1 comes with an indicator for that but you still have to choose a root node yourself before anything else. IMO auto-creating a Spatial/Node2D/Control root depending on what you drag would be even faster and easy to change later on with change type. The video also show the vertex snapping feature, which is a bit hidden under its shortcut but so handy to align things up in 3D. 9.

Multiple scripts per object is already a long-discussed topic in Godot, not sure what to add here. 10.

Built-in, simple terrain system sounds great. Only concern is, half of devs may ditch it for their own, or will ask to add countless features to it. Also this is an actual engine feature, not just an editor enhancement... to bloat or not to bloat? 11.

The asset store is another beast, we can't have that on the short/medium term I believe. Also Unity's one has totally different mindset that our free one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/20780#issuecomment-411052191, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX0zMkL4VmSwY8kEHrUblQ4yXAyjwdks5uOZOlgaJpZM4VxknR .

[Ace-Dragon]

In my opinion, the issue presented in adding nodes like one for terrain can be largely resolved by doing the following two things.

1. Add a new category of nodes specifically for high-level 2D, 3D, and UI-based mechanics and general design (this will allow the user to know that there might be some level of black-boxing involved and therefore be trickier to expand beyond its design than rolling an entirely custom system).
2. Have a system that automatically strips the code related to unused node types and features on export (to keep both bloat and file-size to a minimum in published games).

The truth is, people tend to gravitate towards engines that have hardcoded solutions for entire game systems and design topics despite the potential issues regarding black-boxing and exported projects having similarities to many others (because they just want to get something up and running quickly). More savvy creators meanwhile will still often roll their own systems because they have the option to do so.

[slapin]

I think ability to compile GDNative into engine and have some approved high quality GDNative implementations of features would solve bloat problem. Currently it is much easier to bloat the engine than use GDNative. Another altrrnative is to build your own bloat-free engine (as one man's bloat is another man treasure). Being able to run quickly is vital (even if you later will build your own custom systems) as it allows getting first impressions and feeling of accomplishments. If you're digging roots for too long you will lose all motivation.

On Tue, Aug 7, 2018 at 5:54 PM, Ace-Dragon notifications@github.com wrote:

In my opinion, the issue presented in adding nodes like one for terrain can be largely resolved by doing the following two things.

1. Add a new category of nodes specifically for high-level 2D, 3D, and UI-based mechanics and general design (this will allow the user to know that there might be some level of black-boxing involved and therefore be trickier to expand beyond its design than rolling an entirely custom system).
2. Have a system that automatically strips the code related to unused node types and features on export (to keep both bloat and file-size to a minimum in published games).

The truth is, people tend to gravitate towards engines that have hardcoded solutions for entire game systems and design topics despite the potential issues regarding black-boxing and exported projects having similarities to many others (because they just want to get something up and running quickly). More savvy creators meanwhile will still often roll their own systems because they have the option to do so.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/20780#issuecomment-411085542, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX0-IAaN1_bDPas7POYk94Yrl0LX2-ks5uOapCgaJpZM4VxknR .

[unfa]

I see that the default materials and the default environment are already much better in the master. Yay!

[starry-abyss]

This status also gets into people's minds as much as MP3 did by its widespread use.

Not really, MP3 doesn't support proper looping, so it just sucks in game development. Developers understand it and don't use it.

[Zylann]

@starry-abyss I was more making a general point about how wanting a format over another gets into peoples mind regardless of the downsides a format has. Reading again I think it wasn't a good example, gonna remove it.

[ghost]

From the usability perspective, I shared some of his views. It's not a deal breaker for me.

While I don't have any opinions on the 3D end, I would definitely welcome and advocate to resolve some of his complaints.

I also get tripped up by all the collapsed properties and some of the navigation into the sub-resources. Mostly it slows me down when trying to rapidly modify common properties. In many situations it seems to add a lot of extra back and forth.

Also wouldn't mind easier snapping with more features to it. Almost thought the snapping options were removed when I first looked at Godot 3. Took a moment to orient to the new icon, so I can imagine there must be new users who aren't even looking for it.

If Godot does trend more towards custom modules to steer away from making a swiss army knife, the ideas I saw some time ago about officially made modules seem like a good compromise. Do some of the highly requested bloaty things and break them off into official modules. For these official type of modules, inside the editor may even exist the menu options to inform and invite the user the feature is at reach. Then when clicking, it could then prompt to be installed with information about its file size and footprint it will have in the project, etc.

Community provided modules would then have to be brought in the longer and more manual route.

In this way, the extendability that is being aimed at could go forward all the same. Developers can also make use of the feature to selectively take on these features that are being expected to come standard with all game engines.

Hope that makes sense.

[dark-penguin]

I am a new Godot user (so I think my input may be valuable as a "fresh view"). I found the experience extremely pleasant (and I'm VERY picky!). Any doubt I had about choosing Godot over Unity or Unreal was gone after watching this video. I wanted to try those two too, but that story ended when I had to register to download multi-gigabyte installers (which won't even run on my old machine anyway) along with Visual Studio or something...

I agree that it's best to keep the core engine minimal, and have all optional functionality provided via plugins; those plugins are one-click install, so if it's hard for someone to do that, then it's probably too early for them to think about game development. One of the reasons is that those plugins must be "hackable" - you install them as templates, and then you are free to change them to suit your project better, or learn the necessary parts from them and reimplement what you need yourself. However, I also agree that the current state of the "AssetLib" is no good; some plugins are broken out of the box, or made for different versions of the editor. My suggestion is to have "Official Assets" and "Community Assets" separately - either in a different store, or just a filter that's enabled by default. And the "official" one is for features that would have been included in the core, but are moved out to avoid bloat.

Also, maybe make it possible to build a custom version of the engine with selected plugins built in - this way, that teacher could roll out his own custom distribution. Maybe even have an official "all included" distribution built with all "official" plugins everything out of the box - for those who prefer hard-coded solutions.

I believe user preferences must be stored in a separate file. Those are mostly per-project, not necessarily per-scene, so having one file you can easily git-ignore would be the best option.

I had a few minor pet peeves with Godot 3.0 interface, but those are mostly fixed in 3.1. Here's what remains:

1) I think the new "mesh assignment" interface in 3.1 only made it worse. Previously, I could easily understand what properties am I editing: now I'm in MultiMeshInstance, now I'm in MultiMesh, now in Mesh, and now in Material. It's all written out there on top. Now I see one huge list of properties in a ridiculous order:

Header
- - MultiMesh (on TOP of MultiMeshInstance)
- - - Mesh (on the BOTTOM of MultiMesh)
- MultiMeshInstance (after two consecutive "Resource"-s)

The one-pixel-wide line on the left does not make it any more intuitive at all. And then there is "Material", which uses the "old" interface - which defeats the purpose of trying to invent a new interface at all.

2) In "Project Settings" or "Editor Settings", those tabs on top - light-grey on dark-grey - don't register with me at all. Every time I spend a good few seconds looking for "Shortcuts" on the left, because I don't notice the barely recognizable word on the top. Simply making those look more like a tab (and a bit brighter) would make them more easily noticeable.

3) I am debugging a script, and I press F5 to run the project. After the project finishes, in Godot 3.0, I was back in the "Script" window, but it was not focused, so I had to reach for my mouse and click on it - and try to remember what position my cursor was. In 3.1, after a project finishes, I'm back to "3D" tab, so now I have to press F3 to go back to "Script". Thankfully, my cursor is in the same place. This is already much better, but is there any reason to switch to the "3D" tab?.. Wouldn't it make mode sense to not switch the tab at all, and return to the script I'm editing?.. I don't mind this if there is any benefit for some particular workflow, but I can't think of one.

[Bauxitedev]

One thing I'm missing from Unity, which is also shown in the video, is the ability to drag nodes from the scene tree to the file system (instead of the other way around, which does work in Godot). Doing that in Unity would create a prefab containing that "node" - I think in Godot it should do the same thing as "Save Branch ss Scene" does, that is, saving the node and all its children as a scene and then replacing it with an instance of that scene in-place.

This would save a lot of time compared to right clicking the node, selecting "Save Branch as Scene", browsing to the folder you want to save the scene, and then finally clicking save.

[jonbonazza]

For me there are four things that could be done that would be huge wins without resulting in major overhaul of the engine and its design:

1. Supporting multiple scripts in the way that Unity does it is not the right approach. Unity is component oriented, whereas Godot is Object Oriented. These two paradigms are fundamentally different and trying to fake one in the other will just end up in a huge mess. I think that instead, we should think about how we can make the current way scripts work in Godot more user-friendly and intuitive. I am sure that there are a lot of things that we can do here, and I won't even try to list them all, but I do think that one major thing that needs to happen in this regard is to allow for custom, redistributable nodes that can have scripts added on top of them. This way, if I create a custom node type and distribute it in the asset lib, some else can then add their own script to the node that will extend that functionality. This has since been fixed! Huzzah!

2. Asset lib... The current asset lib really isn't that bad. The problem is that since there's no means of monetization, there's no incentive for developers to polish their tools and such to make them actually usable by other users. As someone who has a lot of tools being released soon to the asset lib, I can confirm that it's very difficult to motivate myself to polish the tool beyond "good enough" when I have an actual game that needs worked on. I have some thoughts on this matter that are outside the scope of this issue. When I get some time I will bring some ideas up in a separate issue, but for now, this brings me to...

3. We keep saying "oh this doesn't belong in the core engine, it should be a plugin instead..." which is fair, but this doesn't mean that core developers can't work on these features. I would like to see some core development spent on these "nice to have" plugins, where the results would be polished to a degree that any core feature would be. That said...

4. We really need to fix all the bugs and generally clean things up before we go adding more features. I'm not sure what percentage of dev time is spent on new features vs. bug fix and enhancements currently, but we should equalize this ratio a bit (I would even like to see one or two bug fix spikes in the near future where we only focus on bugs for some duration).

[PeteX]

I don't see most of these points being particularly important; perhaps they're more noticeable when you're teaching young beginners. One thing I strongly disagree with though is the comment about prefabs in Unity.

I've used Unity a lot but I'm now trying Godot, in large part because I find Unity's prefabs so frustrating. If you get an asset from the Asset Store it will generally come with a prefab, which makes sense. The problem is that when you modify it, even in the most trivial way, you either have to write it back to the prefab or make the same change over and over again.

If I write my change back to the prefab I've now mixed my own work with someone else's asset in an opaque way. It's the opposite of the usual design principle where you use other people's work through a well defined interface like an API. Godot's scene inheritance seems to give me exactly what I want: customisation without opaque mixing.

[ConnorBP]

I definitely agree on the too shiny thing. Default settings really should be metal 0 and spec 0.5 I know you want to show of your literally shiny new pbr but having literally everything shiny means people new to it just think the materials are crappy. The matte looks better without tweaking than metal and way more objects are going to be matte than are shiny at the end so it really just makes sense.

As for the editor folding having an option to be unfolded by default (for the whole inspector or certain things like transform) would make the workflow a few less clicks therefor less clunky.

In the same way collision meshes really should be something added by default unless you tell it otherwise with a setting. Something used as commonly as collision should be opt-out for auto or at the very least opt-in. The way it is currently isn't a very nice workflow when you need to repeat it constantly for every object which really holds you back from making anything of significant complexity.

As for people saying the opinions of beginners are not important, I strongly believe it is quite the opposite and if you had to learn to get around something because it didn't work as intuitively as it should have then it should be changed / improved. Beginners are the best source of info for whether or not your UI / workflow is friendly and if it is easy and efficient for beginners it is certainly easy and efficient for pros. The trick is balancing ease of use with features, as well as recognizing what the most commonly performed tasks are.

[ConnorBP]

Oh yeah as for the asset library having some sort of nice curation system / user feedback ratings to push popular well liked tools to the front would both make it more useful by actually being able to find the good stuff, but also help with that motivation issue by featuring the creators that really put some effort into their assets. This could be crowd sourced voting for featuring plugins, maybe specific people would manage it, and eventually once it gets traction you could replace that with something more automatic.

TLDR: its gotta be a little more "App Store"-ey ;)

Obviously not a small task or a very specific one but it is important for it to become a proper asset gallery, library, store, whatever

[Calinou]

I definitely agree on the too shiny thing. Default settings really should be metal 0 and spec 0.5 I know you want to show of your literally shiny new pbr but having literally everything shiny means people new to it just think the materials are crappy. The matte looks better without tweaking than metal and way more objects are going to be matte than are shiny at the end so it really just makes sense.

This has been solved as of 3.1 with https://github.com/godotengine/godot/pull/20787 (see also https://github.com/godotengine/godot/issues/27082, which remains to be fixed).

As for the editor folding having an option to be unfolded by default (for the whole inspector or certain things like transform) would make the workflow a few less clicks therefor less clunky.

You can disable inspector folding in the Editor Settings (Interface → Inspector → Disable Folding).

In the same way collision meshes really should be something added by default unless you tell it otherwise with a setting. Something used as commonly as collision should be opt-out for auto or at the very least opt-in. The way it is currently isn't a very nice workflow when you need to repeat it constantly for every object which really holds you back from making anything of significant complexity.

There's no perfect default here, because a significant amount of meshes are going to be non-solid in most games (especially as you start adding small, decorative objects).

Oh yeah as for the asset library having some sort of nice curation system / user feedback ratings to push popular well liked tools to the front would both make it more useful by actually being able to find the good stuff, but also help with that motivation issue by featuring the creators that really put some effort into their assets. This could be crowd sourced voting for featuring plugins, maybe specific people would manage it, and eventually once it gets traction you could replace that with something more automatic.

Issues related to the asset library should be reported in godotengine/godot-asset-library (I believe there's already one about voting/curation though). That said, we don't have much manpower available to work on the asset library, which is why it hasn't improved much since its initial release.

[slapin]

BTW can we have old color "theme" back somehow, as I really do not like how it looks now and by default it is barely usable. Colors are matter of taste, and these changes which were done are of debating usefulness.

On Wed, Apr 3, 2019 at 11:42 AM Hugo Locurcio notifications@github.com wrote:

I definitely agree on the too shiny thing. Default settings really should be metal 0 and spec 0.5 I know you want to show of your literally shiny new pbr but having literally everything shiny means people new to it just think the materials are crappy. The matte looks better without tweaking than metal and way more objects are going to be matte than are shiny at the end so it really just makes sense.

This has been solved as of 3.1 with #20787 https://github.com/godotengine/godot/pull/20787 (see also #27082 https://github.com/godotengine/godot/issues/27082, which remains to be fixed).

As for the editor folding having an option to be unfolded by default (for the whole inspector or certain things like transform) would make the workflow a few less clicks therefor less clunky.

You can disable inspector folding in the Editor Settings (Interface -> Inspector -> Disable Folding).

In the same way collision meshes really should be something added by default unless you tell it otherwise with a setting. Something used as commonly as collision should be opt-out for auto or at the very least opt-in. The way it is currently isn't a very nice workflow when you need to repeat it constantly for every object which really holds you back from making anything of significant complexity.

There's no perfect default here, because a significant amount of meshes are going to be non-solid in most games.

Oh yeah as for the asset library having some sort of nice curation system / user feedback ratings to push popular well liked tools to the front would both make it more useful by actually being able to find the good stuff, but also help with that motivation issue by featuring the creators that really put some effort into their assets. This could be crowd sourced voting for featuring plugins, maybe specific people would manage it, and eventually once it gets traction you could replace that with something more automatic.

Issues related to the asset library should be reported in godotengine/asset-library https://github.com/godotengine/godot-asset-library (I believe there's already one about voting/curation though). That said, we don't have much manpower available to work on the asset library, which is why it hasn't improved much since its initial release.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/20780#issuecomment-479396327, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX066CCQ-bm0wo8WBKMiCv_SbMzSP8ks5vdGlxgaJpZM4VxknR .

[Calinou]

@slapin You can change the theme preset to Godot 2 in the editor settings to get the old colors back.

Anyway, I'll close this issue as it's getting off-topic :slightly_smiling_face: Please open separate issues after searching for duplicates if some of these are still valid in Godot 3.1.

[slapin]

Well, it is not about editor theme, it is about 3D viewport defaults. Current defaults make it very hard to edit things because of color choice and default material color. Godot 3.0 colors and early 3.1 colors before the change were fine but were not liked by some unity worshipers. I guess that defaults should be good to be editable from scratch in any scene at start, so one could create new scene and start editing immediately. Yes you can edit everything, but that requires some experience new users do not have and this might break their step-by-step approach to Godot. Defaults should be reasonable and allow start working, all this nitpicking about colors, etc. is utter bullshit and based on taste, not some objective need. This is why noob's opinion is generally useless as they do not have experience enough to want something reasonable. Current defaults seriously confuse people who want to try Godot 3D scene and find gray stuff on gray stuff without any visual aid and do not know they can turn shadeless view or how they can edit default materials. It was much easier with 3.0 look with sky yet all - people could just start working being able to postpone material settings to a time when they are ready for it so they can freely fool around with cubes now.

On Wed, Apr 3, 2019 at 2:12 PM Hugo Locurcio notifications@github.com wrote:

@slapin https://github.com/slapin You can change the theme preset to Godot 2 in the editor settings to get the old colors back.

Anyway, I'll close this issue as it's getting off-topic 🙂 Please open separate issues after searching for duplicates if some of these are still valid in Godot 3.1.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/20780#issuecomment-479444916, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAX0yfAIR_EOiBKGNixnVZPNVZ47F5lks5vdIykgaJpZM4VxknR .

[ConnorBP]

Issues related to the asset library should be reported in godotengine/godot-asset-library (I believe there's already one about voting/curation though). That said, we don't have much manpower available to work on the asset library, which is why it hasn't improved much since its initial release.

Yeah that is pretty much to be expected. Any sort of curation would need to be automated or crowd sourced due to the nature of the project and manpower.

[RobKohr]

I am working on an asset store here: http://godotasset.store