मैं पेशेवर रूप से एक वर्ष से अधिक समय से गोडोट का उपयोग करता हूं।

मैं आपके द्वारा कही गई हर बात से सहमत हूं, सिवाय इसके कि:

कुछ के लिए, मुझे लगता है कि हमें मौजूदा तरीके को बनाए रखना चाहिए

यदि हमारे पास यह सुनहरा अवसर है, तो आइए सब कुछ नाम बदलें। जिसमें Sprite2D और MeshInstance3D शामिल हैं।

यह हमेशा एक पूर्ण दर्दनाक रिफैक्टर बेहतर होता है, कई आंशिक दर्दनाक रिफैक्टर।

नाम बदलने की बात: https://github.com/godotengine/godot/issues/16863

@ jahd2602 मुझे व्यक्तिगत रूप से किसी भी तरह से कोई फर्क नहीं

मैं निश्चित रूप से लोगों को इससे परेशान सिर्फ इस तथ्य के लिए देख सकता हूं कि यह एक असंगति है, लेकिन हम कम से कम देख सकते हैं कि वे बहुसंख्यक हैं या अल्पसंख्यक।

@Zylann मुझे पता है, अगर हम यहां कुछ तय करते हैं, तो हम इसे वहां ले जाएंगे।

मुझे लगता है कि नामस्थानों के खिलाफ रुख अदूरदर्शी है। यह सामान्य रूप से इंजन वर्कफ़्लो के परिप्रेक्ष्य से समझ में आता है लेकिन यह टूलमेकर के परिप्रेक्ष्य को अनदेखा करता है। उदाहरण के लिए बिटवे द्वारा गोडोट यूनिट टेस्टिंग (जीयूटी) अपने एक अपडेट में नामकरण के विरोध के कारण टूट गया। एक संभावना है कि इसे समर्पित GUT नेमस्पेस से बचा जा सकता था।

मुझे प्रतीक्षा और परीक्षण (वाट) के लिए नामस्थान भी पसंद हैं, इसलिए मैं अन्य ढांचे (जैसे जीयूटी अगर यह जीयूटी.टेस्ट का उपयोग करना था) पर नहीं चल रहा है, तो मैं टेस्ट (वाट। टेस्ट के माध्यम से एक्सेस) जैसे क्लास नामों का उपयोग कर सकता हूं। उपयोगकर्ता की स्क्रिप्ट। मैंने कई बार एक वाट वर्ग का उपयोग करने की कोशिश की है जिसमें उपवर्गों के रूप में उपयोग की जाने वाली सभी स्क्रिप्ट शामिल हैं लेकिन यह सिर्फ एक चक्रीय संदर्भ नरक है।

यदि हमें इंजन के भीतर से उपकरण बनाने के लिए प्रोत्साहित किया जाना है, तो हमें उन उपकरणों को इंजन में बनाने के लिए उपकरणों की आवश्यकता है, भले ही वे इंजन वर्कफ़्लो के लिए बिल्कुल आवश्यक न हों।

संक्षेप में, एक समर्पित नेमस्पेस सिस्टम जिसे एक्सेस किया जा सकता है और साथ ही इंजन (या कम से कम प्लगइन स्क्रिप्ट) से परिभाषित किया जा सकता है, इसलिए टूल निर्माता एक-दूसरे के ऊपर नहीं चलते हैं या उनका उपयोग एक गॉडसेंड होगा।

@CodeDarigan मैं समझता हूं कि इसके लाभ हैं और मैं उन्हें अस्वीकार नहीं कर रहा हूं, लेकिन मैं ईमानदारी से मानता हूं कि लागत उनसे अधिक है।

इसमें जोड़ें कि हमें GDScript उपयोगकर्ताओं से कोई महत्वपूर्ण शिकायत नहीं थी, जो वर्तमान दृष्टिकोण को पसंद करते हैं, इसलिए यह उन्हें एक अवांछित वर्फक्लो के लिए मजबूर करेगा और एक ऐसी भाषा में अधिक कोड टाइप करेगा जिसका उद्देश्य केवल त्वरित और गंदी चीजें तेजी से लिखना है। (सी # उपयोगकर्ता उन्हें चाहते हैं, हालांकि)।

यही कारण है कि मेरा मतलब है कि वे स्क्रिप्ट भाषा बाइंडिंग के लिए मेटाडेटा के रूप में मौजूद हो सकते हैं, और हम उन्हें GDNative C++ के लिए भी जोड़ सकते हैं। बस उन्हें कोर सी ++ इंजन के लिए न जोड़ें।

नेविगेशन -> Nagivagion3D
क्या यह एक टाइपो है?

@nitodico वास्तव में

@reduz मैं @jahd2602 से सहमत हूं। भले ही कुछ चीजें स्पष्ट हों, निरंतरता के लिए, हमें 2D या 3D के साथ पोस्टफ़िक्स करना चाहिए।

मैं अभी भी गोडोट के साथ शुरुआत कर रहा हूं और प्रस्तावित परिवर्तन मेरे लिए समझदार हैं - एक नोड के 2 डी या 3 डी संस्करण के लिए सूक्ष्म रूप से अलग-अलग नामों का उपयोग करना कुछ ऐसा है जिससे मुझे यह जानने में थोड़ा भ्रम होता है कि कौन सा अंत ऊपर है और थिंग 2 डी पर जा रहा है /Thing3D या Thing/Thing3D स्पष्टता और बोधगम्यता में एक महत्वपूर्ण सुधार की तरह महसूस करता है।

कृपया इसे करते हैं।

Tbh यह परिवर्तन वैसे भी आएगा, इसलिए बेहतर है कि इसे अभी करें और इसके साथ बने रहें। ३डी के लिए इतने सारे टुट नहीं हैं इसलिए अब परिवर्तन एक, दो साल बाद की तुलना में कम नुकसान करेगा।

सामग्री के संबंध में यह अच्छा होगा कि किसी प्रकार की विरासत सामग्री हो जो केवल न्यूनतम संसाधनों का उपयोग करे, जैसे फैलाना और स्पेक्युलर, यह 3 डी मोबाइल गेम के लिए उपयोगी होगा।

मैं चीजों का नाम बदलकर स्पष्ट रूप से 3D या 2D करने के पक्ष में भी हूं।

क्या यह संभव नहीं होगा कि मूल नाम अभी भी नए नामों के उपनाम के रूप में मौजूद हों? वे संपादक से छिपाए जाएंगे ताकि पुराने नाम प्रयोग करने योग्य न हों (या "बहिष्कृत" शीर्षक के अंतर्गत रखे जाएं)। इस तरह पुराना कोड अभी भी काम करेगा, बिना किसी बदलाव के और कुछ भी बदलने के लिए अतिरिक्त तर्क की आवश्यकता के बिना।

पदावनत नोड नामों का उपयोग करके कोड के लिए एक चेतावनी जोड़ी जा सकती है और फिर 4.1 या 4.2 में उन्हें हटाया जा सकता है।

यदि नोड के दो संस्करण हैं तो मैं हमेशा 2D/3D प्रत्यय जोड़ूंगा।

साथ ही, मुझे खुशी होगी अगर लेबल -> टेक्स्ट लेबल। मैं एक नोड जोड़ने के लिए जाता हूं ताकि मैं कुछ टेक्स्ट दिखा सकूं, इसलिए मैं खोज बार में टेक्स्ट टाइप करता हूं और निश्चित रूप से केवल RichTextLabel दिखाता है जो मुझे याद दिलाता है कि मानक टेक्स्ट नोड में वास्तव में नाम में टेक्स्ट नहीं है।

@ Janders1800 इस तरह यह अब काम करता है, SpatialMaterial में आप जितनी कम सुविधाओं का उपयोग करते हैं, उतना ही छोटा शेडर बनाता है।

मैं एक 2d व्यक्ति हूं, इसलिए मुख्य रूप से 2d एप्लिकेशन वाले नोड्स के लिए, नोड नामों को प्रत्यय के बिना रखते हुए यदि इसमें पहले से कोई नहीं है तो मुझे ठीक लगता है। यह 3D उपयोगकर्ताओं के लिए एक अधिक दर्दनाक रिफ्लेक्टर की तरह लगता है, लेकिन यह बहुत मायने रखता है जहां कुछ नोड्स में अधिकांश भाग के लिए केवल 2d या 3D एप्लिकेशन होता है, जहां वे अपने इच्छित डोमेन के लिए छोटा नाम रखते हैं और कहीं और प्रत्यय रखते हैं। कुछ और जो एकीकृत किया जा सकता है, एकीकृत देखना अच्छा होगा, विशेष रूप से Spatial ।

मैं बिना शर्त 2D / 3D प्रत्ययों का भी उपयोग करने के पक्ष में हूं।

हालांकि यह सच है कि कुछ नोड्स के लिए यह अधिक "प्राकृतिक" नाम रखने के खोए हुए अवसर की तरह लगता है, निरंतरता जीतती है।

जो मुझे काफी पसंद नहीं है वह यह है कि StandardMaterial3D गैर-ओआरएम वाला है। मेरा मुद्दा यह है कि ओआरएम मानक द्वारा अधिक दृढ़ता से समर्थित है (कम से कम आरएम, जो आपके पास जीएलटीएफ में है)।

लेकिन मैं अभी तक बेहतर नामकरण का सुझाव नहीं दे सकता।

शायद यह भी 'कैनवास' के बारे में कुछ करने का मौका है। मुझे वह अवधारणा कई बार थोड़ी भ्रमित करने वाली लगी।

मुझे पता है कि यह मुश्किल है, क्योंकि इसका कोई 3D समकक्ष नहीं है: 3D दृश्य Spatial नोड्स में रहते हैं, लेकिन कैनवस में Node2D s और Control s का मिश्रण हो सकता है।

हालांकि, यह बहुत अच्छा होगा यदि हम कुछ नामकरण को परिभाषित कर सकें जो CanvasItemMaterial से Material2D नाम बदलने की अनुमति देता है, जबकि इसे "शुद्ध" 2D और GUI क्षेत्र के लिए सार्थक रखते हुए।

मैं जरूरी नहीं कि नाम बदलने के खिलाफ हूं, लेकिन मूल नाम मुझे समझ में आता है, शायद मेरी पृष्ठभूमि के कारण।
भौतिकी या इंजीनियरिंग में डिफ़ॉल्ट "3D" है। जब तक आप किसी अन्य स्थान पर काम नहीं कर रहे हैं, तब तक आप "3D काइनेमेटिक बॉडी" नहीं कहते हैं, आप "किनेमेटिक बॉडी" कहते हैं।
हालांकि, मुझे यकीन है कि हर किसी की पृष्ठभूमि समान नहीं है या यहां तक ​​​​कि उस पर सहमत भी नहीं है, क्योंकि यह आखिरकार गेम इंजन है और इसे भौतिकी या इंजीनियरिंग सम्मेलनों का सख्ती से पालन करने की आवश्यकता नहीं है।

भविष्य की संगतता के लिए, gdscript में

एक जीडीस्क्रिप्ट फ़ाइल...

स्थानिक का विस्तार करता है
class_name Node3D

और इसी तरह।

क्या आपने स्थानिक नोड्स के लिए position translation नाम बदलकर

@BeayemX मुझे लगता है कि अनुवाद 3D स्पेस के लिए एक सामान्य शब्द है, और 2D डेवलपर्स के लिए स्थिति सामान्य है: सोच:

मुझे नहीं पता कि 4.0 नोड नाम परिवर्तन के लिए सबसे अच्छा होगा, इससे निपटने के लिए बहुत सी चीजें होंगी और 2 से 3 तक कई बदलाव हुए, इसका मतलब किताबों, वीडियो, पाठ्यक्रमों को बहिष्कृत करना है।
यहां तक ​​कि दस्तावेज़ीकरण भी पूर्ण नहीं है, मध्य पूर्णता में परिवर्तन के साथ, सुधार चीजों को बहुत धीमा कर देंगे...

मैं यहां सुझाए गए अनुसार 3डी नोड्स का नाम बदलने के पक्ष में हूं। मुझे नहीं पता कि ट्यूटोरियल निर्माताओं के लिए यह कितनी समस्या होगी। कम से कम, मौजूदा कोड बेस को दोबारा करने के लिए यह छोटा होना चाहिए। सी # में हम इसे आसान बनाने के लिए डीबग मोड में ObsoleteAttribute का दुरुपयोग भी कर सकते हैं (सुनिश्चित नहीं है कि हालांकि एक अच्छा विचार है):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

मुझे आशा है कि हम #१८७११ में चर्चा के अनुसार नामस्थान/श्रेणियां जोड़ेंगे। मैं सी # एपीआई को नेमस्पेस और शायद असेंबली में अलग करना चाहता हूं ताकि उपयोगकर्ताओं के लिए केवल वही चुन सकें जो उन्हें चाहिए।
4.0 के लिए मेरी योजना नामस्थानों की एक तालिका को हार्ड-कोड करना था यदि कोई अन्य विकल्प नहीं था, लेकिन मैं पसंद करूंगा यदि इसके बजाय मुझे यह जानकारी ClassDB से मिल सके।

@ eon-s मुझे नहीं लगता कि यह है ... जबकि translation निर्देशांक का प्रतिनिधित्व करने के लिए तकनीकी रूप से मान्य है, गोडोट पहला इंजन है जहां मुझे यहां एक अलग शब्द का उपयोग किया जा रहा है, अन्यथा मैंने हमेशा position देखा है translation आंदोलन से जुड़ा है, और भाषा/परिवर्तन से संबंधित एक अन्य शब्द के साथ संघर्ष करता है, जो इसे अजीब बनाता है। इसका उल्लेख https://github.com/godotengine/godot/issues/16863 में भी किया गया था।

बीटीडब्ल्यू, हम जितना संभव हो उतना कम तोड़ने की योजना क्यों बना रहे हैं? मैं समझता हूं कि लोग अधिक संगतता टूटना क्यों नहीं चाहते, विशेष रूप से ट्यूटोरियल बनाने वाले; लेकिन अगर हम अनुकूलता को तोड़ने के अवसर के रूप में 4.0 नहीं लेंगे, तो हम कब जा रहे हैं? #16863 पहले से ही बहुत सारे सुझाव जमा कर रहा है।

@neikeq 5.0 की प्रतीक्षा नहीं कर सकता? चूंकि कोई नई या बड़ी सुविधाओं की योजना नहीं है, अन्यथा लोग हर 1 या 2 साल में महत्वपूर्ण भागों को बदलने वाले इंजन के लिए चीजें बनाना और खरीदना बंद कर देंगे (वीडियो ट्यूटोरियल निर्माताओं के लिए इसका मतलब है कि उनके सभी काम फिर से करें) और कुछ महीनों के चेतावनी समय के साथ ...

मैं लगातार 2D/3D प्रत्यय के नाम बदलने के पक्ष में हूं, और मैं इस सूत्र में कई लोगों से सहमत हूं कि यह सभी नोड्स के लिए स्थिरता के लिए किया जाना चाहिए। लगातार नामकरण परंपरा का होना इंजन सीखने वाले किसी व्यक्ति के लिए, या चीजों के 2D पक्ष से 3D, या इसके विपरीत जाने वाले किसी व्यक्ति के लिए अत्यंत सहायक होता है।

@ eon-s निश्चित रूप से 5.0 तक प्रतीक्षा कर रहा है, इसका मतलब है कि काम का एक बड़ा निकाय होगा जिसे अद्यतन करने की आवश्यकता है?

ट्यूटोरियल जितना अद्भुत है, मैं मौजूदा ट्यूटोरियल के लिए इसे भ्रमित करने के लिए इंजन को और अधिक समझने योग्य बनाने के लिए वोट दूंगा। उम्मीद है कि अपग्रेड पथ को सुचारू करने के लिए फिक्सिट स्क्रिप्ट या वैकल्पिक उपनाम (जैसा कि ऊपर विभिन्न रूप से चर्चा की गई है) का उपयोग किया जा सकता है।

मैं नोड और स्थानिक के बीच नामकरण में अंतर की सराहना करता हूं क्योंकि नोड नोड्स को अंतरिक्ष का कोई ज्ञान नहीं है, नोड, नोड 2 डी और नोड 3 डी होने से भ्रमित हो जाएगा। जब तक आप नोड से छुटकारा पाने की योजना नहीं बनाते हैं, तब तक यह पूरी तरह से समझ में आता है।

मैं केवल एक दायरे 2D या 3D होने के लिए एक प्रत्यय के साथ सहन करने के लिए हूं। यह इस समय 2D है और 2D और 3D के बीच का भ्रम यहीं समाप्त होता है।

कृपया 3D प्रत्यय न जोड़ें। क्या यह वास्तव में सिरदर्द के लायक है जो इसे जोड़ता है? क्या यह लागत के योग्य है? सब कुछ अपडेट करने या पुराने ट्यूटोरियल होने का? अपरिवर्तनीय और पुराने youtube ट्यूटोरियल? यह और भ्रम लाएगा।

@dpalacio मैं केवल कुछ महीनों के लिए गोडोट का उपयोग कर रहा हूं, लेकिन मुझे लगता है कि यह Node3D, Node2D, और Node का उपयोग करने के लिए अधिक स्पष्ट और संक्षिप्त है क्योंकि Node3D के रूप में स्थानिक कार्य करता है और Node में कोई स्थान जानकारी नहीं है। मुझे लगता है कि 3D के लिए प्रत्यय जोड़ने से समझने में बहुत आसान होगा क्योंकि इसे "विपरीत" नाम दिया जाएगा। मुझे पता है कि यह वास्तव में विपरीत नहीं है, लेकिन मुझे नहीं पता कि इसे बेहतर तरीके से कैसे व्यक्त किया जाए क्योंकि अंग्रेजी मेरी मूल भाषा नहीं है। 3d बनाम 2d रखो स्पष्ट रूप से मुझे बहुत अच्छा लगता है। मुझे लगता है कि शुरुआती लोगों के लिए यह बहुत आसान होगा, और उन लोगों के लिए और भी अधिक होगा जो गेम इंजन के साथ पहला संपर्क कर रहे हैं। नाम स्थान भी महान हैं, मुख्य रूप से बड़ी परियोजनाओं और प्लगइन्स के लिए। परस्पर विरोधी नाम सिरदर्द हैं। शुरुआत के रूप में, मुझे लगता है कि संगतता टूटना न्यूनतम और स्वचालित होना चाहिए क्योंकि संस्करणों के बीच बदलती परियोजनाओं को रखना मुश्किल है। यदि हमारे पास कई परिवर्तन हैं तो हमें इसके लिए एक स्वचालित रूपांतरण उपकरण और दस्तावेज़ीकरण की भी आवश्यकता होगी।

@neikeq हाँ, श्रेणी को नेमस्पेस से बदल दिया जाना चाहिए और हमें उचित बनाना चाहिए।

ठीक वही जो मैं सोच रहा था जब मैंने गोडोट की कोशिश की। मेरा ओसीडी मुझसे कहता है कि ऐसा होना चाहिए।

क्या आपने स्थानिक नोड्स के लिए position translation नाम बदलकर

'स्थिति' अधिक लगता है जैसे यह सापेक्ष स्थिति के बजाय एक पूर्ण स्थिति है।
इसे स्थिति कहने से नए डेवलपर्स को मदद मिल सकती है लेकिन अंततः उन्हें एहसास होगा कि इसे अनुवाद कहा जाना चाहिए।

मैं इस प्रस्ताव के साथ बाड़ पर हूं क्योंकि कोई गोडोट ट्यूटोरियल लिख रहा है और अपनी पूरी तरह से विशेष रुप से प्रदर्शित परियोजनाओं के लिए गोडोट का उपयोग कर रहा है।

मैं लगातार बने रहने के लिए नोड्स के नाम बदलने के पक्ष में हूं, और मैं दूसरों से सहमत हूं कि निरंतरता महत्वपूर्ण है, भले ही यह चीजों को थोड़ा अधिक चिंताजनक बना दे। अगर यह कोड बेस और दस्तावेज़ीकरण में चीजों को और अधिक सुसंगत बनाता है तो मुझे नोड्स के अंत/शुरुआत में 3 डी या 2 डी जोड़ना होगा।

यहां कुछ नोड्स दिए गए हैं जिन्हें मैं लगातार बने रहने के लिए परिवर्तित देखना चाहता हूं:

• MeshInstance -> MeshInstance3D ( MeshInstance2D अनुरूप रहने के लिए)
• GridMap -> TileMap3D या GridMap3D
• TileMap -> TileMap2D या GridMap2D
• YSort -> YSort2D या 2DSort (या इसे दिखाने के लिए कुछ 2डी के लिए है)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (या इसे दिखाने के लिए कुछ 3D के लिए है)
• ReflectionProbe -> ReflectionProbe3D (या इसे दिखाने के लिए कुछ 3D के लिए है)
• SpatialMaterial -> PBRMaterial या Godot3DMaterial या StandardMaterial3D (सिर्फ विचार)
• Label -> TextLabel (मैं @MuffinManKen से सहमत हूं)

यहाँ इस प्रस्ताव पर मेरे विचार हैं, जो सकारात्मकता से शुरू होते हैं:

मुझे लगता है कि इस बदलाव से उन लोगों के लिए चीजें आसान हो जाएंगी जिनके पास गोडोट का कोई अनुभव नहीं है, लेकिन केवल उनके लिए जो इन बदलावों के बाद आते हैं। विशेष रूप से 3D पक्ष पर, मुझे सबसे बड़ी समस्याओं में से एक यह है कि यह खोजना कठिन हो सकता है कि आपको किन नोड्स की आवश्यकता है, और मुझे लगता है कि एक सुसंगत नामकरण योजना का उपयोग करके नोड्स का नाम बदलने से सभी के लिए यह बहुत आसान हो जाएगा।

कई बार मैं गोडोट के साथ दूसरों की मदद कर रहा हूं, मुझे दस्तावेज़ीकरण में समाधान खोजने के लिए सबसे निश्चित तरीकों में से एक लगता है। हालांकि, चूंकि नोड्स के नाम हमेशा सुसंगत नहीं होते हैं, कुछ नोड्स के लिए दस्तावेज़ीकरण पृष्ठ ढूंढना मुश्किल हो सकता है जब तक कि आप पहले से ही उस नोड का नाम नहीं जानते जिसे आप ढूंढ रहे हैं। इस प्रस्ताव में बदलाव से सही नोड का पता लगाना बहुत आसान हो जाएगा।

इस परिवर्तन के साथ मैं एक और लाभ देख सकता हूं कि यह एक मानक निर्धारित करता है कि नोड्स को कैसे नामित किया जाना चाहिए, जो प्लगइन निर्माता और भविष्य के गोडोट इंजन योगदान के लिए सहायक हो सकता है। उदाहरण के लिए, यदि मैं एक डीकल नोड (उदाहरण के लिए) बना रहा हूं, तो इस परिवर्तन के साथ मुझे पता है कि मुझे इसे केवल Decal बजाय Decal3D जैसा कुछ नाम देना चाहिए।
यह GDScript/C# परिभाषित कक्षाओं के नामकरण में भी मदद कर सकता है।

यह भविष्य में ट्यूटोरियल लेखन को थोड़ा आसान बना देगा, क्योंकि अब आपको यह समझाने की ज़रूरत नहीं है कि Spatial मूल रूप से 3D में Node2D है।

अब नकारात्मक के लिए:

इस प्रस्ताव के साथ मेरे पास सबसे बड़ा मुद्दा यह है कि यह बहुत जल्द लगता है, विशेष रूप से यह देखते हुए कि गोडोट 3.0+ ने बहुत पहले ही कितनी चीजें बदल दी हैं। मुझे लगता है कि गोडोट 3.0+ का उपयोग करने वाले कुछ ही गेम सामने आए हैं, और बहुत कम 3डी गोडोट गेम।
गोडोट शोकेस में बहुत सारे बड़े, प्रभावशाली 3डी गेम अभी भी जारी नहीं किए गए हैं, और इस तरह एक बड़ा बदलाव करने का मतलब है कि उन प्रोजेक्ट्स को भी अपडेट करने की आवश्यकता होगी, कुछ वास्तव में मजबूत 3 डी गोडोट गेम में देरी हो रही है।

इसके अलावा गोडोट 3.0+ ट्यूटोरियल अभी भी आ रहे हैं। विशेष रूप से 3D पक्ष पर, चीजें कुछ हद तक कर्षण प्राप्त करने लगी हैं। हालांकि यह आंशिक रूप से गोडोट 3.0+ में गोडोट के 3डी पक्ष के मजबूत होने के कारण है, मुझे डर है कि नाम परिवर्तन के लिए बहुत सारे सामग्री ट्यूटोरियल लेखक बना रहे हैं (या काम कर रहे हैं) अचानक बड़े पैमाने पर रीवर्डिंग की आवश्यकता होगी। नए ट्यूटोरियल बनाने में समय लगेगा, क्योंकि पुराने ट्यूटोरियल को छोड़ना, फिर से बनाना या फिर से लिखना होगा।

नामकरण परिवर्तन मौजूदा संसाधनों को भी बना देगा जो ट्यूटोरियल नहीं हैं, बस समस्याओं के लिए सरल समाधान मिल गए हैं, अचानक पुराने हो गए हैं। जबकि गोडोट का 2डी पक्ष यकीनन काफी मजबूत है और संभवत: जल्दी से अनुकूलित हो सकता है, 3डी पक्ष का उपयोग करने वाला समुदाय काफ़ी छोटा है। नोड्स के नाम बदलने से, मुझे चिंता है कि यह गोडोट के 3D उपयोगकर्ता विकास और 3D संबंधित समस्याओं के समाधान खोजने की क्षमता को प्रभावित करने वाला है।

मैं @ eon-s से सहमत हूं: क्या ये परिवर्तन थोड़ा इंतजार नहीं कर सकते? गोडोट 4.0 के साथ, कम से कम कोड बेस में चीजें पहले से ही काफी नाटकीय रूप से बदल रही हैं। मुझे लगता है कि एक और बड़े बदलाव को जोड़ने से केवल विकास कठिन होगा और लोग गोडोट के 3D पक्ष के साथ बहुत सी प्रगति कर रहे हैं।

एक बार गोडोट 4.0 के बाहर हो जाने के बाद, मुझे लगता है कि संस्करण 4.1 या 5.0 में नोड्स का नाम बदलने पर काम करना उत्कृष्ट होगा, लेकिन मेरी राय में मुझे लगता है कि इस तरह एक और बड़ा बदलाव जोड़ने से मदद से ज्यादा नुकसान होगा।

एक चीज जो इस संक्रमण को बेहतर बना सकती है वह है उपनाम/संक्रमण अवधि, उदाहरण के लिए शायद गोडोट 4.0 से गोडोट 4.1 तक। यह ट्यूटोरियल और संसाधनों (विशेषकर 3D वाले) को तुरंत अप्रचलित नहीं बनाएगा और सभी को आगामी परिवर्तनों के अनुकूल होने का मौका देगा, जबकि अभी भी गोडोट 4.0 में परिवर्तनों से लाभ उठाने में सक्षम होगा।

एक उपनाम/संक्रमण अवधि का उपयोग करने से सभी को एक साथ सभी को अपडेट करने के लिए अचानक मजबूर किए बिना संगतता तोड़ने वाले परिवर्तन किए जा सकेंगे। यह संगतता को तोड़ने वाले परिवर्तनों को अधिक बार करने की अनुमति देगा, क्योंकि सैद्धांतिक रूप से एक बार संक्रमण के लिए एक प्रणाली होने के बाद इसे भविष्य में संगतता तोड़ने वाले परिवर्तनों के लिए फिर से उपयोग किया जा सकता है। यह #16863 में सूचीबद्ध परिवर्तनों के साथ आगे बढ़ना आसान बना देगा।

TLDR: मैं सभी परिवर्तनों के लिए हूं, मुझे लगता है कि इसे तब तक इंतजार करना चाहिए जब तक कि गोडोट 4.1 या एक संक्रमण प्रणाली/अवधि सभी को परिवर्तनों को समायोजित करने के लिए समय देने के लिए नहीं बनाई जानी चाहिए।

चाहे यह प्रस्ताव कैसे भी समाप्त हो: मुझे लगता है कि गोडोट 4.0 बहुत अच्छा होगा और मैं इसके लिए तत्पर हूं

@reduz मैं कहता हूं कि इसके लिए जाओ। और मैं दूसरा @jahd2602

मैं सभी 3D नोड्स को "3D" के साथ समाप्त करने का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन निश्चित रूप से, अगर हर कोई चाहता है। मुझे लगता है कि हमेशा प्रत्यय होने के बजाय अलग-अलग नाम रखना ठीक है (उदा: टाइलमैप और ग्रिडमैप)

मैं "अनुवाद" के बजाय "स्थिति" को बहुत अधिक पसंद करूंगा। उत्तरार्द्ध को स्थानीयकरण और भाषाओं के साथ भ्रमित किया जा सकता है, और पूर्व तुरंत स्पष्ट और शुरुआती-अनुकूल है। हालांकि, क्या गोडोट इसके लिए ज्यादातर जगहों पर पहले से ही "मूल" का उपयोग नहीं करता है?

मैं @neikeq से भी सहमत

(बीटीडब्ल्यू स्प्राइट 3 डी क्यों मौजूद है जब यह सिर्फ क्वाड जाल हो सकता है?)

@TwistedTwigleg मेरी पोस्ट पढ़ें, यदि कोई आंतरिक संगतता प्रणाली जोड़ी जाती है तो 3.0 प्रोजेक्ट 4.0 में ठीक खुलेंगे।

अच्छा बदलाव, एक प्रोग्रामर के रूप में मैं समकक्ष के नाम को यथासंभव सममित देखकर खुश हूं

क्या आप विस्तार से बता सकते हैं कि ORM स्टाइल टेक्सचर का क्या अर्थ है?

@reduz मानक स्थानिक सामग्री और ORM एक के बीच एकमात्र अंतर है, कि आपके पास ORM के साथ केवल एक बनावट चैनल (बजाय 3 जैसा है) है? क्या आपके पास अभी भी उन्हीं मापदंडों (धातु और खुरदरापन में) जैसे कि स्पेक्युलर और मल्टीप्लायरों तक पहुंच होगी? अक्सर इस्तेमाल नहीं किया जाता है लेकिन कभी-कभी ट्विक किया जाता है।

मुझे यह विचार पसंद है, लेकिन सोच रहा था कि इतने छोटे बदलाव के लिए 2 भौतिक प्रकारों का होना अधिक है या नहीं। क्या इसके बजाय ओआरएम मोड के लिए 1 बनावट चैनल या मौजूदा शैली के लिए 3 के बीच एक सामग्री का उपयोग करके स्विच करने के लिए टॉगल हो सकता है?

मैं हाल ही में बनावट से अधिक लाभ प्राप्त करने के लिए अपने ओआरएम मानचित्रों के अल्फा चैनल में गहराई (ऊंचाई) चैनल डाल रहा हूं। फिर आप केवल 3 बनावट का उपयोग करके अधिकांश बनावट कर सकते हैं ... अल्बेडो/सामान्य/ओआरएम (एच)। यह डिफ़ॉल्ट रूप से जोड़ने के लिए उपयुक्त हो सकता है (जब तक हमें ऊंचाई के नक्शे के लिए 16 बिट विकल्प नहीं मिलता है, जहां आप एक अलग का उपयोग करना चाहते हैं)। यदि 4.0 अंततः टेसेलेशन/विस्थापन हो जाता है, तो ऊंचाई चैनल वर्तमान की तुलना में कहीं अधिक महत्वपूर्ण होगा।

और जिसके बारे में बात करते हुए, यह 4.0 में DEPTH चैनल के नामकरण को HEIGHT में बदलने का भी एक अच्छा अवसर होगा और क्या यह वर्तमान में उपयोग की जाने वाली चीज़ों के विपरीत का उपयोग करता है (यानी सफेद एक उभरी हुई सतह है और काला रिक्त है)। यह इसे अन्य रेंडरर्स और गेम इंजनों के साथ, और अधिक महत्वपूर्ण रूप से सबस्टेंस, क्विक्सल और मार्मोसेट जैसे टूल के साथ रखेगा।

मैं 2D और 3D नोड्स के लिए स्पष्ट प्रत्यय पसंद करूंगा, और यदि यह लागू नहीं है तो कोई प्रत्यय नहीं। मैं "नोड2डी" नोड्स के लिए "कंट्रोल" नोड्स को पूरी तरह से अलग करना चाहता हूं (वे दोनों वर्तमान में "कैनवासइटम" के तहत समूहीकृत हैं)।

लगभग translation बनाम position , मैं 2D और 3D दोनों में पूर्व के लिए जाऊंगा।

position अधिक अनुकूल दिखता है, लेकिन पूर्वजों के कुछ घूर्णन या पैमाने के बाद यह समझ में आता है।

अनुकूलता के संबंध में, संक्रमण चरण सभी 4.x रिलीज के लिए चलना चाहिए ताकि ट्यूटोरियल, उपयोगकर्ताओं और परियोजनाओं को भरपूर या समय मिल सके। नए नाम प्रथम श्रेणी के नागरिक होने चाहिए और प्रोत्साहित किए जाने चाहिए, लेकिन पुराने लोगों को बदलाव के बारे में लोगों को बताने के लिए कुछ इन-एडिटर तंत्र के साथ काम करना चाहिए।

मैं पूरी तरह से सुझाए गए परिवर्तनों के पक्ष में हूं, जब तक कि यह इस तरह से किया जाता है कि अंतिम उपयोगकर्ताओं के लिए मौजूदा कोड को अपडेट करना आसान हो जाता है - या तो मौजूदा ट्यूटोरियल और दस्तावेज़ीकरण से कोड या किसी प्रकार के टूल के माध्यम से जैसा कि उल्लेख किया गया है। इस तरह के एक उपकरण की कमी के कारण, मैं इस बात से सहमत हूं कि हम v2 से v3 में बड़े बदलाव के बाद जल्द ही ढेर कर रहे हैं।

@TwistedTwigleg 3D गेम की रिलीज़ के संबंध में, ऐसा इसलिए है क्योंकि हम 4.0 और Vulcan की प्रतीक्षा कर रहे हैं

मैं Control नोड्स नाम... और इनलाइन दस्तावेज़ीकरण की भी समीक्षा करूंगा।

कभी-कभी मुझे आश्चर्य होता है कि AcceptDialog और ConfirmationDialog क्या अंतर है, और PopupPanel , PopupDialog , PopupMenu ... मदद करता है!

एक ट्यूटर और एक डॉक्स योगदानकर्ता के रूप में, मैं कहूंगा कि आगे बढ़ें! अगर भविष्य में सभी के लिए इंजन को सीखना और समझना आसान हो जाता है, तो मुझे अधिक सामग्री का उत्पादन करने में कोई आपत्ति नहीं है। बेहतर होगा इस तरह का बदलाव जल्द से जल्द करें।

पार्टी में देर से आना, लेकिन चीजों को प्रबंधनीय रखने के लिए कुछ स्पष्टीकरण:

• कृपया केवल नोड्स का नाम बदलने के प्रस्ताव के बारे में टिप्पणी करें, और संगतता को संरक्षित करने के तरीके पर इसके तकनीकी प्रभाव, मौजूदा परियोजनाओं, ट्यूटोरियल, सामग्री निर्माताओं आदि पर प्रभाव।
• यह एपीआई में विशिष्ट बिंदुओं पर चर्चा करने का स्थान नहीं है जिसे नाम बदलने पर विचार किया जाना चाहिए। यदि हम इस बड़े पैमाने पर नामकरण के साथ जाने का निर्णय लेते हैं, तो हम यह सुनिश्चित करने के लिए पूरे एपीआई की एक स्प्रेडशीट में समीक्षा करेंगे कि हमारे पास संगत नाम हैं। विधियों, गुणों या वर्गों जैसी विशिष्ट चीजों के लिए जिनका नाम बदला जाना चाहिए, उनके बारे में यहां चर्चा की गई है, देखें #16863।
• @RandomShaper @fracteed @fire @reduz कृपया मानक सामग्री के बारे में चर्चा को एक समर्पित मुद्दे पर ले जाएं।

नमस्ते,
अन्य एपीआई के अभ्यास का पालन क्यों न करें और कक्षाओं (या यहां तक ​​​​कि विधियों) के लिए एक अप्रचलित/पदावनत डेकोरेटर बनाएं, यानी पुराने नाम केवल नए के लिए उपनाम/संकेतक हैं। यह किसी भी ब्रेकिंग परिवर्तन को रोक देगा और नामों को संस्करण 5 में छोड़ने की अनुमति देगा ताकि कम लोग प्रभावित हों या नोटिस भी न करें।

डेकोरेटर का उपयोग करने से दो अन्य लाभ भी मिल सकते हैं:

1. आईडीई आसानी से इस टैग को उठा सकता है और इसे नोड चयन विंडो में प्रदर्शित कर सकता है, उदाहरण के लिए केवल 'स्थानिक' कहने के बजाय यह 'स्थानिक (अप्रचलित उपयोग Node3D)' पढ़ सकता है।

2. डेकोरेटर तब कोड संपादक में दिखाई गई चेतावनी बन सकता है।

साथ ही यह किसी को भी नाम बदलने का टूल बनाने से नहीं रोकता है...

कुछ विचार:

मैं बेहतर स्थिरता के लिए और एपीआई को सीखने और उपयोग करने में आसान बनाने के लिए नोड्स के नाम बदलने के साथ-साथ कुछ विधियों और गुणों (#16863 में वर्तमान सूची देखें) से सहमत हूं। 2D/3D भेद को स्पष्ट करना एक अच्छा विचार लगता है, और यदि किया जाता है तो इसे लगातार किया जाना चाहिए (उदाहरण के लिए MeshInstance3D जैसा कि उल्लेख किया गया है)। मेरा सुझाव है कि हम सभी मौजूदा नोड्स को सूचीबद्ध करने के लिए एक स्प्रेडशीट का उपयोग करें और 4.0 में उनके नए नाम क्या होने चाहिए - और हम टाइलमैप/ग्रिडमैप जैसे विशिष्ट नोड्स के बारे में वहां बाइकशेड कर सकते हैं। अगर हम इस बात की पुष्टि करते हैं कि हम इसी रास्ते पर चलना चाहते हैं, तो मैं आने वाले दिनों में यह स्प्रेडशीट बनाऊंगा।

फिर भी, हमें जितना हो सके अनुकूलता भंग को सीमित करने का प्रयास करना चाहिए। जैसा कि जुआन ने उल्लेख किया है, हमारे पास इंजन इंटर्नल में संगतता नाम हो सकते हैं ताकि पुराने दृश्यों को लोड और परिवर्तित किया जा सके, लेकिन यह पर्याप्त नहीं है।

जैसा कि @RandomShaper और @chucklepie ने उल्लेख किया है, हमें एक संपत्ति डेकोरेटर/मेटाडेटा के साथ सभी नोड्स, विधियों, गुणों, स्थिरांक, सिग्नल इत्यादि के लिए बहिष्कृत उपनाम जोड़ना चाहिए, जो उन्हें अप्रचलित के रूप में संकेत देगा और उपयोगकर्ताओं को बदलने के लिए प्रोत्साहित करेगा। उनका कोड। आईडीई में इस जानकारी का उपयोग करने से उपयोगकर्ताओं के लिए 4.0 में बिना किसी समस्या के 3.x ट्यूटोरियल का पालन करना संभव हो जाता है, जबकि नए नामों के बारे में आसानी से सीखते हैं।

ऐसा करने के लिए, हमें सहायक विधियों की आवश्यकता है जो हमें बाइंडिंग पंजीकृत करते समय बहिष्कृत उपनामों को परिभाषित करने दे सकें। #23023 इस तरह के एक इंटरफ़ेस को जोड़ने का पहला प्रयास है, लेकिन इसे अभी भी समीक्षा, विलय, और शायद विस्तारित करने की आवश्यकता है यदि यह 4.0 में हमारी आवश्यकता के लिए पर्याप्त नहीं है। उन बहिष्कृत उपनामों को पूरे 4.x रिलीज चक्र के लिए रखा जा सकता है, और 5.0 में गिरा दिया जा सकता है।
जब तक हमारे पास इस इंटरफ़ेस को अच्छी तरह से डिज़ाइन और विलय नहीं किया जाता है,

कब के लिए , मैं जोर देकर कहता हूं कि अगर हम कभी भी संगतता को फिर से तोड़ना चाहते हैं, तो यह अभी है। 5.0 की प्रतीक्षा करने का कोई मतलब नहीं है, क्योंकि यह 5.0 तक पहुंचने के बाद और भी अधिक सामग्री को अप्रचलित बना देगा, और यह गोडोट को एक स्थिर विकास उपकरण के रूप में चित्रित करने में मदद नहीं करेगा यदि हम गोडोट 4 के साथ विकास में कई महान खेलों के साथ संगतता को तोड़ते हैं (उम्मीद है) ।एक्स।

गोडोट का उपयोगकर्ता आधार हर साल कमोबेश दोगुना हो जाता है, इसलिए हर साल जो बीत जाता है वह एक रिफैक्टरिंग को कम यथार्थवादी बनाता है, क्योंकि अंततः एक बड़े उपयोगकर्ता आधार की जड़ता संगतता को तोड़ने से होने वाले लाभों से आगे निकल जाती है। यदि गोडोट की तुलना में यूनिटी या अवास्तविक जैसे अन्य इंजन एपीआई के मामले में अपेक्षाकृत स्थिर लगते हैं, तो ऐसा इसलिए नहीं है क्योंकि उनके पास ऐसी चीजें नहीं हैं जिन्हें वे रिफैक्टर या नाम बदलना चाहते हैं, बल्कि इसलिए कि वे बर्दाश्त नहीं कर सकते। हम अभी भी कर सकते हैं, इसलिए हमें अवसर का उपयोग करना होगा। गोडोट 3.0 के लिए भी ऐसा ही था और समुदाय इससे अपेक्षाकृत सुरक्षित निकला, हालांकि हमारे पास 2.1 से चिपके रहने वाले उपयोगकर्ताओं का एक छोटा अनुपात है क्योंकि वे 3.0 को पोर्ट करने का जोखिम नहीं उठा सकते हैं। 4.0 के लिए, उन परिवर्तनों का दायरा बहुत कम होना चाहिए, और कोई भी पोर्टिंग कार्य सीधा होना चाहिए, लेकिन इस बीच समुदाय कई गुना बढ़ गया है, इसलिए किसी भी कॉम्पेट ब्रेक का प्रभाव 3.0 के मुकाबले बड़ा या बड़ा होगा। छवि की शर्तें/संचित उपयोगकर्ता झुंझलाहट :)

मैं संगतता को तोड़ने का एक बड़ा समर्थक हूं।
यह कोई मुद्दा क्यों नहीं है: यदि कोई देव अपने खेल को पुराने संस्करण पर रखता है, तो इंजन के पुराने संस्करण पर विकास करना जारी रखें, कोई भी देव को नए संस्करण में माइग्रेट करने के लिए मजबूर नहीं कर रहा है। इसके अलावा: ठीक इसी उद्देश्य से डाउनलोड करने के लिए पुराने संस्करणों की पेशकश करते रहें।
इंजन के नए संस्करण में नई परियोजनाएं शुरू की जा सकती हैं और फिर यह नीचे आता है कि क्या डेवलपर के पास फिर से सीखने का धैर्य है कि इंजन कैसे काम करता है।
जब इंजन की उपयोगिता में सुधार की बात आती है, तो फिर से सीखने के लिए धैर्य कभी भी एक मुद्दा नहीं होना चाहिए, यदि लक्ष्य सबसे उपयोगकर्ता के अनुकूल या शक्तिशाली इंजन बनना है।

जहां तक ​​नाम बदलने की बात है, यह सीखने की अवस्था को कम करने में मदद करता है यदि सीखी जाने वाली सामग्री में पैटर्न हों। उदाहरण के लिए, अन्य सभी नोड्स के लिए Node2D बनाम Node3D, आदि। यदि यह एक बतख की तरह दिखता है, तो आप जानते हैं कि यह कैसे जाता है, यह इस उदाहरण में एक बतख, या एक नोड होने की सबसे अधिक संभावना है।
मानव मस्तिष्क एक अनुकूलन क्वांटम कंप्यूटर के रूप में काम करता है, जो विचारों के बीच तार्किक पथ बनाने के लिए सिस्टम के निम्नतम ऊर्जा राज्यों को एक दूसरे के साथ जोड़कर सीखता है। यदि सीखे जाने वाले विचार समान हैं, तो उनकी निम्नतम ऊर्जा अवस्थाएं एक-दूसरे के अधिक निकट होती हैं, जिससे उन्हें जोड़ना (और याद रखना) आसान हो जाता है, जो बताता है कि यदि छात्र को पहले से 2D सिखाया गया है तो 3D को समझना क्यों आसान है . यदि नोड्स के नाम उनके बीच समानता को दर्शाते हैं, तो यह सीखना और समझना भी आसान है कि एक समान प्रकार पर ज्ञान मौजूद होने पर एक नए प्रकार का उपयोग कैसे किया जाना चाहिए।

मैं कहता हूं कि आगे बढ़ो और रिफैक्टर करो और किसी भी तरह से संगतता तोड़ो। यहां तक ​​कि अगर आप कुछ उपयोगकर्ताओं को खो देते हैं, तो आप उपयोगकर्ता-मित्रता में वृद्धि और सीखने की अवस्था को कम करके बहुत कुछ हासिल करेंगे।

इसके संबंध में, उदाहरण के लिए ब्लेंडर 2.80 को लें। तुलना करें कि यह अब कैसा दिखता है और पहले जैसा व्यवहार करता है। यह एक बड़ा बदलाव है जो बहुत सारे देवों को फिर से सीखने के लिए मजबूर करता है कि सॉफ्टवेयर कैसे काम करता है। अब सोचिए कि Blender के कितने User हैं। गोडोट की तुलना में, वे विशाल हैं, फिर भी उन्होंने वैसे भी अपने सॉफ़्टवेयर को काफी हद तक बदल दिया है। क्यों? क्योंकि लंबे समय में, सीखने की अवस्था को कम करना और उपयोगकर्ता-मित्रता में सुधार करना हमेशा अधिक लाभदायक होता है, भले ही इसका मतलब कुछ ऐसे उपयोगकर्ताओं को खोना है जिनके पास नए वर्कफ़्लो में संक्रमण करने का धैर्य नहीं है।

संतुलन पर मैं इस मामले में एक ब्रेकिंग बदलाव के पक्ष में नहीं हूं।

मैं नामकरण परंपराओं के साथ महसूस की गई निराशा को समझ सकता हूं जो व्यवस्थित रूप से बढ़ी हैं, लेकिन मुझे ऐसा कोई भी नहीं दिखता है जो व्यापक और ब्रेकिंग परिवर्तन को उचित ठहराता हो।

मैं उन सभी एपीआई को हटाने के लिए हूं, जिनसे हम दूर जाना चाहते हैं (और संकलन समय पर और डॉक्स में उन्हें फ़्लैग करना), लेकिन आदर्श रूप से पुराने नोड नाम पहले की तरह काम करते रहेंगे।

शायद, कुछ वर्षों के समय में, हम पूछ सकते हैं कि क्या यह लीगेसी नोड नामों को बंद करने का समय है क्योंकि यह पूरी तरह से दर्द रहित हो गया है। तब तक मेरा सुझाव यह होगा कि वांछित के रूप में नए नाम जोड़े जाएं (उस पर मेरी कोई मजबूत राय नहीं है) और पिछड़ी संगतता को तोड़ने से बचें।

@fracteed वास्तव में किसी अन्य बनावट के चैनल में गहराई होना शायद एक अच्छा विचार नहीं है, क्योंकि लंबन मानचित्रण उस बनावट के लिए बहुत सारे नल करता है, जिससे हर बार आरजीबी अनावश्यक रूप से प्राप्त होता है। यदि आप एकल ग्रेस्केल बनावट का उपयोग करते हैं, तो गोडोट इसे आधे आकार में संपीड़ित कर देगा, जिससे आपको कुछ बैंडविड्थ की बचत होगी।

मानक सामग्री में ओआरएम मोड होना भी एक अच्छा विचार हो सकता है, इसे एक चेक देने की आवश्यकता है।

@chucklepie समस्या यह है कि सभी भाषाएं वर्ग उपनामों जैसे typedef का समर्थन नहीं करती हैं। सी # उनमें से एक है।

@reduz आह, मुझे यह नहीं पता था, जानना अच्छा है। अधिक महत्वपूर्ण मुद्दा गहराई चैनल को 4.0 के लिए ऊंचाई पर स्विच करना है, इसलिए उम्मीद है कि आप इसे बदलने पर विचार करेंगे।

संपादित करें। क्षमा करें एकियन, इसे पोस्ट करने के बाद ही आपकी टिप्पणी देखी ...

@neikeq समस्या यह है कि सभी भाषाएं वर्ग उपनामों जैसे typedef का समर्थन नहीं करती हैं। सी # उनमें से एक है।

मुझे नहीं पता कि मूल सी ++ लाइब्रेरी कैसे कार्यान्वित की जाती है, लेकिन मैं मूल सी ++ स्तर पर इस सजावट को करने के लिए एक तंत्र की बात कर रहा हूं ताकि इससे कोई फर्क नहीं पड़ता कि अपस्ट्रीम भाषा बाध्यकारी क्या है। यदि यह संभव नहीं है तो प्रत्येक भाषा के लिए बाइंडिंग को आसानी से सूट में अनुकूलित किया जा सकता है (उदाहरण के लिए सी #, आदि में विशेषताओं का उपयोग करना)।

@ gerald1248 मेरी पोस्ट पढ़ें, कहीं भी मैंने उल्लेख नहीं किया कि यह टूट जाएगा, 3.x में बनाई गई परियोजनाएं लोड और स्क्रिप्ट पर उपनामों का उपयोग करके काम करना जारी रखेगी। उनका उपयोग करना एक बहिष्करण चेतावनी को ट्रिगर करेगा, लेकिन आपका प्रोजेक्ट काम करना जारी रखेगा।

मैं का बहुत बड़ा प्रशंसक हूं

नेविगेशन -> Nagivagion3D

नाम बदलें मैं इस अनुरोध को दूसरा करता हूं!

@reduz ने कहा:
@TwistedTwigleg मेरी पोस्ट पढ़ें, यदि कोई आंतरिक संगतता प्रणाली जोड़ी जाती है तो 3.0 प्रोजेक्ट 4.0 में ठीक खुलेंगे।

मेरा बुरा, मैंने पोस्ट के उस हिस्से को याद किया।

एक आंतरिक संगतता प्रणाली प्रवासन में मदद करेगी, और निश्चित रूप से मुझे बाड़ के "परिवर्तन करें" पक्ष पर और अधिक डालती है, खासकर अगर # 23023 जैसी किसी चीज़ के साथ संयुक्त हो। इस परिवर्तन से पहले परियोजनाओं के लिए कुछ योजना बनाई गई है, यह जानना अच्छा है और इस प्रस्ताव के बारे में मेरी बहुत सारी चिंताओं को कम करता है।

@ नोरोक्स ने कहा:
@TwistedTwigleg 3D गेम की रिलीज़ के संबंध में, ऐसा इसलिए है क्योंकि हम 4.0 और Vulcan की प्रतीक्षा कर रहे हैं

यह उचित है।
गोडोट 4.0 में आने वाले गोडोट के 3डी पक्ष में विशेष रूप से सुधारों को देखते हुए, 3डी हेवी प्रोजेक्ट्स के लिए प्रतीक्षा करना कोई बुरी बात नहीं हो सकती है।

3डी और 2डी विभेदन पहले से ही एकरूपता स्पष्ट है । 3d नोड हल्के लाल रंग के होते हैं, 2d नोड नीले रंग के होते हैं, और ui नोड हरे रंग के होते हैं। हमेशा ऐसे उपयोगकर्ता होंगे जिनके पास नामकरण के साथ कोई समस्या है। यह एक कभी न खत्म होने वाली समस्या है और समुदाय के आकार के आधार पर एक बहुगुणित समस्या है।

ओपी में सुझाए गए परिवर्तनों के संबंध में: 2d नोड्स में पहले से ही एक "2D" प्रत्यय लागू होता है, जिसका अर्थ है कि उनके समकक्ष 3d_ हैं।

हालांकि, मैं Label से TextLabel जैसे परिवर्तनों के पक्ष में हूं। ( @MuffinManKen एक महान बिंदु बनाता है)

मैं मूल रूप से यहां सब कुछ के पूर्ण समर्थन में हूं, लेकिन "स्प्राइट 2 डी/स्प्राइट 3 डी" प्रश्न के संबंध में, मैं स्प्राइट को स्प्राइट के रूप में छोड़ने का सुझाव दूंगा, अगर 2 डी प्रत्यय के अलावा किसी अन्य कारण से अव्यवस्था, आईएमओ की अतिरिक्त मात्रा नहीं मिलती है।

जैसा कि @girng कहते हैं, रंग-कोडिंग के कारण 2D/3D बहुत अधिक समय तक जाने की आवश्यकता नहीं है। एक गोडोट डेवलपर के दृष्टिकोण से, मैं व्यक्तिगत रूप से अपने प्रोजेक्ट में प्रत्येक गैर-नामित नोड पर -2 डी से निपटने का आनंद नहीं उठाऊंगा। :डी

क्या वह कलर कोडिंग विभिन्न प्रकार के कलर ब्लाइंडनेस वाले लोगों के लिए मददगार है?
जब आप कोड टाइप कर रहे हों तो यह निश्चित रूप से सहायक नहीं होता है (संवाद से नोड्स जोड़ने के विपरीत)।

@reduz आपके उत्तर के लिए धन्यवाद। मुझे एहसास है कि यह एक प्रमुख संस्करण के लिए है और इस प्रकार एक सेवर अर्थ में पूरी तरह से ठीक है। व्यक्तिगत रूप से मैं एक बड़े संस्करण के लिए भी इस तरह के बदलाव करने से बचूंगा, लेकिन मुझे पता है कि आपको इस बात की बेहतर समझ है कि यह एक समस्या होगी या नहीं। मैं सिर्फ प्रमुख संस्करणों में बड़े बदलावों के इतिहास को देख रहा हूं (उदाहरण के लिए पायथन 2 से पायथन 3) और आमतौर पर मैं असंगतता (या नए नोड नाम और पुराने, बहिष्कृत नोड्स) के साथ रहूंगा। किसी भी तरह से मैं गोडोट से प्यार करता हूं और इसका उपयोग करना जारी रखूंगा, चाहे कुछ भी तोड़ने वाले बदलाव हों।

लेकिन फिर, बेझिझक सुझाव दें कि क्या आप कुछ अधिक स्पष्ट पसंद करेंगे और सब कुछ हमेशा 2D/3D बना देंगे।

स्पष्ट निहित से बेहतर है।

जब आप कोड लिख रहे हों तो @girng @AlexHoratio Nodes का संपादक में एक अलग रंग होना मददगार नहीं है। मुझे लगता है कि यहीं से भ्रम पैदा होता है।

(मैं अभी भी नहीं देखता कि स्प्राइट 3 डी को अस्तित्व में क्यों होना चाहिए, अन्य इंजन केवल उसी उद्देश्य के लिए क्वाड मेश का उपयोग करते हैं, यह आसान होगा यदि स्प्राइट विशेष रूप से 2 डी शब्द था)।

@gimg , @AlexHoratio यह मत भूलिए कि ४.५% आबादी कलर ब्लाइंड भी है :stuck_out_tongue:

मुझे लगता है कि नाम बदलना एक अच्छा विचार है।
2डी से 3डी में ट्रांजिशन करना काफी आसान हो जाएगा। कम से कम उन लोगों के लिए जो 2D से शुरू करते हैं (और शायद इसके विपरीत भी)

यह स्पष्ट है कि कोई समस्या है, और समुदाय को लगता है कि यह एक अच्छा विचार है। मैं सिर्फ गोडोट के साथ पक्षपाती हूं और भावनात्मक रूप से बहुत अधिक जुड़ा हुआ हूं। इस अवस्था में होने से ऐसे विचार उत्पन्न होते हैं जो वास्तव में दूसरों के लिए मायने नहीं रखते हैं, लेकिन मेरे लिए एक सुंदर तरीके से सही मायने रखते हैं। समझाना मुश्किल। मुझे मेरे विचारों को आवाज देने के लिए धन्यवाद

मैं यहां आम सहमति से सहमत हूं कि निरंतरता के लिए उनका नाम बदलना सार्थक है। अभी यह बाहरी धारणा दे सकता है कि नोड्स का एक सेट "प्रथम श्रेणी" है और दूसरा "द्वितीय श्रेणी" है, या शायद पहले के आधार पर अस्तित्व में भी हैक किया गया है।

मुझे व्यक्तिगत रूप से लगता है कि Sprite -> Sprite2D पूरी तरह से कठोर स्पष्ट नामकरण का एक दुर्भाग्यपूर्ण हताहत होगा, लेकिन मुझे लगता है कि जब तक मैं थक नहीं जाता तब तक मैं हर दृश्य में इसे मैन्युअल रूप से स्प्राइट में बदल सकता हूं। इसका।

मुझे लगता है कि यह गलत है कि CanvasLayer और CanvasItem को समूहीकृत नहीं किया गया है, और यह कि Node2D कैनवासइटम के अंदर नियंत्रण के साथ है, जैसे अन्य ने इंगित किया है।

मुझे पता है @ akien-mga ने कहा कि यह केवल नोड्स के नाम बदलने के लिए है, लेकिन मुझे लगता है कि कम से कम position बनाम translation बारे में बहस यहां चलन में आती है। मुझे लगता है कि नोड्स का नाम बदलने का उद्देश्य कुछ हद तक सपाट हो जाता है यदि उनके एपीआई काफी भिन्न होते हैं (समन्वय प्रणालियों और इसी तरह के बीच मतभेदों को छोड़कर), तो वे निश्चित रूप से वही होना चाहिए, जो भी वे हैं। मैं यहां जाने के रास्ते के रूप में "स्थिति" के लिए वोट दूंगा, "अनुवाद" की तुलना में भ्रामक होने के बारे में एक टिप्पणी थी। मैं कहूंगा कि "अनुवाद" भ्रामक है क्योंकि इसका तात्पर्य केवल निर्देशांक होने के बजाय एक परिवर्तन या आंदोलन से है। स्थिति सहज रूप से सापेक्ष है, इमो (आप कम्पास दिशाओं के संबंध में अपनी कुर्सियों को सीधा नहीं करते हैं, आप इसे कमरे की दीवारों के संबंध में करते हैं।)

मुझे लगता है कि चरों को दोनों के लिए स्थिति का नाम दिया जाना चाहिए, लेकिन translate फ़ंक्शंस move_local फ़ंक्शंस को Node2D से translate_local बदलना चाहिए, दस्तावेज़ीकरण भी इसे अनुवाद कहते हैं। मैं भौतिकी से संबंधित नोड्स के लिए move का उपयोग भौतिकी गति और ज्यामितीय अनुवाद के बीच अंतर करने के लिए रखूंगा।

इसका दूसरा भाग भी #16863 के लिए प्रासंगिक है

इसके अलावा @reduz , मुझे लगता है कि इंजन में सी # लाभ कार्यक्षमता के रूप में, अधिक से अधिक लोग सी # के लिए नामस्थान चाहते हैं, और एक बार जब वे सी # में हों, तो मैं कल्पना कर सकता हूं कि बहुत से जीडीस्क्रिप्ट उपयोगकर्ता उनका उपयोग करना चाहते हैं और भाषाओं को स्विच नहीं करना चाहते हैं कार्यक्षमता के लिए। मुझे लगता है कि अंतिम सी # समर्थन के लिए नामस्थान पूरी तरह से आवश्यक हैं, हालांकि जीडीस्क्रिप्ट के लिए लाभ बहुत कम नाटकीय हैं लेकिन यह उपयोगकर्ता की चिंता के बिना प्लग एंड प्ले पैकेज को संभव बना देगा।

मैंने सिर्फ एक विचार के बारे में सोचा, अगर इसे लागू किया गया था, तो हमारे पास "सरल नोड नाम" नामक एक संपादक सेटिंग हो सकती है, जिसका अर्थ है कि नए बनाए गए नोड्स में उनके नाम में प्रत्यय की कमी है, उदाहरण के लिए, एक नया "व्हाटएवर 2 डी" बनाने से इसका सेट हो जाएगा नाम "जो भी हो" लेकिन उस नोड पर स्क्रिप्ट अभी भी कहेंगे "जो कुछ भी 2 डी का विस्तार करता है" आदि। यह नोड बनाने के बाद मैन्युअल रूप से इसका नाम बदलने जैसा ही होगा।

यह पदानुक्रम में "2D" या "3D" डिफ़ॉल्ट नामों को देखने की अव्यवस्था से बचता है यदि उपयोगकर्ता इसे सक्षम करना चुनता है, लेकिन फिर भी कोड को अधिक सुसंगत और स्पष्ट बना देगा। "3D" वाले 3D नोड्स के बिना, यह भ्रमित करने वाला होगा, लेकिन यह डिफ़ॉल्ट रूप से अंत में "3D" के साथ समझ में आता है।

@aaronfranke मुझे लगता है कि यह एक बहुत ही ठोस विचार है। यह एक समझौता की तरह लगता है जो उपयोगकर्ताओं को अपने पदानुक्रम से अतिरिक्त अव्यवस्था को दूर रखने की अनुमति देते हुए कोडबेस को सुसंगत और स्पष्ट रखने की अनुमति देता है। मुझे लगता है कि नाम बदलने के विचार पर बहुत सारी आपत्तियां स्वयं नामों पर आपत्ति के बजाय, पदानुक्रम पर पड़ने वाले प्रभाव से आती हैं।

@aaronfranke मैं उस व्यक्ति से नफरत करता हूं जो अन्यथा एक समझदार विचार को जीडी स्क्रिप्ट फ़ाइलों को साझा करना असंभव बना देंगे। चूंकि सभी प्लगइन्स कच्ची जीस्क्रिप्ट फाइलों और दृश्यों के रूप में निर्यात किए जाते हैं, इसलिए वे काम करना बंद कर देंगे, अगर उन्हें अलग-अलग नोड मैपिंग वाले सिस्टम पर विकसित किया गया था। इससे बचने के लिए, सभी gdscript फ़ाइलों और दृश्य फ़ाइलों को नए सिस्टम के लिए फ़ाइल का अनुवाद करने के लिए नोड नाम मैपिंग को शामिल करना होगा। मुझे पूरा यकीन है कि इस तरह का ओवरहेड @reduz के लिए एक बड़ी संख्या है।

@aspenforest मुझे नहीं लगता कि मैपिंग जोड़ना एक बड़ा ओवरहेड होगा, लेकिन शायद मैं अनुभवहीन हूं क्योंकि मुझे इंजन की वास्तुकला का पता नहीं है

@aaronfranke के विचार से आसानी से जो बनाया जा सकता है, MeshInstance नोड स्वचालित रूप से नामित किया जाएगा mesh_instance के बजाय MeshInstance ), नोड प्रत्यय के लिए एक और सेटिंग जोड़ी जा सकती है, जो नोड नामों से "2D" या "3D" प्रत्यय को हटा देगा (इसलिए एक नया Sprite2D नोड को केवल Sprite नाम दिया गया है)।

किसी ने कभी भी KinematicBody2D या Particles2D और एक अनावश्यक "2D" प्रत्यय के बारे में शिकायत नहीं की, इसलिए मुझे नहीं पता कि हमें "3D" प्रत्यय के अतिरिक्त काम करने के लिए सुविधाओं को क्यों जोड़ना चाहिए अपने समकक्षों पर ... यदि उपयोगकर्ता वास्तव में इन प्रत्ययों को पहले स्थान पर नहीं रखना चाहते हैं, तो इस प्रस्ताव को शायद त्याग दिया जाना चाहिए, किसी कॉस्मेटिक कारण से आईडीई में नोड्स का नाम बदलने के तरीके के साथ काम नहीं किया जाना चाहिए ...

@ akien-mga यह नए नोड नामों के लिए "चारों ओर काम" नहीं करेगा, मेरे लिए यह शीर्ष पर अधिक ग्रेवी है, कुछ ऐसा जो लगातार नामकरण योजना के साथ गैर-हैकी है। मैं वहां प्रत्यय चाहता हूं, जब मैं कोडिंग कर रहा हूं, नोड्स जोड़ रहा हूं, या दस्तावेज़ीकरण देख रहा हूं। लेकिन एक बार जब वे एक दृश्य में होते हैं, तो मुझे पता है कि वे क्या हैं, और बहुत सी चीजों को वैसे भी कस्टम नाम मिलेंगे।

यदि नामों को सुसंगत बनाने और नामों को सरल बनाने के लिए एक संपादक सुविधा प्राप्त करने के बीच चयन करने के लिए नीचे आया, तो मैं पूर्व को चुनूंगा , लेकिन मुझे लगता है कि

मैं निश्चित रूप से सोचता हूं कि संपादक सुविधा जोड़ना इसका अपना मुद्दा/पीआर होगा, इसे शामिल करने के लिए कुछ जरूरी नहीं है।

मैंने शुरू में SpatialMaterial से परहेज किया क्योंकि इसका एक अजीब नाम था। लेकिन यह इतना शक्तिशाली वर्ग है। इसके बजाय मैंने अभी सीखना शुरू किया कि ट्रिप्लानर मैप किए गए अल्बेडो + एओ + नॉर्म्स के साथ शेडर्स को कैसे कोड किया जाए। तब मुझे पता चला कि मैंने जो काम किया था वह सब कुछ नहीं था क्योंकि मैं वह सब SpatialMaterial में कर सकता था और फिर उसे कोड में बदल कर एक बेहतर परिणाम प्राप्त कर सकता था। इसलिए इसे एक और दोस्ताना नाम की जरूरत है।

स्पष्ट 2डी/3डी नामों के लिए +1।

मेरे पास एक नोड से संबंधित प्रश्न है जो मुझे लगता है कि भविष्य में बहिष्करण के लिए चिह्नित किया जा सकता है, और जिसका अस्तित्व मैं कल्पना कर सकता हूं वह नामकरण के दृष्टिकोण से भ्रमित हो सकता है। चूंकि नई एनीमेशन प्रणाली गिरा दी गई है, अब हमारे पास दो नोड्स हैं, एक का नाम एनिमेशनट्री और एनिमेशनट्रीप्लेयर है, जिनका मूल रूप से एक दूसरे से कोई संबंध नहीं है। इसे संबोधित करने का सबसे अच्छा तरीका क्या हो सकता है इस पर कोई विचार?

@SaracenOne इस तरह के प्रश्न पूछने के लिए यह उचित जगह नहीं है। माफ़ करना। यह थ्रेड केवल 2D/3D प्रत्यय पर चर्चा करने के लिए है।

आम तौर पर नाम परिवर्तन पर चर्चा करने के लिए एक और मुद्दा है https://github.com/godotengine/godot/issues/16863

मेरे पास एक विचार था जो शायद 4.0 के लिए स्वीकार्य कॉम्पेट ब्रेकेज के दायरे से बाहर होगा, और इसलिए शायद यह केवल अक्षम्य/अस्वीकार्य है, लेकिन मुझे लगा कि मैं इसका उल्लेख करूंगा कि यह देखने के लिए कि क्या कोई और अधिक अनुभवी है जो मुझे टिप्पणी करने की परवाह है।

मैंने कल्पना की थी कि ये सभी 2D/3D नोड्स एक एकल नोड प्रकार से प्राप्त हो सकते हैं जो या तो 2D या 3D है। ऐसे नोड के लिए एपीआई में वे सभी कार्य होंगे जिनकी आप किसी भी संस्करण के लिए अपेक्षा करते हैं, और उनका कार्यान्वयन इस बात पर निर्भर करेगा कि यह विशेष 2 डी या 3 डी था या नहीं।

सिद्धांत रूप में, ऐसी प्रणाली हो सकती है:

1. सुनिश्चित करें कि हम 2D/3D समकक्षों के बीच सुसंगत API बना रहे हैं। जैसा कि मैं इसे देखता हूं, यह एक लाभ और कमी दोनों है, क्योंकि इस स्थिरता के बावजूद ऐसी चीजें हो सकती हैं जो एक में शामिल करने के लिए जरूरी नहीं हैं लेकिन दूसरे में हैं।
2. दो अलग-अलग प्रकारों के लिए इंटरैक्ट करना या कस्टम स्क्रिप्ट बनाना आसान बनाएं जिन्हें आप नोड के 2D और 3D दोनों संस्करणों में संलग्न करना चाहते हैं।

ऐसी स्थिति से बचने के लिए यह अच्छा होगा जहां "कुछ क्लास 2 डी में एक्स, वाई, और जेड लागू किया गया है लेकिन कुछ क्लास 3 डी के लिए ऐसा कुछ नहीं है" और यह नामकरण समस्या को एक अलग तरीके से हल करता है। यह शायद कुछ कारणों से स्मारकीय रूप से बेवकूफी है, जिसके बारे में मैं अभी नहीं सोच रहा हूँ, लेकिन मैंने सोचा कि मैं इसे वहाँ फेंक दूँगा।

@vortexofdoom पहले से ही यही होता है। Node2D सभी 2D नोड्स द्वारा विरासत में मिला है, और Spatial सभी 3D नोड्स द्वारा विरासत में मिला है। सवाल यह है कि सब कुछ क्या कहा जाए।

और, अधिक महत्वपूर्ण बात, दोनों Spatial और Node2D से विरासत Node ।

मैं कहूंगा कि @vortexofdoom के विचार में अभी भी कुछ है जो केवल वर्ग पदानुक्रम द्वारा कवर नहीं किया गया है, लेकिन मैं यह निर्धारित नहीं कर सकता कि यह वास्तव में क्या है।

बस सोच रहा था: क्या आपको लगता है कि सभी Resource -व्युत्पन्न कक्षाओं में - Res प्रत्यय जोड़ना फायदेमंद होगा?

@aaronfranke मैं प्रत्येक प्रकार के नोड (सिर्फ किनेमेटिकबॉडी या स्प्राइट) में से एक होने के विचार का जिक्र कर रहा हूं, और शीर्ष किसी प्रकार का Node2D3D जो उनके व्यवहार को निर्देशित करता है। क्षमा करें अगर इसे अच्छी तरह से समझाया नहीं गया था। इसलिए 2D पदानुक्रम और 3D पदानुक्रम होने के बजाय, हमारे पास 2D/3D पदानुक्रम होगा। इसलिए मैंने कहा कि यह शायद स्वीकार्य से बड़ा रिफ्लेक्टर होगा।

यह मूल प्रकारों को अपने आप में प्रयोग करने योग्य नहीं होने से काम कर सकता है, लेकिन उन्हें वास्तविक नोड होने के लिए 2D/3D के रूप में लागू करने की आवश्यकता है, इस मामले में हम नोड नामों पर वर्ग एक पर वापस आ गए हैं लेकिन विरासत अधिक है 2D और 3D के बीच स्वचालित रूप से प्रत्यक्ष और संबंधित और सिस्टम के बीच परस्पर क्रिया अभी भी अच्छी होगी (मुझे लगता है)।

@vortexofdoom लेकिन वास्तव में 2D और 3D के बीच कुछ भी साझा नहीं किया जाता है। उनके पास कुछ समान नोड प्रकार हो सकते हैं और समान विधि नाम हो सकते हैं, लेकिन लगभग सभी कार्यान्वयन पूरी तरह से अलग हैं। मैं सबसे अधिक साझाकरण की अपेक्षा कर सकता हूं, एक इंटरफ़ेस होगा, क्योंकि आपके विचार में if (is2d) { do 2d stuff } else { do 3d stuff } होगा और कोड फ़ाइलों को दो बार लंबा और बिना किसी लाभ के बहुत अपठनीय बना देगा।

परिवर्तनीय व्यवहार वाले एकल वर्गों की व्यवहार्यता निश्चित रूप से इस बात पर निर्भर करती है कि शीर्ष-स्तरीय 2D/3D नोड कितना भारी भारोत्तोलन कर सकता है, जिससे अमूर्तता और नीचे जा सकती है। कक्षाओं को मैश करना क्योंकि वे अब एक साथ मौजूद हैं, निश्चित रूप से परेशानी के लायक नहीं होंगे, मुझे यकीन है। हालांकि, पुनर्गठन को पूरा करने के लिए मुझे इंटरफेस के उपयोग पर कोई फर्क नहीं पड़ता, फिर भी यह विभिन्न प्रकारों के मानकीकरण के कम से कम कुछ स्तर को लागू करेगा।

इस विचार को एक निष्क्रिय इच्छा से प्रेरित किया गया था कि मैं एक नोड के सामान्य संस्करण से प्राप्त कर सकता हूं, इसलिए मुझे एक परियोजना में दो बार सब कुछ लागू नहीं करना पड़ा जहां मेरे पास समानांतर में चलने वाला 2 डी और 3 डी संस्करण था। अभी, आपको नोड से इनहेरिट करना होगा और किसी भी तरह से ऐसा करने के लिए कुछ कास्टिंग करना होगा, क्योंकि नोड एकमात्र सामान्य पूर्वज है।

मुझे लगता है कि एक 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 क्योंकि कोई Basis2D क्योंकि यह सब Transform2D भीतर शामिल है।

@RandomShaper

बस सोच रहा था: क्या आपको लगता है कि सभी Resource -व्युत्पन्न कक्षाओं में - Res प्रत्यय जोड़ना फायदेमंद होगा?

हिरन के लिए थोड़ा बहुत धमाका लगता है। मैं कोड हाइलाइटिंग, tbh के लिए अपने सुझाव (#31054) में संसाधन शामिल करने के लिए वोट देना चाहूंगा। जैसे ही आप कक्षा का नाम टाइप करना समाप्त करते हैं, उन्हें एक अलग रंग पर रखना उनके आधार प्रकार को प्रतिबिंबित करेगा (जैसे कि अंतर्निहित प्रकार जैसे वेक्टर और एएबीबी)।

2D और 3D के लिए अलग-अलग परियोजनाओं के बारे में क्या।

(छवि सुझाव पर 2d को UI से और 3d को सीन से बदलने के लिए)।

जब आप प्रोजेक्ट शुरू करते हैं तो आप चुनते हैं कि आप किस पर काम करेंगे।
वर्ग नामों में अधिक प्रत्यय (2D, 3D) की आवश्यकता नहीं है।

तो इस तरह नेमस्पेसिंग बना रहे हैं, और उन प्रकारों के बीच कोई और मिश्रण नहीं है:

Godot2D का उपयोग करना;
Godot3D का उपयोग करना;

जब आप ३डी या २डी प्रोजेक्ट में हों - यूआई पर क्लिक करें तो आपको जीयूआई संपादित करने के लिए यूआई (२डी) विंडो मिलती है, जब सीन पर क्लिक करते हैं - आप सीन में होते हैं (२डी या ३डी प्रोजेक्ट प्रकार पर निर्भर करता है)।

तो ऐसे में हम किसी भी प्रोजेक्ट में UI के लिए 2d मोड रखते हैं, लेकिन सीन 2d या 3d विंडो खोलता है

इस विंडो में केवल प्रोजेक्ट प्रकार (2d या 3d) से संबंधित निकाय उपलब्ध होंगे या यदि वे दोनों में उपयोग कर रहे हैं तो साझा किए जाएंगे

जब आप UI मोड पर होते हैं, तो नया नोड जोड़ने पर यह विंडो केवल UI से संबंधित घटकों के साथ दिखाई देती है।
जब दृश्य मोड में UI नियंत्रण नहीं दिखाया जाता है, तो केवल वे चीज़ें जिन्हें आप दृश्य पर लागू कर सकते हैं

@dmitryuck आपके द्वारा पोस्ट की गई छवि के लिए, 2D बटन हमेशा आवश्यक होता है, क्योंकि 3D गेम को भी UI और सामान के लिए गोडोट के 2D मोड का उपयोग करने की आवश्यकता होगी। और वैसे भी 2D और 3D को मिलाने में सक्षम होना वांछनीय है। तकनीकी रूप से 2D गेम में 3D बटन का उपयोग करने की आवश्यकता नहीं होती है, लेकिन इसे छिपाना शायद ही आवश्यक हो।

मैंने ऊपर सुझाव दिया था कि हम नेत्रहीन अनावश्यक प्रत्ययों से बचने के लिए नोड नामों को पदानुक्रम में कॉस्मेटिक रूप से बदल सकते हैं, लेकिन यह बेहतर होगा कि कोड हमेशा स्पष्ट हो।

@aaronfranke मैंने अपनी पिछली टिप्पणी में जो कुछ भी कहा था उसका थोड़ा व्यापक स्पष्टीकरण जोड़ा है।

मुझे लगता है कि परिस्थितियों के आधार पर अलग-अलग नोड्स के नाम प्रदर्शित करने से भ्रम की स्थिति पैदा होगी।

लोगों को स्क्रिप्ट और सीन ट्री को पहली नजर में समझने में सक्षम होना चाहिए। मुझे लगता है कि सहयोग, स्पष्ट ट्यूटोरियल आदि के लिए यह जरूरी है।

@dmitryuck कुछ परियोजनाओं में 2D और 3D को मिलाने की आवश्यकता हो सकती है, और कुछ खेलों में 3D में UI होते हैं।

@Skaruts इस संपादक की तरह घटक को लागू करके 3D दृश्य में 2d दृश्य में स्विच करना संभव है

यूआई मोड, निश्चित रूप से, दोनों प्रकार की परियोजनाओं में मौजूद होना चाहिए, लेकिन यह एक अलग विंडो हो सकती है जिसमें विशेष रूप से यूआई के लिए बनाए गए उपकरण जैसे ग्रिड, उन्नत स्नैपिंग, शासक आदि शामिल हैं।

@reduz नामकरण अच्छी बात है, लेकिन उदाहरण के लिए 4.0 से 5.0 तक लंबी संक्रमण अवधि होनी चाहिए, क्योंकि यह https://godotengine.org/qa से बहुत सारे ट्यूटोरियल और उत्तरों को पुराना कर देता है

@xxmatxx अगर पुराने नामों को 'क्या होगा' को खींचने से रोकने के लिए नाम एक छोटी ट्रांज़िशन अवधि के साथ हुआ तो मैं पसंद करूंगा।
साथ ही, मैं परिवर्तनों को अच्छी तरह से प्रलेखित करना सुनिश्चित करता हूं और यह सुनिश्चित करता हूं कि जो लोग अभी-अभी गोडोट में फंस रहे हैं, वे परिवर्तनों के बारे में जानते हैं। एक इन-एडिटर चेतावनी आपको सूचित करती है कि आप नोड नामों के बहिष्कृत संस्करण का उपयोग कर रहे हैं, यह भी उपयोगी होगा यदि कुछ लोग इसके बारे में भूल जाते हैं।

मैं मानता हूं, इसमें जितना अधिक समय लगेगा, लोगों को भ्रमित करने का मौका उतना ही अधिक होगा। ट्यूटोरियल और डॉक्स तुरंत पुराने नहीं होंगे, जैसे @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 को देखते हुए, बढ़ाएँ:
प्रमुख संस्करण जब आप असंगत एपीआई परिवर्तन करते हैं,
माइनर संस्करण जब आप पश्च-संगत तरीके से कार्यक्षमता जोड़ते हैं, और
जब आप पश्च-संगत बग फिक्स करते हैं तो PATCH संस्करण।

आप इसके साथ कितनी दूर जाएंगे?

क्या ग्रिडमैप फिर टाइलमैप3डी बन जाएगा, और उदाहरण के लिए तिलमैप टाइलमैप2डी?

इसके अलावा, node2D और node3D थोड़ा सामान्य लगते हैं, तो Spatial2D और Spatial3D क्यों नहीं हैं?

मुझे लगता है कि एक बड़ा यूएक्स अंतर भी नियंत्रण, नोड 2 डी और स्थानिक होगा, जो कुछ भी उनका नाम होगा, सीधे नए नोड संवाद में नोड के नीचे पहुंच योग्य होगा, हालांकि नोड 2 डी और नियंत्रण कैनवासइटम से प्राप्त होता है। आप वैसे भी कैनवासइटम को सीधे पेड़ पर नहीं जोड़ सकते हैं, इसलिए हो सकता है कि यह उस संवाद में दिखाई न दे।

और जहाँ तक तरीके जाते हैं, मुझे लगता है कि उन पर 2D या 3D पोस्टफ़िक्स जोड़ने की कोई आवश्यकता नहीं है, क्योंकि आप जानते हैं कि आप उन्हें क्या कहते हैं?

मुझे अभी भी कुछ उपयोगी अपडेट करने की उम्मीद है, जैसे संसाधनों के धीमे आयात को संबोधित करना, और जीडी स्क्रिप्ट का प्रदर्शन अनुकूलन। वर्तमान में, 1G संसाधनों को आयात करने में लगभग एक घंटे का समय लगता है। यदि आप 10G संसाधन आयात करते हैं, तो आपको कंप्यूटर के सामने बैठकर दो दिन सोना होगा। हालाँकि, 700M-1G आयात का संसाधन संपादक फ़ाइल सिस्टम ब्राउज़र अब टूट गया है, और कुछ भी प्रदर्शित नहीं होगा। फ़ाइल सूची, यह स्वयं संपादक की कमियाँ हो सकती हैं, इसलिए मुझे लगता है कि मौजूदा समस्याओं का अनुकूलन और समाधान गोडोट के लिए बेहतर तरीका है। अगर मैं केवल 100-500M संसाधन आयात कर सकता हूं, तो यह तय है कि गोडोट बड़े खेल विकसित नहीं कर सकता है, लेकिन मेरा रास्ता अब अवरुद्ध है और मैं आगे नहीं बढ़ सकता। आशा है कि अगला संस्करण ऐसी समस्याओं का समाधान करेगा, मैं गोडोट के बेहतर और बेहतर होने की कामना करता हूं!

@qq715152910 कृपया पूरी तरह से असंबंधित जानकारी वाले लंबे धागों पर टिप्पणी न करें। इस मुद्दे पर टिप्पणी करने वाले प्रत्येक व्यक्ति को एक पिंग प्राप्त होगा और आपकी टिप्पणी का नोड्स का नाम बदलने के प्रस्ताव से कोई लेना-देना नहीं है। नतीजतन, मैं आपकी टिप्पणी छुपा रहा हूँ।

मैं कुछ नामकरण के बारे में अपनी राय दूंगा जो हमारे लिए उपयोगी होगा (हम मुख्य रूप से सी # का उपयोग करते हैं)

नाम बदलने का हम दृढ़ता से सुझाव देते हैं:

1. Transform.origin -> transform.origin

(ट्रांसफॉर्म प्रॉपर्टी लोअरकेस तक पहुंच बनाना)

क्यों?
उदाहरण के लिए स्थानिक में ट्रांसफ़ॉर्म होता है जिसे हम एक्सेस कर सकते हैं, लेकिन कई बार हम बेहतर पठनीयता के लिए "this.Transform.origin" लिखते हैं, अगर हम "ट्रांसफ़ॉर्म" को "ट्रांसफ़ॉर्म" में बदलते हैं, तो हमें "यह" सभी का उपयोग करने की आवश्यकता नहीं होगी। समय। यह हमारी निजी राय है।

1. हम "लेबल" को "टेक्स्टलेबल" जैसी किसी चीज़ में बदलने का भी समर्थन करते हैं। या कम से कम जब हम नया नोड जोड़ते समय "टेक्स्ट" द्वारा खोजते हैं, तो "लेबल" दिखना चाहिए, क्योंकि यह पूरी तरह से संबंधित है।

2. कुछ पूर्वनिर्धारित रंगों के लिए स्थिरांक को Color के विपरीत Colors साथ एक्सेस किया जाना चाहिए।

प्रस्तावित नाम बदलने के बाकी हिस्सों के लिए हम आगे देखते हैं कि समुदाय क्या बेहतर सोचता है।

एटलसटेक्सचर -> टेक्सचरएटलस

इसे एटलसटेक्चर नाम दिया गया है क्योंकि यह सामान्य <Type>Texture सम्मेलन का पालन करता है जहां <Type> Image , Viewport , Stream , ...

एटलसटेक्सचर -> टेक्सचरएटलस

इसे एटलसटेक्चर नाम दिया गया है क्योंकि यह सामान्य <Type>Texture सम्मेलन का पालन करता है जहां <Type> Image , Viewport , Stream , ...

जब मैं "एटलस" टाइप करता हूं तो यह दिखाई देता है।

ऐसा तब होता है जब हम Texture टाइप करते हैं:

संपादित करें: हम समझते हैं कि सम्मेलन क्यों। दूसरे स्क्रीनशॉट में, AtlasTexture अन्य चीजों के साथ बहुत कमजोर है जो <Type>Texture सम्मेलन का पालन करते हैं। उसके बाद, उस बिंदु को हमारी पिछली पोस्ट से हटा दिया गया था। इस विशेष मामले के लिए अभी भी बहुत स्वत: पूर्णता अनुकूल नहीं है। लेकिन हम इसे स्वीकार करते हैं। .

@bigmonte इस मुद्दे के अनुसार गोडोट 4.0 में Transform संरचना का नाम बदलकर Transform3D कर दिया जाएगा, इसलिए अब आपको यह स्पष्ट करने के लिए this. आवश्यकता नहीं होगी कि यह एक संपत्ति है।

संपादित करें: https://github.com/godotengine/godot/pull/38430

कुछ पूर्वनिर्धारित रंगों के लिए स्थिरांक को Color के विपरीत Colors साथ एक्सेस किया जाना चाहिए।

मैं वह हूं जिसने प्रस्तावित किया कि पहली जगह में, और मैं दृढ़ता से असहमत हूं। उन्हें अलग रखना बेहतर है, क्योंकि यह Color के स्थिर सदस्यों (वर्तमान में Color8 , ColorN , और FromHsv ) की खोज क्षमता को बढ़ाता है जब स्वत: पूर्ण का उपयोग करते हैं विभिन्न आईडीई। मैं निरंतरता के लिए GDScript में Color.red आदि -> Colors.RED का नाम बदलने का प्रस्ताव करने पर भी विचार कर रहा हूं।

वैसे, मुझे लगता है कि आप #16863 की तलाश में थे।