تفاوت موتور رندر EEVEE و Cycles در بلندر

EEVEE یا Cyclesکدام موتور رندر بلندر را انتخاب کنیم؟

اگر تا حالا یک صحنه را در بلندر با Cycles رندر گرفته‌اید و برای دیدن نتیجه چند دقیقه یا حتی چند ساعت منتظر مانده‌اید، احتمالاً این سوال برایتان پیش آمده که چرا اصلاً باید این‌قدر صبر کنید، وقتی همان صحنه در ویوپورت با EEVEE تقریباً بی‌درنگ نمایش داده می‌شود. از طرف دیگر شاید یک بار هم صحنه‌ای را با EEVEE رندر گرفته‌اید و از تفاوت نورپردازی و بازتاب‌ها نسبت به چیزی که در Cycles دیده بودید، جا خورده‌اید. در این مقاله دقیقاً همین تفاوت را از ریشه بررسی می‌کنیم؛ نه فقط اینکه کدام سریع‌تر است، بلکه چرا این تفاوت وجود دارد و بر اساس چه معیارهایی باید موتور رندر پروژه‌تان را انتخاب کنید.

پیش از این در ماهیت رندر و تفاوت Rasterization و Ray Tracing به شکل عمیق توضیح داده بودیم که رندرگیری در نهایت یعنی تبدیل یک صحنه سه‌بعدی به تصویر، و دو راه اصلی برای این کار وجود دارد. حالا وقت آن رسیده که ببینیم بلندر دقیقاً از کدام راه در EEVEE و کدام راه در Cycles استفاده می‌کند، و این انتخاب چه معنایی برای کار روزمره شما دارد.

چیزی که در این مقاله یاد می‌گیرید

• تفاوت بنیادین EEVEE و Cycles در نحوه محاسبه نور و رندرگیری
• اینکه EEVEE Next در بلندر ۴.۲ به بعد چه تغییری در این معادله ایجاد کرده
• کدام پروژه‌ها برای EEVEE مناسب‌ترند و کدام‌ها به Cycles نیاز دارند
• چرا نتیجه دنویزینگ و مدیریت رنگ در این دو موتور می‌تواند متفاوت به نظر برسد
• اشتباهات رایجی که هنگام سوییچ بین این دو موتور رخ می‌دهد و راه‌حل هرکدام

پیش‌نیازها

برای دنبال کردن این مقاله نیازی به تجربه قبلی در رندرگیری ندارید، اما آشنایی مقدماتی با محیط بلندر لازم است. بهتر است بلندر ۴.۲ یا بالاتر را نصب داشته باشید، چون بخش مهمی از این مقاله درباره EEVEE Next است که فقط از این نسخه به بعد در دسترس قرار گرفته. اگر هنوز مفهوم سمپل و نویز برایتان روشن نیست، پیشنهاد می‌کنم پیش از ادامه، مقاله سمپلینگ و دنویزینگ در بلندر را هم بخوانید، چون در بخش‌های بعدی همان مفاهیم را مبنا قرار می‌دهیم.

تفاوت بنیادین؛ EEVEE چطور کار می‌کند

موتور رندر EEVEE رستریزیشن‌محور است. یعنی به‌جای اینکه برای هر پیکسل، مسیر واقعی نور را در صحنه دنبال کند، از میان‌برهای ریاضی و تکنیک‌های تقریبی استفاده می‌کند تا سریع‌ترین حالت ممکن به یک تصویر قابل قبول برسد. همین رویکرد است که EEVEE را به موتوری تبدیل کرده که می‌توانید تغییرات نور، متریال و دوربین را در ویوپورت به‌صورت زنده و تقریباً بدون تاخیر ببینید.

EeveeCycles

نکته‌ای که باید بدانید این است که EEVEE در نسخه‌های قدیمی‌تر بلندر (پیش از ۴.۲) واقعاً از ری‌تریسینگ استفاده نمی‌کرد. بازتاب‌ها، سایه‌ها و نورپردازی غیرمستقیم همه با تکنیک‌های تقریبی مثل Screen Space Reflections و Light Probes ساخته می‌شدند. این یعنی اگر چیزی خارج از دید دوربین بود، در بازتاب هم دیده نمی‌شد؛ یک محدودیت واقعی که هر کسی با EEVEE قدیمی کار کرده، حتماً یک بار به آن برخورده است.

از بلندر ۴.۲ به بعد، این معادله عوض شده. نسخه جدید که EEVEE Next نام دارد، برای اولین بار از ری‌تریسینگ واقعی (Ray Tracing) برای بازتاب‌ها، سایه‌ها و حتی بخشی از نورپردازی غیرمستقیم استفاده می‌کند، اما همچنان در چارچوب یک موتور real-time طراحی شده. یعنی به‌جای صرف چند هزار سمپل برای هر پیکسل مثل Cycles، از تعداد سمپل بسیار کمتر و همراه با الگوریتم‌های دنویزینگ اختصاصی real-time استفاده می‌کند تا در چند میلی‌ثانیه به نتیجه برسد. نتیجه این تغییر، فاصله گرفتن قابل توجه EEVEE از محدودیت‌های قدیمی‌اش است، هرچند هنوز از نظر دقت فیزیکی با Cycles یکی نیست.

چرا Cycles کندتر است و چطور کار می‌کند

در مقابل، Cycles یک موتور Path Tracing است؛ همان چیزی که در مقاله ماهیت رندر توضیح دادیم. برای هر پیکسل، Cycles چندین پرتوی نور را از دوربین به داخل صحنه شبیه‌سازی می‌کند، اجازه می‌دهد این پرتوها بین سطوح مختلف بازتاب و شکست پیدا کنند، و در نهایت رنگ نهایی هر پیکسل را از میانگین این پرتوها به دست می‌آورد. هرچه تعداد این پرتوها (سمپل) بیشتر باشد، نتیجه دقیق‌تر و طبیعی‌تر می‌شود، اما زمان محاسبه هم به همان نسبت بالا می‌رود.

این دقیقاً همان رابطه‌ای است که در مقاله سمپلینگ و دنویزینگ به آن پرداختیم؛ نویز رندر در Cycles یک باگ نیست، بلکه نتیجه طبیعی همین فرآیند تصادفی نمونه‌برداری است. هرچه صحنه پیچیده‌تر باشد (نورپردازی غیرمستقیم زیاد، سطوح شیشه‌ای، کاستیک) برای رسیدن به یک تصویر تمیز به سمپل بیشتری نیاز دارید، و دنویزرهایی مثل OIDN یا OptiX که در آن مقاله بررسی کردیم، دقیقاً همین‌جا وارد کار می‌شوند تا زمان لازم را کوتاه‌تر کنند.

نکته کلیدی اینجاست؛ Cycles هیچ میان‌بر فیزیکی نمی‌زند. هر بازتاب، هر سایه و هر پخش نور غیرمستقیم، واقعاً محاسبه می‌شود، نه شبیه‌سازی شده با یک تکنیک تقریبی. همین موضوع Cycles را به انتخاب استاندارد صنعت برای رندرهای نهایی، تصاویر معماری و هر پروژه‌ای تبدیل کرده که دقت نوری در آن اهمیت بالایی دارد.

سرعت در برابر دقت؛ عدد واقعی چقدر است؟

مقایسه دقیق بین این دو به سخت‌افزار، پیچیدگی صحنه و تنظیمات بستگی دارد، اما یک قاعده کلی وجود دارد که در اکثر پروژه‌ها صادق است؛ برای یک صحنه با پیچیدگی متوسط، EEVEE Next می‌تواند در کسری از ثانیه تا چند ثانیه یک فریم را رندر بگیرد، در حالی که همان صحنه در Cycles، حتی با GPU قوی و دنویزر فعال، معمولاً چند ثانیه تا چند دقیقه زمان می‌برد. این فاصله در انیمیشن‌های طولانی که باید هزاران فریم رندر شوند، به تفاوت ساعت‌ها یا حتی روزها تبدیل می‌شود.

اما این عدد به تنهایی نباید تصمیم شما را بسازد. سوال واقعی این است که پروژه شما اصلاً به آن سطح از دقت فیزیکی نیاز دارد یا نه. برای پیش‌نمایش سریع، انیمیشن‌های استایلایز شده یا محتوایی که قرار است در پلتفرم‌های زمان واقعی مثل بازی استفاده شود، سرعت EEVEE ارزش بیشتری از دقت اضافه Cycles دارد. برای تصویرسازی معماری، رندر محصول یا هر جایی که مشتری قرار است نتیجه را با معیار فتورئالیستی قضاوت کند، دقت Cycles معمولاً جای خالی نمی‌گذارد.

کجا EEVEE را انتخاب کنیم؟

چند سناریوی مشخص وجود دارد که در آن‌ها EEVEE گزینه درست‌تری است:

پیش‌نمایش و بلاک‌بندی صحنه، جایی که هنوز روی ترکیب‌بندی و نورپردازی کلی کار می‌کنید و نیازی به دیدن جزئیات فیزیکی نور ندارید. سرعت EEVEE اینجا باعث می‌شود چرخه آزمون و خطا خیلی کوتاه‌تر شود.

انیمیشن‌های طولانی با سبک استایلایز یا کارتونی، جایی که فتورئالیسم اصلاً هدف نیست و مخاطب هم انتظار آن را ندارد. در این حالت زمان رندر پایین EEVEE اجازه می‌دهد پروژه‌های بلندتر را در بازه زمانی معقول تحویل دهید.

محتوای تعاملی یا معماری مجازی که قرار است در زمان واقعی اجرا شود، مثل واک‌ثرو معماری یا نمونه‌های اولیه بازی؛ چون در این موارد اصلاً Cycles گزینه‌ای نیست، چون خروجی نهایی باید زنده رندر شود.

پروژه‌هایی با محدودیت سخت‌افزاری جدی، جایی که GPU یا CPU موجود از پس محاسبات سنگین Cycles در زمان معقول برنمی‌آید.

کجا Cycles را انتخاب کنیم؟

در مقابل، این سناریوها معمولاً Cycles را ترجیح می‌دهند:

تصویرسازی معماری و رندر محصول، جایی که مشتری انتظار نوردهی و بازتاب طبیعی و قابل باور دارد. حتی یک خطای کوچک در بازتاب یک سطح شیشه‌ای یا فلزی، در این نوع پروژه‌ها به‌سرعت دیده می‌شود.

صحنه‌هایی با نورپردازی پیچیده غیرمستقیم، مثل نور طبیعی که از پنجره وارد یک اتاق می‌شود و چند بار بین دیوارها بازتاب پیدا می‌کند. هرچند EEVEE در نسخه Next بهتر شده، هنوز در این نوع نورپردازی چندمرحله‌ای به اندازه Cycles دقیق نیست.

هر پروژه‌ای که کاستیک واقعی (نوری که از میان شیشه یا مایعات عبور کرده و الگوی نوری خاصی می‌سازد) در آن اهمیت دارد؛ این یکی از مواردی است که همچنان تفاوت محسوسی بین دو موتور ایجاد می‌کند.

رندرهای نهایی تک‌فریم با کیفیت بالا، جایی که وقت کافی برای رندرگیری وجود دارد و اولویت اصلی، کیفیت نهایی تصویر است، نه سرعت رسیدن به آن.

تفاوت در دنویزینگ و مدیریت رنگ

یک نکته‌ای که کمتر به آن پرداخته می‌شود، تفاوت رفتار این دو موتور در کنار دنویزینگ و مدیریت رنگ است، دو موضوعی که پیش‌تر هرکدام را جداگانه بررسی کرده‌ایم. در Cycles، همان‌طور که در مقاله سمپلینگ گفتیم، دنویزرهایی مثل OIDN و OptiX روی خروجی نویزی موتور اعمال می‌شوند تا با سمپل کمتر به نتیجه تمیز برسید. در EEVEE Next هم دنویزینگ وجود دارد، اما نوع آن برای real-time طراحی شده و معمولاً تهاجمی‌تر عمل می‌کند، چون فرصت گرفتن سمپل زیاد را ندارد. این یعنی در جزئیات ریز، به‌خصوص روی سطوح با بافت نویزی، ممکن است نتیجه EEVEE کمی صاف‌تر یا کم‌جزئیات‌تر از یک رندر معادل در Cycles به نظر برسد.

از طرف دیگر، View Transform و مدیریت رنگ روی هر دو موتور یکسان اعمال می‌شود، چون این بخش از پایپ‌لاین رنگ بلندر مستقل از موتور رندر است. اما چون EEVEE در ویوپورت هم فعال است و معمولاً همان چیزی که در ویوپورت می‌بینید، همان چیزی است که رندر می‌گیرید، اگر تنظیم View Transform را روی Filmic یا AgX عوض کنید، بلافاصله در پیش‌نمایش زنده EEVEE هم می‌بینید. در Cycles این تغییر را معمولاً فقط بعد از رندر کامل صحنه، در پنجره رندر، به‌طور واضح ارزیابی می‌کنید. این تفاوت باعث می‌شود EEVEE ابزار خوبی برای تست سریع تنظیمات رنگ پیش از رندر نهایی با Cycles باشد.

نقش سخت‌افزار در این تصمیم

سخت‌افزار سیستم شما هم روی نتیجه این مقایسه اثر می‌گذارد، هرچند نباید تنها معیار انتخاب باشد. موتور Cycles می‌تواند هم روی CPU و هم روی GPU اجرا شود، اما اگر از رندرگیری با GPU استفاده می‌کنید، حجم VRAM کارت گرافیک تعیین می‌کند که صحنه‌های سنگین با تکسچرهای بزرگ و مدل‌های چندضلعی زیاد، اصلاً در حافظه جا می‌شوند یا نه. کارت‌های گرافیک انویدیا با پشتیبانی OptiX (که پیش‌تر در مقاله دنویزینگ معرفی کردیم) معمولاً سریع‌ترین مسیر برای Cycles هستند، چون هم رندرگیری و هم دنویزینگ را روی هسته‌های اختصاصی RT انجام می‌دهند.

چرا VRAM پر می‌شود و خطای Out of Memory رخ می‌دهد

هر بار که Cycles رندرگیری با GPU را شروع می‌کند، باید کل داده‌های لازم برای آن فریم را داخل حافظه کارت گرافیک بار کند، نه فقط بخشی از آن‌ها. این داده‌ها شامل سه دسته اصلی است؛ تکسچرها، هندسه صحنه، و بافرهای موقتی که خود موتور برای محاسبه نور می‌سازد.

تکسچرها معمولاً بزرگ‌ترین سهم را دارند. یک تکسچر ۴K فشرده‌نشده، بسته به تعداد کانال رنگی و بیت‌عمق، می‌تواند به‌تنهایی چند صد مگابایت از VRAM را اشغال کند، و اگر یک متریال از چند تکسچر (رنگ پایه، نرمال‌مپ، راف‌نس، دیسپلیسمنت) هم‌زمان استفاده کند، این عدد چند برابر می‌شود. حالا این را در یک صحنه با چند ده متریال مختلف ضرب کنید تا ببینید چرا صحنه‌های معماری یا محصول با تکسچرهای باکیفیت این‌قدر سریع VRAM را پر می‌کنند.

هندسه صحنه هم سهم خودش را دارد؛ هرچه تعداد چندضلعی‌ها (پالیگان) بیشتر باشد، حجم داده‌ای که باید برای ساختار BVH (که در مقاله ماهیت رندر توضیح دادیم) نگه‌داری شود هم بزرگ‌تر می‌شود، چون این ساختار باید موقعیت دقیق هر سطح را برای محاسبه برخورد پرتوها در خودش ذخیره کند. مدل‌های های‌پالی بدون بهینه‌سازی، یا تعداد زیاد نمونه‌های Particle و Geometry Nodes که در لحظه رندر تکثیر می‌شوند، همین سهم هندسه را به‌شدت بالا می‌برند.

وقتی مجموع این سه دسته از ظرفیت واقعی VRAM کارت گرافیک عبور کند، بلندر دو راه دارد؛ یا رندر را کامل متوقف کرده و خطای Out of Memory را نشان می‌دهد، یا اگر گزینه CPU Fallback فعال باشد، بخشی از محاسبات را به‌جای GPU روی CPU می‌اندازد تا رندر کامل شود، هرچند این حالت سرعت را به‌شدت پایین می‌آورد، چون CPU برای این نوع محاسبات موازی به‌اندازه GPU بهینه نیست. برای پیشگیری از این وضعیت، سه راه عملی وجود دارد؛ کاهش رزولوشن تکسچرهایی که نیازی به کیفیت ۴K ندارند، استفاده از فرمت‌های فشرده مثل JPEG یا فشرده‌سازی داخلی بلندر برای تکسچرها، و ساده‌سازی هندسه صحنه با ابزارهایی مثل Decimate Modifier در جاهایی که جزئیات بالا واقعاً دیده نمی‌شود.

موتور EEVEE هم به GPU متکی است، اما چون از ابتدا برای اجرای زنده در ویوپورت طراحی شده، معمولاً فشار کمتری روی VRAM وارد می‌کند. با این حال، EEVEE Next با فعال‌بودن Ray Tracing، نسبت به نسخه‌های قدیمی‌تر EEVEE مصرف حافظه و پردازش بیشتری دارد؛ روی سیستم‌های ضعیف‌تر یا کارت‌های گرافیک قدیمی‌تر بدون پشتیبانی سخت‌افزاری از ری‌تریسینگ، ممکن است ببینید که سرعت پیش‌نمایش EEVEE هم به‌وضوح افت می‌کند. در این حالت، خاموش‌کردن Ray Tracing در تنظیمات EEVEE و بازگشت موقت به حالت قدیمی‌تر رستریزیشن محض، می‌تواند سرعت کار در ویوپورت را برگرداند، البته با از دست دادن دقت بازتاب‌ها و سایه‌ها.

نکته عملی این است که پیش از تصمیم نهایی بین این دو موتور، بهتر است سیستم خودتان را در نظر بگیرید، نه فقط نوع پروژه را. یک سیستم با GPU قوی و VRAM بالا، فاصله سرعت بین EEVEE و Cycles را کمتر می‌کند، در حالی که روی سخت‌افزار متوسط یا ضعیف، این فاصله می‌تواند آن‌قدر زیاد شود که برای بسیاری از پروژه‌ها، اصلاً Cycles گزینه عملی نباشد، مگر با صبر روی زمان رندر طولانی‌تر.

اشتباهات رایج هنگام سوییچ بین دو موتور

اگر صحنه‌ای که با Cycles ساخته‌اید را مستقیم به EEVEE سوییچ کنید و نتیجه یکسان انتظار داشته باشید، احتمالاً ناامید می‌شوید، احتمالاً به این خاطر است که برخی نودهای متریال، مثل Volume Scatter پیچیده یا برخی تنظیمات Subsurface Scattering، در نسخه‌های قدیمی‌تر EEVEE پشتیبانی کامل نداشتند. راه‌حل این است که پیش از سوییچ، مستندات رسمی بلندر برای نسخه‌ای که استفاده می‌کنید را چک کنید، چون EEVEE Next پشتیبانی بسیاری از این موارد را اضافه کرده اما هنوز صد‌درصد با Cycles یکسان نیست.

اگر بازتاب یک سطح آینه‌ای در EEVEE ناقص یا بریده به نظر می‌رسد، احتمالاً به این دلیل است که Ray Tracing در تنظیمات Render Properties برای EEVEE Next فعال نشده یا کیفیت آن پایین تنظیم شده است، پس این تنظیم را بررسی و در صورت نیاز کیفیت را افزایش دهید.

اگر نورپردازی غیرمستقیم صحنه در EEVEE خیلی تیره‌تر یا مسطح‌تر از Cycles به نظر می‌رسد، احتمالاً Light Probes به‌درستی جای‌گذاری یا بیک نشده‌اند، چون EEVEE هنوز برای بخشی از نورپردازی غیرمستقیم به این پروب‌ها متکی است، پس مطمئن شوید Irradiance Volume یا Reflection Cubemap مناسب در صحنه قرار دارد.

اگر زمان رندر Cycles غیرمنتظره بالا رفته، احتمالاً تعداد سمپل یا کیفیت دنویزر بیش از نیاز صحنه تنظیم شده، که برای رفع آن بهتر است دوباره سراغ مفاهیم Adaptive Sampling که در مقاله سمپلینگ توضیح دادیم بروید و آستانه نویز را متناسب با صحنه تنظیم کنید.

جمع‌بندی و نکته کلیدی

موتورهای EEVEE و Cycles دو ابزار متفاوت برای دو نیاز متفاوت هستند، نه یک موتور بهتر و یک موتور ضعیف‌تر. موتور EEVEE با تکیه بر رستریزیشن و از نسخه Next به بعد با کمک ری‌تریسینگ محدود، سرعت را در اولویت قرار می‌دهد؛ Cycles با تکیه بر Path Tracing کامل، دقت فیزیکی را در اولویت می‌گذارد و هزینه آن را با زمان می‌پردازد. نکته طلایی این است که این انتخاب لازم نیست یک‌بار برای همیشه باشد؛ خیلی از هنرمندان حرفه‌ای، پیش‌نمایش و بلاک‌بندی صحنه را با EEVEE انجام می‌دهند و فقط برای رندر نهایی به Cycles سوییچ می‌کنند، دقیقاً برای اینکه از سرعت یکی و دقت دیگری هم‌زمان استفاده کنند.

گام بعدی

حالا که تفاوت این دو موتور رندر را از نظر مکانیزم، سرعت و کاربرد می‌دانید، طبیعی‌ترین قدم بعدی این است که این دانش را روی یک پروژه واقعی پیاده کنید. اگر می‌خواهید از صفر تا رندر نهایی، هم Cycles و هم مسیر حرفه‌ای کار با بلندر را قدم‌به‌قدم و پروژه‌محور یاد بگیرید، دوره آموزشی بلندر دقیقاً برای همین طراحی شده. در کنار آن، اگر هنوز مقاله‌های ماهیت رندر ، سمپلینگ و دنویزینگ و Color Management را نخوانده‌اید، این سه مقاله کنار هم، تصویر کاملی از نحوه رندرگیری در بلندر به شما می‌دهند.