저는 Godot를 1년 이상 전문적으로 사용하고 있습니다.

나는 다음을 제외하고 당신이 말한 모든 것에 동의합니다.

누군가에게는 현재 방식을 유지해야 한다고 생각합니다.

이 절호의 기회가 있으면 모든 이름을 바꾸도록 합시다. 여기에는 Sprite2D 및 MeshInstance3D가 포함됩니다.

많은 부분적인 고통스러운 리팩터보다 완전한 고통스러운 리팩터가 항상 더 좋습니다.

이름 바꾸기에 대해 말하자면: https://github.com/godotengine/godot/issues/16863

@jahd2602 개인적으로 어느 쪽이든 상관없습니다. 최악의 경우 투표할 수 있습니다.

단순히 일관성이 없다는 사실 때문에 사람들이 그것을 귀찮게하는 것을 분명히 볼 수 있지만 적어도 그들이 다수인지 소수인지는 알 수 있습니다.

@Zylann 여기에서 결정하면 여기로 옮길 것입니다.

네임스페이스에 대한 입장은 근시안적이라고 생각합니다. 일반적으로 엔진 워크플로의 관점에서 보면 이해가 되지만 도구 제작자의 관점은 무시합니다. 예를 들어 bitwes의 Godot 단위 테스트(GUT)는 업데이트 중 하나의 이름 충돌로 인해 중단되었습니다. 전용 GUT 네임스페이스를 사용하여 이를 피할 수 있었을 가능성이 있습니다.

또한 Waiting And Testing(WAT)을 위한 네임스페이스를 원하므로 다른 프레임워크(GUT.Test를 사용하는 경우 GUT)를 실행하지 않는 동안 Test(WAT.Test를 통해 액세스)와 같은 클래스 이름을 사용할 수 있습니다. 사용자의 스크립트. 하위 클래스로 사용되는 모든 스크립트가 포함된 WAT 클래스를 사용하여 여러 번 시도했지만 이는 순환 참조 지옥일 뿐입니다.

엔진 내에서 도구를 빌드하도록 권장하려면 엔진 워크플로 자체에 절대적으로 필요하지 않더라도 엔진에서 이러한 도구를 만들기 위한 도구가 필요합니다.

요약하자면, 엔진(또는 최소한 플러그인 스크립트)에서 정의할 수 있을 뿐만 아니라 액세스할 수 있는 전용 네임스페이스 시스템을 사용하면 도구 제작자가 서로를 건너뛰거나 사용하는 것이 신의 선물이 될 것입니다.

@CodeDarigan 이점이

여기에 현재 접근 방식을 선호하는 GDScript 사용자로부터 큰 불만이 없었기 때문에 원치 않는 워크플로로 강제 이동하고 빠르고 더러운 것을 빠르게 작성하기 위한 언어로 더 많은 코드를 입력할 수 있습니다. (C# 사용자는 그것을 원하는 것 같지만).

이것이 내가 스크립트 언어 바인딩을 위한 메타데이터로 존재할 수 있고 GDNative C++용으로 추가할 수도 있다는 것을 의미하는 이유입니다. 핵심 C++ 엔진에 추가하지 마십시오.

탐색 -> Nagivagion3D
오타인가요?

@nitodico 정말

@reduz @jahd2602에 동의합니다. 어떤 것이 분명하더라도 일관성을 위해 2D 또는 3D로 후위를 지정해야 합니다.

저는 여전히 Godot를 시작하고 있으며 제안된 변경 사항이 합리적으로 들립니다. 노드의 2D 또는 3D 변형에 대해 미묘하게 다른 이름을 사용하는 것은 어느 쪽이 끝이고 Thing2D로 이동하는지 배우는 동안 약간의 혼란을 야기하는 것입니다. /Thing3D 또는 Thing/Thing3D는 명확성과 이해도가 크게 개선된 것처럼 느껴집니다.

해주세요.

이 변경 사항은 어쨌든 올 것이므로 지금 수행하고 계속 유지하는 것이 좋습니다. 3d의 경우 tuts가 많지 않으므로 이제 변경 사항은 1, 2년 후보다 손상이 적습니다.

머티리얼과 관련하여 디퓨즈 및 스페큘러와 같이 최소한의 리소스만 사용하는 일종의 레거시 머티리얼이 있으면 3D 모바일 게임에 유용할 것입니다.

또한 명시적으로 3D 또는 2D로 이름을 바꾸는 것에 찬성합니다.

원래 이름이 새 이름의 별칭으로 계속 존재하도록 하는 것이 가능하지 않습니까? 편집기에서 숨겨져 이전 이름을 사용할 수 없게 됩니다(또는 "사용되지 않는" 제목 아래에 배치됨). 그런 식으로 이전 코드는 변경하지 않고 변환하기 위한 추가 논리 없이도 계속 작동합니다.

더 이상 사용되지 않는 노드 이름을 사용하는 코드에 대해 경고를 추가한 다음 4.1 또는 4.2에서 제거할 수 있습니다.

두 가지 버전의 노드가 있는 경우 항상 2D/3D 접미사를 추가합니다.

또한 Label -> TextLabel이면 기쁠 것입니다. 일부 텍스트를 표시할 수 있도록 노드를 추가하기 위해 검색 창에 텍스트를 입력합니다. 물론 표준 텍스트 노드의 이름에 실제로 Text가 없다는 것을 상기시켜 주는 RichTextLabel만 표시됩니다.

@Janders1800 그것이 지금 작동하는 방식입니다. SpatialMaterial에서 사용하는 기능이 적을수록 생성하는 셰이더가 작아집니다.

저는 2d 사람이므로 주로 2d 응용 프로그램을 사용하는 노드의 경우 접미사가 없으면 노드 이름을 접미사 없이 유지하는 것이 좋습니다. 이것은 3D 사용자에게 더 고통스러운 리팩터링처럼 보이지만 특정 노드가 의도한 도메인에 대해 더 짧은 이름을 유지하고 다른 곳에 접미사가 있는 대부분의 경우 2D 또는 3D 애플리케이션만 있는 경우에는 많은 의미가 있습니다. 통합할 수 있는 다른 모든 것, 특히 Spatial 통합된 것으로 보는 것이 좋습니다.

저도 무조건 2D / 3D 접미사를 사용하는 것을 찬성합니다.

일부 노드의 경우 더 "자연스러운" 이름을 가질 기회를 잃은 것처럼 보이지만 일관성이 승리합니다.

내가 좋아하지 않는 것은 StandardMaterial3D 가 ORM이 아닌 것입니다. 제 요점은 ORM이 표준에 의해 더 강력하게 뒷받침된다는 것입니다(적어도 RM은 glTF에 있는 것입니다).

그러나 아직 더 나은 이름을 제안할 수 없습니다.

어쩌면 이것은 '캔버스'에 대해 뭔가를 할 수 있는 기회이기도 하다. 나는 그 개념이 때때로 약간 혼란스럽다는 것을 알았다.

에 3D 대응물이 없기 때문에 어렵다는 것을 압니다. 3D 장면은 Spatial 노드에 있지만 캔버스에는 Node2D 와 Control 가 혼합되어 포함될 수 있습니다.

우리가 이름을 변경하여 허용 일부 명명 정의 할 수 있다면 그러나, 그것은 좋은 것입니다 CanvasItemMaterial 에 Material2D 은 "순수"2D와 GUI 영역에 대한 그 의미를 유지하면서.

나는 반드시 이름 변경에 반대하는 것은 아니지만 원래 이름이 나에게 의미가 있습니다. 아마도 제 배경 때문일 것입니다.
물리 또는 공학의 기본값은 "3D"입니다. 다른 공간에서 작업하지 않는 한 "3D 운동학적 몸체"라고 하지 않고 "운동학적 몸체"라고 합니다.
그러나 모든 사람이 동일한 배경을 가지고 있거나 이에 동의하는 것은 아닙니다. 이것은 결국 게임 엔진이고 물리학 또는 엔지니어링 규칙을 엄격하게 따를 필요가 없기 때문입니다.

향후 호환성을 위해 gdscript에서

gdscript 파일...

공간 확장
class_name Node3D

등등.

당신은 이름 바꾸기에 대해 생각 해본 적이 translation 하는 공간 노드에 position ?

@BeayemX 번역은 3D 공간에 대한 일반적인 용어이고 위치는 2D 개발자에게 일반적이라고 생각합니다.

4.0이 노드 이름 변경에 가장 적합한지 모르겠습니다. 처리해야 할 일이 많을 것이고 2에서 3으로 변경이 많았습니다. 즉, 책, 비디오, 코스를 사용하지 않는다는 의미입니다.
문서가 완전하지도 않고 중간에 변경이 완료되면 수정 작업으로 인해 작업 속도가 많이 느려집니다...

나는 여기에 제안된 대로 3D 노드의 이름을 바꾸는 것에 찬성합니다. 튜토리얼 제작자에게 얼마나 큰 문제가 될지 모르겠습니다. 최소한 기존 코드 기반을 리팩토링하는 것은 간단해야 합니다. C#에서는 디버그 모드에서 ObsoleteAttribute 를 남용하여 더 쉽게 만들 수도 있습니다(좋은 생각인지는 확실하지 않음).
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

#18711에서 논의된 대로 네임스페이스/카테고리를 추가하기를 바랍니다. C# API를 네임스페이스와 어셈블리로 분리하여 사용자가 필요한 것만 선택할 수 있도록 하고 싶습니다.
4.0에 대한 내 계획은 다른 선택의 여지가 없는 경우 네임스페이스 테이블을 직접 하드 코딩하는 것이지만 대신 ClassDB에서 이 정보를 얻을 수 있다면 더 좋아할 것입니다.

@eon-s 제 생각에는 그렇지 않다고 생각합니다... translation 는 기술적으로 좌표를 나타내는 데 유효하지만 Godot는 여기서 다른 용어가 사용되는 첫 번째 엔진입니다. 그렇지 않으면 항상 position 보았습니다. translation 는 움직임과 관련이 있으며 언어/변환과 관련된 다른 용어와 충돌하여 이상하게 만듭니다. 이것은 https://github.com/godotengine/godot/issues/16863 에서도 언급되었습니다.

BTW, 왜 우리는 가능한 한 적게 깰 계획입니까? 사람들이 더 많은 호환성 손상, 특히 자습서를 만드는 것을 원하지 않는 이유를 이해합니다. 그러나 우리가 4.0을 호환성을 깨는 기회로 삼지 않는다면 우리는 언제 할 것입니까? #16863은 이미 많은 제안을 모으고 있습니다.

@neikeq 5.0을 기다릴 수 없습니까? 새로운 기능이나 큰 기능이 계획되어 있지 않기 때문에 사람들은 1~2년마다(비디오 자습서 제작자의 경우 모든 작업을 다시 실행하는 것을 의미함) 몇 개월의 경고 시간과 함께 중요한 부품을 변경하는 엔진에 대한 제작 및 과정 구매를 중단할 것입니다. ...

나는 일관된 2D/3D 접미사를 갖도록 이름을 바꾸는 것에 찬성하며 일관성을 위해 모든 노드에 대해 수행되어야 한다는 이 스레드의 많은 의견에 동의합니다. 일관된 명명 규칙을 갖는 것은 엔진을 배우는 사람이나 사물의 2D 측면에서 3D로 또는 그 반대로 이동하는 사람에게 매우 유용합니다.

@eon-s 확실히 5.0이 될 때까지 기다리는 것은 업데이트가 필요한 훨씬 더 많은 작업이 있다는 것을 의미합니까?

튜토리얼이 멋진 만큼, 저는 기존 튜토리얼을 위해 혼란스럽게 하는 것보다 엔진을 더 이해하기 쉽게 만드는 데 투표할 것입니다. 수정 스크립트 또는 선택적 별칭(위에서 다양하게 논의됨)을 사용하여 업그레이드 경로를 원활하게 할 수 있기를 바랍니다.

Node 노드는 공간에 대한 지식이 없기 때문에 Node, Node2D 및 Node3D가 혼동될 수 있기 때문에 Node와 Spatial 사이의 이름 지정 차이에 감사드립니다. Node를 제거할 계획이 없다면 완전히 의미가 있습니다.

나는 접미사를 갖는 것을 견뎌야 하는 2D 또는 3D 영역을 하나만 가지고 있습니다. 현재는 2D이고 2D와 3D의 혼동은 거기서 끝입니다.

3D 접미사를 추가하지 마십시오. 그것이 추가되는 것에 대한 두통의 가치가 정말로 있습니까? 그만한 가치가 있습니까? 모든 것을 업데이트하거나 오래된 자습서를 가지고 있습니까? 수정할 수 없고 오래된 YouTube 자습서? 더 많은 혼란을 가져올 것입니다.

@dpalacio 저는 Godot를 몇 개월 동안 사용하고 있지만 Spatial이 Node3D로 작동하고 Node에 공간 정보가 없기 때문에 Node3D, Node2D, Node를 사용하는 것이 더 명확하고 간결하다고 생각합니다. 3D에 접미사를 추가하면 "반대"라는 이름이 붙기 때문에 훨씬 이해하기 쉬울 것이라고 생각합니다. 정말 반대가 아니라는 걸 알지만 영어가 모국어가 아니기 때문에 어떻게 더 잘 표현해야 할지 모르겠습니다. Put 3d 대 2d는 분명히 나에게 멋지게 보입니다. 초보자에게는 매우 쉬울 것이고 게임 엔진을 처음 접하는 사람들에게는 더욱 쉬울 것이라고 생각합니다. 네임스페이스는 주로 대규모 프로젝트 및 플러그인에 적합합니다. 충돌하는 이름은 골치 아픈 일입니다. 초보자인 저는 버전 간에 프로젝트를 계속 변경하는 것이 어렵기 때문에 호환성 손상을 최소화하고 자동으로 수행해야 한다고 생각합니다. 많은 변경 사항이 있는 경우 자동 변환 도구와 이에 대한 설명서도 필요합니다.

@neikeq 네, 카테고리는 네임스페이스로 대체되어야 하고 적절한 것을 만들어야 합니다.

내가 Godot를 시도했을 때 정확히 생각했던 것입니다. 내 OCD는 이렇게 해야 한다고 말합니다.

당신은 이름 바꾸기에 대해 생각 해본 적이 translation 하는 공간 노드에 position ?

'위치'는 상대적 위치가 아니라 절대 위치처럼 들립니다.
그것을 위치라고 부르는 것은 새로운 개발자에게 도움이 될 수 있지만 결국 그들은 그것이 번역이라고 불려야 한다는 것을 깨닫게 될 것입니다.

나는 Godot 튜토리얼을 작성하고 내 자신의 완전한 기능을 갖춘 프로젝트에 Godot를 사용하는 사람으로서 이 제안에 대해 다소 경계하고 있습니다.

나는 일관성을 유지하기 위해 노드 이름을 변경하는 것에 전적으로 찬성하며, 일관성이 중요하다는 점에 동의합니다. 코드 기반 및 문서에서 일관성을 유지한다면 노드의 끝/시작 부분에 3D 또는 2D를 추가해야 합니다.

다음은 일관성을 유지하기 위해 변경되었으면 하는 몇 가지 노드입니다.

• MeshInstance -> MeshInstance3D ( MeshInstance2D 와 일관성 유지)
• GridMap -> TileMap3D 또는 GridMap3D
• TileMap -> TileMap2D 또는 GridMap2D
• YSort -> YSort2D 또는 2DSort (또는 2D용으로 표시할 항목)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (또는 3D용임을 보여줄 것)
• ReflectionProbe -> ReflectionProbe3D (또는 3D용임을 보여줄 것)
• SpatialMaterial -> PBRMaterial 또는 Godot3DMaterial 또는 StandardMaterial3D (아이디어만)
• Label -> TextLabel (나는 @MuffinManKen에 동의합니다)

다음은 긍정적인 부분부터 시작하여 이 제안에 대한 제 생각입니다.

이번 변경으로 Godot 경험이 없으신 분들도 쉽게 하실 수 있을 거라 생각합니다만, 이러한 변경 이후에 오시는 분들만 가능합니다. 특히 3D 측면에서 내가 찾은 가장 큰 문제 중 하나는 필요한 노드를 찾기가 어려울 수 있다는 것입니다. 일관된 명명 체계를 사용하여 노드 이름을 변경하면 모든 사람이 훨씬 쉽게 할 수 있다고 생각합니다.

내가 Godot로 다른 사람들을 도울 때 많은 경우, 해결책을 찾는 가장 확실한 방법 중 하나는 문서를 보는 것입니다. 그러나 노드의 이름이 항상 일치하는 것은 아니므로 찾고 있는 노드의 이름을 이미 알고 있지 않는 한 특정 노드의 경우 설명서 페이지를 찾는 것이 어려울 수 있습니다. 이 제안을 변경하면 올바른 노드를 훨씬 쉽게 찾을 수 있습니다.

이 변경으로 볼 수 있는 또 다른 이점은 노드 이름 지정 방법에 대한 표준을 설정한다는 것입니다. 이는 플러그인 제작자와 향후 Godot 엔진 기여에 도움이 될 수 있습니다. 내가 (예를 들어) 데칼 노드를 만드는 중이라서 예를 들어,이 변화에 나는 그것을 같은 이름을해야 알 수 Decal3D 대신의 Decal .
이것은 또한 GDScript/C# 정의 클래스의 이름 지정에 도움이 될 수 있습니다.

이것은 또한 더 이상 Spatial 가 기본적으로 3D에서 Node2D 임을 설명할 필요가 없기 때문에 향후 튜토리얼 작성을 조금 더 쉽게 만들 것입니다.

이제 네거티브에 대해:

제가 이 제안에 대해 가지고 있는 가장 큰 문제 중 하나는 너무 빨리 보인다는 것입니다. 특히 Godot 3.0+가 얼마 전에 상황을 얼마나 많이 바꿨는지 고려할 때 그렇습니다. Godot 3.0+를 사용한 게임도 몇 개 안 나왔고, 3D Godot 게임도 거의 없는 것 같아요.
Godot 쇼케이스에 있는 크고 인상적인 3D 게임 중 상당수가 아직 출시되지 않았으며, 이와 같이 큰 변화를 일으키면 해당 프로젝트도 업데이트해야 하므로 매우 강력한 3D Godot 게임이 더 지연됩니다.

또한 Godot 3.0+ 튜토리얼이 계속 나오고 있습니다. 특히 3D 측면에서 상황이 어느 정도 견인력을 얻기 시작했습니다. 이것은 부분적으로 Godot 3.0+에서 더 강력해진 Godot의 3D 측면 때문이지만, 저는 많은 재료 튜토리얼 작성자가 만들고 있는(또는 작업 중인) 이름 변경을 설명하기 위해 갑자기 대대적인 수정이 필요할 것 같아 두렵습니다. 오래된 튜토리얼을 삭제하거나 다시 작성하거나 다시 작성해야 하므로 새 튜토리얼을 만드는 데 시간이 걸립니다.

명명 변경은 또한 튜토리얼이 아닌 기존 리소스, 문제에 대한 간단한 솔루션을 갑자기 구식으로 만듭니다. Godot의 2D 측면은 틀림없이 매우 강력하고 빠르게 적응할 수 있지만 3D 측면을 사용하는 커뮤니티는 눈에 띄게 작습니다. 노드의 이름을 변경함으로써 이것이 Godot의 3D 사용자 성장과 3D 관련 문제에 대한 솔루션을 찾는 능력을 방해할까봐 걱정됩니다.

@eon-s에 동의합니다. 이 변경 사항이 조금 기다리면 안 되나요? 적어도 코드 기반에서는 Godot 4.0과 함께 이미 상황이 상당히 극적으로 바뀌고 있습니다. 또 다른 대규모 변경을 추가하는 것은 개발을 더 어렵게 만들고 사람들이 Godot의 3D 측면에서 이루고 있는 많은 진전을 재설정할 것이라고 생각합니다.

Godot 4.0이 나오면 버전 4.1이나 5.0에서 노드 이름을 바꾸는 작업이 훌륭할 것이라고 생각하지만, 제 생각에는 이와 같은 또 다른 큰 변경을 추가하는 것이 도움보다 해가 더 많을 것이라고 생각합니다.

이 전환을 더 좋게 만들 수 있는 한 가지는 예를 들어 Godot 4.0에서 Godot 4.1로 별칭/전환 기간을 갖는 것입니다. 이것은 튜토리얼과 리소스(특히 3D)를 즉시 쓸모없게 만들지 않으며 모든 사람이 Godot 4.0의 변경으로부터 혜택을 받을 수 있는 동시에 다가오는 변경에 적응할 기회를 줄 것입니다.

별칭/전환 기간을 사용하면 갑자기 모든 사람이 한 번에 모두 업데이트하지 않고도 호환성을 깨는 변경을 수행할 수 있습니다. 또한 이론적으로 시스템이 전환을 위해 배치되면 향후 호환성 주요 변경 사항을 위해 다시 사용될 수 있기 때문에 호환성 주요 변경 사항을 더 자주 수행할 수 있습니다. 이렇게 하면 #16863에 나열된 변경 사항을 보다 쉽게 ​​진행할 수 있습니다.

TLDR: 저는 모든 변경 사항에 찬성합니다. 모든 사람이 변경 사항에 적응할 시간을 주기 위해 Godot 4.1 또는 전환 시스템/기간이 만들어질 때까지 기다려야 한다고 생각합니다.

이 제안이 어떻게 끝나든 간에: Godot 4.0은 훌륭할 거라고 생각하고 기대하고 있습니다. 🙂

@reduz 나는 그것을 위해 간다. 그리고 두 번째 @jahd2602

나는 모든 3D 노드를 "3D"로 끝내는 것을 좋아하지 않지만 모든 사람이 원한다면 확실합니다. 항상 접미사(예: TileMap 및 GridMap)를 사용하는 것보다 다른 이름을 유지하는 것이 좋다고 생각합니다.

나는 "번역"보다 "위치"를 훨씬 더 선호합니다. 후자는 현지화 및 언어와 혼동될 수 있으며 전자는 즉시 명확하고 초보자에게 친숙합니다. 그러나 Godot는 이미 대부분의 장소에서 이것을 위해 "origin"을 사용하지 않습니까?

나는 또한 새로운 프로젝트에 유익한 변화라면 호환성을 깨는 것이 가치가 있다는 @neikeq의 말에 동의합니다. 저는 개인적으로 #16863의 대부분이 구현되는 것을 보고 싶습니다.

(btw Sprite3D가 쿼드 메시일 수 있는데 왜 존재합니까?)

@TwistedTwigleg 내 게시물을 읽어

좋은 변화입니다. 프로그래머로서 상대방의 이름을 최대한 대칭적으로 보게 되어 기쁩니다.

ORM 스타일 텍스처가 무엇을 의미하는지 더 자세히 설명해 주시겠습니까?

@reduz 는 표준 공간 머티리얼과 ORM 머티리얼 사이의 유일한 차이점입니다. ORM에는 텍스처 채널이 하나만 있습니다(현재 3개가 아닌)? 스페큘러 및 승수와 같은 동일한 매개변수(금속 및 거칠기)에 계속 액세스할 수 있습니까? 자주 사용하지는 않지만 가끔 조정하는 데 사용됩니다.

아이디어는 마음에 들지만, 이렇게 작은 변화에 대해 2가지 재료 유형을 갖는 것이 과하지 않은지 궁금합니다. 대신 단일 재료를 사용하여 ORM 모드의 경우 1개의 텍스처 채널 또는 기존 스타일의 경우 3개의 텍스처 채널 간에 전환하는 토글이 있을 수 있습니까?

또한 최근에는 텍스처에서 더 많은 마일리지를 얻기 위해 ORM 맵의 알파 채널에 깊이(높이) 채널을 추가했습니다. 그런 다음 3개의 텍스처를 사용하여 대부분의 텍스처를 수행할 수 있습니다...albedo/normal/ORM(H). 이것은 기본적으로 추가할 가치가 있습니다. 4.0이 결국 테셀레이션/변위를 얻는다면 높이 채널은 현재보다 훨씬 더 중요할 것입니다.

그리고 말하자면 4.0에서 DEPTH 채널의 이름을 HEIGHT로 변경하고 현재 사용하는 것과 반대로 사용하도록 하는 것도 좋은 기회가 될 것입니다(즉, 흰색은 융기된 표면이고 검은색은 오목함). 이것은 다른 렌더러 및 게임 엔진, 그리고 더 중요한 것은 Substance, Quixel 및 Marmoset과 같은 도구와 함께 사용할 수 있습니다.

2D 및 3D 노드에 대한 명시적 접미사를 훨씬 선호하고 해당되지 않는 경우 접미사를 사용하지 않습니다. 나는 또한 "Node2D" 노드에 대해 완전히 분리된 "Control" 노드를 원합니다(둘 모두 현재 "CanvasItem" 아래에 그룹화되어 있음).

translation 대 position , 나는 2D와 3D 모두에서 전자를 택할 것입니다.

position 가 더 친숙해 보이지만 조상에 회전이나 크기가 지정되면 의미가 없어집니다.

호환성과 관련하여 전환 단계는 자습서, 사용자 및 프로젝트에 충분한 시간을 제공하기 위해 모든 4.x 릴리스에 대해 지속되어야 합니다. 새 이름은 일류 시민이어야 하고 권장되어야 하지만 이전 이름은 사람들에게 변경 사항을 알리는 일부 편집자 내 메커니즘과 함께 작동해야 합니다.

최종 사용자가 기존 코드(자신의 코드 또는 기존 자습서 및 설명서의 코드)를 쉽게 업데이트할 수 있는 방식으로 제안된 변경 사항을 언급한 대로 일종의 도구를 통해 찬성합니다. 그러한 도구가 없기 때문에 v2에서 v3으로의 큰 변화가 있은 직후에 우리가 쌓이게 될 것이라는 데 동의하는 경향이 있습니다.

@TwistedTwigleg 3d 게임 출시와 관련하여 4.0과 Vulcan을 기다리고 있기 때문입니다 😎

또한 Control 노드 이름... 및 인라인 문서도 검토합니다.

때로는 AcceptDialog 와 ConfirmationDialog 의 차이점이 무엇인지 궁금합니다. PopupPanel , PopupDialog , PopupMenu ... 희망합니다. 도움이 됩니다!

튜터이자 문서 기고자로서 저는 앞으로 나아가라고 말하고 싶습니다! 변경 사항으로 인해 향후 모든 사람이 엔진을 더 쉽게 배우고 이해할 수 있게 된다면 더 많은 콘텐츠를 제작하는 데 문제가 없습니다. 이런 종류의 변경도 최대한 빨리 하는 것이 좋습니다.

파티에 늦게 왔지만 관리할 수 있는 상태를 유지하기 위한 몇 가지 설명:

• 노드 이름 변경 제안, 호환성 유지 방법에 대한 기술적 의미, 기존 프로젝트, 튜토리얼, 콘텐츠 제작자 등에 대한 영향에 대해서만 의견을 말하십시오.
• 이것은 이름 변경을 고려해야 하는 API의 특정 사항을 논의하는 곳이 아닙니다. 이 대규모 이름 변경을 진행하기로 결정하면 스프레드시트에서 전체 API를 검토하여 이름이 일관된지 확인합니다. 여기에 설명된 것 이상으로 이름을 바꿔야 하는 메서드, 속성 또는 클래스와 같은 특정 사항은 #16863을 참조하세요.
• @RandomShaper @fracteed @fire @reduz 표준 재료에 대한 토론을 전용 문제로 옮겨주세요.

안녕하십니까,
다른 API의 관행을 따르고 클래스(또는 메서드까지)에 대해 사용되지 않는/사용되지 않는 데코레이터를 생성하지 않는 이유는 무엇입니까? 즉, 이전 이름은 단순히 새 이름에 대한 별칭/포인터입니다. 이렇게 하면 주요 변경 사항이 중지되고 버전 5에서 이름이 삭제되어 영향을 받거나 알아차릴 수 있는 사람이 줄어듭니다.

데코레이터를 사용하면 두 가지 다른 이점도 얻을 수 있습니다.

1. IDE는 이 태그를 쉽게 선택하여 노드 선택 창에 표시할 수 있습니다. 예를 들어 단순히 '공간'이라고 말하는 대신 '공간(노드 3D 사용)'을 읽을 수 있습니다.

2. 그러면 데코레이터가 코드 편집기에 표시되는 내장 경고가 될 수 있습니다.

또한 이름 바꾸기 도구를 만드는 사람을 막지 않습니다...

몇 가지 생각:

일관성을 개선하고 API를 더 쉽게 배우고 사용할 수 있도록 몇 가지 메서드 및 속성(#16863의 현재 목록 참조)과 노드 이름 변경에 동의합니다. 2D / 3D 구분을 명확하게 하는 것이 좋은 생각인 것 같습니다. 그렇게 하면 일관되게 수행해야 합니다(예: 언급한 MeshInstance3D도 마찬가지). 스프레드시트를 사용하여 모든 현재 노드와 4.0의 새 이름을 나열하는 것이 좋습니다. 그리고 TileMap/GridMap과 같은 특정 노드에 대해 거기에서 자전거를 탈 수 있습니다. 이것이 우리가 원하는 방식이라는 것이 확인되면 앞으로 이 스프레드시트를 만들겠습니다.

그러나 가능한 한 호환성 손상을 제한하기 위해 노력해야 합니다. Juan이 언급했듯이 엔진 내부에서 호환성 이름을 변경하여 이전 장면을 로드하고 변환할 수 있지만 충분하지 않습니다.

@RandomShaper 와 @chucklepie가 언급했듯이 이름을 바꾸는 모든 노드, 메서드, 속성, 상수, 신호 등에 사용되지 않는 별칭을 추가해야 합니다. 그들의 코드. IDE에서 이 정보를 사용하면 사용자가 문제 없이 4.0의 3.x 자습서를 따를 수 있으며 새로운 이름에 대해 쉽게 배울 수 있습니다.

그렇게 하려면 바인딩을 등록할 때 더 이상 사용되지 않는 별칭을 정의할 수 있는 도우미 메서드가 필요합니다. #23023은 그러한 인터페이스를 추가하려는 첫 번째 시도이지만 4.0에서 필요한 것에 충분하지 않다면 여전히 검토, 병합 및 확장이 필요합니다. 이러한 더 이상 사용되지 않는 별칭은 전체 4.x 릴리스 주기 동안 유지될 수 있으며 5.0에서 삭제됩니다.
나는 우리가 이 인터페이스를 잘 디자인하고 병합 할 때까지 호환성을 깨는 이름 변경에 반대할 것이므로, 이에 관심이 있는 사람은 누구든지 이 PR을 시도하고 필요한 경우 변경을 제안할 수 있습니다.

언제 , 나는 우리가 호환성을 다시 깨고 싶다면 지금이라고 주장합니다. 5.0을 기다리는 것은 의미가 없습니다. 5.0에 도달하면 더 많은 콘텐츠가 쓸모없게 될 것이고, Godot 4로 개발 중인 많은 훌륭한 게임과의 호환성을 깨면 Godot를 안정적인 개발 도구로 묘사하는 데 도움이 되지 않을 것입니다. .NS.

Godot의 사용자 기반은 매년 거의 두 배로 증가하므로 해가 지날수록 리팩토링이 덜 현실적이 됩니다. 결국 큰 사용자 기반의 관성이 호환성을 깨는 이점을 능가하기 때문입니다. Unity나 Unreal과 같은 다른 엔진이 Godot에 비해 API 측면에서 상대적으로 안정적으로 보인다면 리팩토링하거나 이름을 바꾸고 싶은 것이 없기 때문이 아니라 그럴 여유가 없기 때문입니다. 우리는 아직 할 수 있으므로 기회를 이용해야 합니다. 그것은 Godot 3.0에서도 마찬가지였고 커뮤니티는 비교적 상처를 받지 않고 나왔지만 3.0으로 포팅할 여유가 없기 때문에 2.1을 고수하는 사용자의 비율이 적습니다. 4.0의 경우 이러한 변경 사항의 범위가 훨씬 줄어들고 포팅 작업이 간단해야 하지만 그 동안 커뮤니티가 다양하게 성장했기 때문에 모든 호환성 손상의 영향은 3.0의 경우보다 크거나 클 것입니다. 이미지/누적 사용자 성가심의 조건:)

나는 호환성을 깨는 것을 강력히 지지합니다.
문제가 되지 않는 이유: 개발자가 게임을 이전 버전으로 출시하고 이전 버전의 엔진에서 계속 개발한다면 아무도 개발자에게 새 버전으로 마이그레이션하도록 강요하지 않습니다. 또한: 정확히 이 목적을 위해 다운로드할 수 있도록 이전 버전을 계속 제공하십시오.
새 프로젝트는 새 버전의 엔진에서 시작할 수 있으며 개발자가 엔진 작동 방법을 다시 배울 인내심이 있는지 여부에 달려 있습니다.
엔진 사용성을 향상시키는 것과 관련하여 목표가 가장 사용자 친화적이거나 강력한 엔진이 되는 것이라면 재학습에 대한 인내심이 문제가 되어서는 안 됩니다.

이름 바꾸기의 경우 학습할 자료에 패턴이 있으면 학습 곡선을 줄이는 데 도움이 됩니다. 예를 들어, Node2D 대 Node3D 등은 다른 모든 노드에 해당합니다. 오리처럼 보이면 어떻게 진행되는지 알 수 있습니다. 이 경우 오리 또는 노드일 가능성이 큽니다.
인간의 두뇌는 최적화된 양자 컴퓨터로 작동하며, 시스템의 가장 낮은 에너지 상태를 서로 연결하여 아이디어 간의 논리적 경로를 만들어 학습합니다. 학습할 아이디어가 비슷하면 가장 낮은 에너지 상태가 서로 더 가깝기 때문에 연결(및 기억)이 더 쉬워집니다. 따라서 사전에 2D를 배웠다면 학생이 3D를 더 쉽게 이해할 수 있는 이유를 설명합니다. . 노드 이름이 노드 간의 유사성을 반영하는 경우 유사한 유형에 지식이 있는 경우 새 유형을 사용하는 방법을 배우고 이해하는 것도 더 쉽습니다.

나는 당신이 원하는 방식으로 호환성을 리팩토링하고 중단하라고 말합니다. 적은 수의 사용자를 잃더라도 사용자 친화성을 높이고 학습 곡선을 줄이면 더 많은 것을 얻을 수 있습니다.

이와 관련하여 Blender 2.80을 예로 들어 보겠습니다. 이전과 지금이 어떻게 보이고 행동하는지 비교하십시오. 많은 개발자가 소프트웨어 작동 방식을 다시 배우도록 하는 주요 변경 사항입니다. 이제 블렌더가 얼마나 많은 사용자를 가지고 있는지 생각해보십시오. Godot와 비교하면 거대하지만 어쨌든 소프트웨어를 대폭 변경했습니다. 왜요? 새로운 워크플로로 전환할 인내심이 없는 일부 사용자를 잃는 것을 의미하더라도 장기적으로 학습 곡선을 줄이고 사용자 친화성을 개선하는 것이 항상 더 유리하기 때문입니다.

나는 이 경우에 획기적인 변화에 찬성하지 않습니다.

나는 유기적으로 성장한 명명 규칙에 대해 느끼는 좌절감을 이해할 수 있지만 광범위하고 획기적인 변경을 정당화하는 어떤 것도 보지 못합니다.

저는 멀리 옮기고자 하는 API를 더 이상 사용하지 않지만(컴파일 시 및 문서에서 플래그 지정) 이상적으로는 이전 노드 이름이 이전과 같이 계속 작동하는 것이 좋습니다.

아마도 몇 년 안에 완전히 고통스럽지 않게 된 레거시 노드 이름을 중단할 때가 되었는지 물을 수 있습니다. 그때까지 내 제안은 원하는 대로 새 이름을 추가하고(나는 그것에 대해 강한 의견이 없음) 이전 버전과의 호환성을 깨뜨리지 않도록 하는 것입니다.

@fratteed 실제로 다른 텍스처의 채널에 깊이를 갖는 것은 좋은 생각이 아닐 것입니다. 시차 매핑은 해당 텍스처에 많은 탭을 수행하여 매번 불필요하게 RGB를 가져오도록 하기 때문입니다. 단일 그레이스케일 텍스처를 사용하는 경우 Godot는 크기를 절반으로 압축하여 대역폭을 절약합니다.

표준 자료에 ORM 모드를 사용하는 것도 좋은 생각일 수 있으므로 확인해야 합니다.

@chucklepie 문제는 모든 언어가 typedef와 같은 클래스 별칭을 지원하지 않는다는 것입니다. C#도 그 중 하나입니다.

@reduz 아,

편집하다. 죄송합니다 Akien, 이것을 게시하고 나서야 귀하의 댓글을 보았습니다...

@neikeq 문제는 모든 언어가 typedef와 같은 클래스 별칭을 지원하지 않는다는 것입니다. C#도 그 중 하나입니다.

네이티브 C++ 라이브러리가 어떻게 구현되었는지는 모르지만 네이티브 C++ 수준에서 이 데코레이팅을 수행하여 업스트림 언어 바인딩이 무엇인지는 중요하지 않게 하는 메커니즘에 대해 더 많이 언급하고 있습니다. 이것이 가능하지 않다면 각 언어에 대한 바인딩을 제품군에 쉽게 적용할 수 있습니다(예: C#의 속성 사용 등).

@gerald1248 내 게시물을 읽으십시오. 내가 언급한 곳 어디에서도 중단될 것이라고 언급한 곳은 없습니다. 3.x에서 생성된 프로젝트는 로드 및 스크립트에서 별칭을 사용하여 계속 작동할 것입니다. 그것들을 사용하면 사용 중단 경고가 발생하지만 프로젝트는 계속 작동합니다.

나는 의 열렬한 팬이다

탐색 -> Nagivagion3D

이름을 바꿉니다. 나는 이 요청을 두 번째로!

@reduz 는 다음과
@TwistedTwigleg 내 게시물을 읽어

내 나쁜, 나는 게시물의 그 부분을 놓쳤다.

내부 호환성 시스템은 마이그레이션에 도움이 되며 특히 #23023과 같은 항목과 결합되는 경우 "변경" 측면에서 저를 더 많이 만듭니다. 이 변경 이전에 프로젝트에 대해 계획된 것이 있다는 것을 아는 것은 좋은 소식이며 이 제안에 대해 가지고 있던 많은 우려를 덜어줍니다.

@Norrox 는 다음과
@TwistedTwigleg 3d 게임 출시와 관련하여 4.0과 Vulcan을 기다리고 있기 때문입니다 😎

그것은 공정하다.
특히 Godot 4.0에서 제공되는 Godot의 3D 측면에 대한 개선 사항을 고려할 때, 3D 무거운 프로젝트에서 기다리는 것은 나쁘지 않을 수 있습니다.

3d 및 2d 차별화는 이미 일관성이 명확 합니다. 3d 노드는 밝은 빨간색, 2d 노드는 파란색, ui ​​노드는 녹색입니다. 이름 지정에 문제가 있는 사용자는 항상 있을 것입니다. 끝이 없는 문제이며 커뮤니티 규모에 따라 곱해지는 문제입니다.

OP에서 제안된 변경 사항과 관련하여: 2d 노드에는 이미 "2D" 접미사가 적용되어 있습니다. 이는 _본질적으로 해당 노드가 3d임을 의미합니다.

그러나 Label 에서 TextLabel 로의 변경에 찬성합니다. ( @MuffinManKen 은 훌륭한 지적을 합니다)

저는 기본적으로 여기에 있는 모든 것을 전적으로 지지하지만 "Sprite2D/Sprite3D" 질문과 관련하여 2D 접미사가 추가 양의 클러터(IMO)를 추가하는 것 외에 다른 이유가 없다면 Sprite를 Sprite로 남겨두는 것이 좋습니다.

@girng가 말했듯이 우리가 피할 혼란에 훌륭한 길이에 갈 필요가 없습니다 있도록 2D / 3D의 차별화는 이미 컬러 코딩으로 인해 매우 분명하다. Godot 개발자의 관점에서, 저는 개인적으로 내 프로젝트에서 이름이 바뀌지 않은 모든 노드에 -2D를 붙이는 것을 좋아하지 않을 것입니다. :NS

그 색 구분이 다양한 형태의 색맹을 가진 사람들에게 도움이 됩니까?
(대화 상자에서 노드를 추가하는 것과는 대조적으로) 코드를 입력할 때는 확실히 도움이 되지 않습니다.

@reduz 답변 감사합니다. 나는 그것이 메이저 버전을 위한 것이고 따라서 semver 의미에서 완전히 괜찮다는 것을 알고 있습니다. 개인적으로 나는 메이저 버전에 대해서도 이와 같은 변경을 피하고 싶지만 이것이 문제인지 아닌지에 대해 훨씬 더 잘 이해하고 있다는 것을 알고 있습니다. 저는 주요 버전(예: python2에서 python3으로)에 걸친 큰 변경 내역을 보고 있으며 일반적으로 불일치(또는 새 노드 이름과 더 이상 사용되지 않는 노드)를 유지하고 싶습니다. 어느 쪽이든 저는 Godot를 사랑하고 어떤 주요 변경 사항이 있더라도 계속 사용할 것입니다.

그러나 다시 말하지만, 더 명시적인 것을 선호하고 모든 것을 항상 2D/3D로 만들고 싶다면 자유롭게 제안하십시오.

명시적인 것이 암시적인 것보다 낫습니다.

@girng @AlexHoratio 편집기에서 다른 색상을 갖는 노드는 코드를 작성할 때 도움이 되지 않습니다. 여기서 혼란이 생기는 것 같아요.

(나는 여전히 Sprite3D가 존재해야 하는 이유를 전혀 알지 못합니다. 다른 엔진은 동일한 목적으로 쿼드 메시를 사용합니다. Sprite가 독점적으로 2D 용어인 경우 더 쉬울 것입니다.)

@gimg , @AlexHoratio 인구의 4.5%가 색맹이라는 것도 잊지 마세요 :stuck_out_tongue:

이름을 바꾸는 것은 좋은 생각이라고 생각합니다.
2D에서 3D로의 전환이 훨씬 쉬워집니다. 적어도 2D로 시작하는 사람들에게는 (아마도 그 반대일 수도 있음)

문제가 있는 것이 분명하고 커뮤니티에서는 좋은 생각이라고 생각합니다. 나는 Godot에 편향되어 있고 감정적으로 너무 애착이 있습니다. 이 상태에 있다는 것은 다른 사람들에게는 실제로 이해되지 않는 생각을 생성하지만, 아름다운 방식으로 나에게는 완벽하게 이해되는 생각을 생성합니다. 설명하기 어려운. 내 생각을 말할 수 있게 해주셔서 감사합니다

일관성을 위해 이름을 바꾸는 것이 가치가 있다는 일반적인 합의에 동의합니다. 지금 당장은 노드의 한 세트가 "1급"이고 다른 노드가 "2급"인 것처럼 외부적인 인상을 줄 수 있습니다.

나는 개인적으로 Sprite -> Sprite2D 이 완전히 엄격한 명시적 이름 변경의 불행한 희생자가 될 것이라고 생각하지만, 지칠 때까지 내가 만드는 모든 장면에서 항상 수동으로 Sprite로 이름을 바꿀 수 있다고 생각합니다. 그것의.

CanvasLayer 및 CanvasItem 가 그룹화되지 않고 Node2D 가 다른 사람들이 지적한 것처럼 Control이 있는 CanvasItem 내부에 있다는 것이 불쾌하다고 생각합니다.

@akien-mga가 이것이 노드의 이름 변경만을 위한 것이라고 말한 것을 알고 있지만 적어도 position vs. translation 에 대한 논쟁이 여기에서 작동한다고 생각합니다. 나는 노드 이름을 바꾸는 목적이 API가 상당히 다른 경우(좌표계 간의 차이를 제외하고) 다소 단호하다고 생각합니다. 나는 여기로 가는 길로 "포지션"에 투표할 것이다. "번역"에 비해 오해의 소지가 있다는 의견이 있었다. "변환"은 단순히 좌표가 아니라 변형 또는 이동을 의미하기 때문에 오해의 소지가 있다고 말하고 싶습니다. 위치는 직관적으로 상대적입니다(나침반 방향과 관련하여 의자를 곧게 펴지 않고 방의 벽을 기준으로 합니다).

변수 이름은 두 가지 모두에 대해 이름이 지정되어야 한다고 생각하지만 translate 함수는 그대로 있어야 하며 Node2D move_local 함수를 translate_local 로 변경하고 문서도 번역이라고 합니다. 물리 운동과 기하학적 변환을 구별하기 위해 물리 관련 노드에 move 를 계속 사용합니다.

이 후반부의 많은 부분이 #16863과도 관련이 있습니다.

또한 @reduz , 내 생각에 C#이 엔진에서 기능을 얻음에 따라 점점 더 많은 사람들이 C#용 네임스페이스를 원할 것이며, 일단 C#에 있으면 많은 gdscript 사용자가 이를 사용하고 언어를 전환할 필요가 없기를 원한다고 상상할 수 있습니다. 기능을 위해. 나는 네임스페이스가 궁극적인 C# 지원에 완전히 필수적이라고 생각합니다. gdscript의 경우 이점은 훨씬 덜 극적이지만 사용자 걱정 없이 플러그 앤 플레이 패키지를 가능하게 할 것입니다.

방금 아이디어가 떠올랐습니다. 이것이 구현되면 "단순한 노드 이름"이라는 편집기 설정을 가질 수 있습니다. 즉, 새로 생성된 노드에는 이름에 접미사가 없습니다. 예를 들어, 새로운 "Whatever2D"를 생성하면 이름을 "무엇이든"으로 지정하지만 해당 노드의 스크립트는 여전히 "확장 Whatever2D" 등으로 표시됩니다. 이는 노드를 만든 다음 수동으로 이름을 바꾸는 것과 같습니다.

이렇게 하면 사용자가 활성화하기로 선택한 경우 계층에서 "2D" 또는 "3D" 기본 이름을 보는 혼란을 피할 수 있지만 여전히 코드를 보다 일관되고 명시적으로 만듭니다. "3D"가 포함된 3D 노드가 없으면 혼란스러울 수 있지만 기본적으로 끝에 "3D"가 있는 것이 합리적입니다.

@aaronfranke 꽤

@aaronfranke 현명한 아이디어를

@aspenforest 매핑을 추가하는 것이 큰 오버헤드가 될 것이라고 생각하지 않지만 아마도 엔진의 아키텍처를 모르기 때문에 순진한 것 같습니다.

@aaronfranke 의 아이디어로 쉽게 만들 수 있는 것은 생성 시 노드의 이름을 바꾸는 것입니다. (새로운 있도록 새로 snake_case 또는 척추의 경우에 노드 이름을 생성 변경됩니다 ProjectSettings의 기존 설정과 마찬가지로 MeshInstance 노드가 자동으로 이름을 지정해야합니다 mesh_instance 대신 MeshInstance ) 다른 설정은 노드 이름에서 "2D"또는 "3D"접미사를 제거 할 것이다, 노드 접미사 추가 할 수 있습니다 (새로운 있도록 Sprite2D 노드 이름을 바로 얻을 Sprite ).

아무도 KinematicBody2D 또는 Particles2D 대해 불필요한 "2D" 접미사가 있는 것에 대해 불평하지 않았으므로 "3D" 접미사 추가를 해결하기 위해 기능을 추가해야 하는 이유를 모르겠습니다. 상대방에 대해 ... 사용자가 처음부터 이러한 접미사를 원하지 않는다면 이 제안은 폐기되어야 합니다. 외관상의 이유로 IDE에서 노드의 이름을 바꾸는 방법으로 해결하지 않아야 합니다...

@akien-mga 이것은 새 노드 이름을 "주변에 작업"하는 것이 아니라 나에게 더 많은 그레이비 소스이며 일관된 이름 지정 체계로 해킹되지 않은 것입니다. 코딩을 할 때, 노드를 추가하거나 문서를 찾을 때 접미사를 원합니다. 하지만 일단 그들이 한 장면에 들어가면 나는 그들이 무엇인지 알고 있고 어쨌든 많은 것들이 사용자 정의 이름을 갖게 될 것입니다.

이름을 일관성 있게 만드는 것과 이름을 간단하게 만드는 편집기 기능 중 하나를 선택해야 한다면 전자를 선택 하겠지만 @aaronfranke 는 이 제안에 대한 반대가 근본적으로 이해하고 있었던 것

나는 확실히 편집기 기능을 추가하는 것이 이것을 포함하는 데 필요한 것이 아니라 자체 문제/PR이 될 것이라고 생각합니다.

나는 처음에 SpatialMaterial이 이상한 이름을 가지고 있었기 때문에 피했습니다. 하지만 그만큼 강력한 클래스다. 대신 3면 매핑된 알베도+ao+노멀로 셰이더를 코딩하는 방법을 배우기 시작했습니다. 그런 다음 SpatialMaterial에서 모든 작업을 수행한 다음 코드로 변환하여 더 나은 결과를 얻을 수 있었기 때문에 내가 한 모든 작업이 헛된 것임을 알게 되었습니다. 그래서 더 친근한 이름이 필요합니다.

명시적 2D/3D 이름의 경우 +1입니다.

미래에 사용 중단으로 표시될 수 있는 노드에 대해 질문이 있습니다. 그리고 내가 상상할 수 있는 존재는 이름 지정 관점에서 혼란스러울 수 있습니다. 새 애니메이션 시스템이 삭제된 이후로 기본적으로 서로 아무런 관련이 없는 AnimationTree 및 AnimationTreePlayer라는 두 개의 노드가 있습니다. 이 문제를 해결하는 가장 좋은 방법은 무엇입니까?

@SaracenOne 그런 질문을 하기에 적당한 곳이 아닙니다. 죄송합니다. 이 스레드는 2D/3D 접미사에 대해서만 논의하기 위한 것입니다.

이름 변경에 대해 더 일반적으로 논의하기 위한 또 다른 문제가 있습니다. https://github.com/godotengine/godot/issues/16863

나는 아마도 4.0에서 허용되는 호환성 손상의 범위를 넘어설 것이라고 생각했기 때문에 아마도 단순히 실행 불가능/허용될 수 없었을 것입니다.

이 모든 2D/3D 노드가 2D 또는 3D인 단일 노드 유형에서 상속될 수 있다고 상상했습니다. 이러한 노드에 대한 API에는 두 버전에 대해 기대하는 모든 기능이 포함되며 해당 구현은 이 특정 항목이 2D인지 3D인지에 따라 달라집니다.

이론적으로 이러한 시스템은 다음을 수행할 수 있습니다.

1. 2D/3D 대응 간에 일관된 API를 만들고 있는지 확인하십시오. 이 일관성에도 불구하고 하나에는 포함할 필요가 없지만 다른 하나에는 포함할 수 있기 때문에 이것은 내가 보기에 장점이자 단점입니다.
2. 두 가지 다른 유형이 더 쉽게 상호 작용할 수 있도록 하거나 노드의 2D 및 3D 버전 모두에 첨부하려는 사용자 정의 스크립트를 작성하십시오.

"SomeClass2D에는 x, y, z가 구현되어 있지만 SomeClass3D에는 그런 것이 전혀 없는" 상황을 피하는 것이 좋으며 다른 방식으로 이름 지정 문제를 해결합니다. 이것은 내가 지금 생각하고 있지 않은 몇 가지 이유로 기념비적으로 어리석은 일이지만, 나는 그것을 버릴 것이라고 생각했습니다.

@vortexofdoom 이미 일어난 일입니다. Node2D는 모든 2D 노드에 상속되고 Spatial은 모든 3D 노드에 상속됩니다. 문제는 모든 것을 무엇이라고 부를 것인가입니다.

그리고 더 중요한 것은 Spatial 및 Node2D Node 에서 상속된다는 것입니다.

@vortexofdoom 의 아이디어에는 클래스 계층 구조에서 다루지 않는 것이 여전히 있다고 말하고 싶지만 그것이 무엇인지 정확히 결정할 수는 없습니다.

모든 Resource 파생 클래스에 - Res 접미사를 추가하는 것이 도움이 될까요?

@aaronfranke 각 유형의 노드(단순히 KinematicBody 또는 Sprite) 중 하나를 갖는 아이디어를 언급하고 있으며, 최상위 노드는 행동을 지시하는 일종의 Node2D3D 입니다. 잘 설명되지 않았다면 죄송합니다. 따라서 2D 계층 구조와 3D 계층 구조가 아니라 2D/3D 계층 구조가 있습니다. 그렇기 때문에 수용 가능한 것보다 더 큰 리팩터가 될 것이라고 말한 것입니다.

기본 유형을 자체적으로 사용할 수 없도록 _할 수_ 있지만 실제 노드가 되려면 2D/3D로 구현해야 합니다. 이 경우 노드 이름에 대해 다시 1로 돌아가지만 상속이 더 많습니다. 2D와 3D 간에 자동으로 직접 연결되고 시스템 간의 상호 작용이 여전히 더 좋을 것입니다(내 생각에).

@vortexofdoom 그러나 실제로 2D와 3D 간에 공유되는 것은 없습니다. 그들은 일부 동일한 노드 유형과 동일한 메소드 이름을 가질 수 있지만 거의 모든 구현이 완전히 다릅니다. 당신의 아이디어가 if (is2d) { do 2d stuff } else { do 3d stuff } 하고 코드 파일을 두 배나 길어서 전혀 읽을 수 없게 만들 것이기 ​​때문에 내가 기대할 수 있는 가장 공유는 인터페이스일 것입니다.

가변 동작이 있는 단일 클래스의 실현 가능성은 최상위 2D/3D 노드가 수행할 수 있는 무거운 작업의 양에 따라 확실히 달라져 추상화를 더 아래로 보냅니다. 현재 존재하는 클래스를 함께 통합하는 것은 확실히 문제의 가치가 없을 것입니다. 저는 확신합니다. 나는 재구성을 달성하기 위해 인터페이스를 사용하는 것을 신경 쓰지 않겠지만 여전히 다른 유형에 대해 적어도 어느 정도의 표준화 수준을 시행할 것입니다.

이 아이디어는 노드의 일반 버전에서 상속받을 수 있기 때문에 2D 및 3D 버전이 병렬로 실행되는 프로젝트에서 모든 것을 두 번 구현할 필요가 없었으면 하는 유휴 희망에 의해 촉발되었습니다. 노드가 유일한 공통 조상이기 때문에 지금 당장은 노드에서 상속을 받고 어떤 식으로든 그렇게 하려면 일부 캐스팅을 수행해야 합니다.

Node2D3D (나는 그것이 얼마나 우스꽝스럽게 들리는지 알고 있습니다)는 두 좌표계가 서로 더 잘 작동하도록 하는 방법일지라도 어느 정도 가치가 있다고 생각하지만 이는 완전히 다른 디자인 문제에 접근하고 있습니다. 이 스레드보다. 곁길로 빠져서 죄송합니다.

@RandomShaper 특히 간단한 이름 옵션이 있는 경우 이점을 확실히 알 수 있었습니다.

내 의견은 후손을 위해 남겨두지만, 계층 구조는 대부분 그대로 유지하면서 엄격한 2D/3D 명명 체계에 찬성하여 내 제안을 철회합니다.

그 이유는 모든 노드의 이름을 바꾸면 사용자가 사용할 수 있도록 해당 클래스 이름을 모두 확보할 수 있기 때문입니다. 즉, KinematicBody 또는 CollisionObject 과 같은 고유한 클래스 세트를 생성하여 내가 찾던 기능을 구현할 수 있습니다. 관련 기능을 가져와 전달할 수 있는

그러나 그 극단적인 경우를 제외하고도 RoomGroup 와 같은 것을 빠른 예제로 고안하는 대신 Area 와 같은 클래스를 만들 수 있습니다.

이것이 논의되고 있어 매우 기쁩니다. 나는 그것이 완료되기를 바랍니다.

그것이 말했는지는 모르지만 일관성을 위해 이름이 바뀌면 완전한 일관성 (인간적으로 가능한 한)으로 가고 특정 방법의 이름도 바꿀 수 있습니다.

예시:

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

노드와 메서드 외에도 데이터 구조는 어떻습니까? 나는 가정 Transform 로 이름이 변경됩니다 Transform3D 줄을 가진 Transform2D 있지만 Basis 아마있을 필요가 없습니다 Basis3D Transform2D 내에 모두 포함되어 있으므로 Basis2D 가 없기 때문입니다.

@RandomShaper

모든 Resource 파생 클래스에 - Res 접미사를 추가하는 것이 도움이 될까요?

가성비에 비해 양이 너무 적은 것 같습니다. 코드 강조 표시를 위한 내 제안(#31054)에 리소스를 포함하는 데 투표하고 싶습니다. tbh. 다른 색상으로 설정하면 클래스 이름 입력을 마치자마자 기본 유형이 반영됩니다(Vector 및 AABB와 같은 내장 유형과 마찬가지로).

2D와 3D로 분리된 프로젝트는 어떻습니까?

(2d를 UI로, 3d를 Scene으로 대체하는 이미지 제안).

프로젝트를 시작할 때 작업할 프로젝트를 선택합니다.
클래스 이름에 더 이상 접미사(2D, 3D)가 필요하지 않습니다.

따라서 이러한 방식으로 일종의 네임스페이스가 생성되고 이러한 유형 간에 더 이상 혼합되지 않습니다.

Godot2D 사용
Godot3D 사용하기;

3d 또는 2d 프로젝트에 있을 때 - UI를 클릭하면 편집 GUI를 위한 UI(2D) 창이 있고 장면을 클릭하면 장면에 있습니다(2d 또는 3d는 프로젝트 유형에 따라 다름).

그런 식으로 모든 프로젝트에서 UI에 대해 2d 모드를 유지하지만 Scene은 2d 또는 3d 창을 엽니다.

이 창에서는 프로젝트 유형(2d 또는 3d)과 관련된 엔터티만 사용할 수 있거나 둘 다에서 사용하는 경우 공유됩니다.

UI 모드에서 새 노드를 추가하면 이 창에는 UI와 관련된 구성 요소만 표시됩니다.
장면 모드에서 UI 컨트롤이 표시되지 않으면 장면에 적용할 수 있는 항목만 표시됩니다.

@dmitryuck 게시한 이미지의 경우 2D 버튼이 항상 필요합니다. 3D 게임도 UI 및 기타 항목에 Godot의 2D 모드를 사용해야 하기 때문입니다. 그리고 어쨌든 2D와 3D를 혼합할 수 있는 것이 바람직합니다. 기술적으로 2D 게임은 3D 버튼을 사용할 필요가 없지만 숨길 필요는 거의 없습니다.

위에서 나는 시각적으로 불필요한 접미사를 피하기 위해 계층 구조에서 노드 이름을 외관상 변경할 수 있다고 제안했지만 코드가 항상 명시적이면 더 좋습니다.

@aaronfrank 나는 이전 코멘트에서 내가 의미하는 바에 대한 약간의 광범위한 설명을 추가했습니다.

상황에 따라 노드 이름을 다르게 표시하는 것은 혼란을 가중시킬 수 있다고 생각합니다.

사람들은 첫눈에 대본과 장면 트리를 이해할 수 있어야 합니다. 협업, 명확한 튜토리얼 등을 위해 필수라고 생각합니다.

@dmitryuck 일부 프로젝트는 2D와 3D를 혼합해야 할 수 있으며 일부 게임에는 3D UI가 있습니다.

@Skaruts 는 이 편집기와 같은 구성 요소를 구현하여 3D 장면에서 2D 보기로 전환할 수 있습니다.

물론 UI 모드는 두 가지 유형의 프로젝트에 모두 존재해야 하지만 그리드, 향상된 스냅, 눈금자 등과 같이 UI를 위해 특별히 제작된 도구가 있는 별도의 창일 수 있습니다.

@reduz 이름 변경은 좋은 일이지만 예를 들어 4.0에서 5.0으로의 전환 기간이 길어야 합니다. 이는 https://godotengine.org/qa의 많은 자습서와 답변에 구식이기 때문입니다.

@xxmatxx 이름 바꾸기가 짧은 전환 기간으로 발생하여 '무엇이 될 것인가' 이전 이름을 끌지 않는 것이 좋습니다.
또한, 변경 사항을 잘 문서화하고 Godot에 막 막힌 사람들이 변경 사항에 대해 알 수 있도록 합니다. 더 이상 사용되지 않는 버전의 노드 이름을 사용하고 있음을 알려주는 편집기 내 경고는 일부 사람들이 이를 잊어버린 경우에도 유용할 것입니다.

동의합니다. 시간이 오래 걸릴수록 사람들을 혼란스럽게 할 기회가 더 길어질 것입니다. @AtomaFajrovulpo가 제안한 것처럼 편집기가 사용되지 않는 항목을 계속 허용하지만 경고를 표시하는 경우 자습서 및 문서가 즉시 구식이 되지 않습니다. 내가 생각하는이 라인을 따라 뭔가 :

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

그리고

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

나는 상수가 모두 같은 경우를 따르지 않는다는 것을 어제 발견했습니다. 예를 들어 Color.black 및 Vector3.UP 있습니다. 이것은 4.0에 대해 일관성을 유지해야 하지 않습니까?

@BenjaminNavarro 색상 상수를 대문자로 변경하는 것도 https://github.com/godotengine/godot/pull/14704 하단에서 논의되었습니다

또한 메소드/시그널/상수 이름 변경은 #16863에서 논의해야 합니다. 이 문제는 특히 노드 이름에 관한 것입니다.

@Calinou 감사합니다, 다른 문제가 있다고 확신했지만 찾을 수 없었습니다.

나는 4.0에서 이름을 바꾸고 내가 작업하고 있는 프로젝트가 더 성장한 후에 나중에 올 것이라는 것을 알고 끝내고 싶습니다.

주요 릴리스가 그것을 할 시간이 아니라면 무엇입니까?

SemVer: MAJOR.MINOR.PATCH 버전 번호가 주어지면 다음을 증가시킵니다.
호환되지 않는 API 변경 시 MAJOR 버전,
이전 버전과 호환되는 방식으로 기능을 추가하는 경우 MINOR 버전 및
이전 버전과 호환되는 버그 수정 시 PATCH 버전입니다.

이걸로 어디까지 갈까?

그러면 GridMap이 TileMap3D가 되고 Tilemap Tilemap2D가 예를 들어 됩니까?

또한 node2D와 node3D는 약간 일반적인 것처럼 보이지만 Spatial2D와 Spatial3D가 없는 이유는 무엇입니까?

UX의 큰 차이점은 이름이 무엇이든 제어, node2D 및 공간이 있고, 비록 node2D와 제어가 CanvasItem에서 상속되지만 새 노드 대화 상자의 노드 아래에서 직접 액세스할 수 있다는 것입니다. 어쨌든 CanvasItem을 트리에 직접 추가할 수 없으므로 해당 대화 상자에 표시되지 않아야 합니다.

그리고 메소드가 진행되는 한, 2D 또는 3D 접미사를 추가할 필요가 없다고 생각합니다.

느린 리소스 가져오기 및 GD 스크립트의 성능 최적화와 같은 몇 가지 유용한 업데이트를 만들 수 있기를 바랍니다. 현재 1G 리소스를 가져오는 데 약 1시간이 걸립니다. 10G 자원을 수입하면 컴퓨터 앞에 앉아 이틀을 자야 한다. 그러나 700M-1G 가져오기의 리소스 편집기 파일 시스템 브라우저가 이제 손상되어 아무 것도 표시되지 않습니다. 파일 목록, 이것은 에디터 자체의 단점일 수 있으므로 기존 문제를 최적화하고 해결하는 것이 Godot에게 더 좋은 방법이라고 생각합니다. 100~500만 자원만 수입할 수 있다면 Godot는 대형 게임을 개발할 수 없는 운명이지만 지금은 길이 막혀 앞으로 나아갈 수 없습니다. 다음 버전에서 이러한 문제가 해결되기를 바랍니다. Godot가 더 좋아지기를 바랍니다!

@qq715152910 전혀 관련없는 정보로 긴 스레드에 댓글을

우리에게 유용한 이름 변경에 대한 의견을 제시하겠습니다. (주로 C#을 사용합니다)

우리가 강력하게 제안하는 이름 변경:

1. Transform.origin -> transform.origin

(변환 속성에 대한 액세스를 소문자로 만들기)

왜요?
예를 들어 공간에는 액세스할 수 있는 Transform이 있지만 더 나은 가독성을 위해 여러 번 "this.Transform.origin"을 작성합니다. "Transform"을 "transform"으로 변경하면 "this"를 모두 사용할 필요가 없습니다. 시간. 그것은 우리의 개인적인 의견입니다.

1. "Label"을 "TextLabel"과 같은 것으로 변경하는 것도 지원합니다. 또는 적어도 새 노드를 추가할 때 "텍스트"로 검색할 때 "레이블"이 나타나야 합니다. 왜냐하면 완전히 관련이 있기 때문입니다.

2. 일부 미리 정의된 색상에 대한 상수는 Colors 아닌 Color 로 액세스해야 합니다.

제안된 이름 변경의 나머지 기간 동안 우리는 커뮤니티가 더 낫다고 생각하는 것을 기대합니다.

AtlasTexture -> TextureAtlas

는 보통 다음과 때문에이 AtlasTexture라는 것 <Type>Texture 규칙을 경우 <Type> 가 될 수 Image , Viewport , Stream ...

AtlasTexture -> TextureAtlas

는 보통 다음과 때문에이 AtlasTexture라는 것 <Type>Texture 규칙을 경우 <Type> 가 될 수 Image , Viewport , Stream ...

"Atlas"를 입력하면 이것이 표시됩니다.

Texture를 입력하면 이렇게 됩니다.

편집: 우리는 그 규칙을 이해합니다. 두 번째 스크린샷에서 AtlasTexture 는 <Type>Texture 규칙을 따르는 다른 것들과 함께 매우 웅장합니다. 그 후, 그 점은 우리의 이전 게시물에서 제거되었습니다. 이 특별한 경우에는 여전히 자동 완성 친화적이지 않습니다. 그러나 우리는 그것을 받아들입니다. .

@bigmonte Transform 구조체 는 이 문제에 따라 Godot 4.0에서 Transform3D 로 이름이 변경 될 수 있으므로, 속성임을 명확히 하기 위해 더 이상 this. 가 필요하지 않습니다.

편집: https://github.com/godotengine/godot/pull/38430

일부 predifined 색상에 대한 상수에 액세스해야합니다 Color 반대에 Colors .

나는 처음에 그것을 제안한 사람이며 강력하게 동의하지 않습니다. 에서 자동 완성을 사용할 때 Color 의 정적 멤버(현재 Color8 , ColorN 및 FromHsv )의 검색 가능성을 높이므로 별도로 유지하는 것이 좋습니다. 다양한 IDE. 또한 일관성을 위해 GDScript에서 Color.red 등 -> Colors.RED 의 이름을 바꾸는 것을 제안하는 것도 고려하고 있습니다.

그건 그렇고, 나는 당신이 # 16863을 찾고 있었던 것 같아요.