Ich benutze Godot seit mehr als einem Jahr beruflich.

Ich stimme allem zu, was Sie gesagt haben, außer:

Für einige denke ich, wir sollten den aktuellen Weg beibehalten

Wenn wir diese einmalige Gelegenheit haben, benennen wir einfach alles um. Dazu gehören Sprite2D und MeshInstance3D.

Es ist immer besser, eine vollständige schmerzhafte Refaktorierung durchzuführen, so viele teilweise schmerzhafte Refaktorisierungen.

Apropos Umbenennung: https://github.com/godotengine/godot/issues/16863

@jahd2602 Mir persönlich ist es

Ich kann definitiv sehen, dass die Leute sich damit belästigen, nur weil es eine Inkonsistenz ist, aber wir können zumindest sehen, ob es sich um eine Mehrheit oder eine Minderheit handelt.

@Zylann Ich weiß, wenn wir hier etwas entscheiden, verschieben wir das dorthin.

Ich halte die Haltung gegenüber Namespaces für kurzsichtig. Es ist aus der Perspektive des Motorworkflows im Allgemeinen sinnvoll, ignoriert jedoch die Perspektive der Werkzeugmacher. Godot Unit Testing (GUT) von bitwes zum Beispiel brach aufgrund eines Namenskonflikts in einem seiner Updates ab. Es besteht die Wahrscheinlichkeit, dass dies mit einem dedizierten GUT-Namespace hätte vermieden werden können.

Ich möchte auch Namespaces für Waiting And Testing (WAT), damit ich Klassennamen wie Test (Zugriff über WAT.Test) verwenden kann, während ich nicht über andere Frameworks (wie GUT, wenn es GUT.Test verwenden würde) oder nur das Skript des Benutzers. Ich habe es mehrmals versucht, eine WAT-Klasse zu verwenden, die alle Skripts enthält, die als Unterklassen verwendet werden, aber das ist nur eine zyklische Referenzhölle.

Wenn wir dazu ermutigt werden sollen, Tools innerhalb der Engine zu erstellen, benötigen wir die Tools, um diese Tools in der Engine zu erstellen, auch wenn sie für den Engine-Workflow selbst nicht unbedingt erforderlich sind.

Zusammenfassend lässt sich sagen, dass ein dediziertes Namespace-System, auf das sowohl über die Engine (oder zumindest über das Plugin-Skript) zugegriffen werden kann als auch definiert werden kann, damit Werkzeughersteller nicht übereinander laufen oder ihre Verwendungen ein Glücksfall wären.

@CodeDarigan Ich verstehe, dass es Vorteile hat und ich leugne sie nicht, aber ich glaube aufrichtig, dass die Kosten sie überwiegen.

Hinzu kommt, dass wir so gut wie keine nennenswerten Beschwerden von GDScript-Benutzern hatten, die den aktuellen Ansatz bevorzugen, so dass sie zu einem unerwünschten Workklow gezwungen würden und mehr Code in einer Sprache eingeben würden, die nur schnelles und schmutziges Zeug schnell schreiben soll. (C#-Benutzer scheinen sie jedoch zu wollen).

Aus diesem Grund meine ich, dass sie als Metadaten für Skriptsprachenbindungen existieren können, und wir könnten sie sogar für GDNative C++ hinzufügen. Fügen Sie sie einfach nicht für die Kern-C++-Engine hinzu.

Navigation -> Nagivagion3D
Ist das ein Tippfehler?

@nitodico in der Tat

@reduz Ich stimme @jahd2602 zu. Auch wenn einige Dinge offensichtlich sein mögen, sollten wir aus Konsistenzgründen entweder 2D oder 3D postfixieren.

Ich beginne noch mit Godot und die vorgeschlagenen Änderungen klingen für mich vernünftig - die Verwendung subtil unterschiedlicher Namen für die 2D- oder 3D-Variante eines Knotens hat mich ein wenig verwirrt, als ich lernte, welches Ende dran ist und zu Thing2D wechselte /Thing3D oder Thing/Thing3D fühlt sich an wie eine deutliche Verbesserung der Übersichtlichkeit und Verständlichkeit.

Bitte tu es.

Tbh diese Änderung würde sowieso kommen, also besser jetzt machen und dabei bleiben. Für 3D gibt es nicht so viele Tuts, also wird die Änderung jetzt weniger Schaden anrichten als in ein, zwei Jahren später.

Was die Materialien angeht, wäre es schön, eine Art Legacy-Material zu haben, das nur minimale Ressourcen verwendet, wie diffus und spiegelnd, dies wäre nützlich für 3D-Handyspiele.

Ich bin auch dafür, Dinge explizit in 3D oder 2D umzubenennen.

Wäre es nicht möglich, dass die ursprünglichen Namen als Aliase für die neuen noch existieren? Sie würden vom Editor ausgeblendet, sodass die alten Namen nicht mehr verwendet werden können (oder unter einer "veralteten" Überschrift platziert). Auf diese Weise würde alter Code noch funktionieren, ohne Änderungen und ohne zusätzliche Logik, um etwas zu konvertieren.

Eine Warnung könnte für Code hinzugefügt werden, der die veralteten Knotennamen verwendet, und dann könnten sie in 4.1 oder 4.2 entfernt werden.

Wenn es zwei Versionen eines Knotens gibt, würde ich immer das 2D/3D-Suffix anhängen.

Außerdem würde ich mich freuen, wenn Label -> TextLabel. Ich füge einen Knoten hinzu, damit ich etwas Text anzeigen kann, also gebe ich Text in die Suchleiste ein und natürlich wird nur RichTextLabel angezeigt, was mich daran erinnert, dass der Standardtextknoten eigentlich keinen Text im Namen hat.

@Janders1800 So funktioniert es jetzt, je weniger Funktionen Sie in SpatialMaterial verwenden, desto kleiner ist der erstellte Shader.

Ich bin eine 2D-Person, daher scheint es mir für Knoten mit hauptsächlich 2D-Anwendung in Ordnung, die Knotennamen ohne Suffix beizubehalten, wenn sie nicht bereits einen haben. Dies scheint für 3D-Benutzer eine schmerzhaftere Umgestaltung zu sein, aber es ist sehr sinnvoll, wenn bestimmte Knoten größtenteils nur eine 2D- oder 3D-Anwendung haben, dass sie den kürzeren Namen für ihre beabsichtigte Domäne beibehalten und an anderer Stelle ein Suffix haben. Alles andere, was vereinheitlicht werden kann, wäre schön, wenn es vereinheitlicht wäre, insbesondere Spatial .

Ich bin auch dafür, bedingungslos die Suffixe 2D / 3D zu verwenden.

Es stimmt zwar, dass es für einige Knoten wie eine verpasste Gelegenheit aussieht, "natürlichere" Namen zu haben, aber die Konsistenz gewinnt.

Was mir nicht ganz gefällt, ist, dass das StandardMaterial3D nicht-ORM ist. Mein Punkt ist, dass ORM stärker von einem Standard unterstützt wird (zumindest RM, den Sie in glTF haben).

Aber eine bessere Namensgebung kann ich noch nicht vorschlagen.

Vielleicht ist dies auch eine Gelegenheit, etwas über „Leinwand“ zu tun. Ich fand dieses Konzept manchmal etwas verwirrend.

Ich weiß, dass es schwierig ist, weil es kein 3D-Gegenstück hat: 3D-Szenen leben in Spatial Knoten, aber Leinwände können eine Mischung aus Node2D s und Control s enthalten.

Es wäre jedoch großartig, wenn wir eine Benennung definieren könnten, die es ermöglicht, CanvasItemMaterial in Material2D , während es für die "reinen" 2D- und GUI-Bereiche sinnvoll bleibt.

Ich bin nicht unbedingt gegen die Umbenennung, aber die ursprünglichen Namen machen für mich Sinn, vielleicht aufgrund meines Hintergrunds.
Die Vorgabe in Physik oder Ingenieurwesen ist "3D". Sie sagen nicht "kinematischer 3D-Körper", sondern "kinematischer Körper", es sei denn, Sie arbeiten in einem anderen Raum.
Ich bin mir jedoch sicher, dass nicht jeder den gleichen Hintergrund hat oder sogar darin einig ist, da dies schließlich eine Spiel-Engine ist und nicht streng an Physik- oder Ingenieurskonventionen gehalten werden muss.

für zukünftige Kompatibilität, in gdscript

eine gdscript-Datei...

erweitert räumlich
class_name Node3D

Und so weiter.

Haben Sie darüber nachgedacht, translation für räumliche Knoten in position umzubenennen?

@BeayemX Ich denke, dass Übersetzung ein gebräuchlicher Begriff für den 3D-Raum ist und die Position für 2D-Entwickler üblich ist: Denken:

Ich weiß nicht, ob 4.0 das Beste für Node-Namensänderungen sein wird, es wird eine Menge Dinge zu erledigen geben und es gab viele Änderungen von 2 auf 3, das bedeutet, Bücher, Videos und Kurse abzulehnen.
Selbst die Dokumentation ist nicht vollständig, mit Änderungen in der Mitte der Fertigstellung werden Korrekturen die Dinge stark verlangsamen ...

Ich bin dafür, 3D-Knoten wie hier vorgeschlagen umzubenennen. Ich weiß jedoch nicht, wie groß das Problem für Tutorial-Hersteller sein wird. Zumindest sollte es trivial sein, bestehende Codebasen umzugestalten. In C# könnten wir sogar ObsoleteAttribute im Debug-Modus missbrauchen, um es einfacher zu machen (obwohl ich nicht sicher bin, ob eine gute Idee ist):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

Ich hoffe, wir fügen Namespaces/Kategorien hinzu, wie in #18711 beschrieben. Ich möchte die C#-API in Namespaces und möglicherweise auch Assemblys unterteilen, damit Benutzer nur das auswählen können, was sie benötigen.
Mein Plan für 4.0 war, selbst eine Tabelle mit Namespaces hart zu codieren, wenn es keine andere Wahl gäbe, aber ich würde es vorziehen, wenn ich diese Informationen stattdessen von ClassDB beziehen könnte.

@eon-s Ich glaube nicht, dass es so ist ... während translation technisch gültig ist, um Koordinaten darzustellen, ist Godot die erste Engine, bei der hier ein anderer Begriff verwendet wird, ansonsten habe ich immer position gesehen translation mit Bewegung in Verbindung gebracht und steht in Konflikt mit einem anderen Begriff, der sich auf Sprache/Transformation bezieht, was es seltsam macht. Dies wurde auch in https://github.com/godotengine/godot/issues/16863 erwähnt .

Übrigens, warum planen wir, so wenig wie möglich zu brechen? Ich verstehe, warum die Leute nicht mehr Kompatibilitätsbrüche wollen, insbesondere diejenigen, die Tutorials erstellen; Aber wenn wir 4.0 nicht zum Anlass nehmen, die Kompatibilität zu unterbrechen, wann dann? #16863 sammelt bereits viele Vorschläge.

@neikeq kann nicht auf 5.0 warten? da keine neuen oder großen Features geplant sind, sonst werden die Leute aufhören, Dinge zu bauen und Kurse für einen Motor zu kaufen, der alle 1 oder 2 Jahre wichtige Teile ändert (für Video-Tutorial-Hersteller bedeutet dies, dass die ganze Arbeit neu gemacht wird) und mit ein paar Monaten Vorwarnzeit ...

Ich befürworte die Umbenennung, um ein konsistentes 2D/3D-Suffix zu haben, und stimme vielen in diesem Thread zu, dass dies aus Konsistenzgründen für alle Knoten durchgeführt werden sollte. Eine konsistente Namenskonvention ist äußerst hilfreich für jemanden, der die Engine lernt oder von der 2D-Seite zu 3D wechselt oder umgekehrt.

@eon-s Sicherlich bedeutet das Warten auf 5.0 nur, dass es noch größere Arbeiten geben wird, die aktualisiert werden müssen?

So toll Tutorials auch sind, ich würde dafür stimmen, die Engine verständlicher zu machen, anstatt sie im Interesse bestehender Tutorials verwirrend zu halten. Hoffentlich können Fixit-Skripte oder optionale Aliase (wie oben verschiedentlich diskutiert) verwendet werden, um den Upgrade-Pfad zu glätten.

Ich schätze den Unterschied bei der Benennung zwischen Node und Spatial, da Node-Knoten keine Raumkenntnisse haben, und Node, Node2D und Node3D zu verwirren. Es sei denn, Sie planen, Node loszuwerden, dann wäre es absolut sinnvoll.

Ich bin dafür, dass ich nur einen Realm 2D oder 3D habe, der ein Suffix ertragen muss. Im Moment ist es 2D und die Verwirrung zwischen 2D und 3D endet dort.

Bitte fügen Sie das 3D-Suffix nicht hinzu. Ist es wirklich die Kopfschmerzen wert für das, was es hinzufügt? Ist es die Kosten wert? alles zu aktualisieren oder veraltete Tutorials zu haben? Nicht veränderbare und veraltete YouTube-Tutorials? Es wird mehr Verwirrung bringen.

@dpalacio Ich verwende Godot nur ein paar Monate, aber ich denke, es ist klarer und prägnanter, Node3D, Node2D und Node zu verwenden, da die räumlichen Funktionen als Node3D fungieren und der Node keine Rauminformationen hat. Ich denke, das Hinzufügen eines Suffixes für 3D wird viel einfacher zu verstehen sein, da es "entgegengesetzt" genannt wird. Ich weiß, dass es nicht wirklich Gegensätze sind, aber ich weiß nicht, wie ich es besser ausdrücken soll, weil Englisch nicht meine Muttersprache ist. Put 3d versus 2d sieht für mich explizit gut aus. Ich denke, es wird für Anfänger sehr einfacher sein und noch mehr für die Leute, die den ersten Kontakt mit einer Spiel-Engine haben. Die Namespaces sind auch großartig, hauptsächlich für große Projekte und Plugins. Widersprüchliche Namen bereiten Kopfzerbrechen. Als Anfänger denke ich, dass der Kompatibilitätsbruch minimal und automatisch sein muss, da es schwierig ist, Projekte zwischen den Versionen zu wechseln. Wenn wir viele Änderungen haben, benötigen wir auch ein automatisches Konvertierungstool und eine Dokumentation dafür.

@neikeq ja, die Kategorie sollte durch den Namespace ersetzt werden und wir sollten die richtigen erstellen.

Genau das, was ich dachte, als ich Godot ausprobierte. Meine OCD sagt mir, dass es so sein sollte.

Haben Sie darüber nachgedacht, translation für räumliche Knoten in position umzubenennen?

'position' klingt eher nach einer absoluten Position als nach einer relativen Position.
Es Position zu nennen, könnte neuen Entwicklern helfen, aber irgendwann werden sie erkennen, dass es Übersetzung heißen sollte.

Ich bin mit diesem Vorschlag ziemlich am Zaun, da jemand Godot-Tutorials schreibt und Godot für meine eigenen voll ausgestatteten Projekte verwendet.

Ich bin absolut dafür, die Namen der Knoten zu ändern, um konsistent zu bleiben, und ich stimme mit anderen überein, dass Konsistenz wichtig ist, auch wenn dies die Dinge vielleicht etwas wortreicher macht. Ich würde viel lieber 3D oder 2D am Ende/Anfang von Knoten hinzufügen müssen, wenn dies in der Codebasis und Dokumentation konsistenter wird.

Hier sind einige Knoten, die ich gerne geändert sehen würde, um konsistent zu bleiben:

• MeshInstance -> MeshInstance3D (um mit MeshInstance2D konsistent zu bleiben)
• GridMap -> TileMap3D oder GridMap3D
• TileMap -> TileMap2D oder GridMap2D
• YSort -> YSort2D oder 2DSort (oder etwas, um zu zeigen, dass es für 2D ist)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (oder etwas, um es zu zeigen, ist für 3D)
• ReflectionProbe -> ReflectionProbe3D (oder etwas, um es zu zeigen, ist für 3D)
• SpatialMaterial -> PBRMaterial oder Godot3DMaterial oder StandardMaterial3D (nur Ideen)
• Label -> TextLabel (Ich stimme @MuffinManKen zu)

Hier sind meine Gedanken zu diesem Vorschlag, beginnend mit den positiven Aspekten:

Ich denke, diese Änderung wird die Dinge für diejenigen einfacher machen, die keine Godot-Erfahrung haben, aber nur für diejenigen, die nach diesen Änderungen kommen. Besonders auf der 3D-Seite ist eines der größten Probleme meiner Meinung nach, dass es schwierig sein kann, die benötigten Nodes zu finden, und ich denke, die Umbenennung der Nodes mit einem konsistenten Namensschema wird dies für alle viel einfacher machen.

Wenn ich anderen mit Godot helfe, finde ich oft eine der sichersten Möglichkeiten, eine Lösung zu finden, indem ich in der Dokumentation nachschaue. Da die Namen der Knoten jedoch nicht immer konsistent sind, kann es für bestimmte Knoten schwierig sein, die Dokumentationsseite zu finden, es sei denn, Sie kennen den Namen des gesuchten Knotens bereits. Die Änderungen in diesem Vorschlag würden das Auffinden des richtigen Knotens viel einfacher machen.

Ein weiterer Vorteil, den ich bei dieser Änderung sehen kann, ist, dass sie einen Standard für die Benennung von Knoten festlegt, was für Plugin-Ersteller und zukünftige Beiträge zur Godot Engine hilfreich sein könnte. Wenn ich zum Beispiel einen Abziehbildknoten erstelle (zum Beispiel), dann weiß ich, dass ich ihn mit dieser Änderung etwa Decal3D anstelle von nur Decal benennen sollte.
Dies kann auch bei der Benennung von GDScript/C#-definierten Klassen hilfreich sein.

Dies würde das Schreiben von Tutorials in Zukunft auch etwas einfacher machen, da Sie nicht mehr erklären müssen, dass Spatial im Grunde ein Node2D in 3D ist.

Nun zu den Negativen:

Eines der größten Probleme, die ich mit diesem Vorschlag habe, ist, dass er zu früh erscheint, insbesondere wenn man bedenkt, wie sehr Godot 3.0+ die Dinge vor nicht allzu langer Zeit geändert hat. Ich denke, nur wenige Spiele mit Godot 3.0+ sind überhaupt erschienen, und nur sehr wenige 3D-Godot-Spiele.
Viele der großen, beeindruckenden 3D-Spiele im Godot-Showcase sind immer noch nicht veröffentlicht, und eine große Änderung wie diese bedeutet, dass auch diese Projekte aktualisiert werden müssen, was einige wirklich starke 3D-Godot-Spiele weiter verzögert.

Auch Godot 3.0+ Tutorials kommen noch heraus. Vor allem auf der 3D-Seite nehmen die Dinge langsam Fahrt auf. Obwohl dies teilweise darauf zurückzuführen ist, dass die 3D-Seite von Godot in Godot 3.0+ stärker wird, befürchte ich, dass viele der Materialien, die Tutorial-Autoren erstellen (oder in Arbeit haben), plötzlich eine massive Neuformulierung benötigen, um die Namensänderungen zu berücksichtigen. Dies nimmt Zeit für die Erstellung neuer Tutorials in Anspruch, da alte Tutorials gelöscht, neu erstellt oder neu geschrieben werden müssen.

Durch die Namensänderung würden auch vorhandene Ressourcen, die keine Tutorials sind, sondern nur einfache Lösungen für Probleme, plötzlich veraltet. Während Godots 2D-Seite wohl ziemlich stark ist und sich wahrscheinlich schnell anpassen kann, ist die Community, die die 3D-Seite verwendet, merklich kleiner. Durch die Änderung der Namen der Knoten befürchte ich, dass dies Godots 3D-Benutzerwachstum und die Fähigkeit, Lösungen für 3D-bezogene Probleme zu finden, bremsen wird.

Ich stimme @eon-s zu: Können diese Änderungen nicht ein bisschen warten? Die Dinge ändern sich mit Godot 4.0 bereits ziemlich dramatisch, zumindest in der Codebasis. Ich denke, das Hinzufügen einer weiteren massiven Änderung wird die Entwicklung nur erschweren und viele Fortschritte zurücksetzen, die die Leute mit der 3D-Seite von Godot machen.

Sobald Godot 4.0 herauskommt, denke ich, dass es großartig wäre, die Knoten in Version 4.1 oder 5.0 umzubenennen, aber meiner Meinung nach wird eine weitere große Änderung wie diese meiner Meinung nach mehr schaden als helfen.

Eine Sache, die diesen Übergang verbessern könnte, ist eine Alias-/Übergangsperiode, zum Beispiel von Godot 4.0 zu Godot 4.1. Dies würde Tutorials und Ressourcen (insbesondere 3D) nicht sofort obsolet machen und jedem die Möglichkeit geben, sich an die bevorstehenden Änderungen anzupassen und gleichzeitig von den Änderungen in Godot 4.0 zu profitieren.

Die Verwendung eines Alias-/Übergangszeitraums würde es ermöglichen, kompatibilitätsbrechende Änderungen vorzunehmen, ohne plötzlich alle zu zwingen, alle auf einmal zu aktualisieren. Dies würde es auch ermöglichen, häufiger kompatibilitätsbrechende Änderungen vorzunehmen, da theoretisch ein System, das einmal für Übergänge eingerichtet ist, für zukünftige kompatibilitätsbrechende Änderungen wieder verwendet werden könnte. Dies würde die Zukunft mit den in #16863 aufgeführten Änderungen erleichtern.

TLDR: Ich bin voll und ganz für die Änderungen, ich denke, es sollte einfach warten, bis Godot 4.1 oder ein Übergangssystem/eine Übergangsperiode eingeführt werden sollte, um allen Zeit zu geben, sich an die Änderungen anzupassen.

Egal wie dieser Vorschlag ausgeht: Ich finde Godot 4.0 toll und freue mich schon drauf 🙂

@reduz Ich sage,

Ich bin kein großer Fan davon, dass alle 3D-Knoten mit "3D" enden, aber sicher, wenn alle wollen. Ich denke, dass es in Ordnung ist, verschiedene Namen beizubehalten, anstatt immer ein Suffix zu haben (z. B. TileMap und GridMap).

Ich würde "Position" statt "Übersetzung" deutlich vorziehen. Letzteres kann mit Lokalisierung & Sprachen verwechselt werden, und ersteres ist sofort klar und anfängerfreundlich. Verwendet Godot dafür aber nicht schon an den meisten Stellen "Ursprung"?

Ich stimme @neikeq auch zu, dass es sich lohnt, die Kompatibilität zu

(Übrigens, warum existiert Sprite3D, wenn es nur ein Quad-Mesh sein könnte?)

@TwistedTwigleg Lesen Sie meinen Beitrag, 3.0-Projekte werden in 4.0

Schöne Abwechslung, als Programmierer freue ich mich, den Namen für das Gegenstück möglichst symmetrisch zu sehen

Können Sie genauer erklären, was Texturen im ORM-Stil bedeuten?

@reduz ist der einzige Unterschied zwischen dem Standard-

Ich mag die Idee, frage mich aber, ob es übertrieben ist, 2 Materialtypen für eine so kleine Änderung zu haben. Könnte es stattdessen einen Umschalter geben, um zwischen 1 Texturkanal für den ORM-Modus oder 3 für den vorhandenen Stil zu wechseln, wobei ein einziges Material verwendet wird?

Ich habe auch kürzlich den Tiefen-(Höhen-)Kanal in den Alpha-Kanal meiner ORM-Maps eingefügt, um mehr Kilometer aus den Texturen herauszuholen. Dann können Sie die meisten Texturen mit nur 3 Texturen erstellen ... Albedo/Normal/ORM(H). Dies könnte sich lohnen, standardmäßig hinzuzufügen (es sei denn, wir erhalten eine 16-Bit-Option für Höhenkarten, bei denen Sie eine separate verwenden möchten). Wenn 4.0 schließlich eine Tessellation/Verschiebung erhält, wird der Höhenkanal viel wichtiger sein, als er es derzeit ist.

Apropos, es wäre auch eine gute Gelegenheit, die Benennung des DEPTH-Kanals in 4.0 auf HEIGHT zu ändern und ihn das Gegenteil von dem verwenden zu lassen, was er derzeit verwendet (dh Weiß ist eine erhabene Fläche und Schwarz ist vertieft). Dies würde es mit anderen Renderern und Game-Engines und vor allem mit Tools wie Substance, Quixel und Marmoset in Einklang bringen.

Ich würde explizite Suffixe für 2D- und 3D-Knoten bevorzugen und kein Suffix, wenn es nicht anwendbar ist. Ich möchte auch, dass die "Control" -Knoten vollständig für die "Node2D" -Knoten getrennt sind (beide sind derzeit unter "CanvasItem" gruppiert).

Ungefähr translation Vergleich zu position , ich würde mich für ersteres in 2D und 3D entscheiden.

position sieht freundlicher aus, aber es macht keinen Sinn mehr, sobald ein Vorfahre eine Rotation oder Skalierung hat.

In Bezug auf die Kompatibilität sollte die Übergangsphase für alle 4.x-Releases dauern, um Tutorials, Benutzern und Projekten genügend Zeit zu geben. Die neuen Namen sollten erstklassige Bürger sein und ermutigt werden, aber die alten sollten funktionieren, mit einem Mechanismus im Editor, um die Leute über die Änderung zu informieren.

Ich befürworte die vorgeschlagenen Änderungen absolut, solange sie so durchgeführt werden, dass es Endbenutzern leicht gemacht wird, vorhandenen Code zu aktualisieren - entweder ihren eigenen oder Code aus bestehenden Tutorials und Dokumentationen - über eine Art Tool, wie erwähnt. Ohne ein solches Tool würde ich eher zustimmen, dass wir ziemlich bald nach den großen Veränderungen in v2 zu v3 weitermachen.

@TwistedTwigleg bezüglich der Veröffentlichung von 3D-Spielen, das liegt daran, dass wir auf 4.0 und Vulcan warten

Ich würde auch die Namen von Control Knoten überprüfen ... und die Inline-Dokumentation.

Manchmal frage ich mich, was der Unterschied zwischen AcceptDialog und ConfirmationDialog , und dasselbe mit PopupPanel , PopupDialog , PopupMenu ... hoffe das hilft!

Als Tutor und Dozent für Dokumentation würde ich sagen, mach weiter! Es macht mir nichts aus, mehr Inhalte zu produzieren, wenn die Änderungen es in Zukunft für alle einfacher machen, die Engine zu erlernen und zu verstehen. Machen Sie diese Art von Änderung auch besser so schnell wie möglich.

Kommen spät zur Party, aber einige Klarstellungen, um die Dinge überschaubar zu halten:

• Bitte kommentieren Sie nur den Vorschlag zur Umbenennung von Knoten und seine technischen Auswirkungen auf die Wahrung der Kompatibilität, die Auswirkungen auf bestehende Projekte, Tutorials, Inhaltsersteller usw.
• Dies ist nicht der Ort, um bestimmte Punkte in der API zu diskutieren, die bei der Umbenennung berücksichtigt werden sollten. Wenn wir uns für diese massive Umbenennung entscheiden, werden wir die gesamte API in einer Tabelle überprüfen, um sicherzustellen, dass wir konsistente Namen haben. Für spezielle Dinge wie Methoden, Eigenschaften oder Klassen, die über das hier Besprochene hinaus umbenannt werden sollten, siehe #16863.
• @RandomShaper @fracteed @fire @reduz Bitte geben Sie die Diskussion über Standardmaterialien zu einer dedizierten Frage bewegen.

Hallo,
Warum nicht der Praxis anderer APIs folgen und einen veralteten/veralteten Dekorator für Klassen (oder sogar Methoden) erstellen, dh die alten Namen sind einfach Aliase/Zeiger auf die neuen. Dies würde alle Breaking Changes stoppen und ermöglichen, dass die Namen in Version 5 weggelassen werden, so dass weniger Leute betroffen sind oder es sogar bemerken.

Die Verwendung eines Dekorateurs kann auch zwei weitere Vorteile bieten:

1. Die IDE könnte dieses Tag leicht aufnehmen und im Knotenauswahlfenster anzeigen, zB anstatt einfach 'Spatial' zu sagen, könnte es 'Spatial (obsolete use Node3D)' lesen.

2. Der Dekorator könnte dann zu einer eingebauten Warnung werden, die im Code-Editor angezeigt wird.

Außerdem hindert es niemanden daran, ein Umbenennungstool zu erstellen ...

Einige Gedanken:

Ich stimme der Umbenennung von Knoten sowie einigen Methoden und Eigenschaften (siehe aktuelle Liste in #16863) zu, um die Konsistenz zu verbessern und die API einfacher zu erlernen und zu verwenden. Es scheint eine gute Idee zu sein, die 2D / 3D-Unterscheidung klar zu machen, und wenn dies getan wird, sollte dies konsistent erfolgen (also zB auch MeshInstance3D wie erwähnt). Ich schlage vor, dass wir eine Tabelle verwenden, um alle aktuellen Nodes und ihre neuen Namen in 4.0 aufzulisten - und wir können dort über bestimmte Nodes wie TileMap/GridMap radeln. Ich werde diese Tabelle in den kommenden Tagen erstellen, wenn wir bestätigen, dass dies der richtige Weg ist.

Wir sollten uns jedoch bemühen, Kompatibilitätsbrüche so weit wie möglich zu begrenzen. Wie Juan erwähnte, können wir Kompatibilitäts-Umbenennungen in den Engine-Interna vornehmen, damit alte Szenen geladen und konvertiert werden können, aber das reicht nicht aus.

Wie @RandomShaper und @chucklepie erwähnt haben, sollten wir für alle Knoten, Methoden, Eigenschaften, Konstanten, Signale usw., die wir umbenennen, veraltete Aliase hinzufügen, mit einem Eigenschafts-Dekorator/Metadaten, die sie als veraltet signalisieren und Benutzer zum Ändern ermutigen würden ihren Code. Die Verwendung dieser Informationen in der IDE sollte es Benutzern ermöglichen, 3.x-Tutorials in 4.0 ohne Probleme zu folgen, während sie gleichzeitig leicht die neuen Namen lernen.

Dazu benötigen wir Hilfsmethoden, mit denen wir beim Registrieren von Bindungen veraltete Aliase definieren können. #23023 ist ein erster Versuch, eine solche Schnittstelle hinzuzufügen, aber sie muss noch überprüft, zusammengeführt und möglicherweise erweitert werden, wenn sie für das, was wir in 4.0 benötigen, nicht ausreicht. Diese veralteten Aliase können für den gesamten 4.x-Releasezyklus beibehalten und in 5.0 entfernt werden.
Ich würde mich jeder kompatibilitätsbrechenden Umbenennung widersetzen, bis wir diese Schnittstelle gut gestaltet und zusammengeführt haben. Jeder, der daran interessiert ist, ist willkommen, diese PR auszuprobieren und bei Bedarf Änderungen vorzuschlagen.

Was das Wann betrifft, so bestehe ich darauf, dass dies jetzt der Fall ist, wenn wir die Kompatibilität jemals wieder unterbrechen wollen. Es macht keinen Sinn, auf 5.0 zu warten, da es noch mehr Inhalte überflüssig machen würde, sobald wir 5.0 erreichen, und es würde nicht helfen, Godot als stabiles Entwicklungswerkzeug darzustellen, wenn wir die Kompatibilität mit (hoffentlich) vielen großartigen Spielen in der Entwicklung mit Godot 4 brechen .x.

Godots Benutzerbasis verdoppelt sich jedes Jahr mehr oder weniger, so dass jedes Jahr, das verstreicht, ein Refactoring weniger realistisch macht, da schließlich die Trägheit einer großen Benutzerbasis die Vorteile einer Unterbrechung der Kompatibilität überwiegt. Wenn andere Engines wie Unity oder Unreal im Vergleich zu Godot relativ stabil in Bezug auf die API erscheinen, liegt das nicht daran, dass sie keine Dinge haben, die sie umgestalten oder umbenennen möchten, sondern weil sie es sich nicht leisten können. Wir können es vorerst noch, also müssen wir die Gelegenheit nutzen. Bei Godot 3.0 war es genauso und die Community kam relativ unbeschadet davon, obwohl wir einen kleinen Anteil von Benutzern haben, die an 2.1 festhalten, da sie sich eine Portierung auf 3.0 nicht leisten können. Für 4.0 sollte der Umfang dieser Änderungen hoffentlich viel geringer sein und jede Portierungsarbeit sollte unkompliziert sein, aber die Community ist in der Zwischenzeit vielfältig geworden, sodass die Auswirkungen jedes Compat-Bruchs genauso groß oder größer sein werden als bei 3.0 Begriffe des Bildes / kumulierte Benutzerbelästigung :)

Ich bin ein großer Befürworter des Brechens der Kompatibilität.
Warum es kein Problem ist: Wenn ein Entwickler sein Spiel auf einer älteren Version veröffentlicht und dann auf der älteren Version der Engine weiter entwickelt, zwingt niemand den Entwickler, auf die neue Version zu migrieren. Außerdem: immer genau zu diesem Zweck ältere Versionen zum Download anbieten.
Neue Projekte können in der neuen Version der Engine gestartet werden und dann kommt es darauf an, ob der Entwickler die Geduld hat, die Funktionsweise der Engine neu zu erlernen.
Wenn es darum geht, die Benutzerfreundlichkeit der Engine zu verbessern, sollte die Geduld beim erneuten Lernen nie ein Problem sein, wenn das Ziel darin besteht, die benutzerfreundlichste oder leistungsstärkste Engine zu werden.

Bei den Umbenennungen hilft es, die Lernkurve zu verkürzen, wenn Muster im Lernstoff vorhanden sind. Zum Beispiel Node2D vs Node3D usw. für alle anderen Knoten. Wenn es wie eine Ente aussieht, wissen Sie, wie es geht, es ist höchstwahrscheinlich eine Ente oder in diesem Fall ein Knoten.
Das menschliche Gehirn arbeitet als optimierender Quantencomputer, der lernt, indem er niedrigste Energiezustände von Systemen miteinander verbindet, um logische Pfade zwischen Ideen zu schaffen. Wenn die zu lernenden Ideen ähnlich sind, liegen ihre niedrigsten Energiezustände näher beieinander, was es einfacher macht, sie zu verbinden (und sich zu merken), was erklärt, warum es für einen Schüler einfacher ist, 3D zu verstehen, wenn ihm 2D zuvor beigebracht wurde . Wenn die Namen der Knoten die Ähnlichkeit zwischen ihnen widerspiegeln, ist es auch einfacher zu lernen und zu verstehen, wie ein neuer Typ verwendet werden sollte, wenn Wissen über einen ähnlichen Typ vorhanden ist.

Ich sage, mach weiter und refaktoriere und unterbreche die Kompatibilität, wie du es willst. Selbst wenn Sie wenige Benutzer verlieren, gewinnen Sie durch erhöhte Benutzerfreundlichkeit und reduzierte Lernkurve viel mehr.

Nehmen Sie in diesem Zusammenhang zum Beispiel Blender 2.80. Vergleichen Sie, wie es jetzt aussieht und sich verhält, mit dem, was es vorher war. Es ist eine große Änderung, die viele Entwickler zwingt, die Funktionsweise der Software neu zu erlernen. Überlegen Sie nun, wie viele Benutzer Blender hat. Im Vergleich zu Godot sind sie gigantisch, aber sie haben ihre Software trotzdem drastisch verändert. Wieso den? Denn auf lange Sicht ist es immer rentabler, die Lernkurve zu verkürzen und die Benutzerfreundlichkeit zu verbessern, auch wenn dies bedeutet, dass einige Benutzer verloren gehen, die nicht die Geduld haben, auf den neuen Workflow umzusteigen.

Alles in allem bin ich in diesem Fall nicht für einen Breaking Change.

Ich kann die Frustration über organisch gewachsene Namenskonventionen verstehen, aber ich sehe keine, die einen weitreichenden und bahnbrechenden Wandel rechtfertigen würden.

Ich bin dafür, APIs zu verwerfen, von denen wir wegkommen möchten (und diese zur Kompilierungszeit und in den Dokumenten zu kennzeichnen), aber im Idealfall würden die alten Knotennamen weiterhin wie zuvor funktionieren.

Vielleicht können wir uns in ein paar Jahren fragen, ob es an der Zeit ist, Legacy-Knotennamen einzustellen, da dies völlig schmerzlos geworden ist. Bis dahin wäre mein Vorschlag, nach Wunsch neue Namen hinzuzufügen (ich habe keine starke Meinung dazu) und zu vermeiden, die Abwärtskompatibilität zu beeinträchtigen.

@fracteed Tatsächlich ist es wahrscheinlich keine gute Idee, Tiefe in einem Kanal einer anderen Textur zu haben, da das Parallax-Mapping viele Taps auf diese Textur ausführt und jedes Mal unnötig RGB erzwingt. Wenn Sie eine einzelne Graustufentextur verwenden, komprimiert Godot sie auf die Hälfte der Größe, wodurch Sie etwas Bandbreite sparen.

Es kann auch eine gute Idee sein, einen ORM-Modus im Standardmaterial zu haben, müssen Sie dies überprüfen.

@chucklepie Das Problem ist, dass nicht alle Sprachen Klassenaliase wie typedef unterstützen. C# ist einer davon.

@reduz ah, das wusste ich nicht, gut zu wissen. Das wichtigere Thema ist, den Tiefenkanal für 4,0 auf Höhe umzustellen, also werden Sie hoffentlich in Betracht ziehen, dies zu ändern.

bearbeiten. Entschuldigung Akien, habe deinen Kommentar gerade erst gesehen, nachdem ich das gepostet habe...

@neikeq Das Problem ist, dass nicht alle Sprachen Klassenaliase wie typedef unterstützen. C# ist einer davon.

Ich weiß nicht, wie die native C++-Bibliothek implementiert wird, aber ich beziehe mich eher auf einen Mechanismus, um diese Dekoration auf der nativen C++-Ebene durchzuführen, damit es keine Rolle spielt, was die Upstream-Sprachbindung ist. Wenn dies nicht möglich ist, können die Bindungen für jede Sprache leicht an die Suite angepasst werden (zB mithilfe von Attributen in C# usw.).

@gerald1248 Lesen Sie meinen Beitrag, nirgendwo habe ich erwähnt, dass es

Ich bin ein großer Fan von

Navigation -> Nagivagion3D

umbenennen. Ich unterstütze diese Bitte!

@reduz sagte:
@TwistedTwigleg Lesen Sie meinen Beitrag, 3.0-Projekte werden in 4.0

Schade, ich habe diesen Teil des Beitrags übersehen.

Ein internes Kompatibilitätssystem würde bei der Migration helfen und bringt mich definitiv mehr auf die "Änderungsseite" des Zauns, besonders wenn es mit etwas wie #23023 kombiniert wird. Zu wissen, dass vor dieser Änderung etwas für Projekte geplant ist, ist gut zu hören und nimmt viele Bedenken, die ich bezüglich dieses Vorschlags hatte.

@Norrox sagte:
@TwistedTwigleg bezüglich der Veröffentlichung von 3D-Spielen, das liegt daran, dass wir auf 4.0 und Vulcan warten

Das ist fair.
Vor allem angesichts der Verbesserungen an der 3D-Seite von Godot, die in Godot 4.0 kommen, ist Warten bei 3D-schweren Projekten möglicherweise keine schlechte Sache.

die 3d und 2d differenzierung ist schon durchgängig klar . 3D-Knoten sind hellrot, 2D-Knoten sind blau und UI-Knoten sind grün. Es wird immer Benutzer geben, die ein Problem mit der Benennung haben. es ist ein nie endendes Problem und ein multiplikatives Problem basierend auf der Community-Größe.

in Bezug auf die vorgeschlagenen Änderungen im OP: 2D-Knoten haben bereits ein "2D"-Suffix angewendet, was _inhärent bedeutet, dass ihre Gegenstücke 3d sind_.

Ich befürworte jedoch Änderungen wie Label zu TextLabel . ( @MuffinManKen macht einen großen Punkt)

Ich unterstütze im Grunde alles hier voll und ganz, aber in Bezug auf die Frage "Sprite2D / Sprite3D" würde ich vorschlagen, Sprite als Sprite zu belassen, wenn aus keinem anderen Grund als dem 2D-Suffix eine zusätzliche Menge an Unordnung hinzugefügt wird, IMO.

Wie @girng sagt, ist die 2D / 3D - Differenzierung bereits ziemlich klar , aufgrund der Farbcodierung, so dass wir auf große Längen zu vermeiden Verwirrung nicht gehen müssen. Aus der Sicht eines Godot-Entwicklers würde ich persönlich nicht gerne -2D auf jeden nicht umbenannten Knoten in meinem Projekt heften. :D

Ist diese Farbcodierung für Menschen mit verschiedenen Formen von Farbenblindheit hilfreich?
Es ist definitiv nicht hilfreich, wenn Sie Code eingeben (im Gegensatz zum Hinzufügen von Knoten aus dem Dialogfeld).

@reduz danke für deine Antwort. Mir ist klar, dass es für eine Hauptversion ist und daher in gewissem Sinne völlig in Ordnung ist. Ich persönlich würde es vermeiden, solche Änderungen selbst für eine Hauptversion vorzunehmen, aber ich bin mir bewusst, dass Sie ein viel besseres Verständnis dafür haben, ob dies ein Problem darstellen würde oder nicht. Ich schaue mir nur den Verlauf großer Änderungen in den Hauptversionen an (z. B. Python2 zu Python3) und normalerweise würde ich lieber mit Inkonsistenz leben (oder neuen Knotennamen plus alte, veraltete Knoten). So oder so liebe ich Godot und werde es weiterhin benutzen, was auch immer es für bahnbrechende Veränderungen geben mag.

Aber andererseits können Sie auch gerne vorschlagen, ob Sie etwas expliziteres bevorzugen und alles immer 2D/3D machen.

explizit ist besser als implizit.

@girng @AlexHoratio Knoten mit einer anderen Farbe im Editor sind jedoch nicht hilfreich, wenn Sie Code schreiben. Ich denke, hier entsteht die Verwirrung.

(Ich verstehe immer noch nicht, warum Sprite3D überhaupt existieren muss, andere Engines verwenden nur Quad-Meshes für den gleichen Zweck, es wäre einfacher, wenn Sprite ausschließlich ein 2D-Begriff wäre).

@gimg , @AlexHoratio Vergiss nicht, dass 4,5% der Bevölkerung auch farbenblind sind :stuck_out_tongue:

Ich finde eine Umbenennung eine gute Idee.
Der Übergang von 2D zu 3D wird viel einfacher. Zumindest für Leute, die mit 2D beginnen (und wahrscheinlich auch umgekehrt)

Es ist klar, dass es ein Problem gibt, und die Community hält es für eine gute Idee. Ich bin einfach nur voreingenommen mit Godot und viel zu emotional verbunden. In diesem Zustand zu sein, erzeugt Gedanken, die für andere nicht wirklich sinnvoll sind, aber für mich auf eine schöne Art und Weise vollkommen Sinn machen. schwer zu erklären. Danke, dass ich meine Gedanken äußern darf

Ich würde hier dem allgemeinen Konsens zustimmen, dass es sich lohnt, sie aus Konsistenzgründen umzubenennen. Im Moment kann es den äußeren Eindruck erwecken, dass ein Satz von Knoten "erster Klasse" und der andere "zweiter Klasse" ist oder vielleicht sogar basierend auf dem ersten gehackt wurde.

Ich persönlich denke, dass Sprite -> Sprite2D ein unglückliches Opfer einer völlig rigorosen expliziten Umbenennung wäre, aber ich denke, ich kann es in jeder Szene, die ich mache, manuell in Sprite umbenennen, bis ich müde werde davon.

Ich finde es abstoßend, dass CanvasLayer und CanvasItem nicht gruppiert sind und dass sich Node2D innerhalb von CanvasItem mit Control befindet, wie andere darauf hingewiesen haben.

Ich weiß, dass @akien-mga gesagt hat, dass dies nur für die Umbenennung von Knoten gedacht ist, aber ich denke, dass hier zumindest die Debatte über position vs. translation ins Spiel kommt. Ich denke, der Zweck des Umbenennens von Knoten ist etwas flach, wenn sich ihre APIs erheblich unterscheiden (mit Ausnahme von Unterschieden zwischen Koordinatensystemen und dergleichen), also sollten sie auf jeden Fall gleich sein, was auch immer sie sind. Ich würde hier für "Position" stimmen, es gab einen Kommentar, dass dies im Vergleich zu "Übersetzung" irreführend ist. Ich würde sagen, dass "Übersetzung" irreführend ist, weil sie eine Transformation oder Bewegung impliziert, anstatt nur Koordinaten zu sein. Die Position ist intuitiv relativ, imo (Sie richten Ihre Stühle nicht in Bezug auf die Himmelsrichtungen auf, Sie tun es in Bezug auf die Wände des Raums.)

Ich denke, dass die Variablen für beide als Position benannt werden sollten, aber die translate Funktionen sollten bleiben und die move_local Funktionen in Node2D in translate_local ändern, die Dokumentation sogar nennt es übersetzen. Ich würde die Verwendung von move für die physikbezogenen Knoten beibehalten, um zwischen Physikbewegung und geometrischer Translation zu unterscheiden.

Ein Großteil der zweiten Hälfte davon ist auch für #16863 relevant

Auch @reduz , ich denke, da C# in der Engine an Funktionalität gewinnt, werden immer mehr Leute Namespaces für C# wollen, und sobald sie in C# sind, kann ich mir vorstellen, dass viele gdscript-Benutzer sie verwenden möchten und nicht die Sprache wechseln müssen für die Funktionalität. Ich denke jedoch, dass Namespaces für eine eventuelle C#-Unterstützung absolut unerlässlich sind, für gdscript sind die Vorteile viel weniger dramatisch, aber es wird Plug-and-Play-Pakete ohne Sorgen des Benutzers möglich machen.

Mir ist gerade eine Idee eingefallen, wenn dies implementiert würde, könnten wir eine Editor-Einstellung namens "Einfache Knotennamen" haben, was bedeutet, dass neu erstellten Knoten das Suffix in ihrem Namen fehlt, zum Beispiel würde das Erstellen eines neuen "Whatever2D" seine setzen name zu "Whatever", aber Skripte auf diesem Node würden immer noch "extends Everything2D" usw. sagen. Es wäre dasselbe, als würde man einen Node erstellen und ihn dann manuell umbenennen.

Dies würde das Durcheinander von "2D"- oder "3D"-Standardnamen in der Hierarchie vermeiden, wenn der Benutzer sie aktivieren möchte, aber der Code würde dennoch konsistenter und expliziter. Ohne die 3D-Knoten, die "3D" enthalten, wäre dies verwirrend, aber mit "3D" am Ende würde es standardmäßig Sinn machen.

@aaronfranke Ich denke, das ist eine ziemlich solide Idee. Es scheint ein Kompromiss zu sein, der es ermöglicht, die Codebasis konsistent und klar zu halten, während es den Benutzern ermöglicht, überschüssiges Durcheinander aus ihrer Hierarchie herauszuhalten. Ich denke, dass viele der Einwände gegen die Idee der Umbenennung eher auf die Auswirkungen auf die Hierarchien als auf die Namen selbst zurückzuführen sind.

@aaronfranke Ich würde es hassen, derjenige zu sein, der ansonsten eine vernünftige Idee verdirbt, aber unterschiedliche Knotennamen zwischen verschiedenen Systemen würden die gemeinsame Nutzung von gd-Skriptdateien unmöglich machen. Da alle Plugins als Roh-Gscript-Dateien und -Szenen exportiert werden, würden sie nicht mehr funktionieren, wenn sie auf einem System mit unterschiedlichen Node-Mappings entwickelt würden. Um dies zu vermeiden, müssten alle gdscript-Dateien und Szenendateien Knotennamen-Zuordnungen enthalten, um die Datei für das neue System zu übersetzen. Ich bin mir ziemlich sicher, dass diese Art von Overhead für @reduz ein großes Nein ist.

@aspenforest Ich glaube nicht, dass das Hinzufügen eines Mappings ein großer Aufwand wäre, aber vielleicht bin ich naiv, da ich die Architektur der Engine nicht kenne

Was man leicht aus der Idee von @aaronfranke machen könnte , ist, die Knoten beim Erstellen einfach umzubenennen. Ähnlich der bestehenden Einstellung in ProjectSettings, die neu erstellte Knotennamen in snake_case oder spine-case ändert (so würde ein neuer MeshInstance Knoten automatisch mesh_instance statt MeshInstance heißen), eine weitere Einstellung könnte für Knotensuffixe hinzugefügt werden, die das "2D"- oder "3D"-Suffix aus den Knotennamen entfernen würde (so wird ein neuer Sprite2D Knoten nur Sprite ).

Niemand hat sich jemals darüber beschwert, dass KinematicBody2D oder Particles2D und dergleichen ein unnötiges "2D"-Suffix haben, daher sehe ich nicht ein, warum wir Funktionen hinzufügen sollten, um das Hinzufügen eines "3D"-Suffixes zu umgehen auf ihren Gegenstücken... Wenn Benutzer wirklich nicht möchten, dass diese Suffixe überhaupt vorhanden sind, dann sollte dieser Vorschlag vielleicht verworfen werden, nicht aus kosmetischen Gründen mit einer Möglichkeit, Knoten in der IDE umzubenennen...

@akien-mga Dies würde nicht so sehr die neuen Knotennamen "umarbeiten", für mich ist es eher die Soße obendrauf, etwas, das nur mit einem konsistenten Namensschema nicht hackig ist. Ich möchte, dass die Suffixe vorhanden sind, wenn ich codiere, Knoten hinzufüge oder Dokumentation nachschlage. Aber sobald sie in einer Szene sind, weiß ich, was sie sind, und viele Dinge werden sowieso benutzerdefinierte Namen bekommen.

Wenn es darum ginge, die Namen konsistent zu machen und eine Editorfunktion zu bekommen, um die Namen zu ersteres wählen, aber ich denke,

Ich denke definitiv, dass das Hinzufügen der Editor-Funktion ein eigenes Problem / PR wäre, nicht etwas, das für die Aufnahme erforderlich ist.

Ich habe SpatialMaterial zunächst vermieden, weil es einen seltsamen Namen hatte. Aber es ist eine so starke Klasse. Stattdessen habe ich gerade angefangen zu lernen, wie man Shader mit triplanar zugeordneten Albedo + Ao + Normals codiert. Dann entdeckte ich, dass all meine Arbeit umsonst war, da ich all das in SpatialMaterial hätte tun und es dann in Code konvertieren und ein besseres Ergebnis erzielen können. Es braucht also einen freundlicheren Namen.

+1 für explizite 2D/3D-Namen.

Ich habe eine Frage zu einem Knoten, von dem ich annehme, dass er in Zukunft als veraltet markiert wird, und dessen Existenz ich mir vorstellen kann, dass er aus Sicht der Benennung verwirrend sein könnte. Da das neue Animationssystem weggefallen ist, haben wir jetzt zwei Knoten, einen namens AnimationTree und AnimationTreePlayer, die im Grunde keine Beziehung zueinander haben. Irgendwelche Gedanken, wie man das am besten angehen könnte?

@SaracenOne Dies ist nicht der richtige Ort, um

Es gibt ein weiteres Problem bei der Diskussion von Namensänderungen im Allgemeinen https://github.com/godotengine/godot/issues/16863

Ich hatte einen Gedanken, der wahrscheinlich den Rahmen des für 4.0 akzeptablen Compat-Bruchs sprengen würde und daher wahrscheinlich einfach nicht durchführbar / inakzeptabel ist, aber ich dachte, ich würde ihn erwähnen, um zu sehen, ob jemand mehr Erfahrung hat, als ich kommentieren möchte.

Ich stellte mir vor, dass alle diese 2D/3D-Knoten von einem einzigen Knotentyp erben könnten, der entweder 2D oder 3D ist. Die API für einen solchen Knoten würde alle Funktionen enthalten, die Sie für beide Versionen erwarten, und ihre Implementierung würde davon abhängen, ob es sich bei diesem speziellen Knoten um 2D oder 3D handelte.

Theoretisch könnte ein solches System:

1. Stellen Sie sicher, dass wir konsistente APIs zwischen 2D/3D-Gegenstücken erstellen. Dies ist meiner Meinung nach sowohl ein Vor- als auch ein Nachteil, da es trotz dieser Konsistenz Dinge geben kann, die nicht in das eine, aber in das andere aufgenommen werden müssen.
2. Erleichtern Sie die Interaktion der beiden verschiedenen Typen oder erstellen Sie benutzerdefinierte Skripte, die Sie sowohl an die 2D- als auch die 3D-Version eines Knotens anhängen möchten.

Es wäre gut, um eine Situation zu vermeiden, in der "SomeClass2D x, y und z implementiert hat, aber für SomeClass3D gibt es nichts dergleichen" und das Benennungsproblem auf andere Weise gelöst wird. Das ist wahrscheinlich aus einigen Gründen, an die ich gerade nicht denke, monumental dumm, aber ich dachte, ich werfe es da raus.

@vortexofdoom Das passiert schon. Node2D wird von allen 2D-Knoten geerbt und Spatial wird von allen 3D-Knoten geerbt. Die Frage ist, wie man alles nennt.

Und noch wichtiger, sowohl Spatial als auch Node2D erben von Node .

Ich würde sagen, es gibt immer noch etwas in der Idee von @vortexofdoom , das nicht nur von der Klassenhierarchie abgedeckt wird, aber ich kann nicht genau bestimmen, was es ist.

Ich frage mich nur: Glaubst du, dass es von Vorteil wäre, allen von Resource abgeleiteten Klassen ein - Res Suffix hinzuzufügen?

@aaronfranke Ich beziehe mich auf die Idee, EINEN von jedem Knotentyp (einfach KinematicBody oder Sprite) zu haben, und der oberste ist eine Art Node2D3D , die ihr Verhalten diktiert. Sorry, wenn das nicht gut erklärt wurde. Anstelle einer 2D-Hierarchie und einer 3D-Hierarchie hätten wir also eine 2D/3D-Hierarchie. Deshalb sagte ich, es wäre eine größere Umgestaltung, als wahrscheinlich akzeptabel ist.

Es _könnte_ funktionieren, indem die Grundtypen nicht für sich allein verwendet werden können, sondern als 2D/3D implementiert werden müssen, damit sie ein echter Knoten sind. In diesem Fall sind wir wieder bei den Knotennamen, aber die Vererbung ist mehr automatisch direkt und verwandt zwischen 2D und 3D und das Zusammenspiel zwischen den Systemen wäre noch schöner (glaube ich).

@vortexofdoom Aber tatsächlich wird nichts zwischen 2D und 3D geteilt. Sie können einige der gleichen Knotentypen und die gleichen Methodennamen haben, aber fast alle Implementierungen sind völlig unterschiedlich. Das meiste, was ich erwarten könnte, wäre eine Schnittstelle, da Ihre Idee if (is2d) { do 2d stuff } else { do 3d stuff } würde und die Codedateien doppelt so lang und ohne Nutzen sehr unlesbar machen würde.

Die Durchführbarkeit einzelner Klassen mit variablem Verhalten hängt definitiv davon ab, wie viel von der Schwerarbeit dieser 2D/3D-Knoten der obersten Ebene leisten könnte und Abstraktionen weiter nach unten senden. Die Klassen, wie sie jetzt existieren, zusammenzumischen, wäre die Mühe definitiv nicht wert, da bin ich mir sicher. Ich hätte nichts gegen die Verwendung von Schnittstellen, um die Reorganisation durchzuführen, es würde immer noch zumindest ein gewisses Maß an Standardisierung für die verschiedenen Typen erzwingen.

Die Idee entstand aus dem müßigen Wunsch, dass ich von einer allgemeinen Version eines Knotens erben könnte, damit ich in einem Projekt, in dem eine 2D- und eine 3D-Version parallel lief, nicht alles zweimal implementieren musste. Im Moment müssten Sie von node erben und etwas umwandeln, um dies in irgendeiner Weise zu tun, da node der einzige gemeinsame Vorfahre ist.

Ich denke, ein Node2D3D (ich bin mir bewusst, wie lächerlich es klingt) hätte einen gewissen Wert, wenn auch nur, um die beiden Koordinatensysteme besser miteinander spielen zu lassen, aber das nähert sich einer ganz anderen Designfrage als in diesem Thread. Tut mir leid, abgelenkt zu werden.

@RandomShaper Ich könnte definitiv den Vorteil sehen, besonders wenn wir diese einfache

Ich überlasse meine Kommentare der Nachwelt, aber ich ziehe meinen Vorschlag zugunsten eines strikten 2D/3D-Namensschemas zurück, während die Hierarchie weitgehend unverändert bleibt.

Der Grund dafür ist , dass alle Knoten Umbenennung für Benutzer verwenden alle diese Klassennamen freisetzen würde, was bedeutet , dass ich die Funktionalität implementieren könnte ich suchte durch meine eigenen Satz von Klassen wie das Erstellen KinematicBody oder CollisionObject , die relevante Funktionen abrufen und weitergeben könnten.

Aber auch außerhalb dieses Grenzfalls könnten Sie Klassen wie Area erstellen, anstatt etwas wie RoomGroup als schnelles Beispiel zu erfinden.

Ich freue mich sehr, dass darüber diskutiert wird. Ich hoffe, es wird erledigt.

Ich weiß nicht, ob es gesagt wurde, aber wenn die Dinge aus Konsistenzgründen umbenannt werden, könnte man genauso gut mit voller Konsistenz gehen (so wie es menschlich möglich ist) und auch bestimmte Methoden umbenennen.

Beispiel:

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

Was ist neben Knoten und Methoden mit Datenstrukturen? Ich gehe davon aus, dass Transform in Transform3D , um mit Transform2D , aber Basis wahrscheinlich nicht Basis3D weil es kein Basis2D da alles in Transform2D .

@RandomShaper

Ich frage mich nur: Glaubst du, dass es von Vorteil wäre, allen von Resource abgeleiteten Klassen ein - Res Suffix hinzuzufügen?

Scheint ein bisschen zu wenig für das Geld zu sein. Ich würde eher dafür stimmen, Ressourcen in meinen Vorschlag (#31054) für die Codehervorhebung aufzunehmen, tbh. Eine andere Farbe würde ihren Basistyp widerspiegeln, sobald Sie mit der Eingabe des Klassennamens fertig sind (genau wie bei integrierten Typen wie Vectors und AABB).

Was ist mit separaten Projekten in 2D und 3D.

(Auf dem Bildvorschlag, 2d durch UI und 3d durch Szene zu ersetzen).

Wenn Sie das Projekt starten, wählen Sie aus, an welchem ​​Sie arbeiten möchten.
In Klassennamen werden keine Suffixe (2D, 3D) mehr benötigt.

Auf diese Weise wird also eine Art Namespace erstellt und keine Mischungen mehr zwischen diesen Typen:

mit Godot2D;
mit Godot3D;

Wenn Sie sich in einem 3D- oder 2D-Projekt befinden - klicken Sie auf UI, Sie haben ein UI (2D)-Fenster zum Bearbeiten der GUI. Wenn Sie auf Szene klicken, befinden Sie sich in der Szene (2d oder 3d je nach Projekttyp).

Auf diese Weise behalten wir den 2D-Modus für die Benutzeroberfläche in jedem Projekt bei, aber Scene öffnet 2D- oder 3D-Fenster

In diesem Fenster sind nur Entitäten verfügbar, die sich auf den Projekttyp (2d oder 3d) beziehen oder geteilt werden, wenn sie in beiden verwendet werden

Wenn Sie sich im UI-Modus befinden, wird beim Hinzufügen eines neuen Knotens dieses Fenster nur mit Komponenten angezeigt, die sich auf die UI beziehen.
Im Szenenmodus werden keine UI-Steuerelemente angezeigt, nur Dinge, die Sie auf die Szene anwenden können

@dmitryuck Für das von Ihnen gepostete Bild ist die 2D-Schaltfläche immer erforderlich, da sogar 3D-Spiele Godots 2D-Modus für Benutzeroberflächen und ähnliches verwenden müssen. Und es ist wünschenswert, 2D und 3D sowieso mischen zu können. Technisch gesehen brauchen 2D-Spiele die 3D-Taste nicht zu verwenden, aber es ist kaum notwendig, sie auszublenden.

Ich habe oben vorgeschlagen, dass wir Knotennamen in der Hierarchie kosmetisch ändern können, um visuell unnötige Suffixe zu vermeiden, aber es wäre besser, wenn der Code immer explizit ist.

@aaronfranke Ich habe etwas

Ich denke, dass eine unterschiedliche Anzeige von Knotennamen je nach den Umständen zu Verwirrung führen würde.

Man sollte Skripte und Szenenbäume auf den ersten Blick verstehen können. Ich denke, das ist ein Muss für die Zusammenarbeit, klare Tutorials usw.

@dmitryuck Bei einigen Projekten kann es jedoch erforderlich sein, 2D und 3D zu mischen, und einige Spiele haben Benutzeroberflächen in 3D.

@Skaruts Wechsel zur 2D-Ansicht in der 3D-Szene möglich, indem eine Komponente wie in diesem Editor implementiert wird

Der UI-Modus muss natürlich in beiden Projekttypen vorhanden sein, aber es kann sich um ein separates Fenster mit speziell für die Benutzeroberfläche entwickelten Werkzeugen wie einem Raster, verbessertem Einrasten, Linealen usw. handeln.

@reduz Umbenennen ist gut, aber es sollte lange Übergangsfristen geben, z. B. von 4.0 auf 5.0, da dies viele Tutorials und Antworten von https://godotengine.org/qa veraltet

@xxmatxx Ich würde es vorziehen, wenn die Umbenennung mit einer kurzen Übergangszeit erfolgt, um das Mitschleppen der alten Namen zu stoppen.
Außerdem würde ich sicherstellen, die Änderungen gut zu dokumentieren und sicherzustellen, dass Leute, die gerade in Godot stecken, von den Änderungen wissen. Eine Warnung im Editor, die Sie darüber informiert, dass Sie die veraltete Version der Knotennamen verwenden, ist ebenfalls nützlich, falls dies von einigen vergessen wird.

Ich stimme zu, je länger es dauert, desto länger besteht die Chance, die Leute zu verwirren. Tutorials und Dokumente werden nicht sofort veraltet sein, wenn, wie @AtomaFajrovulpo vorgeschlagen, der Editor für eine Material noch zulässt, aber eine Warnung

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

und

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

Ich habe gestern festgestellt, dass Konstanten nicht alle dem gleichen Fall folgen. Zum Beispiel gibt es Color.black und Vector3.UP . Sollte das nicht für 4.0 konsistent gemacht werden?

@BenjaminNavarro Das Ändern von https://github.com/godotengine/godot/pull/14704 diskutiert

Außerdem sollte das Umbenennen von Methoden/Signalen/Konstanten in #16863 besprochen werden, da es sich bei diesem Thema speziell um Knotennamen handelt.

@Calinou Danke, ich war mir ziemlich sicher, dass es andere Probleme gibt, konnte sie aber nicht finden.

Ich würde die Umbenennung lieber in 4.0 haben und damit fertig sein, dann zu wissen, dass sie später kommen wird, nachdem das Projekt, an dem ich arbeite, stärker geworden ist.

Wenn eine Hauptversion nicht der richtige Zeitpunkt dafür ist, was dann?

SemVer: Bei gegebener Versionsnummer MAJOR.MINOR.PATCH, inkrementieren Sie:
MAJOR-Version, wenn Sie inkompatible API-Änderungen vornehmen,
MINOR-Version, wenn Sie Funktionen abwärtskompatibel hinzufügen, und
PATCH-Version, wenn Sie abwärtskompatible Fehlerkorrekturen vornehmen.

Wie weit werden Sie damit gehen?

Wird aus GridMap dann TileMap3D und Tilemap Tilemap2D zum Beispiel ?

Außerdem scheinen node2D und node3D etwas generisch zu sein, warum dann nicht Spatial2D und Spatial3D?

Ich denke, ein großer UX-Unterschied wäre auch, dass Control, node2D und Spatial, wie auch immer sie heißen werden, direkt unter node im neuen Node-Dialog zugänglich sind, obwohl node2D und Control von CanvasItem erben. Sie können ein CanvasItem sowieso nicht direkt zu einem Baum hinzufügen, daher sollte es in diesem Dialogfeld möglicherweise nicht sichtbar sein.

Und was die Methoden angeht, ist es wohl nicht nötig, ein 2D- oder 3D-Postfix hinzuzufügen, da Sie wissen, wie Sie sie nennen, oder?

Ich hoffe immer noch, einige nützliche Aktualisierungen vornehmen zu können, wie z. B. den langsamen Import von Ressourcen und die Leistungsoptimierung von GD-Skripten. Derzeit dauert es etwa eine Stunde, um 1G-Ressourcen zu importieren. Wenn Sie 10G-Ressourcen importieren, müssen Sie zwei Tage vor dem Computer sitzen und schlafen. Der Dateisystembrowser des Ressourceneditors des 700M-1G-Imports ist jetzt jedoch defekt und es wird nichts angezeigt. Dateiliste, dies können die Mängel des Editors selbst sein, daher denke ich, dass die Optimierung und Lösung der bestehenden Probleme für Godot der bessere Weg ist. Wenn ich nur 100-500M Ressourcen importieren kann, dann ist es bestimmt, dass Godot keine großen Spiele entwickeln kann. Aber mein Weg ist jetzt blockiert und ich komme nicht weiter. Hoffe, dass die nächste Version solche Probleme löst, ich wünsche Godot immer besser!

@qq715152910 Bitte kommentieren Sie keine langen Threads mit völlig unabhängigen Informationen. Jeder, der sich zu diesem Thema geäußert hat, erhält einen Ping und Ihr Kommentar hat nichts mit dem Vorschlag zur Umbenennung von Knoten zu tun. Aus diesem Grund werde ich Ihren Kommentar ausblenden.

Ich werde unsere Meinung zu einer Umbenennung abgeben, die für uns nützlich wäre (wir verwenden hauptsächlich C#)

Die Umbenennung, die wir dringend empfehlen:

1. Transform.origin -> transform.origin

(Zugriff auf eine Transformationseigenschaft in Kleinbuchstaben umwandeln)

Wieso den?
Zum Beispiel hat der Raum die Transform, auf die wir zugreifen können, aber oft schreiben wir "this.Transform.origin", um die Lesbarkeit zu verbessern. Wenn wir "Transform" in "transform" ändern, müssen wir nicht "this" all verwenden die Zeit. Das ist unsere persönliche Meinung.

1. Wir unterstützen auch die Änderung von "Label" in etwas wie "TextLabel". Oder zumindest, wenn wir beim Hinzufügen des neuen Knotens nach "Text" suchen, sollte "Label" erscheinen, da es völlig verwandt ist.

2. Auf die Konstanten für einige vordefinierte Farben sollte mit Color im Gegensatz zu Colors zugegriffen werden.

Für den Rest der vorgeschlagenen Umbenennung freuen wir uns darauf, was die Community für besser hält.

AtlasTexture -> TexturAtlas

Es heißt AtlasTexture, weil es der üblichen <Type>Texture Konvention folgt, wobei <Type> Image , Viewport , Stream , …

AtlasTexture -> TexturAtlas

Es heißt AtlasTexture, weil es der üblichen <Type>Texture Konvention folgt, wobei <Type> Image , Viewport , Stream , …

Das wird angezeigt, wenn ich "Atlas" eingebe.

Das passiert, wenn wir Texture eingeben:

Edit: Wir verstehen, warum diese Konvention. Im zweiten Screenshot ist AtlasTexture sehr weit unten mit anderen Dingen, die der <Type>Texture Konvention folgen. Danach wurde dieser Punkt aus unserem vorherigen Beitrag entfernt. Für diesen speziellen Fall ist die Autovervollständigung immer noch nicht sehr freundlich. Aber wir akzeptieren es. .

@bigmonte Die Transform Struktur wird in Godot 4.0 möglicherweise in Transform3D in Godot 4.0 umbenannt, sodass Sie this. nicht mehr benötigen, um klarzustellen, dass es sich um eine Eigenschaft handelt.

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

Auf die Konstanten für einige vordefinierte Farben sollte mit Color im Gegensatz zu Colors zugegriffen werden.

Ich bin derjenige, der das zuerst vorgeschlagen hat, und ich stimme nicht zu. Es ist besser, sie getrennt zu halten, da dies die Auffindbarkeit der statischen Mitglieder von Color (derzeit Color8 , ColorN und FromHsv ) erhöht, wenn die automatische Vervollständigung verwendet wird verschiedene IDEs. Ich erwäge auch eine Umbenennung von Color.red etc -> Colors.RED in GDScript aus Konsistenzgründen vorzuschlagen.

Übrigens, ich glaube, Sie haben nach #16863 gesucht.