Godot: Godot has a dissimilarity problem

[2plus2makes5]

Godot is a great engine with a huge potential that can easily become the Blender of game engines, but the more i use it the more i see differences between things that should be similar, making harder and slower to use it and making it feel a little messy.
To be really great Godot should be as uniform as possible, each change and addition should be planned to be coherent with what already exists, because with the growth of the engine the problem can only become bigger.

The biggest problem is the difformity between 2d and 3d nodes, i know it's not that simple but in theory and in general the difference between a 2d and 3d node should be limited to the presence of the "z" component and everything that's tied to that.

I'll post some examples to make you understand what i mean, but i'll open an issue for each problem like the rules say.

-dissimilarity between 2d and 3d nodes, just a pair of examples:
-in Sprite you can directly set a normal map but not in Sprite3D
-Camera2D is able to interpolate while Camera is not, we need to use InterpolatedCamera that has no equivalent in 2d, Camera2D also has limits and many other useful properties that are missing in Camera and even in InterpolatedCamera.

In general it seems that some 2d nodes have more functionalities than their 3d equivalent.

-there are also some dissimilarity issues in getting/setting properties:
--most properties have getters/setters simply named get_/set_/is_ added to the property name
--others properties need to use get_/set_property functions, like "omni_range" of OmniLight
--others have getters/setters with custom names, for example in Sprite3D the "region_enabled" has set_region and is_region, instead of set_region_enabled and is_region_enabled

[BastiaanOlij]

I think there is a strong argument for this, the more uniform the engine can be, the better. But I do think Godot makes a good effort considering how many people are involved. I remember Juan spending a fair amount of time at the beginning of the year to unify a lot of the names as we were breaking compatibility anyway.

That said, I think you underestimate how much impact that extra dimension has. There are fundamental differences in how things work in 3D, how they are organised, and as a result, how the nodes behave and look.

So while I agree that we should try and keep things as uniform as possible, there are enough places where structural differences can't be avoided and are possibly even beneficial because you don't put people on the wrong footing because something is more different then the same.

[2plus2makes5]

I love the work that you and all the others are doing and that's why i'm using Godot, sorry if that wasn't clear in the post, i just want Godot to be the best of the best.

I know it's not simple and that in Godot 2d and 3d aren't the same unlike Unity for example, but some of the problems i have pointed are not even tied to the extra dimension, like the getters/setters or the normal map in Sprite3D(while we are at it, i can only use a normal map with Sprite3D by setting a material_override shader and initialising NORMAL, BINORMAL, and TANGENT in the vertex shader, a thing that's not necessary with a plane MeshInstance for example, i'll open an issue for that later).

I don't know how the contribution work, i imagine there are some sort of general guidelines or rules to follow, maybe an update or improvement to them would make everything easier and more coherent, like for example saying that all the properties should have standardly named getters and setters.

Keep up the good work, we really appreciate it.

[Zylann]

That reminds me of https://github.com/godotengine/godot/issues/9128
Which was raised ages before 3.0 but was closed after 3.0 went out due to... 3.0 being out.

[vnen]

-in Sprite you can directly set a normal map but not in Sprite3D

Well, in Sprite3D you should be able to add a SpatialMaterial with a normal map texture. In Sprite the only way you can do it is with a custom shader. The property to add a normal map in Sprite was added for convenience, it's not need in Sprite3D because it's already convenient enough.

In many cases, doing something in 2D is completely different than doing in 3D. Trying to unify the interface in those cases might be more harmful than useful, and might hinder the usability.

About methods/properties names, feel free to add suggestions to #16863.

[reduz]

This is intended. There are many things that make more sense in 2D games,
which don't make as much sense in 3D.
By far most APIs are similar, so i don't really see this as much of a
problem.

On Wed, Jun 20, 2018 at 10:47 AM George Marques [e-mail]
wrote:

-in Sprite you can directly set a normal map but not in Sprite3D

Well, in Sprite3D you should be able to add a SpatialMaterial with a
normal map texture. In Sprite the only way you can do it is with a custom
shader. The property to add a normal map in Sprite was added for
convenience, it's not need in Sprite3D because it's already convenient
enough.

In many cases, doing something in 2D is completely different than doing in
3D. Trying to unify the interface in those cases might be more harmful than
useful, and might hinder the usability.

About methods/properties names, feel free to add suggestions to #16863
https://github.com/godotengine/godot/issues/16863.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19668#issuecomment-398754358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zqqjNFmfoVD26OMFVNHLUMDC5KIks5t-lKLgaJpZM4Uu-aQ
.

[akien-mga]

I also don't see this as a big issue. As @reduz says 2D and 3D are separate things, and the APIs don't have to be the same if they cover different things. Whenever things are supposed to be the same in both spaces, we do try to keep the APIs consistent.

If any specific property/method is inconsistent and could reasonably be changed for the better, it can be documented in #16863.