دوستان من سعی کردم این آموزش رو تو یونیتی پیاده سازی کنم اما یکسری مشکل داره که ان شاء الله بعداً اصلاحش می کنم

پیاده سازی Depth

در مبحث قبل اشاره ای به forward rendering شد
امروز می خوایم Forward rendering و Deferred Rendering رو با هم مقایسه کنیم

اگر شما یک توسعه دهنده بازی های سه بعدی هستید، احتمالا تا حالا اسم forward rendering و deferred rendering به گوشتون خورده. درواقع شما باید یکی از آن دو را انتخاب کنید تا در بازی خود استفاده کنید. اما آیا تا به حال فکر کردید آنها چه هستند ، چه تفاوتی دارند و کدام یک را باید انتخاب کنید؟
با ما همراه باشید تا جلو تر این دو شیوه ی رندرینگ را تعریف و مقایسه کنیم تا شما را از سردر گمی نجات دهیم.

Deferred Rendering for many lights

پایپ لاین های گرافیک مدرن

برای شروع نیاز داریم تا کمی درباره ی پایپ لاین های مدرن یا قابل برنامه نویسی بدانیم
در زمان قدیم ما در چیزی که پایپ لاین کارت های گرافیک داشتند محدود بودیم
جدا از فرستادن در یک تکسچر متفاوت نمی توانستیم بگیم چطور هر پیکسل باید تغییر کند،
و نمی توانستیم ورتکس ها را وقتی در کارت بودند پیچیده کنیم.
اما زمان تغییر کرده است و ما هم اکنون می توانیم پایپ لاین های گرافیکی قابل برنامه نویسی داشته باشیم.
ما اکنون می توانیم کُد را به کارت ویدیو ارسال کنیم تا تعیین کنیم چگونه پیکسل ها ظاهر شوند و آنها را با نرمال مپ نا هموار جلوه دهیم و بازتاب(reflection) را اضافه کنیم( و چیز های دیگری اضافه کنیم که واقعی تر به نظر برسد)
این کد شکل هندسی است، ورتکس و فرگمنت شیدر ، و اساساً آنها تعیین می کنند که ویدیو کارت چگونه آبجکت هاتون رو رندر کند.

دید اجمالی از کارت گرافیک قابل برنامه نویسی

Forward Rendering

فوروارد رندرینگ استاندارد است،تکنیک رندر بیرون جعبه (out-of-the-box) که بیشتر موتورها استفاده می کند.شما شکل هندسی را برای کارت گرافیک تهیه می کنید،شکل هندسی آن را طرح ریزی ، و آن را به ورتکس ها تقسیم می کند و سپس آنها تبدیل و جدا به فرگمنت یا پیکسل هایی می کند که رفتار نهایی رندر را قبل از اینکه روی صفحه فرستاده شوند بیان می کند.

Forward rendering: Geometry shader to vertex shader to fragment Shader

این روش نسبتا خطی است و هر شکل هندسی یک بار در زمان به از خط لوله عبور می کند تا تصویر نهایی را ایجاد کند.

Deferred Rendering

همانطور که از نامش بر می آید ، در رندر تأخیر دارد یعنی رندرینگ تا زمانی که تمام شکل های هندسی لوله را عبور نکند، انجام نمی شود لذا کمی به تعویق می افتد.در نهایت تصویر نهایی پس از اعمالShading تولید می شود.

حالا، چرا این کار را می کنیم؟

Deferred rendering: Geometry to vertex to fragment shaders. Passed to multiple render targets, then shaded with lighting.

نور پردازی تأخیر افتاده یک deferred rendering اصلاح شده است که سایز G-buffer
را با استفاده از پاس های بیشتر در Scene کاهش می دهد

Lighting Performance

نورپردازی دلیل اصلی رفتن یک مسیر در مقابل مسیر دیگر است. در یک پایپ لاینforward rendering استاندارد، محاسبات روشنایی باید بر روی هر ورتکس و هر فرگمنت در صحنه قابل رویت، برای هر نور در صحنه اجرا شود.

اگر یک صحنه با 100 شکل هندسی داشته باشید و هر شکل هندسی دارای 1000 ورتکس باشد،حتی ممکن است شما حدود 100000 چند ضلعی داشته باشید (یک تخمین بسیار خشن). کارت های ویدئویی می توانند این را به راحتی اداره کنند. اما زمانی که این چند ضلعی ها به فرگمنت شیدر فرستاده می شوند، در این صورت محاسبات نور گرانقیمت اتفاق می افتد و می تواند سرعت واقعی را کاهش دهد

توسعه دهندگان سعی می کنند تا محاسبات روشنایی را به Vertex shader بسپارند تا بتوانند میزان کارهایی را که فرگمنت شیدر باید انجام دهد را کاهش دهند.

محاسبات گرانقیمت نور باید برای هر قطه قابل مشاهده چند ضلعی ها روی صفحه نمایش اجرا شود، صرفنظر از اینکه آیا آن با هم تداخل دارند یا توسط قسمت های چند ضلعی دیگر پنهان می شوند. اگر صفحه نمایش شما دارای رزولوشن 1024x768 باشد (که به هیچ وجه، رزولوشن بسیار بالا نیست) تقریبا 800،000 پیکسل دارید که باید رندر شوند. شما به راحتی می توانید به یک میلیون عملیات قطعه در هر فریم برسید. همچنین بسیاری از قطعات آن را هرگز به صفحه نمایش نمی برند زیرا آنها با آزمایش عمق(depth testing) حذف شده اند و بنابراین محاسبات روشنایی بر روی آنها نابود شده است.