[Pswin]

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

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

[Pswin]

انجینی که من در حال طراحیش هستم. اسمش رو D-Engine گذاشتم. که مشخصات زیر رو داره:

1- رندرینگ OpenGL 3.0+
2- صوت : OpenAL
3- زبان اسکریپ : Lua
4 - زبان برنامه نویسی C++
5- کراس پلتفرم
6. نوع رندرینگ deffered shading

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

در حال حاضز بیشتر وقت من رو دیزاین مربوط ارتباط کلاسهای صحنه و مدیر صحنه و نحوه ارتباط اون با بقیه اجزاء میگیره. در حالت کلی من توی مدیر صحنه یک نود اصلی صحنه ( مثل Ogre) رو در نظر گرفتم که تمام نودهای دیگه و اشیاء به اونها متصل میشن. اشیاء داخل صحنه میتونه منابع صدا، دوربین و یا حتی موجودیتهای قابل پردازش باشن. برای تمامی این نودها متد _update رو در نظر گرفتم که با به روز شدن این متد نود متدهای _update تمامی اشیاء و تمامی نودهای فرزند خودش رو فراخوانی میکنه. موجودیت ها بعد از فزاخوانی متد _update خودشون رو توی یک صف که به نام RenderQueue هست ثبت می کنند. این صف بعدا توسط رندرر پردازش میشه و قبل از اینکه موجودیتها رسم بشن صف طبق شیدرها و تکسچرها بهینه سازی میشه که کمترین سوئیچ شیدر و تکسچر توشون اتفاق بیفته.

[Pswin]

اشیاء داخل صحنه:

هیچ کدوم از اشیاء داخل صحنه نمی تونن موقعیت، چرخش و یا موارد مثل اون رو بگیرن. بلکه برای گرفتن موقعیت و موارد دیگه باید به پدر خودشون ( که یک نود صحنه - SceneNode) است مراجعه کنن. فعلا من برای داخل صحنه سه شی رو در نظر گرفتم:

شی منبع صوتی:
فراخوانی _update : هیچ عکس العملی نشون نمیده. تنها زمانی عکس العمل نشون میده که متد play اون فراخوانی شه.

شی دوربین:
فراخوانی _update : اگر دوربین فعال باشه ماتریس پروجکشن و ماتریس دوربین رو ست میکنه.

شی موجودیت: این نوع اشیا< موجودیتهایی هستند که داخل صحنه باید رسم شن و دارای یک مش- اطلاعات فریم انیمیشن، اطلاعات متریال و ... هستند.
فراخوانی _update: خودشون رو توی renderQueue ثبت می کنن. تا رسم بشن.

کلاس RenderQueue: یه کلاس برای بهینه سازی رندرینگ هستش. به همین شکل از ارتباط مستقیم هر شی Entity با رندرر جلوگیری میکنه.

سوالی که اینجا مطرحه: برای یک دیزاین بهتر کدوم یکی رو پیشنهاد میکنین:
1. بهتر هستش که شی Entity رو به رندرر بدم( مدیر صحنه RenderQueue رو مرتب کنه بعد تک تک Entityها رو بفرسته به رندرر که رسموشون کنه)
2. خود RenderQueue رو مدیر صحنه تحویل رندرر بده که رسموشن کنه.

متدی که قبلا استفاده می کردم این بودش که خود مدیر صحنه RenderQueue رو می خوند و اطلاعات انیمیشن، هندسته مش و متریال رو به صورت جدا برای رندرر می فرستاد. بعدا تصمیم گرقتم که خود renderer هر Entity رو بگیره و رندر کنه.

[Elf]

سلام
کار جالبی رو شروع کردید من هم مثل شما در حال طراحی یک موتور هستم اما به زبان پاسکال!
من فکر میکنم که بهتره عملیات ترسیم رو به گردن مدیر صحنه بیندازی همون کاری که من هم کردم به این ترتیب میتونید از مزایایی این کار وقتی که پروژتون بزرگتر شد استفاده کنید. در ضمن وظیفه مدیر صحنه همین هم هست دیگه

[Pswin]

سلام

من هم اولا کار شما رو میکردم. بعدش متوجه شدم برای یکسری از بهینه سازیها ( از لحاظ سرعت) و اما کار کرد به ظور اصولی ترسیم رو باید رندرر انجام یده و مدیر صحنه باید مورد ها رو برای ترسیم انتخاب کنه. به نظر من تنها کار مدیر صحنه مدیریت ارتباط نودها و اعمال cullingها باید باشه. مدیر صحنه من بعد ار اینکه نودها رو به روز کرد culling رو انجام میذه، صف رو مرتب میکنه ( متد sort رو فراخوانی میکنه ) بعدش تک تک lEntity ها رو تحویل رندرر میده که رسمشون کنه. هر موجودیت هم شامل متریال، اطلاعات ورنکس و اطلاعات انیمیشن هستش. (فعلا موتور از انیمیشن پشتیبانی نمکنه ولی تا برگزاری هماشی pd اون هم راه اندازی میشه.) .

برای افزایش سرعت حتما باید تعداد سوئیچ حالت رو به حداقل ممکن رسوند:
- تعداد سوئیچ شیدر
- تعداد سوئیچ تکسچر
- تعداد سوئیچ حالتها متریالها

[Kochol]

سلام

بحث خیلی خوبی رو شروع کردی و اولین موضوع ای هم که مطرح کردی بسیار مهم و جالب است.

خوب این چیزی که می گی کاملا درسته و بر می گرده به سوییچ حالت ها.

اول از همه راجب به RenderQueue صحبت کنم که به نظرم باید چندتا RenderQueue داشته باشی.

حداقل دو تا یکی برای اجسام معمولی و دیگری برای اجسام شفاف

[quote]
سوالی که اینجا مطرحه: برای یک دیزاین بهتر کدوم یکی رو پیشنهاد میکنین:
1. بهتر هستش که شی Entity رو به رندرر بدم( مدیر صحنه RenderQueue رو مرتب کنه بعد تک تک Entityها رو بفرسته به رندرر که رسموشون کنه)
2. خود RenderQueue رو مدیر صحنه تحویل رندرر بده که رسموشن کنه.
[/qoute]

من تو این فکر هستم که چه طوری از شرط ها جلوگیری بشه مثلا اینکه کدوم شی نیاز به ایجاد تغییر در شیدر و تکستچر و حالتها داره.

ولی چیزی به فکرم نمی رسه حتی چندبار هم رفتم دستشویی ولی فرجی نشد البته فکر نکنم که حالا چندتا if زیاد هم تاثیر داشته باشه.

من هم روش اول رو پیشنهاد می کنم به نظرم روش درستی است.

[Pswin]

کوچول:
حق داری، مرتب سازی بر اساس فاصله برای اجسام شفاف خیلی مهمتر تا شیدر و تکسچر هستش اما برای مدیریت ( مدیریت خوب) حتما باید یکدونه RenderQueue داشته باشیم. و تنها توی نحوه sort کردنمون تغییر ایجاد کینم.
من برای sort کردن از std استفاده می کنم و اون رو هم پیشنهاد می کنم، چون الگوریتم ( نحوه sort رو خوت بهش میدی) فکر کنم این بتونه موثر باشه:

http://www.cplusplus.com/reference/algorithm/sort/

در مورد شرطها منظورت رو متوجه نشدم!!! اگر منظورت اینه که تغییر وضعیت ندی! فکر کنم غیر ممکن باشه مگر اینکه شرایط خاص باشن. اما هر چند تا if هم بذاری مظمئن باش باز هم سرعت تغییر زیادی نمیکنه ( نصب به gpu).

نظر من:
به نظر من برای اینکه بحث تاپیک خوب جلو بره و برای همه فایده داشته باشه. بهتر اولا یکسری کارهای عملی انجام بدیم و همه شروع کنیم در موردش نظر بدیم و اونها رو بهینه کنیم. منظورم این نیست که حتما موتور بسازیم، بر عکس میخوام حداقل یکسری کلاسهای کوچیک پرکاربرد رو بسازیم و یا به کمک uml یکسری از دیزاین ها رو شرح بدیم. به عنوان مثال میتونم با کلاسهایی برای کار با ماتریسها (خود ماتریسها، ماتریس پروجکشن و یا world ... ) شروع کنیم. و یا همون دیزاین scene manager رو به کمک uml پیاده سازی کنیم تا به یه نتیجه برسیم.

[Pswin]

مخم کم کم داره صوت میکشه. الان یک هفته میشه که روزی 10و12 ساعت دارم روی موتور بکوب کار میکنم و بقیه روزم توی بنگاه فکر منتظرم تا فرجی بشه. تازه دارم درک میکنم که کوچول اون زمان چه حجم کاری سنگینی رو انجام داده. بگذریم...

post effectها رو باید چه چیزی کنترل کنه؟؟ مدیر صحنه و یا موارد دیگه. میدونن بدی کار چیه؟ به نظر من این کار مدیر صحنه نیستش چون اگر دو تا مدیر صحنه داشته باشیم رو یکی اعمال مبشه و اون یکی هم ... . به نظر من باید یدونه کلاس با نام render piple تعریف کنیم که مواردی ر. که بهش داده میشه مرتب کنه و در نهایت برای رندرر بفرسته. این لوله ( کانال یا هر چیز دیگه) میتونه خیلی مفید باشه مثلا شما میتونین بین دو حالت دیفرید شیدینگ و مد دیگه کاری خودتون سوئیج کنید و... . نظر شما درباره این مورد چیه.

[Pswin]

از دوستان میتونه کسی در مورد ریسورس منیجر و پیاده سازی اون توضیح بده.

من چند نمونه رو توی نت دیدم که به نظرم هیچ کدوم مناسب نبودن.

[Pswin]

دوستان عزیز از همکاریتون واقعا ممنونم!!!

چند تا سوال:
1.ریسورس منیجر باید بر اساس فایل تصمیم بگیره که یه ریسورس تکراری هست یا بر اساس نام باید این تصمیم رو بگیره؟

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

2. به نظرتون نابود کردن ریسورسهایی که تعداد count اونها ( از نطر اختصاص به یه object یا node و ... ) به صفر برسه باید نابود بشن؟

3. دسترسی به ریسورسها از طریق نام خیلی آسونه ( user-friendly) ولی برای برنامه خیلی دردسر ساز هستش و و قت زیادی رو برای پیدا کردن میگیره ( مقایسه رشته هزینه بالا داره) شما چه راهی رو پیشنهاد می کنن.

- یه نکته که باید بهش دقت کرد اینه که اگر میخوایم از اسکریپت استفاده کنیم، حتما باید از نام استفاده کنیم. من فکر کنم اگر نام ها رو از یه طریق مثل md5 به یه عدد تبدیل کنیم کار به مراتب سریعتر بشه. شما روشی به غیر از md5 برای هش کردن یه رشته میدونین که محاسبه اون هم سریع باشه؟