سعی کنید تجسم کنید که موقعیت فضای جهان و بردارهای نرمال واقعاً درست است. به عنوان مثال، بردارهای نرمال که به سمت راست می آیند، بیشتر به یک رنگ قرمز تراز می شوند، بردارهای موقعیت هم مشابه آن ازorigin صحنه به سمت راست است. به زودی از محتوای G-buffer راضی می شوید، وقت آن است که به مرحله بعدی بروید: پاس lighting.
با یک مجموعه بزرگ از داده های فرگمنتی در G-Buffer که در اختیار ما قرار دارد، می توانیم به طور کامل رنگ های نور نهایی صحنه را با تکرار بر هر یک از پیکسل بافت های G-Buffer با استفاده از پیکسل و استفاده از محتوای آنها به عنوان ورودی به الگوریتم های نور محاسبه کنیم. از آنجا که مقادیر بافت G-buffer مقادیر تبدیل شده فرگمنت نهایی را نشان می دهد، ما فقط باید عملیات گران قیمت نورپردازی را یک بار در هر پیکسل یکبار انجام دهیم.
این باعث می شود که deferred shading بسیار کارآمد باشد، به ویژه در صحنه های پیچیده که در آن ما می توانیم به راحتی فرگمنت شیدر های گران قیمت را در هر پیکسل در تنظیمات forward rendering فراخوانی کنیم.
برای پاس نور ما قصد داریم یک چهارگوش(quad) دوبعدی را در صفحه رندر کنیم(کمی شبیه به post-processing effect) و یک نور پردازی گران قیمت فرگمنت شیدری را روی هر پیکسل اجرا کنیم.
ما قبل از رندر همه بافت های مربوط به G-buffer را به هم متصل می کنیم و همچنین متغیرهای یکنواخت مرتبط با نور را به shader ارسال می کنیم.
فرگمنت شیدرِ پاس نور خیلی شبیه به آموزش هایی است که تا کنون دیدیم. چیزی که جدید است روشی است که ما در مقادیر ورودی نور از G-Buffer نمونه برداری می کنیم به دست می آوریم:
پاس نور 3 بافت یکنواخت را قبول می کند که G-buffer را نشان می دهد و تمام اطلاعاتی را که ما در پاس geometry ذخیره کرده ایم را نگه می دارد. اگر ما این نمونه ها را با مختصات بافت فعلی فرگمنت مقایسه کرده بودیم، می توانستیم مقادیر دقیق فرگمنت را همانطور که مستقیما در geometry رندر می کنیم، بدست آوریم.در ابتدای فرگمنت شیدر ما متغیرهای مربوط به روشنایی را از بافت بافت G-Buffer با یک جستجوی بافت ساده بازیابی می کنیم. توجه داشته باشید که هر دو رنگ Albedo و شدت Specular را تنها از بافت gAlbedoSpec بازیابی می کنیم.
همانطور که در حال حاضر متغیرهای هر فرگمنت (و متغیرهای یکنواخت یکسان) برای محاسبه روشنایی Blinn-Phong ضروری است ما لازم نیست که هیچ تغییری در کد نور بدهیم. تنها چیزی که در deferred shading تغییر می دهیم، روش دریافت متغیرهای ورودی روشنایی است.
اجرای یک نسخه ی نمایشی ساده با مجموع 32 عدد کوچک به نظر می رسد کمی شبیه به این است:
یکی از معایب deferred shading این است که امکان ترکیب کردن همه مقادیر وجود ندارد زیرا تمام مقادیر موجود در G-buffer از یک فرگمنت است و ترکیب روی ترکیب چندین فرگمنت عمل می کند.یکی دیگر از ضعف ها این است که deferred shading شما را مجبور به استفاده از الگوریتم نور مشابه برای اکثر روشنایی های صحنه ی شما می کند. شما می توانید این کار کمی را با اضافه نمودن داده های متریال خاص در G-Buffer کاهش دهید.
برای غلبه بر این معایب (به ویژه ترکیب کردن) ما اغلب رندر را به دو بخش تقسیم می کنیم: یک بخش deferred rendering و دیگری بخش forward rendering به طور خاص به این معنی است که برای ترکیب یا شیدر جلوه های ویژه برای یک پایپ لاین deferred rendering مناسب نیست.برای نشان دادن این که چگونه این کار می کند، منابع نور به صورت مکعب های کوچک با استفاده از یک رندر رو به جلو به کار گرفته می شود، زیرا مکعب های نور به یک سایه مخصوص نیاز دارند (به سادگی یک رنگ نور منفرد).
می خواهیم هر یک از منابع نور را به عنوان یک مکعب سه بعدی که در موقعیت منبع نور قرار گرفته و در حال تاباندن رنگ نور در کنار deferred renderer است رندر کنیم.اولین ایده ای که به ذهن می آید این است که به سادگی منابع نور را در بالای چهار گوش deferred lighting در پایان پایپ لاین deferred shading ، forward render کنیم.بنابراین اساسا مکعب ها را همانطور که ما به طور معمول انجام می دهیم، انجام می دهیم، اما تنها پس از اینکه ما عملیات deferred rendering را تمام کردیم. .در کد اینجور به نظر می رسد:
با این حال، این مکعب های رندر شده هیچی از عمق geometry ذخیره شده ی deferred renderer به حساب نمی آید و در نتیجه همیشه در بالای اشیاء قبلی رندر می شود ؛ این نتیجه ای نیست که ما دنبال آن هستیم.