I use Godot professionally for more than a year.

I agree with everything you said, except for:

For some, I think we should keep the current way

If we have this golden opportunity, let's just rename everything. That includes Sprite2D and MeshInstance3D.

It's always better a full painful refactor, that many partial painful refactors.

Speaking of renaming: https://github.com/godotengine/godot/issues/16863

@jahd2602 I don't mind either way personally, we can poll that in the worst case.

I definitely can see people bothered with that simply for the fact that it's an inconsistency, but we can at least see if they are majority or minority.

@Zylann I know, if we decide something here, we'll move this over there.

I think the stance against namespaces is short-sighted. It makes sense from perspective of the engine workflow in general but it ignores the perspective from toolmakers. Godot Unit Testing (GUT) by bitwes for example broke due to a naming conflict in one of its updates. There is a likelihood this could have been avoided with a dedicated GUT namespace.

I would also like namespaces for Waiting And Testing (WAT) so I can I can use class names like Test (accessed via WAT.Test) while not running over other frameworks (like GUT if it were to use GUT.Test) or just the user's script. I've tried a number of times using a WAT class that contained all of the scripts used as subclasses but that's just a cyclic reference hell.

If we are to be encouraged to build tools from within the engine, then we need the tools to make those tools in the Engine even if they aren't absolutely necessary for the engine workflow itself.

In summary, a dedicated namespace system which can be both accessed as well as defined from the engine (or at the very least the plugin script) so tool makers don't end up walking over each other or their uses would be a godsend.

@CodeDarigan I understand it has benefits and I'm not denying them, but I sincerely believe that the costs outweighs them.

Add to this that pretty much we had no significant complains from GDScript users, who prefer the current approach, so it would force them to an unwanted worfklow and type more code in a language that is intended to just write quick and dirty stuff fast. (C# users seems to do want them, though).

This is why I mean that they can exist as metadata for script language bindings, and we could even add them for GDNative C++. Just not add them for core C++ engine.

Navigation -> Nagivagion3D
Is this a typo?

@nitodico indeed

@reduz I agree with @jahd2602. Even if some things may be obvious, for consistency sake, we should postfix with either 2D or 3D.

I'm still getting started with Godot and the proposed changes sound sensible to me -- using subtly different names for the 2D or 3D variant of a node is something that's caused me a bit of confusion while learning which end is up and moving to Thing2D/Thing3D or Thing/Thing3D feels like a significant improvement to clarity and comprehensibility.

Please do it.

Tbh this change would come anyway, so better to do it now and stick with it. For 3d there are not that many tuts so now the change will do less damage than in one, two years later.

Regarding materials it would be nice to have some kind of Legacy Material that only uses minimum resources, like diffuse and specular, this would be useful for 3D mobile games.

I'm also in favour of renaming things to be explicitly 3D or 2D.

Wouldn't it be possible to have the original names still exist as aliases to the new ones? They would be hidden from the editor so the old names wouldn't be usable (or placed under a "deprecated" heading). That way old code would still work, without changes and without needing additional logic to convert anything.

A warning could be added for code using the deprecated node names and then in 4.1 or 4.2 they could be removed.

If there are two versions of a node I would always append 2D/3D suffix.

Also, I would be happy if Label -> TextLabel. I go to add a node so I can show some text, so I type text in the search bar and of course only RichTextLabel shows up which reminds me that the standard text node doesn't actually have Text in the name.

@Janders1800 that's how it works now, the less features you use in SpatialMaterial, the smaller the shader it creates.

I'm a 2d person, so for nodes with mainly 2d application, keeping the node names without a suffix if it doesn't already have one seems fine to me. This seems like a more painful refactor for 3D users, but it does make a lot of sense where certain nodes have only a 2d or 3D application for the most part that they retain the shorter name for their intended domain and have a suffix elsewhere. Anything else that can be unified would be nice to see unified, specifically Spatial.

I'm in favor of unconditionally using 2D/3D suffixes, too.

While it's true that for some nodes it seems like a lost opportunity to have more "natural" names, consistency wins.

What I don't quite like is that the StandardMaterial3D is the non-ORM one. My point is that ORM is more strongly backed by a standard (at least RM, which is what you have in glTF).

But I can't yet suggest a better naming.

Maybe this is also an opportunity to do something about 'canvas'. I found that concept a bit confusing at times.

I know it's difficult, because is has no 3D counterpart: 3D scenes live in Spatial nodes, but canvases can contain a mix of Node2Ds and Controls.

However, it would be great if we could define some naming that allowed renaming CanvasItemMaterial to Material2D, while keeping it meaningful for the "pure" 2D and the GUI realms.

I'm not necessarily against the rename, but the original names make sense to me, maybe because of my background.
The default in physics or engineering is "3D". You don't say a "3D kinematic body", you say a "kinematic body", unless you're working in some other space.
However, I'm sure not everyone has the same background or even agrees on that, as this after all is game engine and doesn't have to strictly follow physics or engineering conventions.

for future compatiblility, in gdscript

a gdscript file...

extends Spatial
class_name Node3D

And so on.

Have you thought about renaming translation for spatial nodes to position?

@BeayemX I think that translation is a common term for 3D space, and position is common for 2D developers :thinking:

I do not know if 4.0 will be the best for node name changes, there will be a lot of things to deal with and there were many changes from 2 to 3, it means deprecating books, videos, courses.
Even documentation is not complete, with changes in mid completion, fixes will slow things down a lot...

I'm in favour of renaming 3D nodes as suggested here. I don't know how much of a problem it will be for tutorial makers though. At the very least, it should be trivial to refactor existing code bases. In C# we could even abuse the ObsoleteAttribute in debug mode to make it easier (not sure if a good idea though):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

I hope we add namespaces/categories as discussed in #18711. I want to separate the C# API into namespaces and perhaps assemblies as well to make it possible for users to pick only what they need.
My plan for 4.0 was to hard-code a table of namespaces myself if there was no other choice, but I would prefer if instead I could get this information from ClassDB.

@eon-s I don't think it is... while translation is technically valid to represent coordinates, Godot is the first engine where I see a different term being used here, otherwise I've always seen position regardless of 2D or 3D. Also to me translation is associated with movement, and conflicts with another term related to language/transformation, which makes it odd. This was mentionned in https://github.com/godotengine/godot/issues/16863 too.

BTW, why are we planning to break as little as possible? I understand why people don't want more compatibility breakages, specially those making tutorials; but if we won't take 4.0 as an opportunity to break compatibility, when are we going to? #16863 is already accumulating a lot of suggestions.

@neikeq can't wait for 5.0? since no new or big features are planned, otherwise people will stop making things and buying courses for an engine that changes important parts every 1 or 2 years (for video tutorial makers this mean redo all their work) and with a few months of warning time...

I'm in favor of renaming to have a consistent 2D/3D suffix, and I agree with many in this thread that it should be done for all nodes for consistency. Having a consistent naming convention is extremely helpful for someone learning the engine, or someone moving from the 2D side of things to 3D, or vice versa.

@eon-s Surely waiting until 5.0 just means there will be an even larger body of work that needs updating?

As much as tutorials are wonderful to have, I'd vote for making the engine more comprehensible over keeping it confusing for the sake of existing tutorials. Hopefully fixit scripts or optional aliases (as discussed variously above) could be used to smooth the upgrade path.

I appreciate the difference in naming between Node and Spatial because Node nodes have no knowledge of space, having Node, Node2D and Node3D would BE confusing. Unless you plan to get rid of Node, then it'd make completely sense.

I'm for having only one realm 2D or 3D having to bear with having a suffix. It's 2D at the moment and the confusion between 2D and 3D ends there.

Please don't add the 3D suffix. Is it really worth the headache for what it adds? Is it worth the cost? of updating everything or having outdated tutorials? Unmodifiable and outdated youtube tutorials? It will bring more confusion.

@dpalacio I'm using Godot for only a few months but I think it is more clear and concise to use Node3D, Node2D, and Node because of the Spatial acts as a Node3D and the Node has no space information. I think adding suffix for 3D will be much more simple to understand as it will be named "oppositely". I know it is not really opposites but I don't know how to express it better because English is not my native language. Put 3d versus 2d explicitly looks great to me. I think it will be very easier for beginners, and still more for the people that are having the first contact with a game engine. The namespaces are great too, mainly for big projects and plugins. Conflicting names are a headache. As a beginner, I think the compatibility breakage needs to be minimal and automatic because it is hard to keep changing projects between versions. If we have many changes we'll need to have an automatic conversion tool and documentation for it too.

@neikeq yeah, category should be replaced by namespace and we should make proper ones.

Exactly what I was thinking when I tried Godot. My OCD tells me that it should be this way.

Have you thought about renaming translation for spatial nodes to position?

'position' sounds more like it's an absolute position instead of relative position.
Calling it position might help new developers but eventually they will realize it should be called translation.

I'm kinda on the fence with this proposal as someone writing Godot tutorials and using Godot for my own fully featured projects.

I am totally in favor of changing the names of the nodes to stay consistent, and I agree with others that consistency is important, even if it makes things perhaps a tad more wordy. I would much rather have to add 3D or 2D to the end/beginning of nodes if it makes things more consistent in the code base and documentation.

Here are some nodes that I would like to see changed to stay consistent:

• MeshInstance -> MeshInstance3D (to stay consistent with MeshInstance2D)
• GridMap -> TileMap3D or GridMap3D
• TileMap -> TileMap2D or GridMap2D
• YSort -> YSort2D or 2DSort (or something to show it is for 2D)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (or something to show it is for 3D)
• ReflectionProbe -> ReflectionProbe3D (or something to show it is for 3D)
• SpatialMaterial -> PBRMaterial or Godot3DMaterial or StandardMaterial3D (just ideas)
• Label -> TextLabel (I agree with @MuffinManKen)

Here are my thoughts on this proposal, starting with the positives:

I think this change will make things easier for those who have no Godot experience, but only those who come after these changes are made. Especially on the 3D side, one of the biggest problems I find is that it can be hard to find what nodes you need, and I think renaming the nodes using a consistent naming scheme will make this much easier for everyone.

Many of the times I am helping others with Godot, I find one of the most surefire ways to find a solution is to look in the documentation. However, since the names of nodes are not always consistent, finding the documentation page can be difficult for certain nodes unless you already know the name of the node you are looking for. The changes in this proposal would make finding the correct node much easier.

Another benefit I can see with this change is that it sets a standard on how nodes should be named, which could be helpful for plugin creators and future Godot Engine contributions. For example, if I am making a decal node (for example), then with this change I know I should name it something like Decal3D instead of just Decal.
This might also help with the naming of GDScript/C# defined classes.

This would also make tutorial writing in the future a little easier, as no longer you have to explain that Spatial is basically a Node2D in 3D.

Now for the negatives:

One of the biggest issues I have with this proposal is that it seems too soon, especially given how much Godot 3.0+ changed things up not too long ago. I think only a few games using Godot 3.0+ have even come out, and very few 3D Godot games.
A lot of the big, impressive 3D games in the Godot showcase are still not released, and making a big change like this means those projects will need updating too, further delaying some really strong 3D Godot games.

Also Godot 3.0+ tutorials are still coming out. Especially on the 3D side, things are starting to somewhat gain traction. While this is in part due to the 3D side of Godot becoming stronger in Godot 3.0+, I fear that a lot of the material tutorial writers are making (or have in the works) will suddenly need massive rewording to account for the name changes. This will take time away from making new tutorials, as old tutorials will have to be dropped, remade, or rewritten.

The naming change would also make existing resources that are not tutorials, just simple solutions found to problems, suddenly outdated. While Godot's 2D side is arguably quite strong and can probably adapt quickly, the community using the 3D side is noticeably smaller. By changing the names of the nodes, I worry this is going to stunt Godot's 3D user growth and the ability to find solutions to 3D related problems.

I agree with @eon-s: can't these changes wait a bit? Things are already changing pretty dramatically, at least in the code base, with Godot 4.0. I think adding another massive change is only going to make development harder and reset a lot of progress people are making with the 3D side of Godot.

Once Godot 4.0 is out, I think working on renaming the nodes in version 4.1 or 5.0 would be excellent, but in my opinion I think adding another big change like this is going to do more harm than help.

One thing that might make this transition better is to have an alias/transition period, perhaps from Godot 4.0 to Godot 4.1 for example. This would not make tutorials and resources (especially 3D ones) obsolete instantly and would give everyone a chance to adapt to the upcoming changes while still being able to benefit from the changes in Godot 4.0.

Using a alias/transition period would allow compatibility breaking changes to be made without suddenly forcing everyone to update all at once. This would also allow compatibility breaking changes to be made more often, as theoretically once a system is in place for transitions it could be used again for future compatibility breaking changes. This would make things easier going forward with changes listed in #16863.

TLDR: I am all for the changes, I think it should just wait until Godot 4.1 or a transition system/period should be made to give everyone time to adjust to the changes.

Regardless of how this proposal ends up: I think Godot 4.0 will be great and I am looking forward to it 🙂

@reduz i say go for it. And I second @jahd2602

I'm not a big fan of making all 3D nodes end with "3D", but sure, if everyone wants to. I do think that it's fine keeping different names rather than always having a suffix (ex: TileMap and GridMap)

I would vastly prefer "position" instead of "translation". The latter can be confused with localization & languages, and the former is immediately clear and beginner-friendly. However, doesn't Godot already use "origin" in most places for this?

I also agree with @neikeq that it's worth it to break compatibility if it's a beneficial change to new projects. I would personally love to see the vast majority of things in #16863 implemented.

(btw why does Sprite3D exist when it could just be a quad mesh?)

@TwistedTwigleg Read my post, 3.0 projects will open fine in 4.0 if an internal compatibility system is added..

Nice change, as a programmer I'm happy to see the name for the counterpart as symmetric as possible

Can you explain what ORM style textures mean in more detail?

@reduz is the only difference between the standard spatial material and the ORM one, that you only have one texture channel (rather than 3 as it is currently) with the ORM? Will you still have access to the same parameters (in metallic and roughness) such as specular and the multipliers? Not used often but sometimes used to tweak.

I do like the idea, but wondering if it is overkill to have 2 material types for such a small change. Could there instead be a toggle to switch between 1 texture channel for ORM mode or 3 for the existing style, using a single material?

I have also recently been putting the depth(height) channel into the alpha channel of my ORM maps to get more mileage out the textures. Then you can do most textures using just 3 textures...albedo/normal/ORM(H). This could be worthwhile to add in by default (unless we get a 16bit option for height maps, where you would want to use a separate one). If 4.0 eventually gets tessellation/displacement, the height channel will be much more important than it currently is.

And speaking of which, it would also be a good opportunity to change the naming of the DEPTH channel to HEIGHT in 4.0 and have it use the inverse of what it currently uses (ie white is a raised surface and black is recessed). This would put it in step with other renderers and game engines, and more importantly with tools like Substance, Quixel and Marmoset.

I'd much prefer explicit suffixes for 2D and 3D nodes, and no suffix if it's not applicable. I'd also like the "Control" nodes separated completely for the "Node2D" nodes (they're both currently grouped under "CanvasItem").

About translation versus position, I'd go for the former in both 2D and 3D.

position looks more friendly, but it stops making sense once an ancestor has some rotation or scale.

Regarding compatibility, the transition stage should last for all the 4.x releases to give plenty or time to tutorials, users and projects. The new names should be the first-class citizens and encouraged, but the old ones should work, with some in-editor mechanism to tell people about the change.

I'm absolutely in favor the suggested changes as long as it's done in a way that makes it easy for end users to update existing code--either their own or code from existing tutorials and documentation--via some sort of tool as mentioned. Lacking such a tool, I would tend to agree that we're piling on rather soon after the big shifts in v2 to v3.

@TwistedTwigleg regarding of the release of 3d games, that's because we're waiting for 4.0 and Vulcan 😎

I would also review Control nodes names... and inline documentation.

Sometimes I wonder what's the difference between AcceptDialog and ConfirmationDialog, and the same with PopupPanel, PopupDialog, PopupMenu... hope this helps!

As a tutor and a docs contributor, I'd say go ahead! I don't mind producing more content if the changes make it easier for everyone to learn and to understand the engine in the future. Better do this kind of change ASAP as well.

Coming late to the party, but some clarifications to keep things manageable:

• Please comment only about the proposal for renaming nodes, and its technical implications on how to preserve compatibility, the impact on existing projects, tutorials, content makers, etc.
• This is not the place to discuss specific points in the API that should be considered for renaming. If we do decide to go with this massive renaming, we will review the whole API in a spreadsheet to ensure that we have consistent names. For specific things like methods, properties or classes which should be renamed beyond what is discussed here, see #16863.
• @RandomShaper @fracteed @fire @reduz Please move the discussion about standard materials to a dedicated issue.

Hello,
Why not follow practice of other APIs and create an Obsolete/Deprecated decorator for classes (or even methods), i.e. the old names are simply aliases/pointers to the new. This would stop any breaking changes and allow the names to be dropped in version 5 so less people would be affected or even notice.

Using a decorator could also give two other benefits:

1. The IDE could easily pick up this tag and display it in the node selection window, e.g. instead of simply saying 'Spatial' it could read 'Spatial (obsolete use Node3D)'.

2. The decorator could then become a built in warning shown in the code editor.

Plus it doesn't stop anyone creating a renaming tool...

Some thoughts:

I agree with renaming nodes, as well as a few methods and properties (see current list in #16863) for improved consistency and to make the API easier to learn and use. Making the 2D / 3D distinction clear seems a good idea, and if done it should be done consistently (so e.g. also MeshInstance3D as mentioned). I suggest that we use a spreadsheet to list all current Nodes and what their new names in 4.0 should be - and we can bikeshed there about specific nodes like TileMap/GridMap. I'll create this spreadsheet in coming days if we confirm that this is the way we want to go.

Yet, we should strive to limit compatibility breakage as much as we can. As Juan mentioned, we can have compatibility renames in the engine internals so that old scenes can be loaded and converted, but that's not enough.

As @RandomShaper and @chucklepie mentioned, we should add deprecated aliases for the all the nodes, methods, properties, constants, signals, etc. that we rename, with a property decorator/metadata that would signal them as obsolete and encourage users to change their code. Using this information in the IDE should make it possible for users to follow 3.x tutorials in 4.0 without issue, while learning easily about the new names as they go.

To do so, we need helper methods that can let us define deprecated aliases when registering bindings. #23023 is a first attempt to add such an interface, but it still needs to be reviewed, merged, and maybe expanded if it's not sufficient for what we will need in 4.0. Those deprecated aliases can be kept for the whole 4.x release cycle, and dropped in 5.0.
I would oppose any compatibility breaking renaming until we have this interface well designed and merged, so anyone interested in this is welcome to give this PR a try and suggest changes if needed.

As for the when, I insist that if we want to ever break compatibility again, this is now. Waiting for 5.0 doesn't make sense, as it would make even more content obsolete once we reach 5.0, and it would not help depict Godot as a stable development tool if we break compatibility with (hopefully) many great games in development with Godot 4.x.

Godot's userbase more or less doubles each year, so each year that passes makes a refactoring less realistic, as eventually the inertia of a big userbase outweighs the benefits from breaking compatibility. If other engines like Unity or Unreal seem relatively stable in terms of API compared to Godot, it's not because they don't have things that they would like to refactor or rename, but because they cannot afford to. We still can, for now, so we have to use the opportunity. It was the same for Godot 3.0 and the community came out of it relatively unscathed, though we do have a small proportion of users sticking to 2.1 as they can't afford porting to 3.0. For 4.0, the scope of those changes should hopefully be a lot less, and any porting work should be straightforward, but the community has grown manifold in the meantime, so the impact of any compat breakage will be as big or bigger than for 3.0 in terms of image/cumulated user annoyance :)

I'm a big proponent of breaking compatibility.
Why it's not an issue: if a dev puts out their game on an older version, then keep developing on the older version of the engine, nobody is forcing the dev to migrate to the new version. Also: keep offering older versions for downloading just exactly for this purpose.
New projects can be started in the new version of the engine and then it comes down to whether the developer has the patience to re-learn how to engine works.
When it comes down to improving engine usability, the patience for re-learning should never be an issue, if the goal is to become the most user-friendly or powerful engine around.

As for the renames, it helps to reduce the learning-curve if there are patterns in the material to be learned. For instance, Node2D vs Node3D, etc for all the other nodes. If it looks like a duck, you know how it goes, it most likely is a duck, or a node in this instance.
Human brain works as an optimizing quantum computer, which learns by connecting lowest energy states of systems with each other to create logical paths between ideas. If the ideas to be learned are similar, their lowest energy states are more closer to each other, which makes it easier to connect (and remember) them, which explains why its easier for a student to understand 3D if they have been taught 2D beforehand. If the names of the nodes reflect the similarity between them, it's also easier to learn and understand how a new type should be used if knowledge is present on a similar type.

I say go ahead and refactor and break compatibility any way you wish. Even if you lose few users, you'll gain many more by increased user-friendliness and reduced learning-curve.

In relation to this, take Blender 2.80 for instance. Compare how it looks and behaves now with what it was before. It's a major change which forces a lot of devs to re-learn how the software works. Now think how many users Blender has. Compared to Godot, they're gigantic, yet they drastically changed their software anyways. Why? Because in the long run, it's always more profitable to reduce learning curve and improve user-friendliness, even if it means losing some users who don't have the patience to transition to the new workflow.

On balance I'm not in favour of a breaking change in this case.

I can understand the frustration felt with naming conventions that have grown organically, but I don't see any that quite justify a wide-ranging and breaking change.

I'm all for deprecating APIs that we wish to move away from (and flagging those at compilation time & in the docs), but ideally the old node names would continue to function as before.

Perhaps, in a few years' time, we can ask if it's time to discontinue legacy node names as it has become entirely painless. Until then my suggestion would be to add new names as desired (I don't have a strong opinion on that) and avoid breaking backward compatibility.

@fracteed Actually having depth in a channel of another texture is probably not a great idea, because parallax mapping does a lot of taps to that texture, forcing to get RGB unnecesarily every time. If you use a single grayscale texture, Godot will compress it to half the size, saving you some bandwidth.

Having an ORM mode in the standard material may be a good idea too, need to give that a check.

@chucklepie The problem is that not all languages support class aliases like typedef. C# is one of them.

@reduz ah, I didn't realise that, good to know. The more important issue is getting the depth channel switched to height for 4.0, so hopefully you will consider changing that.

edit. sorry Akien, only just saw your comment after posting this...

@neikeq The problem is that not all languages support class aliases like typedef. C# is one of them.

I don't know how the native C++ library is implemented, but I'm referring more to a mechanism to do this decorating at the native C++ level so that it doesn't matter what the upstream language binding is. If that's not possible then the bindings for each language could easily be adapted to suite (e.g. using attributes in C#, etc).

@gerald1248 Read my post, nowhere I mentioned it will be breaking, projects created in 3.x will continue to work by using aliases on load and on scripts. Using them will trigger a deprecation warning, but your project will continue to work.

I'm a huge fan of the

Navigation -> Nagivagion3D

rename. I second this request!

@reduz said:
@TwistedTwigleg Read my post, 3.0 projects will open fine in 4.0 if an internal compatibility system is added..

My bad, I missed that part of the post.

A internal compatibility system would help with migration, and definitely puts me more on the "make the change" side of the fence, especially if combined with something like #23023. Knowing something is planned for projects prior to this change is good to hear and eases a lot of the concerns I had about this proposal.

@Norrox said:
@TwistedTwigleg regarding of the release of 3d games, that's because we're waiting for 4.0 and Vulcan 😎

That is fair.
Especially given the improvements to the 3D side of Godot coming in Godot 4.0, waiting might not be a bad thing for 3D heavy projects.

the 3d and 2d differentiation is already consistency clear. 3d nodes are light red, 2d nodes are blue, and ui nodes are green. there will always be users who have an issue with naming. it's a never-ending problem and is a multiplicative issue based on the community size.

in regards to the suggested changes in the OP: 2d nodes already have a "2D" suffix applied, which _inherently means their counterparts are 3d_.

however, i am in favor for changes like Label to TextLabel. (@MuffinManKen makes a great point)

I am in full support of basically everything here, but with regards to the "Sprite2D/Sprite3D" question, I would suggest leaving Sprite as Sprite, if for no other reason than the 2D suffix adds an extra quantity of clutter, IMO.

As @girng says, the 2D/3D differentiation is already pretty clear due to the colour-coding, so we don't need to go to great lengths to avoid confusion. From the perspective of a Godot developer, I would personally not enjoy having -2D tacked onto every non-renamed node in my project. :D

Is that colour coding helpful to people with various forms of colour blindness?
It's definitely not helpful when you're typing out code (as opposed to adding nodes from the dialog).

@reduz thanks for your reply. I realise it's for a major version and thus entirely fine in a semver sense. Personally I'd avoid making changes like these even for a major version, but I'm aware you have a much better grasp of whether this would be a problem or not. I'm just looking at the history of big changes across major versions (python2 to python3 for example) and usually I'd rather live with inconsistency (or new node names plus old, deprecated nodes). Either way I love Godot and will continue using it, whatever breaking changes there may be.

But then again, feel free to suggest if you would prefer something more explicit and make everything 2D/3D always.

explicit is better than implicit.

@girng @AlexHoratio Nodes having a different color in the editor isn't helpful when you are writing code, though. I think this is where the confusion arises.

(I still don't see why Sprite3D needs to exist at all, other engines just use quad meshes for the same purpose, it would be easier if Sprite was exclusively a 2D term).

@gimg, @AlexHoratio Don't forget that 4.5% of the population is color blind also :stuck_out_tongue:

I think renaming is a good idea.
Transition from 2D to 3D will become a whole lot easier. At least for people who start with 2D (and probably the other way around, too)

it's clear there's an issue, and the community thinks it's a good idea. i'm just biased with godot and far too emotionally attached. being in this state generates thoughts that don't really make sense to others, but make perfect sense to me, in a beautiful way. hard to explain. thanks for letting me voice my thoughts

I would agree with the general consensus here that renaming them for consistency is worthwhile. Right now it can give the external impression that one set of nodes is "first class" and the other is "second class", or maybe even hacked into existence based on the first.

I personally think Sprite -> Sprite2D would be an unfortunate casualty of a completely rigorous explicit renaming, but I guess I can always just manually rename it to Sprite in every scene I make until I get tired of it.

I do think it's off-putting that CanvasLayer and CanvasItem aren't grouped, and that Node2D is inside of CanvasItem with Control, like others have pointed out.

I know @akien-mga said that this is only for the renaming of nodes, but I think that at least the debate about position vs. translation comes into play here. I think the purpose of renaming nodes falls somewhat flat if their APIs are significantly different (barring differences between coordinate systems and the like,) so they definitely should be the same, whatever they are. I'd vote for "position" as the way to go here, there was a comment about it being misleading compared to "translation". I'd say that "translation" is misleading because it implies a transformation or movement rather than simply being coordinates. Position is intuitively relative, imo (you don't straighten your chairs with respect to the compass directions, you do it with respect to the walls of the room.)

I think that the variables should be named position for both, but the translate functions should stay, changing move_local functions in Node2D to translate_local, the documentation even calls it translating. I would keep the use of move for the physics related nodes, to distinguish between physics motion and geometric translation.

A lot of the second half of this is relevant to #16863 as well

Also @reduz, I think as C# gains functionality in the engine, more and more people will want namespaces for C#, and once they're in C#, I can imagine a lot of gdscript users wanting to use them and not having to switch languages for the functionality. I think namespaces are completely essential to eventual C# support though, for gdscript the benefits are much less dramatic but it will make plug and play packages possible without user worry.

I just thought of an idea, if this was implemented, we could have an editor setting called "Simple node names", which means that newly created nodes lack the suffix in their name, for example, creating a new "Whatever2D" would set its name to "Whatever" but scripts on that node would still say "extends Whatever2D" etc. It would be the same as making a node then renaming it manually.

This would avoid the clutter of seeing "2D" or "3D" default names in the Hierarchy if the user chooses to enable it, but would still make the code more consistent and explicit. Without the 3D nodes containing "3D", this would be confusing, but it would make sense with "3D" at the end by default.

@aaronfranke I think that's a pretty solid idea. It seems like a compromise that allows for keeping the codebase consistent and clear while allowing users to keep excess clutter out of their hierarchy. I think a lot of the objections to the idea of renaming come from the effect it will have on hierarchies, rather than an objection to the names themselves.

@aaronfranke I'd hate to be the one who spoils otherwise a sensible idea, but different node names between different systems would make sharing gd script files impossible. Since all plugins are exported as raw gscript files and scenes, they would stop working, if they were developed on a system with different node mappings. To avoid this, all gdscript files and scene files would need to include node name mappings to translate the file for the new system. I'm pretty certain that this kind of overhead is a big no for @reduz.

@aspenforest I don't think adding a mapping would be a big overhead but perhaps I am being naive as I don't know the architecture of the engine

What could be easily made of @aaronfranke's idea is to just rename the nodes on creation. Similar to the existing setting in ProjectSettings which changes newly created node names to snake_case or spine-case (so a new MeshInstance node would automatically be named mesh_instance instead of MeshInstance), another setting could be added for node suffixes, which would remove the "2D" or "3D" suffix from node names (so a new Sprite2D node gets named just Sprite).

Nobody ever complained about KinematicBody2D or Particles2D and the like having an unnecessary "2D" suffix, so I don't see why we should add features to work around the addition of a "3D" suffix on their counterparts... If users really don't want these suffixes to be there in the first place, then this proposal should maybe be discarded, not worked around with a way to rename nodes in the IDE for some cosmetic reason...

@akien-mga this wouldn't so much be "working around" the new node names, to me it's more the gravy on top, something that is only non-hacky with a consistent naming scheme. I DO want the suffixes there, for when I'm coding, adding nodes, or looking up documentation. But once they're in a scene, I know what they are, and a lot of things will get custom names anyway.

If it came down to choosing between making the names consistent and getting an editor feature to make the names simple, I'd choose the former, but I think @aaronfranke was getting at the fact that any objections to this proposal were really fundamentally cosmetic, and his suggestion addresses that while not costing any of the below-ground consistency this idea is actually about.

I definitely think that adding the editor feature would be its own issue/pr, not something necessary for including this.

I initially avoided SpatialMaterial because it had a weird name. But it's such a powerful class. Instead I just started to learn how to code shaders with triplanar mapped albedo+ao+normals. Then I discovered all that work I had done was for naught as I could have done all that in SpatialMaterial and then converted it to code and gotten a better result. So it needs a more friendly name.

+1 for explicit 2D/3D names.

I have question concerning one node which I assume may be marked for deprecation in the future, and who's existence I can imagine might be confusing from a naming standpoint. Since the new animation system dropped, we now have two nodes, one named AnimationTree and AnimationTreePlayer which have basically no relation to one another whatsoever. Any thoughts on what might be the best way to address this?

@SaracenOne This isn't the proper place to ask questions like that. Sorry. This thread is for discussing the 2D/3D suffix only.

There is another issue for discussing name changes more generally https://github.com/godotengine/godot/issues/16863

I had a thought that would probably be beyond the scope of the compat breakage acceptable for 4.0, and therefore is probably simply unfeasible/unacceptable, but I figured I'd mention it to see if someone more experienced than I am cared to comment.

I imagined that all these 2D/3D nodes could inherit from a single node type that is either 2D or 3D. The API for such a node would contain all the functions that you'd expect for either version, and their implementation would depend on whether this particular one was 2D or 3D.

In theory, such a system could:

1. Make sure that we are creating consistent APIs between 2D/3D counterparts. This is both a benefit and drawback as I see it, since despite this consistency there might be things that aren't necessary to include in one but are in the other.
2. Make it easier for the two different types to interact, or creating custom scripts that you wanted to attach to both 2D and 3D versions of a node.

It'd be good for avoiding a situation where "SomeClass2D has x, y, and z implemented but there's nothing like that for SomeClass3D" and it resolves the naming problem in a different way. This is probably monumentally stupid for some reasons I'm not thinking of right now, but I thought I'd throw it out there.

@vortexofdoom That's already what happens. Node2D is inherited by all 2D nodes, and Spatial is inherited by all 3D nodes. The question is what to call everything.

And, more importantly, both Spatial and Node2D inherit from Node.

I'd say there's still something in @vortexofdoom's idea not covered just by the class hierarchy, but I can't determine exactly what it is.

Just wondering: do you think it would be beneficial to add a -Res suffix to all Resource-derived classes?

@aaronfranke I'm referring to the idea of having ONE of each type of node (simply KinematicBody or Sprite), and the top one being some kind of Node2D3D that dictates their behavior. Sorry if that wasn't explained well. So rather than having a 2D hierarchy and a 3D hierarchy, we'd have a 2D/3D hierarchy. That's why I said it'd be a bigger refactor than is probably acceptable.

It _could_ work by having the basic types not be usable on their own, but needing to be implemented as 2D/3D for them to be a real node, in which case we're back to square one on node names but the inheritance is more automatically direct and related between the 2D and 3D and the interplay between the systems would still be nicer (I think).

@vortexofdoom But nothing is actually shared between 2D and 3D. They might have some of the same node types and have the same method names, but almost all implementation is completely different. The most sharing I could expect would be an interface, as your idea would involve if (is2d) { do 2d stuff } else { do 3d stuff } and would make the code files twice as long and very unreadable for no benefit.

The feasibility of single classes with variable behavior is definitely dependent on how much of the heavy lifting that top-level 2D/3D node could do, sending abstractions further down. Mashing the classes as they exist now together would definitely not be worth the trouble, I'm sure. I wouldn't mind the use of interfaces to accomplish the reorganization though, it would still enforce at least some level of standardization to the different types.

The idea was prompted by an idle wish that I could inherit from a general version of a node so I didn't have to implement everything twice in a project where I had a 2D and 3D version running in parallel. Right now, you'd have to inherit from node and do some casting to do that in any way, since node is the only common ancestor.

I think a Node2D3D (I'm aware how ridiculous it sounds) would have some value even if only as a way to make the two coordinate systems play more nicely with each other, but that's approaching a different design question altogether than this thread's. Sorry to get sidetracked.

@RandomShaper I could definitely see the benefit to that, especially if we have that simple names option.

Leaving my comments up for posterity, but I'm retracting my suggestion in favor of a strict 2D/3D naming scheme while leaving the hierarchy largely as is.

The reason being that renaming all of the nodes would free up all of those class names for user use, meaning that I could implement the functionality I was looking for by creating my own set of classes like KinematicBody or CollisionObject that could pull relevant functionality and pass it down.

But even outside of that edge case, it would allow you to create classes like Area instead of contriving something like RoomGroup as a quick example.

I'm quite happy that this is being discussed. I'm hoping it gets done.

Don't know if it's been said, but if things are gonna be renamed for consistency, might as well go with full consistency (as humanly possible) and also rename certain methods.

Example:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

In addition to nodes and methods, what about data structures? I assume that Transform will be renamed to Transform3D to line up with Transform2D, but Basis probably doesn't need to be Basis3D because there is no Basis2D as it's all included within Transform2D.

@RandomShaper

Just wondering: do you think it would be beneficial to add a -Res suffix to all Resource-derived classes?

Seems a bit too little bang for the buck. I'd rather vote to include Resources in my suggestion (#31054) for code highlighting, tbh. Having them on a different color would reflect their base type as soon as you finish typing the class name (just like with built-in types like Vectors and AABB).

What about separate projects to 2D and 3D.

(On the image suggestion to replace 2d with UI and 3d with Scene).

When you start the project you select which one you will work on.
No more suffixes (2D, 3D) are needed in class names.

So in that way kind of namespacing are creating, and no more mixes between those types:

using Godot2D;
using Godot3D;

When you are in 3d or 2d project - click on UI you have got UI (2D) window for edit GUI, when clicking on Scene - you are in the scene (2d or 3d depends on project type).

So in that way we keep 2d mode for UI in any project, but Scene opens 2d or 3d window

In this window will be only available entities related to project type (2d or 3d) or shared if they using in both

When you on UI mode, adding new node shows this window only with components related to UI.
When in the Scene mode UI controls are not shown, only things you can apply to scene

@dmitryuck For the image you posted, the 2D button is always necessary, since even 3D games will need to use Godot's 2D mode for UIs and stuff. And it's desirable to be able to mix 2D and 3D anyway. Technically 2D games don't need to use the 3D button, but it's hardly necessary to hide it.

I suggested above that we can make node names be cosmetically changed in the hierarchy to avoid visually unnecessary suffixes, but it would be better if the code is always explicit.

@aaronfranke I've added a bit widely explanation of what I meant in my previous comment.

I think that displaying names of nodes differently depending on the circumstances would add confusion.

People should be able to understand scripts and scene trees at first sight. I think that's a must for collaboration, clear tutorials, etc.

@dmitryuck Some projects can require mixing 2D and 3D though, and some games have UIs in 3D.

@Skaruts switching to 2d view in 3d scene possible by implementing component like in this editor

UI mode, of course, has to be present in both types of projects, but it might be a separated window with tools specially made for UI like a grid, enhanced snapping, rulers and so on..

@reduz Renaming is good thing, but there should be long transition period for example from 4.0 to 5.0, because this outdate lots of tutorials and answers from https://godotengine.org/qa

@xxmatxx I would prefer if the rename happened with a short transistion period to stop dragging the 'what would be' old names along.
Also, I'd ensure to well document the changes and makes sure people who are just getting stuck into Godot know about the changes. An in-editor warning informing you that you are using the deprecated version of the node names will also be useful incase some forget about this.

I agree, the longer it takes, the longer it will have a chance to confuse people. Tutorials and docs won't be immediately outdated if, like @AtomaFajrovulpo suggested, for a period of time the editor still allows the deprecated stuff but shoots out a warning. Something along these lines I suppose:

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

and

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

I found yesterday that constants don't all follow the same case. For instance there is Color.black and Vector3.UP. Shouldn't this be made consistent for 4.0?

@BenjaminNavarro Changing Color constants to uppercase was also discussed at the bottom of https://github.com/godotengine/godot/pull/14704.

Also, method/signal/constant renaming should be discussed in #16863, as this issue is specifically about node names.

@Calinou Thanks, I was pretty sure there was other issues but couldn't find them.

I'd rather have the rename in 4.0 and be over with it then knowing it will come later after the project i'm working on has grown more.

if a major release isn't the time to do it, what is.

SemVer: Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

How far will you go with this?

Will GridMap then become TileMap3D, and Tilemap Tilemap2D for example ?

Also, node2D and node3D seem a bit generic, why not have Spatial2D and Spatial3D then ?

I think a big UX difference too would be to have control, node2D and spatial, whatever they will be named, directly accessible beneath node in the new node dialog, although node2D and control inherit from CanvasItem. You can't add a CanvasItem directly to a tree anyway, so maybe it should not be visible in that dialog.

And as far as methods go, i guess there is no need to add a 2D or 3D postfix on those, since you know what you call them on right ?

I still hope to make some useful updates, such as addressing the slow import of resources, and the performance optimization of GD scripts. At present, it takes about an hour to import 1G resources. If you import 10G resources, you have to sit in front of the computer and sleep for two days. However, the resource editor file system browser of the 700M-1G import is now broken, and nothing will be displayed. File list, this may be the shortcomings of the editor itself, so I think that optimizing and solving the existing problems is the better way for Godot. If I can only import 100-500M resources, then it is destined that Godot cannot develop large games , But my path is now blocked and I cannot move forward. Hope that the next version will solve such problems, I wish Godot better and better!

@qq715152910 Please don't comment on long threads with completely unrelated information. Everyone who has commented on this issue will receive a ping and your comment has nothing to do with the proposal for renaming nodes. As a result, I will be hiding your comment.

I'll give our opinion about some renaming that would be usefull for us (We use C# mainly)

The renaming that we strongly suggest:

1. Transform.origin -> transform.origin

(Making the access to a transform property lowercase)

Why?
For example the spatial has the Transform that we can access, but many times we write "this.Transform.origin" for better readibility, if we change "Transform" to "transform", we wouldn't need to use "this" all the time. That's our personal opinion.

1. We also support changing "Label" to something like "TextLabel". Or at least when we search by "text" when adding the new node, "Label" should appear, since it's totally related.

2. The constants for some predifined colors should be access with Color in contrary to Colors.

For the rest of the proposing renaming we look forward to what the community think is better.

AtlasTexture -> TextureAtlas

It's named AtlasTexture because it follows the usual <Type>Texture convention where <Type> can be Image, Viewport, Stream, …

AtlasTexture -> TextureAtlas

It's named AtlasTexture because it follows the usual <Type>Texture convention where <Type> can be Image, Viewport, Stream, …

This what shows up when I type "Atlas".

This is what happens when we type Texture:

Edit: We understand why that convention. In the 2nd screenshot, AtlasTexture is very bellow with other things that follow <Type>Texture convention. Following that, that point was removed from our previous post. For this particular case is still not very autocompletion friendly. But we accept it. .

@bigmonte The Transform struct will might be renamed to Transform3D in Godot 4.0 as per this issue, so you will no longer need this. to make it clear that it's a property.

EDIT: https://github.com/godotengine/godot/pull/38430

The constants for some predifined colors should be access with Color in contrary to Colors.

I'm the one that proposed that in the first place, and I strongly disagree. It's better to keep them separate, since it increases discoverability of Color's static members (currently Color8, ColorN, and FromHsv) when using autocomplete in various IDEs. I'm also considering proposing a rename of Color.red etc -> Colors.RED in GDScript for consistency.

By the way, I think you were looking for #16863.