المخاطرة بذكر ما هو واضح ، ولكن هل جربت إصدار threeocttree الموجود بالفعل في الريبو ( أمثلة / js / Octree.js )؟

أنا لا أصوت للاستخدام الشاق لأشجار البحث المكاني في three.js . إن العبء / التعقيد لهذه الخوارزميات يوازن مكاسب الأداء في العديد من التطبيقات.

فحص الصندوق المحيط والكرة أولاً قبل القيام ببث أشعة فعلي

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

مرحبا وشكرا على ردودكم ،
@ Mugen87 أوافق على أن العديد من حالات الاستخدام لا تتطلب مثل عمليات البحث السريعة. ومع ذلك ، فإن وجود آلية للتفاعل مع الكائنات ثلاثية الأبعاد (وأعتقد أن هذا هو الحال بالنسبة لما يتم استخدامه في الغالب) ، خطوة THREE.Raycaster من فحص المربع المحيط / الكرة أولاً (وهو ما أوافق تمامًا على أن يكون معقولًا ) دعنا نقول أن الوقت الثابت لجهد وقت خطي عند القيام ببث الشعاع الفعلي كبير جدًا. يمكنني تخيل نوع من "شجرة بحث لكل هندسة" بدلاً من شجرة بحث عالمية واحدة. طالما أن الهندسة لا تتغير (في كثير من الأحيان تكون عمليات التحويل أكثر احتمالا بكثير من التغييرات الهندسية) ، فلن تحتاج شجرة البحث إلى التحديث.

لهذا السبب اعتقدت أن مثل هذا النوع من التحسين باستخدام أشجار البحث المكاني يمكن أن يكون جزءًا لا يتجزأ من three.js . لكنني أفهم أيضًا أن هذا يتسبب في مزيد من التعقيد والنفقات العامة.

moraxy سألقي نظرة على نسخة المثال. أردت فقط معرفة ما إذا كانت هذه الميزة منطقية.

شكرا مرة أخرى وتحياتي الطيبة

ربما يمكن دمج شجرة بحث أبسط في THREE.BufferGeometry . على سبيل المثال ، يمكن لاستدعاء computeBoundingBox إنشاء نوع من شجرة بحث للقراءة فقط تشير إلى الرؤوس المقابلة. منذ THREE.BufferGeometry هو

الأنسب للكائنات الثابتة حيث لا تحتاج إلى معالجة الهندسة كثيرًا بعد إنشائها

لا تحتاج شجرة البحث هذه للتغيير بعد تهيئتها. سيؤدي هذا إلى تقليل بعض النفقات العامة للتحديث / الحذف. سيكون Octree نقطة انطلاق جيدة ( مفهوم مماثل في BabylonJS ).

الأنسب للكائنات الثابتة حيث لا تحتاج إلى معالجة الهندسة كثيرًا بعد إنشائها

FWIW ، لا أعتقد أن هذا بيان صحيح.

اقتباس WestLangley من وثائق THREE.BufferGeometry

ثلاثة وثائق عازلة للهندسة المعمارية

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

ربما ينبغي إزالته

بالتأكيد.

لقد نفذت للتو طريقة أفضل للبث الشعاعي على PlaneBufferGeometry. أستخدم المعامل far وأجد موقعي الفهرس الأول والأخير. يعمل هذا في المستوي لأن مصفوفة الفهرس بترتيب x / y. بمجرد الخروج من المربع المحيط x / y ، يجب أن يكون كل التصادم خارج النطاق البعيد. هل هناك رغبة في ارتكاب هذا في مكان ما؟ التنفيذ الحالي خاص بحالة الاستخدام الخاصة بي ولكنني سأكون على استعداد لمحاولة جعله أكثر عمومية إذا رغبت في ذلك. لقد تمكنت من تقليل أداء Raycasting الخاص بي بشكل كبير على متن طائرة كبيرة (2.5 ثانية إلى 10 مللي ثانية)

@ kpetrow أعتقد أن الأمثلة الثلاثة. js الثلاثة كافية. أنت بالطبع حر في مشاركة الكود الخاص بك على GitHub إذا شعرت أنه سيكون مفيدًا للآخرين.

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

سأكون سعيدًا للتبرع برمز BVH الخاص بي للمشروع ، إذا كان هناك اهتمام كافٍ ونية لإدراجه في التوزيع الرئيسي (وليس الأمثلة).
يركز الكود الخاص بي على جانبين:

• مشاهد ديناميكية
  
  
  
  • إدراج سريع
  
  
  • الحذف السريع
  
  
  • إعادة التشكيل (قدرة العقد على تغيير شكلها دون الحاجة إلى إعادة إدخالها)
  
  
• سرعة الاستعلام

لدي تطبيقان:

• ثنائي BVH
  
  
  
  • مضغوط للغاية ، باستخدام ByteBuffer
  
  
  • مزيج من أنواع UintX و FloatX عبر DataView
  
  
  • عظيم للتسلسل
  
  
  • يمكن ضغطها باستخدام أدوات قياسية مثل مكتبة lzma
  
  
  • ثابت
  
  
  • تم تحسين سرعة البناء بشكل كبير
  
  
  • يعمل فقط مع BufferGeometry
  
  
  • تحسين SAH
  
  
  • استفسارات راي
  
  
• BVH
  
  
  
  • شجرة الكائن ، نتيجة لذلك أكبر بكثير من التنفيذ الثنائي
  
  
  • متقلب
  
  
  • إدراج سريع بالجملة
  
  
  • إدراج عنصر واحد سريع
  
  
  • التجديد
  
  
  • تطبيقات الاجتياز المكدسة والتكرارية وبدون تكديس (خصائص أداء مختلفة)
  
  
  • تحسين SAH
  
  
  • استفسارات Frustum
  
  
  • استفسارات راي
  
  

أنا شخصياً لا أستطيع العيش بدون فهرس مكاني ، إنه فرق بين أداء n ^ 2 و log (n). على سبيل المثال ، في مشروعي الحالي ، تعتمد الأجزاء التالية على الفهرس المكاني:

• نظام أوراق الشجر (الأشجار ، الزهور ، الشجيرات ، إلخ)
• كل موضع الكائن (الشخصيات والمنازل)
• الانتقاء (المستخدم في التفاعلات ، مثل نقرات الماوس)

http://server1.lazy-kitty.com/komrade

تحتوي التضاريس على حوالي مليون مضلع ، ووضع الآلاف من الأشجار وتشغيل أشعة الأشعة في الوقت الفعلي على هذا ببساطة أمر محظور ، خاصة بالنسبة للأجهزة ذات النهاية المنخفضة.

أود أن أرى أي شيء يجعل البث الشعاعي محسنًا. هل هناك أي مجال للتحسين دون إضافة تعقيد؟ Octree يتطلب كل مكتبة جديدة ، مع كل الإضافات والتحديثات الجديدة ، إلخ.

هناك شيء واحد ألاحظه هو أنه بمجرد تحويل الهندسة إلى مصفوفة مخزن مؤقت مفهرس ، فإنها لم تعد تستخدم خصائص الهندسة الأصلية بذكاء. كما هو مذكور أعلاه ، يمكن تحسين هندسة المخزن المؤقت للمستوى بشكل فائق من خلال معرفة أن arrayBuffer جاء من PlaneGeometry. ربما يتم استبدال طريقة MESH.raycast (رايكاستر ، تتقاطع) على أساس النوع الهندسي؟

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

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

• الاعدام المكاني (اعتقد اعدام frustum)
• القيام باستفسارات الرؤية
• بناء عارض تتبع المسار
• الفرز السريع (استغلال منطقة البيانات)

تقوم شركة Three.js حاليًا بتنفيذ 2 بشكل صريح (الفرز والاستبعاد) و 1 عبر الأمثلة (عارض تتبع الشعاع)

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

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

https://github.com/brianxu/GPUPicker

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

دعنا نجري مقارنة ، دعنا نقول أن لديك نموذج بولي 1 متر ، وترغب في إرسال شعاع من مساحة الشاشة مباشرة على طول اتجاه الكاميرا إلى المشهد (اختيار حالة الاستخدام). لنفترض أنك تستخدم الجزء السفلي من دقة الأسطوانة ، "دقة عالية كاملة" ، أو 1920 × 1080. لنفترض أنك تقدم RGB فقط (24 بت لكل بكسل) ، ستحتاج إلى 6220800 بايت (حوالي 6 ميجا بايت) أو ذاكرة وصول عشوائي للرسومات لتقديمها الذي - التي. إذا كنت تستخدم حل وحدة المعالجة المركزية ، فلنقل أنك تذهب مع AABB BVH مع 10 مضلعات لكل ورقة ، وهذا يعني أنك بحاجة إلى حوالي 200000 عقدة ، دعنا نقول أن كل عقدة تبلغ حوالي 6 * 8 بايت للإحداثيات ، والعقد الوسيطة بها 2 * 4 بايت إضافية للمؤشرات الفرعية تحتوي العقد الورقية على 10 * 4 بايت لمؤشر المضلع ، أي 14400000 بايت (حوالي 14 ميغا بايت). يلعب الاختلاف الرئيسي دورًا عندما تتعامل مع حقيقة أن استعلامات BVH الخاصة بك لها طلب ضئيل جدًا على النطاق الترددي لذاكرة الوصول العشوائي ، مقارنةً بحالة وحدة معالجة الرسومات ، ولا يوجد سوى عدد قليل من العمليات المتضمنة لكل استعلام ، مقارنةً بتقديم هندسة بولي كاملة تبلغ 1 مليون.
إذا اتخذت دقة أكثر شيوعًا لأجهزة سطح المكتب ، مثل 2560 × 1440 ، فسينتهي بك الأمر مع هدف عرض 11059200 بايت (11 ميجا بايت).

إذا كان لديك ميزانية كبيرة من عرض النطاق الترددي لذاكرة الوصول العشوائي للرسومات وعدد نواة تظليل لائق إلى حد ما - بالتأكيد ، هذه طريقة بسيطة ومباشرة للقيام بالاختيار.

Usnul بالتأكيد ، لكنه على الأرجح الحل الأبسط للتنفيذ. من المحتمل أن يكون تنفيذ هياكل بيانات الفهرس المكاني وصيانتها عبئًا غير مهم على القائمين على الصيانة.

ومع ذلك ، أرغب تمامًا في الحصول على بنية بيانات مؤشر مكاني جيدة ومُختبرة جيدًا وصيانتها كجزء من ثلاثة أو كحزمة npm منفصلة.

كنت مهتمًا بتطبيق مثل هذا الفهرس المكاني لأشكالي الهندسية المستخدمة ، لذلك قمت بتطبيق Octree بسيط جدًا (إنشاء وبحث فقط) يقسم BufferGeomtry. مع هذا الحل البسيط ، حققت نتائج واعدة تمامًا: تم تطبيقه على شكل هندسي بحوالي 500 ألف رأس ، مما أدى إلى تقليل وقت بث الشعاع من 120 مللي ثانية إلى 2.3 مللي ثانية. يستغرق إنشاء الشجرة حاليًا حوالي 500 مللي ثانية ولكن نظرًا لأن الهندسة وإنشاء الشجرة يتم داخل عامل الويب مرة واحدة فقط عند بدء التطبيق ، فهذه ليست مشكلة من هذا القبيل.

أعتقد أن الخوارزمية يمكن دمجها بسهولة في THREE.BufferGeometry وربما يتم تشغيلها أو إيقاف تشغيلها باستخدام علامة مثل THREE.BufferAttribute 's dynamic . بهذه الطريقة ، يمكن استخدامه فقط عندما لا يُفترض أن يتغير BufferGeometry. لسوء الحظ ، اضطررت إلى الكتابة فوق طريقة THREE.Mesh raycast على الرغم من أنني كنت بحاجة فقط لتغيير سطرين فيها (استدعاء بحث Octree وتكرار صفيف الموضع).

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

تحديث لقد أخطأت في قياس وقت بث الشعاع. القيمة الصحيحة ~ 2.3 مللي ثانية (بدلاً من ~ 0.3 مللي ثانية). لقد غيرت القيمة أعلاه وفقًا لذلك.

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

@ matthias-w لقد جربت جهاز raycaster لنموذج obj لكن وحدة التحكم لا تكتشف أي شيء. الأشعة تمر عبر النموذج. هل يمكن أن تخبرني كيف أصلحت هذه المشكلة

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

13909

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

https://github.com/gkjohnson/threejs-fast-raycast

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

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

Usnul @ matthias-w هل تطبيقاتك الثمانية / BVH مفتوحة المصدر أم متاحة على الإنترنت؟ سأكون بالتأكيد مهتمًا بإلقاء نظرة!

تضمين التغريدة

هل أي من تطبيقاتك الثمانية / BVH مفتوحة المصدر أم متاحة عبر الإنترنت؟ سأكون بالتأكيد مهتمًا بإلقاء نظرة!

الكود ليس مفتوح المصدر حاليا. يمكنني تزويدك بالمصادر إذا اتصلت بي بشكل خاص.

هناك مثال فعلته للتفاعلات المتداخلة:
http://server1.lazy-kitty.com/tests/instanced-foliage-1mil/
يتضمن المثال أعلاه ما يلي:

• يتم تحديث BVH ديناميكيًا حيث يتم إدراج مثيلات جديدة في الشجرة
• يتم تحسين BVH بشكل تدريجي باستخدام عمق 1-2 دوران أثناء الطيران
• يتم أخذ عينات من BVH باستخدام استعلام frustum إلى أي مثيلات يتم عرضها

لدي نسخة منه تعمل في اللعبة التي أعمل عليها:
http://server1.lazy-kitty.com/komrade/

فيما يتعلق بالتنفيذ الخاص بك. يعجبني ، أنا مختلف بطريقتين رئيسيتين:

• أنا أركز على الأداء
• أركز على بصمة الذاكرة
• أتجنب جمع القمامة في كثير من الأماكن

بعض النقاط الأكثر تحديدًا:

• أستخدم أيضًا مزيجًا من استراتيجيات التقسيم بشفافية ، بناءً على ما تريد القيام به باستخدام BVH
• بلدي BVH هو مقرها AABB
• أنا أدعم التحديثات لحدود العقدة عن طريق التجديد

Usnul لا يمكنني رؤية عنوان بريدك الإلكتروني أو أي شيء ، لكني مهتم جدًا بدراسة حل الفهرسة المكانية.

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

تضمين التغريدة
إنه
travnick at gmail com
لم أدرك أنها ليست متاحة للجمهور. خطأي.

Usnul أنا مهتم أيضًا بمشروع المليون. ربما حتى 10 أو 20 مليونًا إن أمكن. يرجى مراسلتي عبر البريد الإلكتروني: kaori.nakamoto. [email protected]

شكرا جزيلا لك!

http://server1.lazy-kitty.com/tests/instanced-foliage-10mil/
هذه نسخة مع 10 مليون

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

@ sid3007 لست متأكدًا مما إذا كنت أفهم مشكلتك. يمكنني شرح مقاربتي. ربما من المفيد.

حالة الاستخدام الخاصة بي بسيطة للغاية. عندما يبدأ طلبي ، يتم تحميل الأشكال الهندسية لنماذج مختلفة. يمكن تحويل هذه النماذج من قبل المستخدم. لا تتغير الأشكال الهندسية. لا توجد تشوهات هندسية. ومن ثم ، قمت بتطبيق Octree بسيط للغاية تم إنشاؤه مرة واحدة لكل هندسة عند بدء التطبيق. الأوكتري ليس ديناميكيًا. إنه مبني على أساس المربع المحيط للهندسة المحددة ومجموعة القمم. أثناء بنائه ، يتحقق ما إذا كان الثماني يحتوي على رأس أم أن المربع المحيط للأوكتانت Box3 يتقاطع مع مثلث (ثلاثة رؤوس متتالية في هندسة غير مفهرسة) ويخزن مراجع مصفوفة الرأس مع عقدة الثماني.
ثم يتم تخزين الثماني لكل شبكة مع الشبكة. لقد قمت أيضًا بالكتابة فوق مثيلات الشبكة المتداخلة ' THREE.Mesh ' طريقة raycast (سطر واحد فقط) من أجل استدعاء طريقة اختبار التقاطع الثماني. يؤدي هذا إلى إرجاع الفهارس الهندسية للوجه والتي يمكن استخدامها بواسطة منطق التقاطع الافتراضي للشبكة.
لقد أجريت تحسينًا واحدًا: تم إنشاء الثماني مرة واحدة عند بدء التطبيق داخل WebWorker (في الواقع مجموعة من العمال). والسبب هو أن إنشاء الشجرة لأشكال هندسية كبيرة يستغرق بعض الوقت (بعض الثواني). سيؤدي هذا إلى حظر واجهة مستخدم المتصفح ، لذا قمت بنقلها إلى سلسلة رسائل أخرى.
آمل أن يصبح مقاربتي واضحًا.

@ ماتياس - ث يبدو وكأنه عمل عظيم! لقد فعلت الشيء نفسه تقريبًا بشكل مستقل ، لكن لا أعتقد أنني حققت تحسنًا كبيرًا في الأداء تقريبًا. https://discourse.threejs.org/t/octree-injection-for-faster-raytracing/8291/2 (تنفيذ ثلاثي موجه للكائنات وتعديلات أقل نظافة على Mesh.raycast)

هل سيكون من الممكن لك فتح المصدر / المساهمة في تنفيذ Octree ، مما يسمح بمزيد من التجارب من قبل الآخرين؟

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

@ matthias-w أعتقد أن 2.3 مللي ثانية مقابل 120 مللي ثانية لبث شعاع على شبكة رأس 500 كيلو لا يزال يمثل تحسنًا كبيرًا ، على سبيل المثال ، يتيح الدقة في الوقت الفعلي للرصاصات التي تم إطلاقها في الألعاب (في جزء كبير إلى حد ما من الحساب الميزانية لكل إطار).

هل جربت Raytracing أيضًا؟

هل يعتمد تنفيذك على شجرة كائنات JS؟ كائنات حرفية أو أمثلة على نموذج أولي؟ المنجم متشابه تمامًا مع نفسه ، بحيث تكون كل عقدة مكونة من ثماني أوكتونات ، مع الطرق وكل شيء.

تضمين التغريدة

إذا كنت مهتمًا بالبث الشعاعي مقابل الهندسة الثابتة ، فقد بذلت أنا وآخرون جهدًا كبيرًا في ثلاث شبكات bvh ، والتي تستخدم BVH لفهرسة المثلثات وتسمح بالبث الشعاعي عالي الأداء بالإضافة إلى اكتشاف التقاطع مقابل الهندسة المعقدة الثابتة. تعتبر عملية بناء الشجرة أكثر تعقيدًا ، لذا فهي تستغرق وقتًا أطول قليلاً ولكنها تستغرق أقل من مللي ثانية وغالبًا أقل من 0.1 مللي ثانية عند البث الشعاعي مقابل الهندسة بمئات الآلاف من المثلثات.

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

أرغب في بناء أوكتري ديناميكي قائم على المشهد لتمكين البث الشعاعي واكتشاف الاصطدام بشكل أفضل للمشاهد التي تحتوي على الكثير من الشبكات ولكن لم يكن لدي حالة استخدام جيدة بنفسي. ربما يوما ما!

EliasHasle تطبيقي عبارة عن شجرة من كائنات فئة JS (أستخدم فئات ES6 ، أي مثيلات النموذج الأولي). في الأساس ، العقدة هي شجرة في تطبيقي. ومع ذلك ، لدي فئة Octree إضافية تحتوي على عقدة الجذر وتوفر طرقًا لبناء الشجرة والبحث (وكذلك بعض التصحيح والتصور).

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

يمكنني أن أوصي بكتاب يمثل مجموعة رائعة جدًا من مناهج اكتشاف التصادم: C.Ericson، Real-Time Collision Detection، CRC Press، 2004

gkjohnson هذا يبدو رائعا! الأداء مثير للإعجاب. ما نوع BVH الذي تستخدمه؟

@ ماتياس - ث شكرا!

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

gkjohnson إذن تنفيذ BVH هو نوع من شجرة Kd غير المتوازنة مع تحديد محور يعتمد على شكل الصندوق ، أليس كذلك؟ إذا كان الأمر كذلك ، كنت أفكر في القيام بشيء من هذا القبيل في الحالات التي يكون فيها الجذر BB بعيدًا جدًا عن المكعب ، ثم استخدام الأوكتري بعد التقسيم الشرطي. من المفترض أن ينطبق هذا جيدًا على حالات مثل خريطة عالم Usnul ، حيث يكون التقسيم الأولي في بعدي "الخريطة" وسيستمر التقسيم اللاحق في صورة ثلاثية الأبعاد. أعتقد أنه حل أفضل بكثير من حل لي ، وهو توسيع الجذر BB إلى مكعب محيط بنفس المركز ، ثم استخدام تقسيم ثماني على طول الطريق.

لقد نفذت للتو طريقة أفضل للبث الشعاعي على PlaneBufferGeometry.

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

إغلاق لصالح # 13909.