भौतिकी इंजन के डिजाइन की कल्पना कैसे करें?


17

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

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

तो, मुझे इस प्रक्रिया का ट्रैक रखने में मदद करने के लिए किस तरह के आरेख का उपयोग करना चाहिए? भौतिकी इंजन बनाने के लिए किस तरह के आरेख प्रोफेशनल्स का उपयोग किया जाता है?


4
सबसे पहले, मैं एक उच्च-स्तरीय प्रवाह आरेख का सुझाव दूंगा, यह दिखाने के लिए कि इंजन का उपयोग कैसे किया जाता है और यह चीजों का मूल्यांकन कैसे करता है। या शायद OpenGL पाइपलाइन आरेख ( openglinsights.com/pipeline.html ) के समान कुछ । फिर, मैं "भौतिक विज्ञान इंजन आरेख" के लिए एक Google छवियां खोजूंगा, यह देखने के लिए कि अन्य लोग इसे कैसे करते हैं! ;)
फ्रस्ट्रेटेडविथफॉर्म्सडिजेनर

4
"एक यूएमएल आरेख" से आप शायद एक वर्ग आरेख का मतलब है? क्लास आरेख यूएमएल में 7 संरचनात्मक आरेखों में से एक है। 7 प्रकार के व्यवहार आरेख भी हैं।
से आ

सबसे पहले, आपको भौतिकी इंजन की बहुत अच्छी समझ होनी चाहिए; हर छोटी विस्तार और चीजें एक साथ कैसे काम करती हैं। प्रोग्रामिंग से कोई लेना-देना नहीं। फिर, आप इसे प्रोग्रामिंग संस्थाओं (कक्षाओं) और इंटरैक्शन में मॉडल करने का प्रयास करते हैं। आप जो भी उपकरण पसंद करते हैं (यहां तक ​​कि रेखाचित्र और हाथ से लिखे नोट्स भी) का उपयोग कर सकते हैं। फिर, आप एक समय में एक कक्षाएं बनाते हैं। कंसोल एप्लिकेशन लिखकर प्रारंभ करें। आप यह सुनिश्चित करने के लिए इकाई / कक्षा परीक्षणों का उपयोग कर सकते हैं कि आपकी छोटी कक्षाएँ काम करती हैं और आप जो अपेक्षा करते हैं
जॉन कौराकेलिस

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

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

जवाबों:


29

TO सूचियां अद्भुत चीजें हैं।

मैं // #TODO: blah blah comments की बात नहीं कर रहा हूँ। मेरा मतलब है कि भगवान के लिए एक ईमानदार हो नोटबुक।

आप कभी नहीं जानते कि आपको कब कुछ करना याद होगा। एक नोटबुक चुपचाप वहाँ बैठेगी और आपको बिना किसी शिकायत के यह सोचने में मदद करेगी कि आपकी लिखावट कैसे संकलित है। मेरे सबसे अच्छे विचारों में से कुछ बाथरूम में होते हैं (हाँ, मैं एक वाटर प्रूफ नोटबुक का मालिक हूं लेकिन आपको उस दूर जाने की ज़रूरत नहीं है)।

आप पॉकेट के आकार वाले पा सकते हैं जो सिलना (सरेस से जोड़ा हुआ) नहीं हैं ताकि वे आपकी जेब में न गिरें। बिल्ट इन द मार्क के साथ एक फैंसी पाने का प्रबंधन नहीं किया? टेप, कैंची, रिबन और किसी को भी कभी पता नहीं चलेगा।

जब कोई विचार हिट होता है तो उसे नीचे दबाएं। प्रत्येक विचार के बगल में छोटे बक्से बनाएं और आप इसे आसानी से चिह्नित कर सकते हैं। पृष्ठ के शीर्ष पर एक बॉक्स रखें और आप जानते हैं कि पृष्ठ कब किया जाता है।

क्या अनुक्रमिक पहुँच आपके लिए पर्याप्त नहीं है? हाँ, वे पॉकेट बाइंडर भी बनाते हैं। यह सब थोड़ा बहुत लग सकता है लेकिन यह नोटों में डूबने से बेहतर है या जीरा में सब कुछ पकड़ने की कोशिश करना।

आधी चीजें लागू न करें

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

यह सोचना बंद करें कि आपको कागज पर पूरे डिजाइन की आवश्यकता है

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

जब आप कोड करना बंद कर दें तो नोट्स लिखें

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

इस तरह से आप अपने मस्तिष्क को इनायत से जमीन पर उतार सकते हैं, अपने मूत्राशय को बचा सकते हैं, और बाद में कैफीन और दांतों को काटे बिना सहारा ले सकते हैं।


(एक ईमानदार नोटबुक के रूप में, जो स्मार्ट भी है, Emacs Org मोड अच्छी तरह से काम करता है। एक समान टूल, यहां तक ​​कि एक मुद्दा ट्रैकर भी प्रक्रियाओं के आधार पर अच्छी तरह से काम कर सकता है। एक पेपर नोटबुक चारों ओर ले जाने के लिए बहुत अच्छा है, और यह त्वरित चार्ट के लिए अनुमति देता है। चित्र, जो सोचते समय बहुत अच्छा है ।)
9000

6
के लिए +1 Don't start anything that can't be finished in one sitting. If it's to big for that then break it down into smaller steps.। यह सबसे महत्वपूर्ण चीजों में से एक है जिसे मैंने उद्योग में सीखा है।
महाजुन

8

"सब कुछ ऊपर-नीचे बनाया जाना चाहिए, पहली बार को छोड़कर," वे कहते हैं।

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

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

उम्मीद है कि प्रत्येक परत इतनी छोटी है कि आपको इसके लिए एक जटिल आरेख की आवश्यकता नहीं है, या किसी उपयोगी के साथ आना आसान है।

मैंने कभी भी एक जटिल कोड आरेख का सामना नहीं किया है जो उपयोगी था। बातचीत और जीवन चक्र चित्र उपयोगी होते हैं, हालांकि। काफी बार ऐसा डायग्राम होता है, जो 1-2 परतों पर विवश होता है, और इस तरह सरल होता है।

आमतौर पर मुझे जो सबसे अधिक मूल्यवान लगता है वह है इंटरफ़ेस विवरण और प्रत्येक स्तर द्वारा प्रदान की गई गारंटी। जैसे सदिश गणित का प्रारूप, और संख्यात्मक त्रुटियों पर क्या होता है; बड़ी वस्तुओं के विवरण का प्रारूप (हमेशा उत्तल; हमेशा क्लॉकवाइज-ओरिएंटेड ?, इंटरसेक्ट कैसे करें? आदि), इंटरैक्शन के मैकेनिकल पैरामीटर (समय कैसे आगे बढ़ता है? कैसे बड़े पैमाने पर संभाला जाता है? गति हमेशा संरक्षित रहती है? बलों की गणना कैसे की जाती है? तब गणना करें उचित बातचीत (घर्षण को कैसे संभालना है? विरूपण? विखंडन? गर्मी में यांत्रिक ऊर्जा एक चीज को नुकसान?)।

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


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

4

वास्तुकला के चित्र बनाओ! ओपन पाइपलाइन आरेख FrustratedWithFormsDesigner पोस्ट में टिप्पणी कार्यक्रम के लिए एक महान उदाहरण हैं प्रवाह , लेकिन उस चित्र का केवल एक प्रकार है कि उपयोगी हो सकता है है।

आरेख डिजाइन करते समय, आप कोड को सरल और सहज समझना चाहते हैं ; यह दोनों उच्च-स्तरीय अवधारणाओं को शामिल कर सकता है (जैसे कि OpenGL पाइपलाइन आरेख में नोड्स की शीर्ष रेखा, कुछ कहते हुए) या बहुत बारीक, तकनीकी विवरण (जैसे एक पूर्ण फ़ंक्शन कॉल ग्राफ़)।

आदर्श रूप से, आपके दस्तावेज़ को अन्य लोगों को समझने के लिए कोड को आसान बनाना चाहिए; यह कोड समीक्षा या ओपन-सोर्स सहयोग जैसी चीजों को आसान बना सकता है। बड़ी परियोजनाओं को देखें कि वे इसे कैसे पूरा करते हैं - कोड की सैकड़ों-हजारों या लाखों लाइनों के साथ काम करते समय, यह समझना कि प्रोग्राम को बिना पढ़े कैसे काम करता है यह कोडबेस का ट्रैक रखने या इसे दूसरों से परिचित कराने के लिए बड़े पैमाने पर महत्वपूर्ण है। । 1.3 मिलियन LOC के साथ विम रिपॉजिटरी के पास /src/README.txt में इसके लिए बहुत बढ़िया उच्च-स्तरीय प्रलेखन (IMO) है । यह परिचय देता है:

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

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

विम के बारे में सबसे अच्छी विशेषताओं में से /src/README.txtएक यह खोजना कितना आसान है और यह कितना व्यापक है; यह किसी भी मायने में दानेदार नहीं है, लेकिन यदि आप srcजीथब पर फ़ोल्डर को स्वचालित रूप से लोड करते हैं, और यह अन्य कोड या प्रलेखन खोजने के लिए दिशा देता है। इसके विपरीत, पॉवर्सशेल रेपो के साथ, जिसे मैंने एक उदाहरण के लिए देखा था लेकिन विम के लिए कोई समकक्ष फाइल या फाइल नहीं मिल पाई थी /src/README.txt। (988 हजार LOC वाली परियोजना के लिए एक बुरा संकेत!)

कुछ चीजें जिन्हें आप आरेख या दस्तावेज़ में शामिल करना चाहते हैं, उनमें शामिल हैं:

  • वैचारिक कार्यक्रम प्रवाह (कार्यक्रम क्या पूरा करता है , और किस क्रम में?)
  • कार्यान्वित प्रोग्राम फ्लो / फंक्शन कॉल ग्राफ (प्रोग्राम अपने लक्ष्यों को कैसे पूरा करता है? कार्यों को क्या कहते हैं या बनाई गई कक्षाएं?)
  • क्या कोड क्या फ़ाइलों में है? संगठनात्मक योजना क्या है और एक नया कार्य कहाँ जाता है, यह निर्धारित करने के लिए आपके पास क्या नियम हैं? यदि आपके पास एक मजबूत संगठनात्मक योजना है, तो यह जानना कि किसी दिए गए फ़ंक्शन या वर्ग को देखने के लिए कौन सी फ़ाइल आसान है, यहां तक ​​कि बिना आईडीई या आईडीई-जैसे "प्रोजेक्ट-वाइड" सुविधा भी मिल सकती है।
  • संबंधित, कौन सी फाइलें शामिल हैं जो अन्य फाइलें (फ़ंक्शन कॉल ग्राफ़ से संबंधित) हैं?
  • कौन सी कक्षाएं अन्य वर्गों से विरासत में मिली हैं? प्रत्येक वर्ग का उद्देश्य क्या है?

आप उन आरेखों को कैसे बना सकते हैं? अपने स्तर पर, और पहले ड्राफ्ट के लिए, पेंसिल और पेपर शायद सबसे अच्छा / सबसे तेज़ तरीका है। जब आरेख और प्रलेखन अधिक परिष्कृत हो जाते हैं, तो आप इस पर गौर कर सकते हैं:

  • डॉट / ग्राफविज़, .dotफाइलों से ग्राफ बनाने के लिए कार्यक्रमों का एक सेट ।
  • LaTeX / TikZ, ग्राफ़ या किसी भी प्रकार के चित्र बनाने के लिए एक बहुत ही जटिल और क्रियात्मक उपकरण है - यह आपकी आवश्यकताओं के लिए बहुत अधिक हो सकता है, विशेष रूप से सभी नोड पोजीशनिंग मैनुअल है, लेकिन इसे ध्यान में रखा जाना चाहिए, खासकर यदि आप लिखने की योजना बनाते हैं कागज या उस तरह का कुछ भी बाद में।
  • C के लिए, gson's egyptहुक में gccऔर .dotकॉल ग्राफ को आउटपुट करता है । स्वचालित या एक makeकमांड में एम्बेड किया जा सकता है , जो अच्छा है!
  • संबंधित रूप से, GNU cflowC. के लिए केवल-पाठ कॉल ग्राफ़ उत्पन्न कर सकता है। अन्य भाषाओं के लिए समतुल्य उपकरण मौजूद हो सकते हैं, हालाँकि आप सामान्य रूप से स्वचालित उपकरणों से भटकना चाह सकते हैं - मैन्युअल रूप से ग्राफ़ न बनाना, कोड की आपकी समझ में बाधा उत्पन्न कर सकता है या अनुचित रूप से प्रदान कर सकता है। विस्तार के जटिल स्तर (यह जानते हुए कि कौन से कार्य कॉल printf()आमतौर पर बहुत अनपेक्षित हैं)।

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

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

0

पेट्री नेट पर आधारित आरेख का उपयोग करने का प्रयास करें। कंप्यूटर कार्यक्रमों में आरेख को व्यवस्थित तरीके से अनुवाद करना संभव है, और निम्न-स्तरीय आरेखों के साथ उच्च-स्तरीय आरेखों को एकीकृत करना संभव है।

संदर्भ

नेट एलिमेंट्स एंड एनोटेशन्स: ए-पर्पस विज़ुअल प्रोग्रामिंग लैंग्वेज (2016)। Https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language पर उपलब्ध ।

कंप्यूटर प्रोग्रामिंग के लिए नेट एलीमेंट्स एंड एनोटेशन्स: पीडीएफ (2014) में कम्प्यूटेशन और इंटरेक्शन। पर उपलब्ध है https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.