كيف يتم تقديم إطار Rise of the Tomb Raider

Rise of the Tomb Raider (2015) هو تكملة لإعادة تشغيل Tomb Raider الممتازة (2013). شخصيا ، أجد أن كلا الجزأين مثير للاهتمام لأنهما ابتعدا عن السلسلة الأصلية الراكدة وروا قصة لارا مرة أخرى. في هذه اللعبة ، كما هو الحال في المجموعة السابقة ، يحتل المكان الرئيسي قطعة الأرض ، وهو يوفر ميكانيكا رائعة للصياغة والصيد والتسلق / البحث.

Tomb Raider يستخدم Crystal Engine ، الذي طورته Crystal Dynamics ، والذي يستخدم أيضًا في Deus Ex: Human Revolution . استخدم التكميل محركًا جديدًا يسمى Foundation ، تم تطويره مسبقًا لارا كروفت ومعبد أوزوريس (2014). يمكن وصف عملية التقديم بشكل عام على أنها محرك بلاطات مع تمرير إضاءة أولي ، وسنتعرف فيما بعد على معنى ذلك. يتيح لك المحرك الاختيار بين عارضين DX11 و DX12 ؛ اخترت هذا الأخير ، للأسباب التي نناقشها أدناه. لالتقاط الإطار ، تم استخدام Renderdoc 1.2 على Geforce 980 Ti ، وتشمل اللعبة جميع الوظائف والديكورات.

تحليل الإطار

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

تقدم العمق

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

في هذه المرحلة ، اكتشفت مستوى مثيرًا للاهتمام من التفاصيل (LOD) يسمى "fizzle" أو "checkerboard". هذه طريقة شائعة لعرض الأشياء أو إخفائها تدريجياً من مسافة بعيدة ، بحيث يمكن استبدالها لاحقًا بشبكة منخفضة الجودة أو إخفائها تمامًا. انظر إلى هذه الشاحنة. يبدو أنه يتم تقديمه مرتين ، ولكنه في الواقع يتم تقديمه باستخدام LOD مرتفع و LOD منخفض في نفس الموضع. يعرض كل مستوى من هذه البكسلات التي لم يعرضها الآخر. تحتوي LOD الأولى على 182،226 رأسًا ، والثانية LOD لها 47،250. على مسافة كبيرة ، لا يمكن تمييزها ، لكن أحدهما أقل تكلفة بثلاث مرات. في هذا الإطار ، يختفي LOD 0 تقريبًا ، ويتم تقديم LOD 1 تقريبًا بالكامل. بعد الاختفاء الكامل لـ LOD 0 ، سيتم تقديم LOD 1 فقط.


LOD 0


اللد 1


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

1. الراحة للمرور الأولي للأعماق: بفضل تقديم كائن غير شفاف مع وجود ثقوب مصنوعة فيه ، يمكننا تقديمه في المرور التمهيدي واستخدامه مبكرًا. الكائنات مع مزج ألفا في مثل هذه المرحلة المبكرة لن يتم عرضها في المخزن المؤقت للعمق بسبب مشاكل الفرز.
2. الحاجة إلى تظليل إضافي : إذا تم استخدام عارض مؤجل ، فإن تظليل الكائنات المعتمة لا يحتوي على أي إضاءة. إذا كنت بحاجة إلى استبدال كائن غير شفاف بكائن شفاف ، فأنت بحاجة إلى خيار منفصل به إضاءة. بالإضافة إلى زيادة مقدار الذاكرة المطلوبة والتعقيد بسبب تظليل إضافي واحد على الأقل لجميع الكائنات غير الشفافة ، يجب أن تكون دقيقة لتجنب تحرك الكائنات للأمام. هذا الأمر معقد لعدة أسباب ، لكن الأمر كله يرجع إلى حقيقة أن التقديم يتم الآن في مسار رمز مختلف.
3. عمليات إعادة رسم أكبر : يمكن أن يؤدي مزج ألفا إلى إنشاء عمليات إعادة رسم كبيرة ، وفي مستوى معين من تعقيد الكائنات ، قد تكون هناك حاجة لجزء كبير من عرض النطاق الترددي لتظليل LOD.
4. تعارضات Z : تعارضات z تأثير وميض عندما يتم عرض مضلعين على عمق وثيق جدًا لبعضهما البعض. في هذه الحالة ، فإن عدم دقة حسابات الفاصلة العائمة يجبرهم على الظهور بدورهم. إذا قمنا بتقديم LODs متتاليين ، ونخفي أحدهما بشكل تدريجي ونظهر الثاني ، فقد يتسبب ذلك في حدوث تعارض ، لأنهم قريبون جدًا من بعضهم البعض. هناك دائمًا طرق للتغلب على هذا ، على سبيل المثال ، تفضيل مضلع واحد إلى آخر ، ولكن مثل هذا النظام معقد.
5. تأثيرات Z-Buffer : تستخدم العديد من التأثيرات مثل SSAO المخزن المؤقت للعمق فقط. إذا قمنا بتقديم كائنات شفافة في نهاية خط الأنابيب عند اكتمال انسداد المحيط ، فلن نتمكن من أخذ ذلك في الاعتبار.

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

ممر عادي

تستخدم Crystal Dynamics نمط إضاءة غير عادي إلى حد ما في ألعابها ، والتي سنغطيها في ممر الإضاءة. في الوقت الحالي ، يكفي أن نقول أن المحرك ليس لديه ممر G-buffer ؛ على الأقل إلى الحد الذي هو مألوف في الألعاب الأخرى. في هذا المقطع ، تنقل الكائنات معلومات فقط عن العمق والقواعد الطبيعية إلى الإخراج. يتم تسجيل المعايير في هدف التجسيد بتنسيق RGBA16_SNORM في مساحة العالم. من الغريب أن يستخدم هذا المحرك مخطط Z-up ، وليس Y-up (يتم توجيه المحور Z للأعلى وليس المحور Y) ، والذي يتم استخدامه في أغلب الأحيان في محركات / حزم نماذج أخرى. تحتوي قناة ألفا على لمعان ، يتم تفكيكها بعد ذلك كـ exp2(glossiness * 12 + 1.0) . يمكن أن تكون قيمة اللمعان سلبية أيضًا ، لأن العلامة تستخدم كعلم يشير إلى ما إذا كان السطح معدنيًا. يمكن ملاحظة ذلك من تلقاء نفسه ، لأن كل الألوان الداكنة في قناة ألفا مرتبطة بالكائنات المعدنية.

ر	ج	ب
Normal.x	عادي	Normal.z	لمعان + المعدن

عادي


اللمعان / المعدن

مزايا المغادرة


تذكر أنه في قسم "العمق الأولي" ، تحدثنا عن توفير تكاليف البكسل؟ سأعود قليلا لتوضيح ذلك. التقط الصورة التالية هذا هو تقديم الجزء المفصل من الجبل إلى المخزن المؤقت العادي. يرجى Renderdoc تمييز البكسلات التي اجتازت اختبار العمق باللون الأخضر ، وتلك التي لم تجرها باللون الأحمر (لن يتم عرضها). إجمالي عدد البكسلات التي سيتم تقديمها دون هذا التمرير الأولي يساوي تقريبًا 104518 (يتم حسابه في Photoshop). إجمالي عدد وحدات البكسل التي يتم عرضها فعليًا هو 23858 (يتم حسابها بواسطة Renderdoc). وفر حوالي 77 ٪! كما نرى ، مع الاستخدام الذكي ، يمكن لهذا التمرير الأولي أن يحقق مكسبًا كبيرًا ، ولا يتطلب سوى حوالي مائة مكالمة سحب.

تسجيل الأوامر ذات مؤشرات الترابط


تجدر الإشارة إلى جانب واحد مثير للاهتمام ، بسببه اخترت العارض DX12 - تسجيل أوامر متعددة الخيوط. في واجهات برمجة التطبيقات السابقة ، مثل DX11 ، يتم إجراء التقديم عادةً في سلسلة رسائل واحدة. تلقى برنامج تشغيل الرسومات أوامر تقديم من اللعبة وطلبات GPU المرسلة باستمرار ، لكن اللعبة لم تكن تعلم متى سيحدث ذلك. هذا يؤدي إلى عدم الكفاءة ، لأن السائق يجب أن يخمن بطريقة ما ما يحاول التطبيق القيام به ، ولا يتعدى عدد مؤشرات الترابط. تقوم واجهات برمجة التطبيقات الأحدث ، مثل DX12 ، بتسليم التحكم إلى مطور يمكنه تحديد كيفية كتابة الأوامر ومتى يتم إرسالها. على الرغم من أن Renderdoc لا يمكنه إظهار كيفية إجراء التسجيل ، فسترى أن هناك سبعة تمريرات ملونة تم تمييزها على أنها Color Pass N ، ويتم لف كل منها في زوج من ExecuteCommandList: Reset / Close. يمثل بداية ونهاية قائمة الأوامر. حسابات القائمة لحوالي 100-200 مكالمات السحب. هذا لا يعني أنه تم تسجيلها باستخدام عدة تدفقات ، ولكن تلميحات في ذلك.

آثار أقدام في الثلج


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

أطلس الظلال

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


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

الظلال من الإضاءة الاتجاهية

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

انسداد المحيطة

بالنسبة للإغلاق المحيط ، تسمح لك ROTR باستخدام إما HBAO أو متغير من HBAO + (تم نشر هذه التقنية في الأصل بواسطة NVIDIA). هناك العديد من الاختلافات في هذه الخوارزمية ، لذلك سأنظر في تلك التي وجدت في ROTR. أولاً ، يتم تقسيم المخزن المؤقت للعمق إلى 16 نسيجًا ، يحتوي كل منها على 1/16 من جميع قيم العمق. يتم إجراء الفصل بطريقة تحتوي كل مادة على قيمة واحدة من كتلة 4 × 4 من النسيج الأصلي الموضح في الشكل أدناه. يحتوي النسيج الأول على جميع القيم المميزة باللون الأحمر (1) ، والثاني يحتوي على القيم المحددة باللون الأزرق (2) ، وهكذا. إذا كنت تريد معرفة المزيد عن هذه التقنية ، إليك مقالة كتبها لويس بافويل ، الذي كان أيضًا أحد مؤلفي المقال حول HBAO.


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


أجزاء HBAO


HBAO الكامل مع الضوضاء


HBAO الكامل طمس أفقي


جاهز HBAO

الإضاءة المتجانبة

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


منتشر الإضاءة


إضاءة المرآة


الإضاءة المحيطة

تحسين البلاط

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

عمق التكبير

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

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


نصف القرار الإضاءة المحيطة


تحجيم أعماق الداخلية


الإضاءة المحيطة قرار كامل ، لا أضلاعه


زيادة أعماق الأضلاع


الإضاءة المحيطة جاهزة


عرض نصف القرار


صورة عن قرب للصورة المعاد إنشاؤها

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

تأملات

هذا المشهد ليس مثالًا جيدًا لإظهار الأفكار ، لذلك اخترت مشهدًا آخر. تظليل الانعكاس هو مجموعة معقدة إلى حد ما من الدورات ، والتي يمكن تقليصها إلى جزأين: واحدة عينات خرائط مكعب ، والآخر ينفذ SSR (انعكاس مساحة الشاشة - حساب الانعكاسات في مساحة الشاشة) ؛ كل هذا يتم في مسار واحد وفي النهاية يتم خلطه مع الأخذ في الاعتبار المعامل الذي يحدد ما إذا كان SSR قد تم اكتشاف الانعكاس (ربما يكون المعامل ليس ثنائيًا ، ولكنه يمثل قيمة في الفاصل الزمني [0 ، 1]). يعمل SSR بطريقة قياسية للعديد من الألعاب - يتتبع مرارًا وتكرارًا المخزن المؤقت للعمق ، في محاولة للعثور على أفضل تقاطع بين الأشعة المنعكسة على السطح المظلل وسطح آخر في أي مكان في الشاشة. يعمل SSR مع سلسلة mip للمقياس المخفض مسبقًا من المخزن المؤقت HDR الحالي ، وليس مع المخزن المؤقت بأكمله.

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


تأملات ل


انعكاس العازلة


تأملات بعد

ضباب مضاء

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


الضباب ل


الضباب بعد

الإضاءة الحجمي

في المراحل المبكرة من الإطار ، يتم إجراء العديد من العمليات للتحضير للإضاءة الحجمي. يتم نسخ جهازي تخزين مؤقت من وحدة المعالجة المركزية إلى وحدة معالجة الرسومات: فهارس مصدر الضوء وبيانات مصدر الضوء. تتم قراءة كلاهما بواسطة تظليل حسابي ، والذي يخرج نسيجًا ثلاثي الأبعاد 40 × 23 × 16 من عرض الكاميرا يحتوي على عدد مصادر الإضاءة التي تعبر هذه المنطقة. الملمس هو 40 × 23 لأن كل مربع يشغل 32 × 32 بكسل (1280/32 = 40 ، 720/32 = 22.5) ، و 16 هو عدد البكسل في العمق. لا يحتوي النسيج على جميع مصادر الإضاءة ، ولكن فقط تلك التي تم تحديدها كمصطلحات ضخمة (هناك ثلاثة في مشهدنا). كما سنرى أدناه ، هناك تأثيرات حجمية وهمية أخرى تم إنشاؤها بواسطة مواد مسطحة. يحتوي الملمس المعروض على دقة أعلى - 160 × 90 × 64. بعد تحديد عدد مصادر الإضاءة لكل بلاطة وفهرسها ، يتم تنفيذ ثلاثة تظليل حسابي بالتتابع ، وتنفيذ العمليات التالية:

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

, 3D-, , . , — , HDR-. 16 .

PureHair , . - , . , . Tomb Raider TressFX, Crystal Dynamics . 7 . . :

1. ( motion blur)
2. 1×1 ()
3. 122 (Triangle Strip) ( — ). , . 7 , . , , . « ».
4. / quad , , . , , .
5. 4, ( « »)

, AMD , . 1, , 3, , , , ; , Renderdoc - . , , , , .

-

, . , ( ). , ! HDR-, , , .. - , - (, ).


, , , , , , .. HDR- , . , 40 . , . , , ( , , ). , -, , .. , , , . , «» , . , . , .





-


1


2


3








-

ROTR . , -, . , . (luminance) ROTR , . 64×64, (20, 12, 1) 256 . ( ):

 for(int i = 0; i < 16; ++i) { uint2 iCoord = CalculateCoord(threadID, i, j); // Obtain coordinate float3 hdrValue = Load(hdrTexture, iCoord.xyz); // Read HDR float maxHDRValue = max3(hdrValue); // Find max component float minHDRValue = min3(hdrValue); // Find min component float clampedAverage = max(0.0, (maxHDRValue + minHDRValue) / 2.0); float logAverage = log(clampedAverage); // Natural logarithm sumLogAverage += logAverage; } 

64 (256 , 16 ). , , ( 64×64 , , , ). ; 16 , , ( 0) . 240 , . 64 , , . .

, . 64 , , , . , .

. , ROTR (Photographic Tonemapping) , . ( ) :



. , Lm, . whitePoint 1.0, , . LDR! , 1.0.

(Lens Flares) . 1xN ( N — , , 28). - , - , , . , .


, . - 0.01, NaN, . bloom , .


Lens Flares


Lens Flare


Lens Flares

Bloom

Bloom : HDR-, , , . . , . 7 : 2 , 1 , 4 .

1. target (mip 1). . , mip- , 0.02.
2. mip mip 2, 3, 4 5.
3. mip 5. , . , .
4. — . 3 , mip N mip N + 1, , . bloom , .
5. mip 1 HDR-, bloom.

Bloom


MIP 1 Bloom


MIP 2 Bloom


MIP 3 Bloom


MIP 4 Bloom


MIP 5 Bloom


MIP 5 Bloom


MIP 4 Bloom


MIP 3 Bloom


MIP 2 Bloom


MIP 1 Bloom


Bloom

, . , ; , , 16. : , float32 float16! . , .

FXAA

ROTR (), FXAA (Fast Approximate AA) SSAA (Super Sampling AA). temporal AA, AAA- . , FXAA , SSAA , «» , .

Motion Blur

, Motion blur ( ) , Shadows of Mordor . . , , , , . , , . , , . : -, , , -, . , .


Motion Blur


Motion Blur


Motion Blur, 1


Motion Blur, 2


Motion Blur, 3


Motion Blur, 4


Motion Blur, 5


Motion Blur, 6


Motion Blur,


Motion Blur,

, .

1. :
2. :
3. : , , , ,

UI

UI — . UI -. ROTR . , 3D UI; HDR- sRGB- , (-) .

, , . . Crystal Dynamics , . Renderdoc. PC . , , — , DX12. , .