Three.js: عارض WebGL2

لطيف جدا. :) كنت في الواقع قلقة بعض الشيء بشأن كيفية التعامل مع تعقيد WebGL 2 و 1.

سيكون من الرائع تفضيل استخدام UBO. :) وأنا أحب الفكرة التي تدعم BufferGeometry فقط - والتي يجب أن تبسط الأمور بشكل كبير.

سيكون من الرائع دعم نفس الظلال على الرغم من أننا إذا التزمنا بالعرض الأمامي (والذي يبدو أنه ما يفعله UE4 للسرعة للواقع الافتراضي.) أعتقد أنه يمكننا على الأرجح تغيير ذلك؟ ما رأيك؟

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

تضمين التغريدة ومن الرائع أن نسمع أن BufferGeometry سيتم استخدامه حصريًا. 👍

أنا ثاني اقتراح bhouston لتفضيل UBOs.

هل سيكون من الممكن أيضًا فصل معالجة الإضاءة والظل بشكل كامل عن جهاز العرض أيضًا؟ الإعدادات الافتراضية مفيدة حقًا ، ولكن عندما تريد تحكمًا كاملاً في الإضاءة ومنطق الظل ، فإن WebGLRenderer and co. أشعر وكأنهم يخوضون معركة.

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

أتساءل عما إذا كان ينبغي على المرء فقط تعديل WebGLRenderer 1 وإزالة الدعم لأي شيء سوى كائنات BufferGeometry. قد يكون ذلك أسهل طريقة للمضي قدمًا. إذا كانت هناك وظيفة بسيطة لتحويل الهندسة إلى BufferGeometry التي يجبر المرء الناس على الاتصال بها ...

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

أتساءل عما إذا كان ينبغي على المرء فقط تعديل WebGLRenderer 1 وإزالة الدعم لأي شيء سوى كائنات BufferGeometry. قد يكون ذلك أسهل طريقة للمضي قدمًا. إذا كانت هناك وظيفة بسيطة لتحويل الهندسة إلى BufferGeometry التي يجبر المرء الناس على الاتصال بها ...

هناك وظيفة من هذا القبيل بالفعل. لكن الأمر ليس بهذه البساطة ...

أعتقد أنه من الأفضل إنشاء WebGLRenderer2 من البداية حتى نتمكن من إعادة النظر في API والميزات المدعومة.

يحتوي Firefox 51 الآن على دعم WebGL 2: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

لا استطيع الانتظار لهذا!

تم إصدار Chrome 56 الذي يدعم WebGL 2.0!
https://developers.google.com/web/updates/2017/01/nic56

هل حان الوقت لنقل WebGLRenderer2 للأمام؟ وجه ضاحك

هل يجب علينا أيضًا إنشاء WebGLDeffixRenderer2؟

تخطط لبدء النظر في كل هذا الأسبوع المقبل! ✌️

أي فرصة لديك بالفعل بعض الوقت للنظر في الأمر! سووو نتطلع لذلك! (مواد ثلاثية الأبعاد)

تضمين التغريدة
أي تحديثات؟
إذا كانت لديك بعض المخاوف ، يرجى مشاركتها معنا!
يمكننا المناقشة والمساعدة ؛ د

لم يتح لها الوقت بعد. قريبا قريبا! 😇

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

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

لا يعمل وضع الحماية three.js webgl2 الحالي :( https://threejs.org/examples/webgl2_sandbox.html
قد تكون مشكلة في بناء الإصدار three.js؟

إذا تم تنفيذ <script type="module"> على الإنترنت بالفعل ...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

تعمل موزيلا على الأقل عليها https://bugzilla.mozilla.org/show_bug.cgi؟id=1240072

mrdoob ، هل هذا يعني أنه يمكننا توقع أن تستفيد واجهة Three.js API من <script type="module"> عند التحديث إلى WebGL 2.0؟ ؛)

راجع للشغل أعتقد أنه من الأسهل في الوقت الحالي إضافة دعم WebGL 2.0 إلى WebGLRenderer. أعتقد أن هذا سيسمح بالاعتماد المتزايد ويمكننا اكتشاف الميزات لمعرفة ما إذا كان بإمكاننا استخدام ميزات WebGL 2. لا أعتقد أن هذا هو أصعب شيء يمكن القيام به. أعلم أنه يؤدي إلى بعض التعقيد بدلاً من عارض WebGL 2 الخالص ، ولكنه أسهل مسار على المدى القريب والمتوسط. ونحن نتطور ببطء حيث نترك WebGL 1 في نهاية المطاف عندما يكون WebGL 2 في مكان ما أعلى من 90٪ من التبني.

كان لدى Khronos للتو ندوة عبر الإنترنت على webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide = id.gd15060520_0_38
سيتم إصدار الوسائط قريبًا ، لكن العرض التقديمي كان بشكل أساسي عبارة عن صوت فوق الشرائح والعروض التوضيحية المرتبطة بها في الشرائح.

من الواضح تمامًا أن هذا يتطلب بداية جديدة ، وليس "تحديث" من WebGLRenderer الحالي.

فيما يتعلق بوحدات es6 ، أعتقد أن النهج الحالي للمصدر هو وحدات es6 ، ثم استخدام التجميع لحزمة لا يزال هو السبيل لدعم "بناء مزدوج".

لقد قمت بذلك الآن لمدة أسبوع أو نحو ذلك ، لاختبار الوحدات النمطية في Safari Tech Preview والحزمة على جميع المتصفحات. ينتج عنه حقًا إنشاء / امتلاك شجرة المصدر بالإضافة إلى الحزمة الحالية. سطر واحد تراكمي كما هو الحال لديك حاليًا ، ونسخة من شجرة المصدر لاستخدام الوحدة النمطية.

bhouston مغرية ...

أحدث حالة؟

لدي شعور مختلط إلى حد ما حول هذا. في البداية كنت أفكر في نفس المسار الذي اقترحه bhouston ، وأضيف تدريجياً ميزات webgl2 إلى WebGLRenderer الحالي. ولكن هذا من شأنه أن يجعل العارض أكثر تعقيدًا ويصعب التعامل مع الميزات التي تختلف كثيرًا بين الإصدارين وينتهي بها الأمر برمز فوضوي مليء بالفروع وفحوصات الحالة.
قد يكون أحد الخيارات استنساخ WebGLRenderer كنقطة انطلاق لـ WebGL2Renderer والاستمرار في إزالة / إضافة الميزات دون العبث مع العارض الأصلي.
إذا ألقينا نظرة على محركات مثل Playcanvas ، والتي من المحتمل أن تكون المحرك الموجود مع أقدم دعم webgl2 ، يمكننا أن نرى أنه حتى لا يستفيد من ميزات webgl2 الجديدة مثل UBO أو VAO لأنه شيء سيتم تعديله أجزاء كثيرة من المحرك.

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

لذا فإن تصويتي هو أن تبدأ WebGL2Renderer من نقطة الصفر حتى لو تباطأنا (لا يزال لدينا مجال للتحسين حتى يقترب دعم webgl2 من 100٪).

يجب تعديل بعض الملفات بخلاف العارض نفسه ، على سبيل المثال الأنسجة والبرامج وما إلى ذلك. هل يجب علينا إنشاء مجلد فرعي renderer\webgl2 والاستمرار في إضافة الملفات التي سيتم إنشاؤها خصيصًا لهذا العارض؟

يمكننا إنشاء مشكلة بقائمة التغييرات التي يجب أن نقوم بها للحصول على عارض متوافق تمامًا مع webgl2 لوضعها في الاعتبار عند كتابة العارض ، وكذلك إنشاء قائمة بالميزات التي نود أن نوفرها لـ MVP لتركيز جهودنا على المناقشة هذه في هذه الحالة الأولية لبدء محادثة أعمق حول التنفيذ.

أي تحديثات على تطورها؟

ليس بعد. كنت أعطي الأولوية لـ WebVR هذا الشهر.

لقد جربت تحويلًا سريعًا في المكان إلى WebGL2 و ES3 shader ، كما اقترحه fernandojsg أعلاه. ها هو الفرق المحصور: https://github.com/tstanev/three.js/compare/master...tstanev : traian / webgl2 في الواقع ، لا يبدو سيئًا كما توقعت في البداية. يبدو أنه لن يكون من القبيح للغاية دعم كلاهما عبر بعض ifdefs الموضوعة استراتيجيًا.
[تحرير: ارتباط محدث.]

tstanev هل لديك مثال عملي؟

تعمل أمثلة three.js المجمعة في الفرع المرتبط (كما ترى في الفرق ، لقد قمت بتحويل تلك التي كانت تتطلب ملحقات مسبقًا). يمكنك استنساخ الريبو / الفرع وتشغيلها محليًا.

tstanev ماذا عن إجراء مقارنة أداء لتغييرات webgl2 عبر الإنترنت؟) سيكون من الرائع رؤيتها. (three.js مقابل three.js على webgl2)

مرحبا
شكرا لك على هذه الفكرة الأفضل.
أرغب في استخدام webgl2renderer في برنامجي ولكني لم أتمكن من استخدامه في إصدار ما قبل التحويل البرمجي (r86) لذلك أحصل على المصدر وأزل تعليق webgl2rendrer في استيراد three.js ثم إنشائه.
الآن سيتم تشغيل الكود الخاص بي ومثالك (webgl2-sandbox) دون أي خطأ لكنهم لا يظهرون شيئًا

تحرير: لقد اختبرتها في Firefox 54 و chrome 60
المثال الخاص بي باستخدام bufferGeometry و ShaderMaterial وسيعمل بشكل صحيح في webglrenderer

لا احد يجيبني ما هي مشكلة webgl2renderer الآن؟

@ MHA15 من المفترض أنه لم يتم تضمينه في التصميم لأنه غير جاهز للإنتاج بعد.

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

في هذه المرحلة ، هل يمكننا إعادة النظر في استنساخ WebGLRenderer وتغييره إلى WebGL2 بدلاً من ذلك مثل ما فعله mattdesl في https://github.com/mrdoob/three.js/issues/8125 ؟؟ يمكننا بعد ذلك تعديل العارض بناءً على بعض الميزات الجديدة مثل UBO كما قالfernandojsg. في النهاية ، سنقوم بإزالة جميع أكواد webgl 1 القديمة.

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

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

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

أيضًا ، أعتقد أن fernandojsg كان يخطط لتجربته في الأسابيع المقبلة.

هذا رائع. نتطلع إلى عمل رائع منfernandojsg !!

ملاحظة: يجب أن أقول .. أشكر جميع المساهمين في هذا المشروع لتوسيع أفق رسومات الكمبيوتر. آمل أن أتمكن من المساهمة ببعض الأمثلة في المستقبل.

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

بينما نحن فيه ... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
يعمل webgl2_sandbox مرة أخرى (يتطلب وحدات es6).

mrdoob هل لديك أي تقدير تقريبي متى سيكون متاحًا في الإصدار الرئيسي / الإصدار؟ :) أنا سعيد بحدوث ذلك! :)

wdanilo ليس حقًا ... ما الميزات التي تحتاجها من WebGL2؟

mrdoob ستأتي أكبر التحسينات من Uniform Buffer Objects و Sampler2DArray. ستكون مصفوفة النسيج مفيدة بشكل كبير لمشروعي الحالي لأننا نعارض حدود وحدة النسيج لأنني أستخدم تظليلًا معقدًا يضع طبقات متعددة من المواد المقنعة بواسطة خرائط ألفا.

mrdoob ستكون الكلمات الرئيسية الجديدة مثل flat في glsl مفيدة جدًا أيضًا.

يحتاج مشروعي إلى زخارف ثلاثية الأبعاد.

مثير للاهتمام...
من المفيد للغاية أن تكون على دراية بالحالات المحددة التي يحتاج الأشخاص إلى WebGL 2.0 لها.
دعهم يأتون!

تعد القوام ثلاثي الأبعاد أيضًا ميزة كبيرة بالنسبة لنا. أعتقد أننا نستخدم أيضًا بعض ميزات التظليل.

في بعض الأحيان أريد MRT

+1 لأهداف عرض متعددة أيضًا

أهداف العرض المتعددة مدعومة بالفعل في WebGL1 عبر امتداد ، وهناك أيضًا علاقات عامة لها في ThreeJS: https://github.com/mrdoob/three.js/pull/9358 ( عرض توضيحي ).

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

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

+1 لرسم الملاحظات. أم أنها مدعومة بالفعل كملحق webgl1 في
ثلاثة؟

في الخميس ، 14 ديسمبر 2017 الساعة 9:45 مساءً ، كتب Kyle [email protected] :

أنا موافق. تظليل الحل البديل لمنع التشويش على المشاهد التي تمت معالجتها بعد ذلك
مع تأثيرات الملحن لا يكفي لمقاومة التعرجات الحقيقية.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

لدي حالتان من حالات الاستخدام هنا:

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

يعد استخدام الصقل والمعالجة اللاحقة معًا هو الأكثر أهمية بالنسبة لي.

mrdoob أفضل 3 ميزات لـ WebGL 2 / حالات استخدام (مرتبة حسب الأهمية):

1. أهداف العرض متعددة العينات: للحصول على AA مناسب (MS) في مرحلة ما بعد المعالجة.
2. القوام الصحيح: للقيام بالخوارزميات القائمة على الصور مثل حقول المسافة الموقّعة ، بالإضافة إلى استخدام بيانات أكثر غرابة قائمة على النسيج مثل DEM (نماذج الارتفاع الرقمية).
3. ردود الفعل التحويلية: للقيام بأنظمة الجسيمات.

mrdoob بالمناسبة ، هل تعرف لماذا لم يتم دمج # 9358 PR؟ كما كتب mattalat ، فإنه يجلب عرض multitarget إلى threejs. تم الالتزام به منذ عامين ، وتم إصلاحه عدة مرات لمواكبة التغييرات الأخرى وحتى الآن لم يعد موجودًا :(

أنا أسأل عن ذلك لأنني حصلت على مشهد بكثافة باستخدام أوصاف شكل SDF. ينتج كل شكل 6 مخرجات مختلفة ، لذا الآن أحسبه 6 مرات بالمرور إلى أرقام التظليل من 0 إلى 5. سيكون من الأجمل استخدام نواتج متعددة وسيؤدي ببساطة إلى تعزيز أداء 5x.

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

/ سم مكعب edankwan

نحتاج إلى مواد ثلاثية الأبعاد وأهداف عرض متعددة العينات.

إنني أتطلع لاستخدامه حتى أتمكن من تعيين deepTexture.type = THREE.FloatType .. ما لم تكن هناك طريقة أخرى للقيام بمثل هذا الشيء حاليًا.

هل هناك أمل في أن يعمل LineThickness بخلاف 1 على Windows و WebGL 2.0؟ إذا كانت الإجابة بنعم ، فسيؤدي ذلك إلى تحسين بعض مخرجاتنا.

وهنا أرد على نفسي. قراءة سماكة الخطوط باستخدام مادة أساسية بثلاثة أسطر على SO فهمت أن الخطوط السميكة ستحتاج إلى هندسة في المستقبل على أي حال.

@ Richard004 هذا ليس له علاقة بـ WebGL 2. لدينا بالفعل علاقات عامة لطلب هذه الميزة ، راجع # 11349 👍

مرحبًا mrdoob و @ Mugen87
أحتاج إلى معالجات صغيرة داخل تظليل الأجزاء بالإضافة إلى فهرسة الصفيف الديناميكية. ربما لا يكون النوع الأول شائعًا جدًا ، لكنني أحتاجه بغض النظر لأنني أحاول نقل نواة CUDA إلى WebGL (GLSL) ولغات تظليل أخرى تسمح بمعالجة البتات ، لكن WebGL 1.0 (GLSL) لا يفعل ذلك.

الثاني أعتقد أن الكثير من المطورين يمكن أن يستفيدوا منه: وهو الوصول إلى عنصر مصفوفة بمتغير. حاليًا في WebGL 1.0 (GLSL) ، سيفشل برنامج مثل هذا:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

ولكن في WebGL 2.0 ، يمكنك القيام بذلك. غالبًا ما يكون مطلوبًا داخل حلقة ، حيث تحتاج إلى الحصول على قيم مختلفة من مصفوفة ، ولكن لا يمكنك فقط عمل حلقة تكرارية (من 0 إلى 199 في المثال أعلاه) ، لأنك ستحتاج بعد ذلك إلى التحقق من كل واحدة وهذا بطيء حقًا.

سيكون منع الحواف في المعالجة اللاحقة مفيدًا بالتأكيد.

تحت كل هذا السؤال: هل حان الوقت لمعمارية جديدة لثلاثة؟

لقد بدأت مؤخرًا في استخدام D3 ، الإصدار 4. لقد كانت إعادة تصميم كاملة . Es6
الوحدات. والأهم من ذلك بكثير ، 30 وحدة ، كل منها كانت خاصة بها
الريبو. أوصي حقًا بالنظر إلى بنية D3.

أنا لا أقول أننا بحاجة إلى هذا من أجل Three ، لكنني أعتقد أنه يمكننا التفكير في ملف
نتوء الإصدار الرئيسي. جزئيًا بسبب webgl2. ولكن أيضا بسبب الحاجة إلى
الوحدات الفرعية.

مثال: هناك وحدة نمطية / ريبو / فرعية D3. إنها الأساسيات الخاصة بك
الوحدة النمطية jQuery DOM ولكن مع كل إسهاب DOM المخفي في ملف
وظيفي ، تصميم تسلسلي. يمكن استخدامه كما هو دون استخدام باقي
د 3.

ألا تحب ثلاث وحدات مستقلة جعلت كل webgl
الإسهاب تختفي؟ ربما حتى وحدات فرعية متعددة لـ webgl ctx / shader
الإدارة وإدارة المخزن المؤقت وما إلى ذلك. في الواقع ، فإن هندسة المخزن المؤقت هي أ
الكثير من هذا القبيل. كما سبق لإنشاء تظليل من الأجزاء.

مجرد فكرة.

@ fetox74 متأكد أنك تستطيع فعل AA بالفعل https://threejs.org/examples/؟q=fxaa#webgl_postprocessing_fxaa

elunty لا ينتج FXAAShader نتيجة جيدة بما يكفي مقارنةً بمانع التشويش الأصلي ، لقد استخدمته في البرية.

أنا مهتم في الغالب بـ VAOs والكتابة إلى خرائط الصور التي آمل أن يكون ذلك ممكنًا بموجب تلك المواصفات.

pailhead ذات الصلة # 8705: غمزة:

نتطلع إلى الدعم المحلي لـ EXT_shader_texture_lod .
قد يتم حل المشكلات التي يتم إنشاؤها أثناء استخدام MeshStandardMaterial و MeshPhysicalMaterial على معظم أجهزة Android و MS Edge و Internet Explorer

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

wdanilo إذا كان WebGL 2.0 يمثل أولوية لمشروعك ، فإنني أوصيك بالترحيل إلى Babylon. أعرف أن بعض المساهمين من موقع Three.js يخططون للعمل على ذلك ، لكني شخصياً أركز على WebVR وسير عمل الفنانين (دعم svg ، إلخ).

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

(شكرا مرة أخرى takahirox ، كنت على علم بهذا الموضوع). لقد قدمت للتو طلب سحب # 13692. أفهم أن التركيز ليس عليها ولكن لأغراضنا ، فهي تعمل بشكل جيد.

ذات الصلة # 13702

لقد أنشأت فرعًا أساسيًا لـ WebGL2 يتبع # 9965 و # 12250

الريبو: https://github.com/takahirox/three.js/tree/WebGL2Base
أمثلة: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

يمكنك بدء WebGL2.0 + Three.js معها.

(آسف التضارب مع عمل yoshikiohshima )

mrdoob هل يمكننا الحصول على فرع لـ WebGL2Renderer مثل three.js / dev-2.0؟ أو هل يمكننا دمجها في dev مع استمرار وجود الكثير من الرموز المكررة بين webgl1 و webgl2؟

أنا جديد في التطور السابق بشأن هذه المسألة. takahirox ، هل يمكنك تلخيص الاستراتيجية التي تتبعها وما الذي يدعمه https://github.com/takahirox/three.js/tree/WebGL2Base؟ (وآسف مرة أخرى لجهلي) لكنني لم أرَ الحاجة إلى الكثير من الرموز المكررة لدعم WebGL2. ما هي القضايا؟

mrdoob هل يمكننا الحصول على فرع لـ WebGL2Renderer مثل three.js / dev-2.0؟ أو هل يمكننا دمجها في dev مع استمرار وجود الكثير من الرموز المكررة بين webgl1 و webgl2؟

لست متأكدًا من سبب احتياج هذا إلى فرع جديد. لماذا سيكون هناك رمز مكرر؟

لا يبدو أي صراعات. هناك مطلبان لـ WebGL2.0 الآن.

1. جعل WebGL2Renderer لدعم ميزات WebGL2.0 الكاملة والتحسين الجيد
2. إضافة دعم webgl2 إلى دعم WebGLRenderer الحالي. لكننا لا ندعم ميزات WebGL2.0 بشكل كامل ولا نقوم بالتحسين لـ WebGL2.0 لأننا لا نريد إفساد العارض. هذا في الأساس مخصص للوصول المبكر إلى Three.js + WebGL2.0 + GLSL3.0

خاصتي لـ 1. عمله لـ 2. ليس لدينا رمز مكرر ولست بحاجة إلى إنشاء فرع جديد لـ 2.

takahirox أعتقد أنه سيكون من الأفضل العمل في نفس الفرع في الوقت الحالي.

إذا قمت بتحسين ...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

و webgl2 تستورد الأمثلة الفئات مباشرة (لا تحتاج إلى إصدارات) ...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

لا ينبغي أن تكون هناك صراعات.

يمكنك أن تنسى WebGL2Base الخاص بي حتى الآن لأنه يبدو أننا بدأنا دعم WebGL2.0 في WebGLRenderer .

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

أعتقد ذلك ، نعم. أعتقد أن إضافة دعم webgl 2.0 الأساسي إلى WebGLRenderer الحالي هو مجرد الحصول على شيء ما أثناء العمل على WebGL2Renderer .

لا تتردد في البدء في إعادة كتابة العارض وإرسال العلاقات العامة (بشكل مثالي خطوة بخطوة).

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

أتساءل عما إذا كان webgl2 قابل للاستخدام في حالته الحالية في Three.js؟ (حتى لو كان مجرد عرض شبكات هندسة عازلة بسيطة) هل سيعمل EffectComposer مع عارض يدعم سياق webgl2؟ هل يجب تعديل هدف التجسيد بأي طريقة؟

السؤال الأكبر ، بالطبع ، هو ما إذا كان من الممكن حاليًا الحصول على تنقية مناسبة عند استخدام الملحن مع ممرات مخصصة؟

يبدو في النهاية أننا انتهينا للتو من إضافة ميزات WebGL 2.0 إلى WebGLRenderer .
سيحتاج WebGPU بالتأكيد إلى WebGPURenderer بالرغم من ذلك.