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

प्रयुक्त शब्द

• मार्क या मार्कर - एआर-इंजन में लोड की गई एक छवि, जिसे डिवाइस के कैमरे (टैबलेट या स्मार्टफोन) से पहचाना जाता है और विशिष्ट पहचान की जा सकती है

  
  

• मिला - मार्कर स्थिति जब इसे कैमरे के देखने के क्षेत्र में पता चला था

  
  

• खोया - मार्कर राज्य जब यह कैमरे के दृश्य से खो गया था

  
  

• इसे प्रदर्शित किया जा सकता है - जब मार्कर पाया जाता है, तो हम मार्कर से जुड़ी सामग्री को प्रदर्शित करते हैं

  
  

• प्रदर्शित नहीं किया जा सकता है - जब हम मार्कर पाते हैं, तो सामग्री को प्रदर्शित नहीं करते हैं - मार्कर से जुड़ी सामग्री - किसी भी वस्तु (3 डी मॉडल, स्प्राइट, कण प्रणाली, आदि) जो मार्कर से जुड़ी हो सकती है और, जो, तदनुसार, प्रदर्शित की जाएगी। यदि स्क्रीन पर मार्कर पाया जाता है

  
  

• मार्क, मार्कर, पाया, खो गया - सभी राज्यों में अंतर्निहित राज्य जो मान्यता कार्यक्षमता प्रदान करते हैं

  
  

• यह प्रदर्शित किया जा सकता है और प्रदर्शित नहीं किया जा सकता है - इस समस्या को हल करने के लिए उपयोग किया जाने वाला राज्य

  
  

  एक उदाहरण:

  
  
  • एप्लिकेशन डाउनलोड करें => सभी डाउनलोड किए गए ब्रांड पहचानने योग्य हैं
  • हम पहचानने की कोशिश कर रहे हैं => मार्कर की स्थिति "पाया" में बदल जाती है
  • यदि मार्कर को प्रदर्शित किया जा सकता है => राज्य को "पाया" कहा जाता है और हम मार्कर से जुड़े मॉडल को प्रदर्शित करते हैं
  • यदि मार्कर प्रदर्शित नहीं किया जा सकता है => मार्कर की स्थिति "मिली" है, लेकिन संलग्न मॉडल प्रदर्शित नहीं किया गया है
  • कैमरे के देखने के क्षेत्र से ब्रांड गायब हो गया = हम राज्य को "खो" में बदल देते हैं
  
  

परिचय

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

• एक पूर्ण कोने का निशान (1)
• नीचे की ओर के निशान का एक आधा (5)
• शीर्ष पक्ष के निशान का एक आधा (8)
• क्वार्टर सेंटर मार्क (9)

यदि आपने किसी मान्यता इंजन के साथ काम किया है, उदाहरण के लिए, वुफोरिया, तो आप शायद जानते हैं कि "मान्यता गुणवत्ता" जैसी कोई चीज नहीं है। निशान या तो पहचाना जाता है या नहीं पहचाना जाता है। तदनुसार, यदि इंजन "ब्रांड" देखता है, तो वह स्थिति को Find लिए बदल जाता है और OnSuccess() विधि OnSuccess() , अगर यह "खो" जाता है, तो राज्य Lost बदल जाता है और OnLost() विधि OnLost() । तदनुसार, मौजूदा स्थितियों और इनपुट डेटा से, कार्ड के एक हिस्से (आधा या एक चौथाई) होने पर एक स्थिति उत्पन्न हुई, जिससे ब्रांड को पहचानना संभव हो गया।

बात यह है कि तकनीकी कार्य के अनुसार, वर्णों के क्रमिक अनलॉकिंग की योजना बनाई गई थी। इस स्थिति में, एक क्रमिक अनलॉकिंग संभव है, लेकिन यह देखते हुए कि ऐसे लोग नहीं हैं जो ब्रांड के एक चौथाई या आधे हिस्से को पहचानने की कोशिश करते हैं।

कार्य विवरण

प्रोग्राम कोड के रूप में तर्क को लागू करना आवश्यक है, जो मार्करों से जुड़ी सामग्री के क्रमिक अनलॉकिंग को सुनिश्चित करता है। कार्ड पर तत्वों के स्थान से यह ज्ञात है कि मार्कर 1, 2, 3, 4 शुरू में प्रदर्शित करने के लिए उपलब्ध हैं।

यदि सामग्री को 2 मार्करों पर पढ़ा और प्रदर्शित किया गया है, उदाहरण के लिए, 2 और 3, तो हम मार्कर 6 पर सामग्री को प्रदर्शित करने की अनुमति देते हैं। यदि मार्कर 1 अभी तक पढ़ा नहीं गया है, तो मार्कर 5 तक पहुंच बंद है। सादृश्य द्वारा आगे। हम साइड मार्करों पर सामग्री प्रदर्शित करने की अनुमति तभी देते हैं जब हमने आसन्न कोने मार्करों को पढ़ा हो।

यदि 1 से 8 तक के मार्कर उपलब्ध हैं और पाए जाते हैं, तो प्रदर्शन के लिए मार्कर 9 पर सामग्री खोलें। प्रत्येक मार्कर में 2 राज्य हैं - सामग्री उपलब्ध है और प्रदर्शन के लिए उपलब्ध नहीं है, जिसके लिए public bool IsActive; फ़ील्ड जिम्मेदार है public bool IsActive;

यह तुरंत स्पष्ट है कि यह या तो राज्यों के बीच एक संक्रमण के साथ एक राज्य मशीन होना चाहिए, या "राज्य" पैटर्न का कार्यान्वयन होना चाहिए।

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

स्पष्टता के लिए, मैंने एक वीडियो रिकॉर्ड किया जिस पर एल्गोरिथम का अंतिम परिणाम (यदि आप इसे कॉल कर सकते हैं) पहले से ही कब्जा कर लिया गया है।

समाधान दृष्टिकोण

1. कोने मार्करों से केंद्र तक

पहली बात जो दिमाग में आई वह थी कोने से केंद्र तक मार्करों के बीच की बातचीत को पेश करना। चित्रमय रूप में, यह इस तरह दिखता है:

समस्याएं:

1. राज्य को बदलने के लिए किस पक्ष के लेबल का निर्धारण कैसे करें? बाईं तरफ या दाईं ओर एक? हम प्रत्येक मार्कर को एक केंद्रीय अस्तित्व के बारे में "पता" करने के लिए मजबूर करते हैं।
2. श्रेणी से गैर-स्पष्ट निर्भरता जोड़ना आवश्यक है: साइड मार्कर IsChangedEventCallback () कोने मार्कर इवेंट की सदस्यता लेता है, केंद्रीय मार्कर के लिए भी इसी तरह की कार्रवाई की जानी चाहिए।
3. यदि हम प्रत्येक प्रकार के मार्कर को एक इकाई मानते हैं, तो इन संस्थाओं के पदानुक्रम में हम नीचे से ऊपर तक राज्य-परिवर्तन कमांड को अग्रेषित करेंगे। यह बहुत अच्छा नहीं है, क्योंकि हम कसकर खुद को संख्या के साथ बांधते हैं, इस मामले में, कोणीय मार्कर, स्केल करने की क्षमता खो देते हैं।

कई किनारे के मामलों और धारणा की जटिलता के कारण उपरोक्त समाधान को मेरे सिर में रखने में असमर्थ, मैंने उस मार्कर को चुनने के दृष्टिकोण को बदल दिया, जिस पर निर्भरता फैलने लगती है।

2. पार्श्व को मध्य और कोने के बारे में पता है

पिछले दृष्टिकोण के पैराग्राफ 3 के समाधान के बारे में सोचकर, मार्कर के प्रकार को बदलने के लिए विचार आया, जिससे अन्य मार्करों की स्थिति बदलने लगती है। जैसा कि मुख्य साइड मार्करों को लिया गया था। इस परिदृश्य में, संचार (निर्भरताएँ) इस तरह दिखती हैं:

यहाँ से यह तुरंत स्पष्ट हो जाता है कि लेटरल से सेंट्रल तक के कनेक्शन बहुत कम हैं, क्योंकि लेटरल मार्कर को सेंट्रल मार्कर के बारे में कुछ भी जानने की आवश्यकता नहीं है, इसलिए यह दृष्टिकोण तुरंत अंतिम में बदल गया था।

3. केंद्रीय व्यक्ति सभी के बारे में जानता है, पक्ष वाले कोने के बारे में जानते हैं

अंतिम समाधान तब होता है जब साइड मार्कर कोनों के बारे में जानता है, कोने "अपना जीवन जीते हैं", और केंद्रीय एक सभी मार्करों की स्थिति के बारे में जानता है।

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

• कोण मार्कर - कोण नोड (स्तर 3)
• साइड मार्कर - साइड नोड (स्तर 2)
• केंद्र मार्कर - केंद्र नोड (स्तर 1)

फायदे:

1. मार्करों के बीच निर्भरता स्पष्ट और स्पष्ट है।
2. प्रत्येक स्तर को 3 संस्थाओं के रूप में दर्शाया जा सकता है, जिनमें से प्रत्येक में मूल भाग होते हैं, लेकिन उनके जोड़ प्रत्येक स्तर में निहित होते हैं
3. विस्तार करने के लिए, आपको केवल अपनी विशेषताओं के साथ एक नए प्रकार के नोड को जोड़ने की आवश्यकता होगी
4. यह समाधान एक OO (ऑब्जेक्ट-ओरिएंटेड) शैली में कल्पना करना आसान है

कार्यान्वयन

आधार संस्थाएँ

आइए एक इंटरफ़ेस बनाएं जिसमें प्रत्येक इकाई (नाम, स्थिति) में निहित तत्व शामिल हों:

 public interface INode { string Name { get; set; } bool IsActive { get; set; } } 

अगला, हम प्रत्येक नोड के सार का वर्णन करते हैं:

• कॉर्नरनोड - एक कोणीय नोड। बस INode इंटरफ़ेस लागू करें:

 public class CornerNode : INode { public string Name { get; set; } public bool IsActive { get; set; } public Node(string name) { Name = name; IsActive = true; } } 

क्यों IsActive = true ?

• साइडनोड - एक साइड नोड। हम INode इंटरफ़ेस को लागू करते हैं, लेकिन LeftCornerNode और RightCornerNode । इस प्रकार, साइड नोड अपने राज्य को अपने आप में रखता है और केवल साइड नोड्स के अस्तित्व के बारे में जानता है।

 public class SideNode : INode { public string Name { get; set; } public bool IsActive { get; set; } public CornerNode LeftCornerNode { get; } public CornerNode RightCornerNode { get; } public SideNode(string name, CornerNode leftNode, CornerNode rightNode) { Name = name; IsActive = false; LeftCornerNode = leftNode; RightCornerNode = rightNode; } } 

• CenterNode केंद्रीय नोड है। पिछले वाले की तरह, हम INode लागू INode । List<INode> का एक क्षेत्र जोड़ें List<INode> ।

 public class CentralNode : INode { public List<INode> NodesOnCard; public string Name { get; set; } public bool IsActive { get; set; } public CentralNode(string name) { Name = name; IsActive = false; } } 

ओपन क्लास

निजी तरीके और क्षेत्र

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

 private List<CornerNode> cornerNodes; private List<SideNode> sideNodes; private CentralNode centralNode; 

खेतों के साथ, सब कुछ काफी सरल है। कोणीय, साइड नोड्स और केंद्रीय नोड के एक क्षेत्र के साथ 2 सूचियां।

आगे आपको थोड़ा स्पष्ट करने की आवश्यकता है। तथ्य यह है कि मार्कर स्वयं Trackable और इसका कोई पता नहीं है (और नहीं होना चाहिए) कि यह वहां किसी अन्य तर्क का हिस्सा है। इसलिए, हम जो भी प्रदर्शन को नियंत्रित करने के लिए उपयोग कर सकते हैं वह उसका नाम है। तदनुसार, यदि मार्कर स्वयं उस नोड के प्रकार को संग्रहीत नहीं करता है जिसके अंतर्गत वह आता है, तो हमें इस जिम्मेदारी को अपने OpenCard वर्ग में स्थानांतरित करना होगा। इसके आधार पर, हम पहले 3 निजी तरीकों का वर्णन करते हैं जो नोड के प्रकार को निर्धारित करने के लिए जिम्मेदार हैं।

 private bool IsCentralNode(string name) { return name == centralNode.Name; } private bool IsSideNode(string name) { foreach (var sideNode in sideNodes) if (sideNode.Name == name) return true; return false; } private bool IsCornerNode(string name) { foreach (var sideNode in cornerNodes) if (sideNode.Name == name) return true; return false; } 

लेकिन इन तरीकों का सीधा मतलब नहीं है। जब आप अमूर्त के दूसरे स्तर की वस्तुओं के साथ काम करते हैं तो बुलियन मूल्यों के साथ काम करना सुविधाजनक नहीं होता है। इसलिए, हम एक सरल enum NodeType और एक निजी विधि GetNodeType() , जो नोड के प्रकार को निर्धारित करने से जुड़े सभी तर्क को अपने आप में GetNodeType() देता है।

 public enum NodeType { CornerNode, SideNode, CentralNode } private NodeType? GetNodeType(string name) { if (IsCentralNode(name)) return NodeType.CentralNode; if (IsSideNode(name)) return NodeType.SideNode; if (IsCornerNode(name)) return NodeType.CornerNode; return null; } 

सार्वजनिक तरीके

• IsExist एक ऐसी विधि है जो एक बूलियन मान लौटाती है जो दर्शाता है कि हमारा ब्रांड पोस्टकार्ड से संबंधित है या नहीं। यह एक सहायक विधि है, जो इसलिए की जाती है कि यदि मार्कर किसी कार्ड से संबंधित नहीं है, तो हम उस पर सामग्री प्रदर्शित कर सकते हैं।

 public bool IsExist(string name) { foreach (var node in centralNode.NodesOnCard) if (node.Name == name) return true; if (centralNode.Name == name) return true; return false; } 

• CheckOnActiveAndChangeStatus - एक विधि (जैसा कि नाम का अर्थ है) जिसमें हम नोड की वर्तमान स्थिति की जांच करते हैं और इसकी स्थिति बदलते हैं।

 public bool CheckOnActiveAndChangeStatus(string name) { switch (GetNodeType(name)) { case NodeType.CornerNode: foreach (var node in cornerNodes) if (node.Name == name) return node.IsActive = true; return false; case NodeType.SideNode: foreach (var node in sideNodes) if (node.LeftCornerNode.IsActive && node.RightCornerNode.IsActive) return true; return false; case NodeType.CentralNode: foreach (var node in centralNode.NodesOnCard) if (!node.IsActive) return false; return centralNode.IsActive = true; default: return false; } } 

डिजाइनर

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

 public OpenCard(List<CornerNode> listCornerNode, List<SideNode> listSideNode, CentralNode centralNode) { CornerNodes = listCornerNode; SideNodes = listSideNode; CentralNodes = centralNode; CentralNodes.NodesOnCard = new List<INode>(); foreach (var node in CornerNodes) CentralNodes.NodesOnCard.Add(node); foreach (var node in SideNodes) CentralNodes.NodesOnCard.Add(node); } 

ध्यान दें कि चूंकि केंद्रीय नोड को केवल इस स्थिति की जांच करने की आवश्यकता है कि अन्य सभी true नोड्स, यह हमारे लिए पर्याप्त रूप INode कोण और केंद्रीय नोड्स में INode करने के लिए है जो INode में INode प्रकार में आया है।

प्रारंभ

ऑब्जेक्ट्स बनाने के लिए सबसे सुविधाजनक तरीका क्या है जो MonoBehaviour लिए संलग्न होने की आवश्यकता नहीं है (जैसे MonoBehaviour घटकों)? - सही, ScriptableObject । इसके अलावा, सुविधा के लिए, MenuItem विशेषता जोड़ें, जो नए कार्ड के निर्माण को सरल करेगा।

 [CreateAssetMenu(fileName = "Open Card", menuName = "New Open Card", order = 51)] public class OpenCardScriptableObject : ScriptableObject { public string leftDownName; public string rightDownName; public string rightUpName; public string leftUpName; public string leftSideName; public string rightSideName; public string downSideName; public string upSideName; public string centralName; } 

हमारी रचना में अंतिम कॉर्ड जोड़ा (यदि कोई है) ScriptableObject और उनसे पोस्टकार्ड के निर्माण के माध्यम से एक मार्ग होगा। उसके बाद, यह हमारे लिए Update पद्धति में यह जांचने के लिए रहता है कि हम सामग्री प्रदर्शित कर सकते हैं या नहीं।

 public OpenCardScriptableObject[] openCards; private List<OpenCard> _cardList; void Awake() { if (openCards.Length != 0) { _cardList = new List<OpenCard>(); foreach (var card in openCards) { var leftDown = new CornerNode(card.leftDownName); var rightDown = new CornerNode(card.rightDownName); var rightUp = new CornerNode(card.rightUpName); var leftUp = new CornerNode(card.leftUpName); var leftSide = new SideNode(card.leftSideName, leftUp, leftDown); var downSide = new SideNode(card.downSideName, leftDown, rightDown); var rightSide = new SideNode(card.rightSideName, rightDown, rightUp); var upSide = new SideNode(card.upSideName, rightUp, leftUp); var central = new CentralNode(card.centralName); var nodes = new List<CornerNode>() {leftDown, rightDown, rightUp, leftUp}; var sideNodes = new List<SideNode>() {leftSide, downSide, rightSide, upSide}; _cardList.Add(new OpenCard(nodes, sideNodes, central)); } } } void Update() { var isNotPartCard = false; foreach (var card in _cardList) { if (card.IsExist(trackableName)) isNotPartCard = true; if (card.CheckOnActiveAndChangeStatus(trackableName)) imageTrackablesMap[trackableName].OnTrackSuccess(trackable); if (!isNotPartCard) imageTrackablesMap[trackableName].OnTrackSuccess(trackable); } } 

निष्कर्ष

मेरे लिए व्यक्तिगत रूप से, निष्कर्ष इस प्रकार थे:

1. किसी समस्या को हल करने की कोशिश करते समय, आपको इसके तत्वों को परमाणु भागों में तोड़ने की कोशिश करनी होगी। इसके अलावा, इन परमाणु भागों के बीच बातचीत के सभी संभावित विकल्पों पर विचार करते हुए, आपको ऑब्जेक्ट के साथ शुरू करने की आवश्यकता है, जिसमें से अधिक कनेक्शन संभावित रूप से आएंगे। एक अन्य तरीके से, इसे निम्न रूप में तैयार किया जा सकता है: ऐसे तत्वों के साथ समस्याओं को हल करने का प्रयास करना जो संभवतः, कम विश्वसनीय होंगे
2. यदि संभव हो, तो आपको स्रोत डेटा को एक अलग रूप में प्रस्तुत करने का प्रयास करना चाहिए। मेरे मामले में, ग्राफ प्रतिनिधित्व ने मुझे बहुत मदद की।
3. प्रत्येक इकाई को उन कनेक्शनों की संख्या से अलग किया जाता है जो संभावित रूप से इससे आ सकते हैं।
4. कई लागू किए गए कार्य जो एल्गोरिथ्म लिखकर हल करने के लिए अधिक प्रथागत हैं, उन्हें ओओ शैली में दर्शाया जा सकता है
5. एक समाधान जिसमें रिंग निर्भरता है, एक बुरा समाधान है
6. यदि आपके सिर में वस्तुओं के बीच सभी कनेक्शन रखना कठिन है, तो यह एक बुरा निर्णय है
7. यदि आप वस्तुओं की परस्पर क्रिया के तर्क को ध्यान में नहीं रख सकते हैं - यह एक बुरा निर्णय है
8. आपकी बैसाखी हमेशा एक बुरा निर्णय नहीं होती है

क्या आप एक और उपाय जानते हैं? - टिप्पणियों में लिखें।