قبل أقل من عام بقليل ، تم نشر منشور تحدثنا فيه عن مجمع التدريب والمختبرات (ULK) في القطار الكهربائي ES1 Lastochka الذي طورته جامعتنا. بعد ذلك وعدت بأن هذا لن يكون آخر منشور حول هذا الموضوع ، على وجه الخصوص ، لقد هددت بالتحدث عن مشاكل إنشاء تصور ثلاثي الأبعاد لمثل هذه المحاكاة وتحديد الخطوط العريضة للنُهُج الرئيسية لحلها.

في العام الماضي ، سررنا بالإصدار التالي - ULK من القطار الكهربائي عالي السرعة Sapsan EVS2 ، الذي حدث في أغسطس من العام الماضي. يستحق المجمع التعليمي والمختبري لهذا القطار الكهربائي نفسه قصة منفصلة ، لكن في سياق هذا المنشور سنتحدث عن الألم - مشكلة إنشاء نظام فرعي مناسب للتصور ثلاثي الأبعاد ، والذي تناوله فريقنا من جهات مختلفة لمدة عامين تقريبًا. يعد إصدار محاكي Sapsan مهمًا (من بين أشياء أخرى) ، حيث إنه يحدد متطور تطوراتنا في هذا المجال.

1. باختصار حول ULK EVS2 "Sapsan"

أريد أن أؤكد مرة أخرى (وهو ما أقوم به بتردد يحسد عليه) أن المجمعات التعليمية والمختبرية للمعدات الدارجة التي تم تطويرها في جامعتنا ليست مخصصة لإعداد ألوية قاطرة. كما ذكر أحد المعلقين على المقال السابق بحق ، فإن ULK لدينا ليسوا محاكيات ، بل محاكيات ، حيث ينصب التركيز الأساسي على التنفيذ الفعال لفيزياء حركة القطار ومحاكاة تشغيل النظم الفرعية للمخزون المتداول التي تضمن حركتها وتوقفها. محاكي Sapsan ليس استثناءً ، حيث يتم حل المهام التالية:

• تم تنفيذ نموذج ديناميكي للجزء الميكانيكي من القطار مع الأخذ في الاعتبار القوى الطولية وملف التعقب
• تم تصميم نموذج مفصل للكمبيوتر لتشغيل الأنظمة الفرعية الرئيسية للقطار الكهربائي: الدائرة الكهربائية للطاقة ، محرك السحب الكهربائي ، الفرامل الهوائية والكهربية الهوائية
• يتم استنساخ الخوارزميات الأساسية لتشغيل نظام التحكم في القطار الكهربائي على مستويات مختلفة.

بالإضافة إلى ذلك ، يتضمن مجمع التدريب والمختبر نموذجًا بالحجم الكامل لمقصورة القطار الكهربائي مع أدوات التحكم الرئيسية ووسائل عرض المعلومات. على عكس محاكاة Swallows ، لم يتم تصنيع هذه المقصورة من جانبنا ، ولكن تم شراؤها في عام 2015 من مكتب واحد في البلد ينتج أجهزة محاكاة للتدريب. لذلك ، ركزت عملية تطوير جهاز محاكاة على إنشاء البرامج.


إن تطوير برنامج لمحاكاة جهاز محاكاة كهذه هو سؤال واسع جدًا ، وسأحاول (بأفضل ما أستطيع) إرضاء اهتمام القراء بهذه القضايا في المستقبل (إن وجد) ، ولكن الآن ، دعنا نعود إلى الموضوع الرئيسي للمقال - التصور ثلاثي الأبعاد لعملية حركة القطار.

2. خلفية وتكنولوجيا الماضي

في التعليقات على المادة الأخيرة ، تم طرح سؤال ، وبصراحة ، سخر مني كثيراً. نعم ، في الواقع ، في العديد من أجهزة المحاكاة التي لا تزال مستخدمة حتى اليوم ، لا تزال هذه الطريقة مستخدمة: يتم تصوير الفيديو على جزء حقيقي من السكك الحديدية ، ثم يتم التمرير على جهاز المحاكاة بسرعة تتناسب مع سرعة الحركة. وقد تم ذلك فقط لأنه في تلك الأوقات البعيدة التي تم فيها إنشاء مثل هذه المحاكاة ، تركت جودة الرسومات ثلاثية الأبعاد كثيرًا مما هو مرغوب فيه ، وهذا ينطبق أيضًا على محطات الرسوم القاسية على أنظمة Unixes التجارية ، ولم يكن هناك أي سؤال عن جهاز كمبيوتر شخصي. لذلك ، حتى الشركات المصنعة لألعاب الكمبيوتر ، على سبيل المثال هذه ، لم تتردد في استخدام هذا النهج.

هذا لا معنى له اليوم ، لأنه:

1. لا يوفر معدل الإطارات غير الكافي بسرعات منخفضة للقطار السلاسة المطلوبة لتحديث الصورة. سنحصل على 25 إطارًا في الثانية فقط في السرعة التي تم تصوير الفيديو بها من كابينة السائق. ولا يمكن التغلب على هذا الخلل القاتل بأي شكل من الأشكال - لا بالتصوير باستخدام كاميرا عالية السرعة (ما مقدار وزن لقطة الفيديو بمعدل 120 إطارًا في الثانية؟ هذا هو نفسه ...) ، ولا من خلال الجيل المبرمج من الإطارات المتوسطة. تم تنفيذ هذا الأخير من خلال استخدام تقنية OpenCV ، لكنه لم يؤد إلى نتائج طبيعية. تمت دراسة هذا السؤال مرارًا وتكرارًا من جميع الجهات ، ونتيجةً لذلك ، استنتج أن تكلفة الموارد اللازمة لإنشاء مثل هذا النظام أعلى بكثير من تطوير نظام مشابه ، ولكنه يعتمد على رسومات ثلاثية الأبعاد.
2. الصعوبات مع التمرير بسلاسة الفيديو إلى الوراء. وحتى مع الأخذ في الاعتبار أنه سيتم التغلب عليها ، فأين ستجري الكلاب التي تعمل على المنصة ، هل نعتقد أننا يجب أن نذهب إلى الخلف؟
3. عدم وجود كل "التفاعل". ماذا تفعل مع تغيير في إشارة المرور ، مع حركة الإقبال ، وحركة القطارات القادمة والمارة؟

لذلك ، يتم إنشاء جميع أجهزة المحاكاة وأجهزة المحاكاة الحديثة باستخدام رسومات ثلاثية الأبعاد تفاعلية ، حيث لا توجد اليوم عقبات من وجهة نظر أي برنامج أو جهاز.

إذا كان كل شيء واضحًا للغاية من وجهة نظر الأجهزة - فالشاشة المثبتة بدلاً من الزجاج الأمامي متصلة بجهاز كمبيوتر باستخدام بطاقة فيديو عادية (ولا حتى البطاقة العلوية) ، ثم من وجهة نظر البرنامج ، فإن السؤال الذي يطرح نفسه هو اختيار التكنولوجيا اللازمة لتنفيذ المهمة.

3. محرك الرسومات مقابل محرك اللعبة أو لماذا تم اختيار OpenSceneGraph

يمكن أن أكون مخطئًا ، لكنني أتوقع التعليقات مقدمًا ، والتي سوف تطرح سؤالًا منطقيًا تمامًا ، لماذا ، عند تحليل التقنيات الحالية ، لم يتوقف خيارنا عند أسماء رئيسية مثل Unity أو Unreal Engine 4؟ سأجيب على هذا السؤال ، علاوة على ذلك ، سأبرر إجابتي.

باختصار - لا تفي Unity أو Unreal Engine بمتطلبات المهمة التي يتم حلها. توفر الإجابة الأكثر تفصيلاً ، أولاً وقبل كل شيء ، قائمة بالمتطلبات المعنية. تتضمن المعارف التقليدية ، التي جمعناها على النظام الفرعي للتصور ثلاثي الأبعاد ، (بترتيب الأهمية المتناقص) الأحكام التالية:

1. استقلال عملية تطوير البرمجيات للنظام التصوري الفرعي وعملية خلق الموارد لذلك. تتضمن الموارد ، في هذه الحالة ، نماذج ثلاثية الأبعاد ، وقوام ، بالإضافة إلى ما يسمى الطرق . يتم فهم المسار على أنه مزيج من كائنات التكوين والموارد التي تسمح للنظام الفرعي للفيديو بعرض القسم المرغوب فيه من السكك الحديدية وتوفير محاكاة لحركة القطار على طوله. يتضمن هذا أيضًا إمكانية تغيير المسار دون إعادة إنشاء جزء البرنامج من النظام الفرعي للفيديو
2. إنشاء طرق طول غير محدود. سوف أبدي تحفظًا بأن طولًا غير محدود لا يمكن الوصول إليه من حيث المبدأ بسبب محدودية موارد الأجهزة. يجب أن يفهم هذا الشرط أن طول المسار يجب أن يكون على الأقل داخل "كتف" واحد ، أي جزء من الطريق بين نقاط التحول ، وهذا ، بناءً على عوامل مختلفة ، هو مسافة كبيرة بما فيه الكفاية ، تقدر بأكثر من مائة كيلومتر. يفرض هذا المطلب الحاجة إلى توفير التحميل / التفريغ الديناميكي لموارد البرنامج بسلاسة كافية مع استهلاك ذاكرة معقول. ومن المرغوب فيه أن يحتوي المحرك على مثل هذه الوظيفة "خارج الصندوق"
3. التكامل مريحة مع كومة التكنولوجيا المستخدمة. تقليديًا ، ولأسباب موضوعية مرة أخرى ، يستخدم فريقنا لغة C ++ مع Qt framework و QtCreator IDE و Git كنظام للتحكم في الإصدار لتطوير البرامج لنظام ULK PS. كنظام أساسي لنظام ULK PS ، يتم استخدام نظام تشغيل يعتمد على Linux kernel

ما هو الخطأ في الوحدة و UE؟ ما حقيقة أن المحركات الأخرى قادرة على استيراد الموارد بتنسيقات مختلفة تمامًا. ومع ذلك ، عند تجميع المشروع ، يتم تحويلها بشكل لا رجعة فيه إلى التنسيق الثنائي الداخلي ، مما يجعل من المستحيل إضافة وتغيير الموارد دون إعادة تجميع المشروع. تقنيات مثل المباني الجاهزة وحزم الأصول المتوفرة في Unity لا تحل المشكلة ، لأن محرر المحرك ليس هو أفضل مكان لإنشاء مواقع السكك الحديدية ، مما يستلزم تمديد المحرر ، مما يؤدي إلى الحاجة إلى كتابة "محرك داخل المحرك". بالإضافة إلى ذلك ، فإن إنشاء الجاهزة والحزم أمر مستحيل دون استخدام محرر الوحدة ، وهذا ، كما أثبتت الممارسة ، ليست مريحة للغاية ، وخاصة بالنسبة للمصممين الخالصين ومصممي المستوى. بالنسبة إلى UE ، طرحت الكثير من الأسئلة حول هذا والموارد الأخرى على مدار عامين حول كيفية فصل عملية بناء المشروع عن عملية إضافة / تغيير الموارد التي يستخدمها ، ولم أحصل على إجابة كافية سواء في الوثائق أو من inveterate "مطوري اللعبة. سأكون سعيدًا جدًا (بدون سخرية) إذا تعثرت بشكل معقول في شيء فاتني.

بالنسبة للشرط الثاني ، يبدو أن كلاً من Unity و UE يوفران القدرة على إنشاء مواقع محمّلة ديناميكيًا ، ولكن يبقى السؤال بلا إجابة ، كيف يمكن إنشاء مثل هذه المواقع بشكل مستقل عن المحرر ودون إعادة بناء المشروع؟ لا يوجد سوى مخرج واحد - لكتابة "محرك داخل المحرك" ، والذي سيحمل هندسة "الخام" (في أي من تنسيقات التصدير المحددة سابقًا من محررات ثلاثية الأبعاد) ، وتطبيق جميع التأثيرات اللازمة عليها ووضعها في مساحة استنادًا إلى البيانات الموضحة في جهة خارجية مستقلة عن تنسيق المحرك ، والتي لا تزال بحاجة إلى تطوير وتعليم لتفسير المحرك.

فيما يتعلق بما ذكر أعلاه ، فإن السؤال الذي يطرح نفسه هو: إذا كان من الضروري حل هذه المشكلة ، إذا كان من الضروري حل هذه المشكلة ، كتابة طبقة برمجية قوية فوق محرك اللعبة ، فمعظم وظائفها غير مطلوبة ببساطة في المشكلة قيد النظر ، فلماذا نحتاج إلى محرك ألعاب؟

ربما محرك الرسومات يكفي؟ لقد طرحت هذا السؤال على الفريق السابق ، الذي عالج المشكلة قيد المناقشة ، واعتمد على الوحدة (ودمج بشكل طبيعي بعد ذلك بقليل). وردًا على ذلك ، تلقى سؤالًا مضادًا: "ما الذي تقترحه؟" ، الإجابة على ذلك ، بروح النص أعلاه ، تلقى ابتسامة الخصم الساخرة.

إذا قمت بالاستغناء عن السخرية ، فالمهمة المعروضة هي مهمة تصورية نموذجية - فهي لا تتطلب سوى إطار عمل للتعامل مع الرسومات ، حيث يتم تطبيق كل من الفيزياء والنظام الصوتي المرتكز على الفيزياء على جانب الخادم. لقد توصلت أنا وفريقي إلى هذه الحقيقة ، حيث تحركنا من خلال الجمود بين المطورين السابقين ، أولاً نحو الوحدة ، من خلال UE ومحاولة ربط النظام الفرعي للرسومات من أحد محاكيات السكك الحديدية المفتوحة (OpenBVE ، التي تحولت بالمناسبة ، لكنها أصبحت عكازًا مؤقتًا)

يعد OpenSceneGraph هو محرك الرسومات الأكثر تطوراً (المفتوح والمجاني) الذي يركز على تطوير C ++. يستخدم على نطاق واسع في الخارج على وجه التحديد للتصور الفني ثلاثي الأبعاد. لم يتم إنقاذ هذا المحرك بواسطة أي نوع من أجهزة المحاكاة ، وأشهرها هو FlightGear . كان هناك مرة واحدة محاكي للسكك الحديدية يعتمد على هذا المحرك - Indra ، والذي ، مع ذلك ، لم يترك سوى لقطات مملة للرابط أعلاه ومصيره غير معروف بالنسبة لي.

في سياق المهمة المطروحة ، يتمتع محرك رسومات OSG بالصفات الإيجابية التالية:

• عبر منصة ، مما يجعل من الممكن تطبيقها في نظام جنو / لينكس البيئي
• لغة التطوير هي لغة C ++ / STL ، مما يتيح دمجها بسهولة وبشكل طبيعي في عملية التطوير التكنولوجية القائمة ؛
• أوسع مجموعة من تنسيقات الموارد المدعومة "خارج الصندوق" - هندسة ثلاثية الأبعاد وأنسجة بسبب نظام المكونات المتقدمة. واجهة بسيطة وبديهية لكتابة المكونات الإضافية الخاصة بك لإعداد مدير الموارد للتنسيقات غير القياسية ، التي استخدمناها (سأكتب عن هذا أدناه) ؛
• نظام لإدارة الذاكرة يعتمد على نموذج خاص بالمؤشرات الذكية (تم استخدام تنسيق خاص للمؤشرات الذكية تاريخياً ، نظرًا لعدم وجود محرك مؤشر ذكي في معيار C ++ في بداية التطوير) ؛
• العمارة وحدات مرنة.
• مدير كائن المشهد الذي يقوم بتحميل الكائنات ديناميكيًا ، يوفر تحميل وعرض تلك الكائنات التي تقع فقط في هرم القطع (بسبب فئة osg :: PagedLOD)
• القدرة على الاندماج مع إطار كيو تي. بفضل نموذج "فتحات الإشارات" المريح الذي قدمته شركة Qt ، والذي يبسط ويسرع بشكل كبير تطوير C ++ ، فإننا نستخدم هذا الإطار على نطاق واسع لتطوير برمجيات معقدة للتدريب. وفقًا لذلك ، قمنا بتجميع قاعدة رمز مهمة أعيد استخدامها في مشاريع مختلفة ، لا سيما فيما يتعلق بمكتبة التواصل بين العمليات القائمة على مآخذ TCP. استخدام قدرات Qt في مشروع النظام الفرعي للفيديو يبدو قرارًا منطقيًا ؛
• جودة صورة كافية للمهمة التي يتعين حلها.

استغرق الأمر نحو ستة أشهر من الدراسة المكثفة لقدرات OSG من أجل "استكشاف الأرض" بدقة وإيجاد طرق لحل المشكلة مع هذا المحرك. ما ولد كنتيجة يستحق مناقشة منفصلة.

4. من العمارة إلى نموذج العمل

النظام الفرعي للفيديو لمحاكاة تدريب المتداول (HTSC) هو تطبيق عميل ، يشار إليه عادةً باسم video3d-client ، ويقوم بالوظائف التالية:

• طلب للاتصال بجزء الخادم من جهاز المحاكاة ، والتفويض على الخادم ، متبوعًا بطلب دوري لمعرّف المسار الذي تم تحميله ، ثم الموضع الحالي للقطار. إذا تم قطع الاتصال من جانب الخادم ، ينتقل النظام إلى وضع الاستعداد لإعادة الاتصال ؛
• تنزيل المسار المحدد ، وتنظيم الإدارة الديناميكية لمحتويات المشهد المقدم ؛
• في الواقع تقديم المشهد وفقا للموقف الحالي للقطار على الطريق

ليس هذا المشروع مفتوح المصدر ، ولكن يمكن العثور على رمز العرض التوضيحي للتكنولوجيا كامل المواصفات هنا . يتكون المشروع من الوحدات التالية:

• نظام الملفات - مكتبة للعمل مع نظام الملفات ، ويوفر توليد مسارات لملفات التكوين وموارد التطبيق
• مكتبة - تطبيق عبر النظام الأساسي من محمل مكتبة الحيوية. بشكل عام ، عكاز مكتوب في وقت كانت فيه إمكانات التكامل مع كيو تي (حيث توجد وحدة QLibrary جاهزة للمعركة) لا تزال غامضة
• osgdb_dmd - مكون إضافي لتحميل نماذج من التنسيق الخاص بإصدار محرك DGLEngine 1.1. على ما هو مطلوب ، سأشرح أقل قليلا
• route-loader هي مكتبة توفر واجهة تجريدية لجهاز التوجيه. من الممكن تحميل طرق التنسيق التعسفي
• TCP - اتصال - مكتبة الاتصالات interprocess عبر مآخذ TCP
• المشاهد - الوحدة التنفيذية الرئيسية للبرنامج
• zds-route-loader - البرنامج المساعد لتحميل طرق تنسيق ZDSimulator

عند تصميم VTPS ، نشأ سؤال حول ما إذا كان يجب تطوير تنسيق للمسارات بشكل مستقل ، أو استخدام التنسيق الحالي للطرق ، بالإضافة إلى طرق السكك الحديدية المحلية الجاهزة لمحاكاة السكك الحديدية الحالية. لحسن الحظ ، ظهر أن الحل هو منتج ZDSimulator المُغلَق المُغلَق ، والذي يتمتع بخصوصية أنه مُصمم خصيصًا ليتلاءم مع المواد الدارجة المحلية وخصائص شبكة السكك الحديدية. على الرغم من ثناء مؤلفي المشروع ، إلا أنه يحتوي على الكثير من العيوب المهمة ، إلا أنه يحتوي على تنسيق بسيط وواضح للطرق المتاحة للجمهور. في المرحلة الأولى ، كان من الخطيئة عدم الاستفادة من هذه الفرصة ، على الرغم من أن الجزء الرسومي من المحاكاة يعتمد على محرك DGLEngine المفتوح. تكمن المشكلة في أن هذا المحرك ، على الرغم من أنه قيد التطوير ( يمكن رؤية الحالة الحالية للمشروع هنا ) ، ولكن الإصدار الثاني الحالي الخاص به لا يتوافق مع الإصدار 1.1 ، الذي يستند إليه ZDSimulator.يتم فقد رموز مصدر الإصدار 1.1 ، وقد تلاشت الروابط المؤدية إليها لفترة طويلة.

أتاح البحث الشامل في أرشيف الويب العثور على المفقودين وحفظهم عن طريق نشر DGLEngine v1.1 على Gtihub. يستخدم هذا المحرك التنسيق الخاص به لطرز ثلاثية الأبعاد. امتلاك مصدر المحرك ، كان من السهل كتابة المكوّن الإضافي المناسب لـ OSG.

وبالتالي ، تم تقليل مهمة إنشاء HTPS لكتابة جزء البرنامج على محرك OSG. في المستقبل ، من المخطط تطوير تنسيق المسار الخاص به ، حيث أن التنسيق الحالي ينص على الحركة فقط عبر الطرق الرئيسية ويحتوي على عدد من العيوب التي لا تسمح لك بإعادة إنشاء عدد من المسارات المعقدة.

ويرد التسلسل الهرمي للفئات الرئيسية من HTPS في الرسم البياني التالي


يشبه التسلسل الهرمي فئة محمل الطريق هذا


يمكن كتابة أداة تحميل أي تنسيق مسار آخر كمكون إضافي يحتوي على فئة ترث من فئة RouteLoader. في بداية VTPS ، يتم نقل المسار إلى الدليل مع المسار إليه ، ويتم تحديد تنسيق المسار ، ويتم تحميل المكون الإضافي المقابل بشكل حيوي ، والذي يؤدي بعد ذلك بقية العمل القذر.

كان فارق بسيط مهم هو تكامل محرك OSG و Qt. هذا التكامل موجود ويسمى osgQt . لم يتم استخدام هذه المكتبة في هذا المشروع لسببين:

1. لا حاجة لعناصر تحكم النافذة التي تقدمها كيو تي. لدى OSG نظام إدارة نافذة واجهة المستخدم الرسومية الخاص به والذي تم تطويره إلى حدٍ كبير وليس من المنطقي ربط واجهة المستخدم الرسومية أعلى واجهة المستخدم الرسومية الأخرى ، حيث إن osgQt مصمم أساسًا لدمج عارض OSG في واجهة المستخدم الرسومية المستندة إلى Qt
2. يخضع osgQt لخطأ - عملية غير صحيحة مع سياق OpenGL ، والتي في بعض الحالات لا يمكن تقسيمها بين OSG و QGLWidget ، بسبب عرض المشهد في أي مكان ، ولكن ليس على أداة Qt. علاوة على ذلك ، لم يكن من الممكن حتى الآن العثور على الأسباب ، لأن هذا الخطأ لا يظهر في بعض الأنظمة.

كان هناك فهم أن التكامل مع Qt ضروري من حيث استخدام مفهوم "فتحات الإشارة" لضمان التفاعل مع النظام الفرعي لشبكة اتصال tcp الذي يستخدم Qt وهو المعيار الفعلي في تصميماتنا. لا أريد حقًا الاعتماد على نظام المراسلة OSG وإعادة كتابة عميل TCP (وحتى عبر النظام الأساسي). تم العثور على حل أنيق ، استنادًا إلى حقيقة أننا إذا أردنا أن يرسل كائن ما إشارة تشغل فتحة لكائن آخر ، فيجب أن نحقق ثلاثة شروط:

1. وراثة الطبقات المتفاعلة من QObject
2. تنظيم حلقة معالجة الإشارات
3. قم بإنشاء مثيل لفئة QApplication (أو QCoreApplication) الموجودة في الذاكرة أثناء تشغيل التطبيق

في هذه الحالة ، لا ينبغي عليك بأي حال من الأحوال إجراء مكالمة مع QApplication :: exec () ، والتي تبدأ دورة معالجة الإشارات العادية ، فهذا يكفي لتنظيم دورة يكون فيها من السهل معالجة الإشارات عن طريق الاتصال بـ QApplication :: processEvents (). لدى OSG مثل هذه الدورة (الدورة التي يتم فيها تقديم العرض) ، ومن الممكن إنشاء معالج حدث يتم فيه معالجة حدث osgGA :: GUIEventAdapter :: FRAME الذي تم إنشاؤه بواسطة المحرك عند تقديم الإطار التالي. وبالتالي ، تم تقليل كل التكامل إلى رمز

qt-events.h

#ifndef QT_EVENTS_H #define QT_EVENTS_H #include <osgGA/GUIEventHandler> #include <QtCore/QtCore> class QtEventsHandler : public osgGA::GUIEventHandler { public: QtEventsHandler(){} virtual bool handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa); protected: }; #endif // QT_EVENTS_H 

qt-events.cpp

 #include "qt-events.h" bool QtEventsHandler::handle(const osgGA::GUIEventAdapter &ea, osgGA::GUIActionAdapter &aa) { switch (ea.getEventType()) { case osgGA::GUIEventAdapter::FRAME: { QCoreApplication::processEvents(QEventLoop::AllEvents, 100); break; } default: break; } return false; } 

main.cpp

 #include "main.h" /*! * \fn * \brief Entry point */ //------------------------------------------------------------------------------ // //------------------------------------------------------------------------------ int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); RouteViewer viewer(argc, argv); if (viewer.isReady()) return viewer.run(); return 0; } 

بعد ذلك ، يمكن للفئات الموروثة من QObject ومشتقاتها تبادل الإشارات حتى يتم فقد النبضة.

كل ما سبق سمح لمدة شهرين لإنشاء أول نموذج عمل من HTPS. لإظهار ما حدث في النهاية ، أقترح القسم التالي من الرحلات التجريبية على طرق حقيقية. أعتذر مقدمًا عن جودة التصوير - فلم يحصلوا على التكنولوجيا الذكية

الخلاصة والاستنتاجات

كان الاستنتاج الرئيسي ، على الأقل بالنسبة لفريقنا ، أنه لم يكن هناك "رصاصة رمادية" في اختيار التكنولوجيا لتنفيذ المشروع. محركات اللعبة التي يتم تسويقها بشكل مكثف ليست مناسبة دائمًا لحل مهام محددة ، والتي تشمل تصور نتائج النظم الفنية للنمذجة. وإذا كانت مناسبة ، فهي ليست الأمثل من حيث الجهد المبذول في تطوير وصيانة المشروع.

إنه لأمر مخز أن محرك رسومات OSG جيد جدًا ، والأهم من ذلك كله ، في الواقع لا يوجد به مجتمع في بلدنا. لحل هذه المشكلة ، أكتب سلسلة من المقالات هنا حول المورد (هناك جمعت كل الروابط بمصادر أكثر أو أقل من المعلومات الكافية ، بما في ذلك باللغة الروسية). بالإضافة إلى ذلك ، كوثيقة تصف المبادئ الأساسية لـ OSG ، يمكنني أيضًا تقديم هذه المدونة . آمل أن يجد شخص ما هذه المعلومات مفيدة.

فيما يتعلق HTSC ، يستمر العمل في هذا الاتجاه. لا يزال هناك الكثير من المهام المهمة التي يجب حلها في المستقبل القريب.

شكرا لاهتمامكم!

(ج) مركز تنمية كفاءات الابتكار