Frame تعلن عن 100 مليون مضلع بسرعة 60 إطارًا في الثانية داخل محرر ثلاثي الأبعاد في المتصفح

أن تطلب من الذكاء الاصطناعي بناء قطعة، ثم تفتح النتيجة في المتصفح وتعدّل الأبعاد يدويًا — هذا هو السيناريو الذي يقترحه مؤلف Frame. فهو يطوّر محررًا ثلاثي الأبعاد بمحرك رسومي خاص وواجهة API للوكلاء. وبالنسبة لمطوري التطبيقات الهندسية، هناك أمران مهمان هنا: كيفية التعامل مع الهندسة الثقيلة، وكيف يحرر الإنسان والذكاء الاصطناعي مشهدًا واحدًا.

الرقم الرئيسي في المنشور هو 100 مليون مضلع بسرعة 60 إطارًا في الثانية دون instancing، أي دون عرض نسخ متعددة من الهندسة نفسها. وتشير الملاحظة المرفقة بالعرض التوضيحي إلى 76 FPS على RTX 2080. وهذه نتائج المؤلف نفسه: فالمادة المتاحة لا تتضمن اختبارًا مستقلًا ولا منهجية مقارنة مفصلة.

كيف يتعامل Frame مع الهندسة الثقيلة

يقوم Frame على محرك خاص يعمل على WebGPU دون Three.js. وبحسب وصف المطوّر، تُخزَّن الهندسة على بطاقة الرسوميات، وتُنفَّذ الحسابات الثقيلة في الـ shaders، وتستخدم بعض العمليات WASM. وعند نقل كائن كامل تتغير مصفوفة التحويل، دون الحاجة إلى إعادة كتابة مصفوفات إحداثيات جميع رؤوسه.

تخيّل نموذج STL مستوردًا لقطعة معقدة. يديرها المستخدم ويقرّب الكاميرا وينقل الكائن. في مثل هذا السيناريو، المهم هو أي بيانات يتبادلها المحرر بين المعالج وبطاقة الرسوميات، وأي عمل يعيد تنفيذه عند كل إجراء. ويعزو المؤلف سرعة Frame إلى تصميم المحرر بأكمله ليلائم WebGPU.

أما حجم النواة المعلن بعد ضغط gzip فيبلغ نحو 0.93 ميغابايت في النسخة التي جرى قياسها. وتُحمَّل الإضافات وخامات المكتبة عند الحاجة. وهذا الفصل مفيد للمنتج: فمستخدم النمذجة العادية لا ينبغي أن ينتظر تحميل جميع الوحدات الهندسية. لكن هذا الرقم يخص النواة فقط، أما الحجم الكلي للتحميل فيعتمد على الإمكانات المختارة.

كما يقدّم المحرر أسطح splines وعمليات منطقية (Boolean) وعرضًا بتتبع المسار (path tracing). لكن سرعة تدوير المشهد وحدها لا تبيّن مدى سرعة تغيير الطوبولوجيا أو المواد المعقدة أو العمليات الأخرى. وينبغي التعامل مع ادعاء المؤلف بالتفوق على Cinema 4D بوصفه دافعًا لإعادة المقارنة على مهامك الخاصة.

يحصل الوكيل على الوصول إلى المشهد نفسه

لدى Frame واجهة AI API خاصة به. وبحسب المؤلف، يتعامل الوكيل مع الكائنات والعمليات نفسها المتاحة للإنسان. ويمكن تعديل النتيجة التي يبنيها يدويًا وحفظها، كما يمكن التراجع عن إجراءاته.

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

وتقوم إضافة Atomic المنفصلة بحساب التفاعلات الذرية على وحدة GPU عبر WebGPU. ويذكر المؤلف الجهد البيني الذري العصبي NEP89-1 ودعم 75 عنصرًا. ومن المفترض أن يُكلَّف الوكيل بإعداد البنية والشروط الابتدائية، ثم تُغيَّر القوى والتثبيتات ويُكرَّر التجريب.

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

ما يمكن الاستفادة منه في تطويرك

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

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

وبحسب المؤلف، يمكن استخدام النسخة الرسمية من Frame مجانًا، لكن الشيفرة مملوكة. ولا يُضمن التوافق بين الإصدارات حتى الآن. أما الـ slicer ووحدات الهندسة الأخرى، كالمتانة والحرارة، فما زالت قيد التطوير.

الخطوة العملية التالية هي اختبار Frame على نسخة من مشهدك الخاص: الاستيراد والتحرير والحفظ وإعادة الفتح. وبالنسبة لفريق المنتج، فإن السؤال الأكثر فائدة هو: ما مدى سهولة أن يتحقق المستخدم من عمل الوكيل ويصحّحه في واجهة مألوفة؟