رندرینگ ابری (یا مزرعه رندر) در هکتون ۲۰۲۰ دیوار

مقدمه

هکتون ۲۰۲۰ دیوار در اواخر سال ۱۳۹۹ اجرا شد و در آن حدود ۱۵ تیم شرکت داشتند. در این گزارش تلاش می‌شود تا در مورد یکی از پروژه‌های این ماراتن برنامه‌نویسی با عنوان رندرینگ ابری توضیحاتی داده شود.

درباره هکتون

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

هکتون معمولا بین یک روز تا یک هفته به طول می‌انجامد و هدف اولیه آن تولید ایده یک محصول یا خدمت (معمولا نرم‌افزاری) است. از دو کلمه "هک" (اکتشاف یا جستجو کردن) و "ماراتون" ساخته شده است و می‌توان آن را به "برنامه‌نویسی اکتشافی - استقامتی" نیز ترجمه کرد. خارج از هدف اولیه آن به دلائل دیگری مانند جمع‌آوری ایده‌ها، اهداف اجتماعی و مسئولیت سازمانی، آموزش و تیم‌سازی و یا ایجاد وحدت در سازمان‌ها نیز مورد استفاده قرار می‌گیرد.

در هکتون تیم‌ها معمولا ایده‌ای را مطرح می‌کنند و چند شب خارج از خانه، در کیسه خواب یا پشت میزهایشان تلاش می‌کنند که ۵ گام طراحی را بر روی آن اجرا کنند:

۱- درک کردن

۲- بررسی کردن

۳- انتخاب کردن

۴- ساخت نمونه اولیه

۵- تست کردن

مانند یک ورزش استقامتی، چندین روز کار می کنند، کم می خوابند، همت می‌ورزند و در پایان ایده‌های خود را ارائه می‌دهند.

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

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

سوال: پس در این اکوسیستم چگونه باید پیشرفت کرد؟

پاسخ: جمع‌آوری ایده‌ها، بررسی، ساخت مدل اولیه و تست. در یک کلام استارتاپ(۲).

سوال: کدام ایده یا چگونه ایده‌ها را پیدا کنیم؟

پاسخ: راهکاری مانند هکتون

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

در هکتون دیوار چه هدفی داشتیم ؟

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

مسئله‌ی رندرینگ در حوزه گرافیک کامپیوتر از دیرباز یکی از مشکلات صنعت تصویرسازی و سرگرمی است. به طور مثال در فیلم آواتار(۴) ساخته جیمز کامرون در سال ۲۰۰۹ شرکت جلوه‌های ویژه‌‌ی ویتادیجیتال مجبور بود تا ۸ گیگابایت اطلاعات را در هر ثانیه برای ماه‌ها در یک محیط هزار مترمربعی با ۴۰ هزار پردازنده و ۱۰۴ ترابایت حافظه رندر کند. رندرینگ مرحله‌ای که خروجی نهایی می‌بایست خلق شود و هزینه آن پردازش میلیون‌ها و بعضا میلیاردها داده ریاضی است! در چند سال اخیر از یک سو به دلیل رشد سرعت اینترنت، بحث پردازش ابری قوت یافته است و از سوی دیگر (مخصوصا در ایران) با توجه به مسائل اقتصادی خرید سخت افزار جهت رندرینگ بسیار سخت و گزاف شده است. هر دو مسئله به نوعی راه‌اندازی فضای ابری جهت پردازش تصاویر گرافیکی را به یک ایده‌ی قابل بررسی تبدیل می‌کند.

خوشبختانه تمامی نرم‌افزارهای گرافیکی معروف (مخصوصا نرم‌افزارهای تولید کننده تصاویر سه بعدی) امروزه همگی فرآیندهایی جهت رندرینگ به صورت توزیع شده دارند ولی از آنجایی که بحث رندرینگ ابری موضوعی جدید محسوب می‌شود، مدیریت و توسعه یک زیرساخت همگرا جهت قبول کردن سرویس‌های رندرینگ از نرم‌افزارهای مختلف، برنامه‌ریزی به صورت دسته‌ای و توزیع منابع از مشکلاتی است که هنوز در این صنعت بر روی آن کار می‌شود. از این رو اهداف مستقیمی که در هکتون ۲۰۲۰ تعقیب می‌کردیم به شرح زیر بود:

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

به غیر از اهداف اولیه، اهداف ثانویه دیگری نیز تعریف شده بود تا در صورتی که وقت کافی وجود داشت به سمت آن حرکت کنیم:

اتصال فضای رندرینگ ابری به فضای ذخیره‌سازی ابری(S3) شرکت.
تعریف خصوصیات یا پیاده‌سازی پلاگینی بر روی حداقل یک نرم‌افزار گرافیکی برای اتصال به ساختار رندرینگ ابری ایجاد شده
مدل‌سازی تجاری دقیق فرایند رندرینگ ابری شامل: الف- محاسبه هزینه‌ها ب- ذینفعان ج- درآمدها
تست کل مدل تجاری شامل فرآیند ثبت نام کاربران، مشاهده پروفایل و کیف پول و در نهایت ثبت سفارش رندرینگ (در داخل نرم‌افزار گرافیکی) و تحویل خروجی آن.

رندرینگ چیست؟ مزرعه رندرینگ و رندرینگ ابری به چه معناست؟

رندرینگ(۶) به فرآیند تبدیل داده‌های(۷) ریاضی به تصویر(۸) در یک پردازش رایانه‌ای گفته می‌شود. این فرایند می‌تواند منجر به خلق یک تصویر واقع‌نمایی یا غیرواقع نمایی شود. همچنین رندرینگ به یکی از زیرموضوعات و آخرین بخش از فرآیند تولید تصاویر سه بعدی در گرافیک کامپیوتری(۹) نیز گفته می‌شود که از دهه ۷۰ میلادی مورد استفاده قرار گرفت. مدل‌های ریاضی و ساختمان داده‌های کامپیوتر در پردازشی که شامل محاسبه سطح، رنگ، نور و... است در نهایت تصویری دیجیتال را خلق می‌کنند.

به طور کلی ما دو نوع رندرینگ داریم:

۱- رندرهای زمان اجرا یا فی البداهه(۱۰)

۲- رندرهای با تصاویر واقعی یا گرافیکی بالا (۱۱)

در نوع اول یک تصویر کامپیوتری باید حداقل در ۱/۲۴ ثانیه تولید شود و در نوع دوم ساخت یک تصویر می‌تواند ساعت‌ها به درازا بکشد و خروجی آن یک تصویر واقعی‌نما یا یک تصویر با کیفیت بسیار بالای دیجیتال باشد. به طور ساده‌تر کارکرد اول را می‌توان در بازی‌های کامپیوتری مشاهده کرد که یک محیط دیجیتال در ۱/۲۴ ثانیه در مانیتورها ساخته می‌شود و نوع دوم را می‌توان در صنایع سینما و انیمیشن سازی مشاهده کرد.

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

در ۱۹۹۰ استودیو انیمیشن‌سازی سه بعدی شرکت آتودسک(۱۲) در پروژه ساخت انیمیشن کوتاه The Bored Room به دلیل یک تخمین غیردقیق مجبور شد تا اتاقی را از کامپیوترهای کامپکت ۳۸۶ (۱۳) پر کرده و هر کامپیوتر را برای رندر کردن تنها یک فریم از فیلم تنظیم کند و در انتها خروجی سیستم‌ها را به صورت فریم به فریم در داخل یک دیسکت ذخیره کنند. این آغاز پیدایش مفهوم مزرعه رندر یا رندرفارم(۱۴) بود. در آن زمان هیچکدام از کامپیوترها به صورت شبکه‌ای به یکدیگر وصل نبودند ولی موجب شد تا شرکت آتودسک بر روی رندر گرفتن مجموعه‌ای از کامپیوترها به صورت موازی کار کند. کارتون داستان اسباب‌بازی ها ساخته ۱۹۹۵ شرکت پیکسار نیز از همین تکنولوژی استفاده کرد و این کار موجب شد تا زمانی معادل ۳۹ سال رندرینگ را به میزان بسیار معقولی در حد چند ماه کاهش دهد.

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

با پیشرفت پردازش‌های ابری، همه‌گیری اینترنت و افزایش سرعت آن در جهان، صنعت سرگرمی و گرافیک کامپیوتری نیز دستخوش تغییر شد و فروش سرویسی به عنوان رندرینگ ابری(۱۵) مقرون به صرفه و شدنی گردید. از این رو در دهه ۲۰۱۰ میلادی نرم‌افزارهای گرافیکی به سمت پردازش‌های ابری حرکت کردند و قابلیت رندرینگ در محیطی خارج از شبکه مشتریان در داخل نرم‌افزارها پیاده‌سازی شد.

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

آنچه که در هکتون ۲۰۲۰ انجام دادیم (راه‌اندازی OPENCUE)

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

پس از تحقیقات متوجه پروژه متن باز تازه شرکت گوگل با نام OpenCue شدیم. این پروژه که با همکاری استودیو سونی راه‌اندازی شده است، هدفش ایجاد یک ساختار رندرینگ ابری است. OpenCue بر اساس تجربه موفق از برنامه داخلی رندرفارم استودیو سونی با نام Cue3 است که نزدیک به ۱۵سال توسعه و مورد استفاده قرار گرفته است. این نرم‌افزار محدودیتی در تعداد هسته پردازنده ندارد و استودیو سونی تا ۱۵۰ هزار هسته پردازنده‌ای را در شبکه‌های ابری مانند گوگل تست کرده است. طبق ادعا استودیو سونی در صدها فیلم این استودیو مورد استفاده قرار گرفته و مدیریت رندرینگ را برعهده داشته است.

پروژه OpenCue اواسط سال ۲۰۱۹ رونمایی شد و هنوز در مرحله تست بتا است. این برنامه به زبان پایتون توسعه یافته است و می‌تواند موتورهای رندرینگ مختلف را پوشش دهد. با معماری کوبرنتیز و محاسبات ابری هماهنگ است و قابلیت برنامه‌ریزی جهت انجام رندرهای مختلف با تخصیص منابع متفاوت را داراست.

برنامه Open cue از اجزای زیر تشکیل شده است:

پایگاه داده این نرم‌افزار که از نوع postgresql است. (استفاده در سایت شبکه ابری)
نرم‌افزار سرور با عنوان cuebot که مسئولیت برنامه‌ریزی صف‌ها، دسته‌بندی درخواست‌ها و تقسیم منابع را بر عهده دارد. (استفاده در سایت شبکه ابری)
نرم‌افزار سرور رندرگیر با عنوان RQD این نرم‌افزار در حقیقت یک واسط است بین موتور رندرینگ و نرم‌افزار CUEBOT (استفاده در سایت شبکه ابری)
واسط نرم‌افزاری PyCue که به منظور ارتباط برقرار کردن بخش‌های مختلف OPEN CUE در سمت کاربران با بخش دیپلویمنت‌ها مورد استفاده قرار میگیرد.
کتابخانه PyOutline که یک واسط پایتون برای تنظیم کارها رندرینگ در قالب XML را فراهم می‌کند.
رابط کاربری گرافیکی(۱۷) برای تعریف کارهای رندرینگ با عنوان CUE SUBMIT که وظیفه آن تعریف وظایف رندرینگ است. همچنین نرم‌افزار pycuerun که به صورت خط فرمانی(۱۸) می‌توان وظایف رندرینگ را در آن تعریف کرد. (استفاده در سایت مشتری)
واسط کاربری گرافیکی با عنوان CUE GUI به منظور مانیتورینگ، کنترل و تخصیص منابع در رندرینگ است. معادل این نرم‌افزار به صورت خط فرمانی نیز برنامه cueadmin است. (استفاده در سایت مشتری)

برای راه‌اندازی ساختار open cue لازم بود تا قسمت‌های سمت سرور را در ابتدا به صورت داکر(۱۹) تولید کرده و خروجی داکر را در رجیستری مجموعه دیوار(۲۰) بارگذاری کنیم. سخت‌ترین بخش کار تنظیم RQD ها بود. سرورهای RQD سرورهایی هستند که وظیفه انتقال فایل‌های و تسک رندرینگ را به موتور رندرینگ دارند.

به صورت پیش‌فرض در نرم‌افزاری open cue هیچ یک از نرم‌افزارهای رندرینگ وجود ندارد از این رو لازم بود تا داکرRQD به صورتی تنظیم می‌کردیم که نرم‌افزار رندرینگ بر روی آن نصب و راه‌اندازی شود. برای این کار ۳ نرم‌افزار را به صورت پیش‌فرض برای ساخت سه نوع RQD انتخاب کردیم:

نرم‌افزار RQD_BLENDER_2_90 : داکری که در آن نرم‌افزار RQD و نرم‌افزار گرافیکی بلندر (۲۱) است.
نرم‌افزار RQD_MAYA_LINUX_2020: داکری که در آن نرم‌افزار RQD و نسخه لینوکس نرم‌افزار آتودسک مایا (۲۲) قرار گرفته است.
نرم‌افزار RQD_3DsMax_2020: داکر (ویندوزی) نرم‌افزار آتودسک تری دی استودیو مکس (۲۳).

نرم‌افزار تری دی استودیومکس در سال ۱۹۸۸ توسط شرکت آتودسک تولید شد. این نرم‌افزار را قدیمی ترین نرم‌افزار گرافیکی سه بعدی جهان می‌دانند که به دنیای کامپیوترهای دسکتاپ ارائه شده است. این نرم‌افزار تنها بر روی نسخه سیستم عامل ویندوز ارائه می‌شود، از این رو لازم بود تا داکری از زیر ساخت سیستم عامل ویندوز تولید کنیم. از آنجایی که در شبکه کوبرنتیز دیوار، ما از نودهای سیستم عامل ویندوز استفاده نمی‌کنیم تصمیم بر آن شد تا بر روی ماشین‌های مجازی کوبرنتیز سیستم عامل ویندوز راه‌اندازی شود و پکیج RQD بر روی آن نصب گردد. مشکل دیگر آنجایی بود که open cue به صورت پیش‌فرض تنها نرم‌افزارهایی که نسخه لینوکس دارند پشتیبانی می‌کند از این رو لازم بود تا فرامین رندرینگ نرم‌افزار تری دی مکس در آن تزریق شود.

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

کل نرم‌افزارهای سمت سرورها را در کوبرنتیز راه‌اندازی کردیم و در آدرس rendering.test.divar.ir قرار داده شد.

برای راه‌اندازی نرم‌افزارهای سمت مشتریان نیز، از یک سری دستورات بش(۲۴) استفاده کردیم تا با راه‌اندازی آن متغیرهای پایه‌ای مثل آدرس سرور راه‌اندازی شده و دیگر مشخصات قرار گیرد. دو سری دستورات سیستم عامل ساخته شد برای سیستم عامل ویندوز و سیستم عامل لینوکس. دلیل این کار این بود که اکثر طراحان و انیمیشن‌سازان از سیستم عامل‌های مک و ویندوز استفاده می‌کنند و سیستم عامل لینوکس زیاد مورد استفاده قرار نمی‌گیرد.

پس از راه‌اندازی نرم‌افزارها، نوبت به تست شبکه رندرینگ رسید. لازم بود تا فایلی گرافیکی تولید شود تا میزان قدرت شبکه رندرینگ ابری را بتوان با آن تست کرد. از آنجایی که در این راه‌اندازی از فضای ذخیره‌سازی ابری استفاده نمی‌شد، فایل گرافیکی می‌بایست به شکلی باشد که از تصویر ایستا (۲۵، توضیحات در انتهای متن) استفاده نکند و کلیه اطلاعات بتواند در داخل خود فایل گرافیکی ذخیره شود. پس بهترین راه استفاده از افکت و سیستم ذرات بود. یک سناریو تبلیغاتی سریع طراحی شد و انیمیشن آن در روز پایانی ساخته شد. برای انیمیشن حدود ۱۰ میلیون ذره مورد استفاده قرار گرفته بودند که هرکدام دارای افکت درخشش نور و موشن بلور(۲۶) بودند.

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

برای رندرینگ از موتور رندر آرنولد که به صورت پیش‌فرض در نرم‌افزارهای مایا و تری دی مکس وجود دارد استفاده شد. در ابتدا بنا بر آن بود که خروجی نهایی از طریق نرم‌افزار blender یا مایا تهیه شود تا کلیه عملیات در فضای ابری باشد (نه ماشین مجازی‌های بر روی شبکه ابری کوبرنتیز) با این حال پس از تست نرم‌افزارها و موفق بودن رندر در این نرم‌افزارها از آنجا که کار با تری دی مکس هم از لحاظ تخصص در تیم هکتون و هم از لحاظ سادگی سیستم ذراتش راحت تر بود، کل سناریو فایل تست در نرم‌افزار تری دی مکس و موتور رندر آرنولد تهیه شد. جزئیات فایل تست به صورت زیر :

برای آغاز رندرینگ ۳۲ هسته پردازنده و ۶۴ گیگ رم در نظر گرفته شد شبکه مدیریت عملیات بر روی ماشین مجازی‌ها تنظیم گردید. هر رندر به صورت هر فریم برای هر ماشین مجازی و خروجی به صورت فایل های جداگانه عکس با اندازه 1080 در 650 فرض شد. محل ذخیره کردن خروجی به دلیل نبود وقت کافی جهت راه‌اندازی فضای ذخیره سازی ابری بر روی ماشین اول مجازی قرار داده شد و تمام ماشین مجازی‌ها خروجی خود را در این ماشین مجازی قرار می‌دادند.

زمان رندر گرفتن در این شبکه حدود ۳۲ ساعت و ۳۴ دقیقه به طول انجامید.

https://www.aparat.com/v/Z3rRJ

نتیجه‌گیری

هدف از رندرینگ ابری در هکتون ۲۰۲۰ دیوار راه‌اندازی یک استارت آپ فروش رندرینگ در فضای ابری بود. از این رو لازم بود تا کلیه فرآیند تولید تصاویر مانند یک شرکت تبلیغاتی یا سینمایی و با نرم‌افزارهای مورد استفاده در این صنعت فرض شود. نتایج حاصل به شرح زیر است:

کل نرم‌افزار OPEN CUE بر روی شبکه کوبرنتیز دیوار نصب و راه‌اندازی شد.

۱.۱. برای پایگاه داده از ۳ پاد به صورت replication استفاده گردید.

۱.۲. سه پاد برای نرم‌افزار CUE BOT.

۱.۳. یک پاد برای RQD سفارشی سازی شده نرم‌افزار blender ۲/۹۰ (۱ هسته پردازنده و ۲ گیگ حافظه).

۱.۴. یک پاد برای RQD سفارشی سازی شده نرم‌افزار Autodesk maya ۲۰۲۰ (۲ هسته پردازنده و ۴ گیگ حافظه).

۱.۵. یک داکر فایل برای RQD سفارشی سازی شده نرم‌افزار Autodesk 3ds max ۲۰۲۰ (۲هسته پردازنده و ۴ گیگ حافظه).

۱.۶. دو ماشین مجازی با ۱۶ هسته پردازنده و ۳۲ گیگ رم بر روی شبکه کوبرنتیز دیوار با نرم‌افزارهای RQD سفارشی سازی شده با Autodesk 3ds max.

۲. کل نرم‌افزارهای سمت مشتری به صورت اجرا با یک دستور در دو محیط ویندوز و لینوکس تطبیق داده شد

۳. تست ساده از هر سه نرم‌افزار انجام شد.

۴. برای تست نهایی یک فایل گرافیکی با داشتن ۶ میلیون ذره تهیه شد.

۵. خروجی کار با زمانی حدود ۳۲ ساعت و ۳۴ دقیقه (نزدیک به ۹۸ درصد بهبودی در زمان رندرینگ به صورت ساده) تهیه گردید. خروجی به صورت ۱۱۰۰ عکس با کفیت ۱۰۸۰ * ۶۵۰ تهیه شد.

کارهایی که در این هکتون موفق به انجام آن نشدیم:

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

پی‌نوشت‌ها:

Hackathon
startup
COVID-19
Avatar (2009)
K8S
rendering
data
image
3d computer graphic
Real Time Rendering
Natural Rendering
Autodesk 3d studio animated
Compaq 386tyou
Render farm
Cloud Rendering
GHZ per HOUR
GUI
Command line
Docker
Docker Registry
Blender 2.90
Autodesk Maya 2020
Autodesk 3ds max 2020
Bash command
تصویر ایستا در حقیقت یک تصویر گرافیکی است که به آن تکسچر گفته می شود مثلا تصویر برجستگی های روی یک سنگ که بر روی مدل سه بعدی قرار میگیرد. از آنجایی که در هنگام رندرینگ، موتور رندر لازم دارد تا به کلیه فایل ها دسترسی داشته باشد لازم بود تا بین نودهای رندر یک فضای اشتراکی ابری راه‌اندازی شود که این کار به دلیل نبود وقت کافی صرف نظر شد.
Motion blur