فارسی
باز کردن در Telegram
GGOD Mode Game Dev

GOD Mode Game Dev

@GODModeGameDev · کانال · ایندکس از 2026/10/01
60مشترک
81پست در ایندکس
A
AlbertOv
فونداسیون جبر خطی و جادوی ماتریس‌ها (Linear Algebra Foundations & The Matrix) در توسعه بازی‌های ویدئویی، یک واقعیت پنهان وجود دارد: فضا سیال است. تا به اینجای کار، ما بردارها را به عنوان موجودیت‌های مستقلی می‌دیدیم که در یک جهان ثابت حرکت می‌کنند. اما پشت صحنه، معماری اصلی موتور بازی‌سازی بر پایه‌ی قدرتمندترین ابزار ریاضیات یعنی جبر خطی (Linear Algebra) بنا شده است؛ همان جادوگری که فضای سه‌بعدی را طبق میل ما دگرگون می‌کند. جبر خطی ساختار فونداسیون فیزیک و رندرسازی گرافیکی است. بدون این علم، حرکت دادن یک مدل سه‌بعدی پیچیده با هزاران رأس (Vertex)، بازی شما را بلافاصله دچار افت فریم شدید خواهد کرد. در این مبحث، ریاضیات خشک دانشگاهی را کنار گذاشتیم و این سیستم را در لایه سخت‌افزار کالبدشکافی کردیم: مفهوم فضای برداری (Vector Spaces): درک دایره‌ی مختصات به عنوان یک شبکه ساختاریافته (Grid) و چگونگی فشرده‌سازی اطلاعات در حافظه پیوسته رم. ماتریس‌های TRS (ترکیب فضا): چطور سه عملگر انتقال (Translation)، چرخش (Rotation) و مقیاس (Scale) درون یک ماتریس $4 \times 4$ ترکیب می‌شوند تا فضا را در یک کسر از میکروثانیه دگرگون کنند. مختصات همگن (Homogeneous Coordinates): کالبدشکافی بعد چهارم یا همان مؤلفه مجهول $W$ و کاربرد ساختاری آن در تفکیک «موقعیت‌ها» از «جهت‌ها». موازی‌سازی در GPU: چرا کارت‌های گرافیک برای ضرب ماتریس‌ها بهینه شده‌اند و چطور میلیون‌ها پولیگون را در یک چرخه ساعت پردازش می‌کنند. عملیات‌های پایه‌ای ماتریس: از دترمینان و معکوس گرفته تا ضرب داخلی و خارجی در لایه کد یونیتی با ساختار Matrix4x4. سلسله‌مراتب واقعیت (Local vs. World Space): بررسی انتقال پایه‌ها (Basis Transformation) و چگونگی تبدیل مختصات محلی شیء به حقیقت مطلق جهان بازی (World Space). این مبحث به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math @GODModeGameDev
1 · 62 ·
AlbertOv
ماتریس‌های تبدیل آفین و دگرگونی واقعیت (Affine Transformation Matrices) اگر جبر خطی را موتور محرک فضا بدانیم، ماتریس‌های تبدیل آفین (Affine Transformations) فرمان هدایت آن هستند؛ ابزاری که به شما اجازه می‌دهد فضای بازی را به صورت ساختاریافته بکشید، بچرخانید، جابه‌جا کنید و تغییر دهید. ویژگی کلیدی تبدیل‌های آفین این است که دو قانون هندسی را هرگز نمی‌شکنند: خطوط صاف همواره صاف می‌مانند و خطوط موازی هرگز متقاطع نمی‌شوند. وقتی یاد بگیرید چطور این تبدیل‌ها را در لایه ماتریس زنجیره کنید، عملاً کنترل کامل رندرسازی و جابه‌جایی‌های سنگین بازی را به دست گرفته‌اید. در این مبحث، خط لوله تبدیل‌های هندسی را کالبدشکافی کرده‌ایم: خط لوله TRS: بررسی ترتیب استاندارد و حیاتی پردازش ماتریس‌ها؛ یعنی اعمال مقیاس (Scale)، سپس چرخش (Rotation) و در نهایت انتقال (Translate). کالبدشکافی ماتریس 4*4: اثبات ریاضی چگونگی ضرب و ترکیب ماتریس‌های مجزا در یک ماتریس واحد جهت ارسال به پردازنده گرافیکی (GPU). تبدیل‌های برشی (Shear Transformations): ت کنیک کج کردن فضا برای پیاده‌سازی افکت‌های کارتونی و پویا (Squash & Stretch) روی مش‌ها بدون نیاز به استخوان‌بندی و انیمیشن‌های آماده. تبدیل‌های پروجکشن (Projective Transformations): ریاضیات پشت صحنه لنز دوربین و مخروط دید (Frustum)؛ جایی که با مفهوم Perspective Divide آشنا می‌شویم تا خطوط موازی ریل قطب‌نما روی مانیتور تخت به یک نقطه در افق برسند. سفر میان فضاها (World, Viewport, Screen): درک تفاوت فضاهای سه‌بعدی جهان بازی، فضای نرمال‌شده‌ی لنز دوربین (۰ تا ۱) و فضای پیکسل‌های مطلق مانیتور کاربر، به همراه پیاده‌سازی کدهای بهینه برای قفل کردن UI روی کاراکترها. این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math @GODModeGameDev
61 ·
ویدیو
دروازه_ماتریس_یونیتی.mp4 · 4.8 MB
🗺 سفر میان فضاهای مختصات در یونیتی با ماتریس چطور یک آبجکت موقعیت محلی خودش را به حقیقت مطلق جهان بازی (World Space) تبدیل می‌کند؟ این ویدیو خلاصه کلیدی مبحث Basis Transformation و رفتار ستون‌های ماتریس تبدیل که در مقاله اخیر مورد بحث قرار گرفته شده را در یک نگاه به شما نشان می‌دهد. با فهمیدن جادوی این دروازه، ریاضیات پنهان پشت صحنه transform.localToWorldMatrix را به طور کامل لمس خواهید کرد. 📐🚪 #Math @GODModeGameDev
83 ·
A
استرینگ بیلدر StringBuilder در سی‌شارپ برای ساخت و ویرایش رشته‌ها به شکل بهینه استفاده می‌شود. دلیل وجود آن این است که "string" در سی‌شارپ Immutable است؛ یعنی بعد از ساخته شدن قابل تغییر نیست. هر بار که با "+" یا "+=" متنی را به یک رشته اضافه می‌کنید، در واقع یک رشته جدید در حافظه ساخته می‌شود و رشته قبلی بعداً توسط Garbage Collector پاک می‌شود. اگر این کار فقط چند بار انجام شود، مشکلی ایجاد نمی‌کند. اما وقتی داخل یک حلقه یا متدی مثل "Update" بارها رشته بسازید، تعداد زیادی تخصیص حافظه (GC Allocation) ایجاد می‌شود که می‌تواند باعث افت عملکرد و حتی لگ‌های کوتاه در بازی شود. در "StringBuilder" این مشکل را با نگهداری یک بافر در حافظه حل می‌کند. به جای ساختن یک رشته جدید در هر بار تغییر، همان بافر را ویرایش می‌کند و فقط در پایان، یک رشته نهایی تولید می‌شود. به همین دلیل مصرف حافظه کمتر، فشار روی Garbage Collector پایین‌تر و عملکرد بهتر خواهد بود. در یونیتی، "StringBuilder" بیشتر برای ساخت متن‌های UI، لاگ‌ها، فایل‌های متنی، یا هر جایی که یک رشته به دفعات تغییر می‌کند کاربرد دارد. به طور کلی، برای اتصال یکی دو رشته کوتاه از "string" استفاده کنید؛ اما اگر قرار است رشته را بارها تغییر دهید یا داخل حلقه بسازید، "StringBuilder" انتخاب بهتری برای بهینه‌سازی است. #Optimization #بهینه_سازی #Tips #ترفند @GODModeGameDev
3 · 170 ·
GOD Mode Game Dev
عملیات‌های ماتریسی و دترمینان؛ رازهای پنهان انجین (Matrix Operations & Determinants) آموزش‌های مقدماتی اینترنت همیشه محاسبات سنگین زیر پوست موتور بازی‌سازی را پنهان می‌کنند. همه می‌دانند چطور یک بردار را در ماتریس 4*4 ضرب کنند تا شیء جابه‌جا شود، اما وقتی بازی به بهینه‌سازی‌های لایه‌آخری، پردازش موازی و محاسبات هم‌زمان هزاران رندرپاس می‌رسد، قضیه کاملاً متفاوت است. در این مقاله کاپوت انجین را بالا زده‌ایم تا کثیف‌ترین و سنگین‌ترین بخش‌های ریاضیات رانتایم یعنی عملیات‌های ماتریسی و مفهوم مبهم دترمینان (Determinant) را کالبدشکافی کنیم. در این قسمت خطاهای پنهان سخت‌افزاری و ترفندهای معماران انجین را بررسی کرده‌ایم: شهود فیزیکی دترمینان: درک دترمینان به عنوان مقیاس حجم فضا (Spatial Volume Scale) و کالبدشکافی فرمول بسط لاپلاس در لایه پردازش سخت‌افزاری SIMD. کابوس دترمینان منفی: چرا دادن اسکیل منفی به یک محور، جهت‌داری فضا (Handedness) را از چپ‌دست به راست‌دست تغییر می‌دهد و با برعکس کردن ترتیب چیدمان رئوس (Winding Order)، باعث انفجار سیستم Backface Culling و غیب شدن مِش‌ها یا باگ سایه‌های مطلق می‌شود. هکِ بهینه‌سازی ترانسپوز به جای معکوس: چرا محاسبه معکوس ماتریس ($A^{-1}$) یک فاجعه‌ی پردازشی است و چطور توسعه‌دهندگان ارشد با حفظ ارتونورمال بودن محورها، از ترانسپوز ماتریس به عنوان یک عملیات کاملاً رایگان و بدون محاسبات ریاضی استفاده می‌کنند. تضاد حافظه رم و GPU: بررسی ساختار ذخیره‌سازی داده‌ها در حافظه سیستم (Row-Major vs. Column-Major) و هزینه پنهان انتقال ماتریس‌ها به Constant Bufferهای کارت گرافیک. پیاده‌سازی کد لایه پایین: استفاده از توابع پیشرفته Matrix4x4 در یونیتی برای استخراج ماتریس شاسی، تشخیص معکوس شدن فضا و ردیابی مستقیم بردارهای پایه محلی در مقابل جهانی (transform.right در برابر Vector3.right). این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math #Architecture @GODModeGameDev
67 ·
G
ترکیب ماتریس‌های تبدیل و زنجیره‌سازی فضا (Compounding Transformation Matrices) ریاضیات جبر خطی از اینجا به بعد، از یک بحث تئوریک به یک «جادوی خالص رانتایم» تبدیل می‌شود. وقتی وارد قلمروی انیمیشن‌های اسکلتی (Skeletal Animation)، ریگ‌های پروسجِرال، یا سیستم‌های سلسله‌مراتبی تودرتو (Parent/Child) می‌شوید، دیگر با یک ماتریس واحد سر و کار ندارید؛ بلکه در حال ساختن زنجیره‌ای از وابستگی‌های فضایی هستید. در این مقاله رازهای مهندسی سنگین پشت صحنه ترکیب ماتریس‌ها را بررسی می‌کنیم که در آموزش‌های ساده اینترنت هرگز به آن‌ها اشاره نمی‌شود. در این قسمت مفاهیم عمیق و بهینه‌سازی‌های لایه‌آخری زیر را کالبدشکافی کرده‌ایم: قدرت شرکت‌پذیری (Associativity): چطور به کمک خاصیت شرکت‌پذیری، سه ماتریس مجزای اسکیل، چرخش و جابه‌جایی را روی CPU در یک ماتریس واحد ضرب و ادغام (Collapse) کنیم تا بار پردازشی لودِ رئوس مِش روی کارت گرافیک را تا ۶۶٪ کاهش دهیم. تله‌ی جابه‌جایی (The Commutative Trap): چرا ضرب ماتریس‌ها خاصیت جابه‌جایی ندارد و چطور اشتباه در ترتیب اعمال ماتریس‌ها (TRS) باعث بروز فجایعی مثل چرخش‌های مداری ناخواسته (Orbital Nightmare) یا کج شدن و دفرمه شدن مِش‌ها (Shearing Catastrophe) می‌شود. معماری تغییر نقطه پایوت (Pivot Point Offsetting): ترفند سه‌مرحله‌ای ماتریسی برای تغییر لحظه‌ای مرکز دوران آبجکت‌ها (مثلاً چرخیدن درب قلعه از محل لولا) بدون دستکاری در فایل سورس مدل سه‌بعدی. الگوی بهینه‌سازی Matrix Cache: کالبدشکافی پرفورمنس انجین و چگونگی استفاده از فلگ‌های بیت‌وایز (_isDirty) برای جلوگیری از محاسبه تکراری ماتریس‌های اشیاء فرزند در رانتایم. خطای شناور (Floating-Point Drift) و تجزیه ماتریس: مدیریت ارورهای ریزِ گرد کردن اعداد در سلسله‌مراتب‌های خیلی عمیق و روش استخراج (Decompose) مؤلفه‌های حرکتی در زمان جدا شدن یک آبجکت از والدش. مطالعه موردی (Case Study): پیاده‌سازی سیستم حرکتی یک بازوی رباتیک/مفصلی پروسجرال به صورت مستقیم با کد لایه پایین و بدون تحمیل هزینه‌ی سنگین سلسله‌مراتب پیش‌فرض یونیتی. این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math #Architecture @GODModeGameDev
70 ·
GOD Mode Game Dev
تصور کردن بردارها و سایه‌افکنی در فضا (Scalar & Vector Projections) تصویر کردن یکی از پرکاربردترین ابزارهای استعلام فضایی (Spatial Interrogation) در توسعه بازی است. در دنیای واقعی، وقتی نور چراغ‌قوه را به یک شیء می‌تابانید، سایه‌ای تخت روی دیوار پشت آن می‌افتد. در ریاضیات بازی، پروژکشن (Projection) دقیقاً همین فرآیند سایه‌اندازی است؛ یعنی برداری را در فضای سه‌بعدی می‌گیرید و آن را روی یک خط جهت‌دار دیگر تخت یا فشرده می‌کنید. در این مقاله مفاهیم زیر را در لایه پرفورمنس و شیدرها موشکافی کرده‌ایم: موتور ریاضی پروژکشن: چطور با استفاده از سرعت خیره‌کننده‌ی ضرب داخلی ، طول و بردار سایه را بدون نیاز به محاسبات سنگین مثلثاتی استخراج کنیم. تله‌ی بردار صفر (Zero-Vector Hazard): ترفند ایمن‌سازی کد برای جلوگیری از تولید ارورهای خاموش NaN در مواقع برخورد با نرمال‌های خراب. بهینه‌سازی سیستم میدان دید (FOV Check): چطور بدون استفاده از تابع سنگین Acos و فقط با مقایسه دترمینان کسینوسی، بفهمیم دشمن در زاویه دید کاراکتر قرار دارد یا خیر. حل مشکل برخورد و سرخوردن روی دیوارها (Sliding Vector): کالبدشکافی مکانیک Vector Rejection؛ تکنیکی که در تمام انجین‌های بزرگ برای تجزیه بردار سرعت و تبدیل آن به حرکت نرم و روان در امتداد سطوح ناهموار استفاده می‌شود. کالبدشکافی شیدرهای PBR: چطور کارت‌های گرافیک در هر فریم میلیون‌ها بار از این پروژکشن‌ها برای تفکیک نور به دو مؤلفه Specular (براق) و Diffuse (پخش‌شده) استفاده می‌کنند. مطالعه موردی و کدهای عملیاتی: سیستم ردیابی پیشرفت خودروها در بازی‌های مسابقه‌ای (Leaderboard) و سیستم پیاده‌سازی گرانش سفارشی روی سیارات کروی در بازی‌های فضاپیمایی. این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math #Physics @GODModeGameDev
77 ·
A
خلق بردارهای عمود و جادوی تعامد (Perpendicular Vector Generation) تا به اینجای کار، ما بردارهای موجود را دستکاری می‌کردیم، در ماتریس‌ها ضرب می‌کردیم یا روی فضاها تصویر می‌کردیم. اما به عنوان یک معمار ارشد انجین، بارها با این چالش عریان مواجه می‌شوید: شما فقط یک بردار جهت در فضا دارید و باید یک بردار کاملاً جدید و عمود بر آن خلق کنید. در جبر خطی، این قلمروی تعامد (Orthogonality) است. وقتی دو نیرو یا دو بردار کاملاً بر هم عمود می‌شوند، هم‌راستایی فضایی آن‌ها کاملاً از هم مستقل (Decouple) می‌شود. در این مقاله یاد می‌گیریم چطور از هیچ، بردارهای عمود بر هم بسازیم و ترفندهای لایه سخت‌افزاری را بدون اصطلاحات پیچیده دانشگاهی کالبدشکافی کنیم و خط لوله ساخت فضاهای تعامد را موشکافی کنیم قانون طلایی ضرب داخلی صفر: چطور از عهد تعامد برای بهینه‌سازی فرمول‌ها و خلق کامپوننت‌های عمود بر هم استفاده کنیم. هکِ جابه‌جایی مؤلفه‌ها در فضای دوبعدی: ترفند فوق‌سریع جابه‌جایی سخت‌افزاری کامپوننت‌ها یعنی تبدیل بردار (x, y) به (-y, x) برای ساخت جهت‌های جانبی آنی بدون نیاز به محاسبات سنگین مثلثاتی. تکنیک دیسکِ چرخان در فضای سه‌بعدی: چطور به کمک ضرب خارجی (Cross Product) و یک محور کمکی (Fallback Axis)، از پدیده فروپاشی ضرب خارجی (Cross-Product Collapse) فرار کنیم و تانژانت‌های پایدار بسازیم. پاک‌سازی داده‌ها با الگوریتم Gram-Schmidt: ترفند لایه پایینی که در شیدرهای ورتکس برای اصلاح بردارهای نوئیزدار و دفرمه‌شده مِش‌ها استفاده می‌شود تا بازتاب نور و سیستم Normal Mapping کاملاً بی‌نقص رندر شود. مطالعه موردی و کدهای عملیاتی: پیاده‌سازی سیستم خط لوله داش جانبی در بازی‌های دوبعدی و سیستم ریل‌گذاری پروسجرال در ترن‌های هوایی با مدیریت سه محور مستقل فضا. این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math @GODModeGameDev
82 ·
GOD Mode Game Dev
آنالیز نرمال‌های سطح و دترمینان مساحت (Surface Normal Analysis & Area Interpretation) در هندسه بازی‌سازی، نرمال‌های سطح (Surface Normals) و مساحت چندضلعی‌ها سنگ‌بنای رندرینگ، فیزیک برخورد، و محاسبات نورپردازی هستند. اگر نتوانید جهت‌گیری دقیق سطوح و مساحت اشغال‌شده توسط آن‌ها را تحلیل کنید، هیچ‌وقت نمی‌توانید به تکنیک‌های رده‌بالایی مثل شیدرهای واقع‌گرایانه پوست یا شبیه‌سازی گرانش محلی دست پیدا کنید. در این مقاله یاد می‌گیرید چطور با استفاده از ضرب خارجی، محاسبات دیفرانسیلی و محاسبات تانژانتی، ساختار بیرونی اشیاء سه‌بعدی را مثل یک انجین‌آرکیتکت ارشد کالبدشکافی کنید. همچنین لایه‌های مهندسی پنهان زیر را عمیقاً بررسی کرده‌ایم: ضرب خارجی در نقش مولد مساحت: چطور اندازه ضرب خارجی دو لبه یک مثلث، مساحت متوازی‌الأضلاع متناظر را تولید می‌کند. خطرات و مدیریت پدیده Degenerate: روش‌های پاک‌سازی مِش‌های خراب و نادیده گرفتن مثلث‌های مماس و بسیار باریک (Sliver Triangles) با استفاده از فیلتر اپسیلون جهت جلوگیری از کرش فیزیک بازی. محاسبه میانگین وزن‌دار نرمال‌ها (Area-Weighted Normals): تکنیک استاندارد صنعت برای صاف کردن مِش‌های غیریکنواخت به طوری که مثلث‌های بزرگتر تاثیر بیشتری روی نرمال ورتکس‌های مشترک بگذارند. ریاضیات کالینگ پشت‌صحنه (Backface Culling Math): کالبدشکافی گیت کنترلر سخت‌افزاری پردازنده گرافیکی با استفاده از فرمول ضرب داخلی جهت حذف فوری چندضلعی‌هایی که پشت به دوربین هستند و صرفه‌جویی در میلیاردها پردازش پیکسلی. کدگذاری هکِ برداری در بافت‌های نرمال (Normal Mapping): نحوه تبدیل بردارهای سه‌بعدی در بازه [-1.0, 1.0] به فرمت رنگ‌های RGB در محدوده [0.0, 1.0] و برعکس. بازسازی نرمال بدون داشتن ورتکس (SDF Gradients): چطور سیستم‌های ری‌مارچینگ و ابرهای حجمی، نرمال سطوح را با تقریب مشتق جزئی و گرادیان روی میدان‌های فاصله علامت‌دار (SDF) استخراج می‌کنند. آنالیز شیب زمین در بازی‌های جهان‌باز (Slope Mapping): پیاده‌سازی گرانش سیاره‌ای و سیستم تشخیص شیب مجاز برای عبور هوش مصنوعی یا ممانعت از اسپاونِ درخت روی دامنه کوه‌ها. کشیدگی تفاضلی پوست کاراکتر (The Jacobians): بررسی تغییر شکل‌های ظریف مِش در محل مفاصل (عضلات) با استفاده از ضرب خارجی ماتریس ژاکوبین برای پیاده‌… خواندن کامل ←
100 ·
A
اجرای سریع Play Mode در یونیتی برای اینکه موقع زدن Play یونیتی بدون Reload شدن Scene و Scriptها اجرا بشه، مسیر زیر رو باز کنید: Edit → Project Settings → Editor گزینه Enter Play Mode Options رو فعال کنید و تیک‌های Reload Domain و Reload Scene رو بردارید. با این کار، زمان ورود به Play به شدت کمتر میشه؛ چون یونیتی دیگه Scene و Domain رو از اول لود نمی‌کنه. فقط حواست باشه: اگر پروژه‌ات از موارد زیر استفاده می‌کنه، ممکنه به مشکل بخوری؛ چون با هر Play ریست نمی‌شن و مقدار اجرای قبلی رو نگه می‌دارن: - static Variable - Singleton - static event - DontDestroyOnLoad - Object Pool - Cache اگر از این موارد استفاده می‌کنی، باید موقع شروع بازی خودت اون‌ها رو ریست یا مقداردهی اولیه کنی؛ وگرنه ممکنه با داده‌های اجرای قبلی وارد Play بشی و رفتارهای غیرمنتظره ببینی. #Tips #ترفند @GODModeGameDev
1 · 101 ·
GOD Mode Game Dev
تئوری تجزیه بردارها و مدیریت نیروهای مستقل (Vector Decomposition Theory) وقتی در حال نوشتن یک سیستم حرکتی با کارایی بالا (High-Performance Character Controller) یا کلنجار رفتن با باگ‌های عجیب فیزیک هستید، پردازش یک بردار به صورت خام و سه‌تکه نشده، مثل یک تبر کُند عمل می‌کند. اگر بازیکن شما به صورت مورب به یک رمپ شیب‌دار برخورد کند، بردار سرعت خام او شامل ترکیبی آشفته از سه تمایل فیزیکی مجزاست: حرکت به جلو، سرخوردن به طرفین و مبارزه با جاذبه. در این مقاله، تجزیه بردارها (Vector Decomposition) را بررسی می‌کنیم؛ یعنی شکافتن یک بردار واحد در فضا به زیربردارهای مستقل و کاملاً عمود بر هم. با این کار، شما کانال‌های حرکتی را از هم مستقل (Decouple) می‌کنید تا بتوانید یک رفتار فیزیکی خاص (مثلاً اصطکاک یا نیروی بالابرنده) را بدون خراب کردن سایر مؤلفه‌های حرکتی، تغییر دهید یا تضعیف کنید. در این قسمت، مفاهیم و بهینه‌سازی‌های لایه‌آخری زیر را کالبدشکافی کرده‌ایم: مکانیک شبیه‌سازی فیلتر سایه (Projection vs. Rejection): خط لوله دو مرحله‌ای برای استخراج مؤلفه موازی از طریق پروژکشن و استخراج آنی مؤلفه عمود بر آن از طریق محاسبات تفاضلی ریجکشن. تله‌ی گلوگاه پردازشی مکرر محاسبات دات‌پروتکت: چرا بازسازی مداوم محاسبات پروجکشن روی ترد اصلی (مثلاً برای سیستم تعلیق خودرو روی زمین‌های ناهموار پروسجرال) CPU را قفل می‌کند و چطور با ترفند ضرب ماتریسی ترانهاده (Transpose TBN Matrix) کل تجزیه سه محور را در یک سیکل سخت‌افزاری انجام دهیم. مدیریت خطای شناور فضا (Orthogonality Drifting): بررسی ارورهای ریز گرد کردن اعداد اعشاری در محاسبات فریم‌به‌فریم فیزیک خودرو که باعث دفرمه شدن و کج شدن فضاهای تعامدِ سیستم تعلیق می‌شود. تاریخچه کامپیوتر ساینس و الگوریتم Gram-Schmidt: نوار نقاله ریاضیاتی فوق‌العاده‌ای که مجموعه‌ای از بردارهای تصادفی و غیرعمود را می‌گیرد و با پاک‌سازی هم‌راستایی‌های تکراری، یک بوم فضای سه‌بعدی کاملاً ارتوگونال و اختصاصی خلق می‌کند. مطالعه موردی و کدهای عملیاتی: پیاده‌سازی سیستم محاسبه امتیاز دریفت خودرو (Drifting Meter) بر اساس سرعت جانبی چرخ‌ها و شبیه‌سازی آیرودینامیک گلایدر در مقابل بادهای حرارتی با تفکیک نیروی Lift و Drag. این فصل به دو زبان انگلیسی و فارسی منتشر شده ا… خواندن کامل ←
1 · 113 ·
AlbertOv
تولید خودکار مرحله یکی از مهم‌ترین بخش‌های توسعه‌ی بازی است. در بسیاری از بازی‌ها، تعداد مراحل می‌تواند به صدها یا حتی هزاران مرحله برسد. طراحی دستی این حجم از محتوا علاوه بر زمان‌بر بودن، حفظ کیفیت، تنوع و بالانس مراحل را نیز بسیار دشوار می‌کند. برای حل این مشکل، از سیستمی استفاده می‌شود که وظیفه‌ی تولید خودکار مراحل را بر عهده دارد. این سیستم با استفاده از قوانین و محدودیت‌هایی که طراح بازی مشخص می‌کند، مراحل جدید تولید می‌کند. این قوانین می‌توانند شامل اندازه‌ی نقشه، تعداد آیتم‌ها، محل قرارگیری آبجکت‌ها، قوانین گیم‌پلی، اهداف مرحله و بازه‌ی سختی موردنظر باشند. در پیاده‌سازی این سیستم معمولاً از Level Generator استفاده می‌شود. این سیستم می‌تواند بر پایه‌ی الگوریتم‌های Procedural Content Generation (PCG) کار کند یا از مدل‌های هوش مصنوعی برای تولید مراحل کمک بگیرد. همچنین ترکیب این دو روش نیز در بسیاری از پروژه‌ها استفاده می‌شود. هدف از تولید خودکار مرحله، فقط افزایش تعداد مراحل نیست؛ بلکه ایجاد مراحل متنوعی است که قوانین بازی را رعایت کنند و تجربه‌ی متفاوتی برای بازیکن به وجود آورند. البته تولید شدن یک مرحله به این معنا نیست که آن مرحله کیفیت مناسبی دارد. ممکن است مرحله غیرقابل حل باشد، بیش از حد ساده یا سخت باشد، یا شباهت زیادی به مراحل قبلی داشته باشد. #Algorithm @GODModeGameDev
1 · 116 ·
A
اعتبارسنجی و تحلیل مراحل، آخرین بخش از فرآیند تولید محتوای بازی است. بعد از اینکه مراحل توسط طراح، الگوریتم یا هوش مصنوعی تولید شدند، باید کیفیت آن‌ها بررسی شود. تولید یک مرحله به‌تنهایی کافی نیست؛ مهم این است که آن مرحله قابل حل، متعادل و مناسب تجربه‌ی بازیکن باشد. برای انجام این کار معمولاً از دو سیستم استفاده می‌شود که یکی وظیفه‌ی حل کردن مرحله را بر عهده دارد و دیگری کیفیت آن را تحلیل می‌کند. سیستم Level Solver قوانین بازی را شبیه‌سازی می‌کند و مانند یک بازیکن ایده‌آل، مرحله را تا انتها حل می‌کند. هدف این سیستم پیدا کردن پاسخ صحیح نیست، بلکه بررسی رفتار مرحله از نظر منطقی است. با استفاده از Solver می‌توان اطلاعاتی مانند موارد زیر را به دست آورد: - آیا مرحله قابل حل است یا خیر. - بهترین یا کوتاه‌ترین مسیر برای حل مرحله چیست. - حداقل تعداد حرکت یا اکشن موردنیاز برای اتمام مرحله. - وجود بن‌بست‌ها (Deadlock) یا حالت‌هایی که ادامه‌ی بازی را غیرممکن می‌کنند. - تعداد مسیرهای معتبر برای رسیدن به هدف. پس از پایان فرآیند حل، نوبت به تحلیل کیفیت مرحله می‌رسد. سیستم Level Analyzer با استفاده از اطلاعات تولیدشده توسط Solver و همچنین معیارهای آماری، کیفیت هر مرحله را ارزیابی می‌کند. برخلاف Solver که فقط منطق مرحله را بررسی می‌کند، Analyzer تلاش می‌کند تجربه‌ی احتمالی بازیکن را پیش‌بینی کند. خروجی Analyzer می‌تواند شامل موارد زیر باشد: - برآورد میزان سختی مرحله. - تخمین زمان موردنیاز برای تکمیل مرحله. - میزان پیچیدگی تصمیم‌گیری در طول بازی. - شباهت مرحله به مراحل قبلی. - تشخیص مراحل تکراری یا بسیار مشابه. - بررسی روند افزایش سختی مراحل در طول بازی (Difficulty Curve). - شناسایی مراحل نامتعادل یا مراحلی که احتمال گیر کردن یا خسته شدن بازیکن در آن‌ها زیاد است. در بسیاری از بازی‌های مدرن، این سه سیستم به‌صورت یک زنجیره کنار هم قرار می‌گیرند. ابتدا Level Generator مرحله را تولید می‌کند، سپس Level Solver از قابل حل بودن آن مطمئن می‌شود و در نهایت Level Analyzer کیفیت، سختی و تجربه‌ی کلی آن مرحله را ارزیابی می‌کند. به همین دلیل، در پروژه‌های حرفه‌ای، تولید هزاران مرحله بدون استفاده از این Pipeline تقریباً غیرممکن است؛ زیرا کیفیت مراحل فقط با ساختن آن‌ها تضمین نمی‌شود، بلکه … خواندن کامل ←
1 · 113 ·
GOD Mode Game Dev
فیزیک برخوردهای الاستیک و بازتاب‌های ساختاری (Physics of Elastic Collisions & Reflections) پس از یادگیری تئوری تجزیه بردارها، نوبت به یکی از جذاب‌ترین و در عین حال چالش‌برانگیزترین مباحث فیزیک بازی می‌رسد: کوبیدن بردارهای تکه‌شده به مرزهای جامد. چه در حال کدنویسی بازتاب یک پرتو لیزر باشید، چه مسیر پرتاب یک نارنجک و چه یک سولور فیزیکی اختصاصی برای ریجیدبادی‌ها، باید بر جادوی بازتاب‌های ساختاری مسلط شوید. ضرب کردن ساده‌ی بردار سرعت در عدد منفی یک فاجعه‌بار است؛ باعث رد شدن اشیاء از دیوار، هدر رفتن نامتوازن انرژی و باگ‌های حرکتی کورکورانه می‌شود. در این مقاله، فرمولاسیون و هک‌های سخت‌افزاری پدیده بازتاب را در سطح سیلیکون کالبدشکافی می‌کنیم تا بدون نیاز به توابع سنگین مثلثاتی، سیستم‌های جهش فیزیکی کاملاً بهینه و پایداری را توسعه دهید. در این قسمت، مفاهیم و بهینه‌سازی‌های لایه‌آخری زیر را کالبدشکافی کرده‌ایم: موتور ریاضی فرمول بازتاب استاندارد: کالبدشکافی چگونگی معکوس کردن مؤلفه عمود بر دیوار و توسعه فرمول جادویی و فوق‌بهینه‌ی انعطاف‌پذیر بدون نیاز به محاسبات سنگین و گران‌قیمت سینوس و کسینوس. تزریق فاکتور دنیای واقعی و ضریب بازگشت: معرفی فرمول ایمپالس رفلکشن برای شبیه‌سازی دقیق فیزیک مواد مختلف و چگونگی کنترل مستقیم اتلاف انرژی، به طوری که سرعت خزشی و موازی با دیوار کاملاً حفظ شود اما سرعت عمودی دچار افت فیزیکی گردد. مدیریت اصطکاک جانبی و ویژگی‌های مادی سطوح: روش اعمال فاکتور اصطکاک روی مؤلفه موازی با سطح جهت متمایز کردن جهش روی یخ در مقایسه با بتن زبر و چگونگی کش کردن پویا از طریق ساختار فیزیکال متریال مِش‌ها. تله‌ی پردازشی تانلینگ و فلاش گلیچ روی پردازنده: کالبدشکافی باگ وحشتناک رد شدن اشیاء سریع از دیوارهای نازک در فریم‌ریت‌های پایین و پیاده‌سازی معماری سیستم تشخیص برخورد مداوم با تکنیک اسکن خطی پارامتری جهت استخراج زمان دقیق برخورد. مطالعه موردی و کدهای عملیاتی: پیاده‌سازی مکانیک شلیک‌های ترفند‌آمیز پرتو لیزر با رای‌کست‌های متوالی و ساخت ضربه‌گیرهای انفجاری بازی پین‌بال با تزریق انرژی افزاینده و بزرگتر از یک به سیستم فیزیک. این فصل به دو زبان انگلیسی و فارسی منتشر شده است. لینک مطالعه #Math #Physics @GODModeGameDev
1 · 139 ·
G
پدیده قفل گیمبال و فروپاشی فضایی (Gimbal Lock Phenomena & Spatial Collapse) دوران یک شیء سه‌بعدی در موتورهای بازی، یکی از گول‌زننده‌ترین و پیچیده‌ترین تبدیل‌هاست. در حالی که موقعیت یک نقطه در فضای اقلیدسی کاملاً سرراست است، چرخش مثل یک تله عمل می‌کند. اگر برای ساخت دوربین‌ها، کنترلرهای پرواز یا ریگ‌های پروسجرال خود به زوایای ملموس اولر (چرخش روی سه محور X، Y و Z) متکی باشید، دیر یا زود با یک سینگولاریتی و منفردی ریاضی به نام قفل گیمبال برخورد خواهید کرد. در این مقاله، پدیده قفل گیمبال و فروپاشی فضایی را بررسی می‌کنیم؛ یعنی کالبدشکافی دلایل شکست شهود مکانیکی ما در چرخش، چگونگی فروپاشی ساختاری سیستم و روش‌های رهاسازی سلسله‌مراتب مختصات استاندارد به نفع منیفولدهای دورانی چهاربعدی. در این قسمت، مفاهیم و بهینه‌سازی‌های لایه‌آخری زیر را کالبدشکافی کرده‌ایم: هندسه تله و منشأ مکانیکی سه محوره: کالبدشکافی حلقه متداخل گیمبال‌های مکانیکی و بررسی لحظه دقیق ریاضی که در آن با چرخش ۹۰ درجه‌ای حلقه وسط، سه درجه آزادی به دو درجه آزادی تنزل پیدا کرده و دو محور کاملاً بر هم منطبق می‌شوند. افت رتبه ماتریس ژاکوبین و سرقت درجه آزادی: چگونگی صفر شدن خطی بردارهای پایه در ماتریس تبدیل هنگام نزدیک شدن زاویه پیتچ به ۹۰ درجه و غیرممکن شدن محاسبات ماتریسی برای تشخیص دو بعد دورانی مختلف. مصائب قفل گیمبال؛ از پرش ناگهانی دوربین تا انحراف مسیر: بررسی باگ‌های چالش‌برانگیز بازی‌ها از جمله چرخش ناگهانی و ۱۸۰ درجه‌ای دوربین (Camera Snapping)، طی کردن مسیرهای منحنی شکل و غیرمستقیم برای رسیدن به هدف (Circular Detour) و قفل شدن کنترلرهای پرواز. راهکار ساختاری اشتباه؛ شبیه‌سازی گیمبال مکانیکی چهار محوره: چرا پیاده‌سازی حلقه چهارم مکانیکی هواپیماها در کد و حلقه بازی فاجعه‌بار است و چرا به جای راه‌حل‌های فیزیکی باید زیربنای ریاضیات چرخش را تغییر داد. فرار به ابرکره چهاربعدی و ورود کواترنیون‌ها: تاریخچه کشف کشف رزونانس ۴ بعدی توسط ویلیام روآن همیلتون، تعریف کواترنیون‌ها به عنوان اعداد مختلط چهاربعدی و بررسی این موضوع که چرا چرخش روی منیفولد ۴ بعدی هیچ‌گاه دچار سینگولاریتی نمی‌شود. مزیت الگوریتم SLERP و درک انحراف ناشی از LERP: چرا اینترپولیشن خطی (LERP) باعث تغییر سرعت زاویه‌ای و خروج بردار از سطح ک… خواندن کامل ←
3 · 171 ·
A
AlbertOv
خیلی ساده بخوام بگم، Raycast با Alloc و بدون Alloc اینطوریه: Raycast با Alloc وقتی مثلاً می‌گی: RaycastHit[] hits = Physics.RaycastAll(ray); یونیتی هر بار که این دستور اجرا میشه، میره توی حافظه یه آرایه جدید درست می‌کنه و نتیجه‌ها رو میریزه داخلش. مثلاً اگر هر فریم اجراش کنی: فریم 1 → ساخت آرایه جدید فریم 2 → ساخت آرایه جدید فریم 3 → ساخت آرایه جدید آرایه‌های قبلی دیگه استفاده نمی‌شن و بعداً Garbage Collector باید بیاد جمعشون کنه. اگه تعدادشون زیاد بشه، ممکنه باعث لگ و افت فریم بشه. Raycast بدون Alloc اینجا از قبل یه آرایه می‌سازی: RaycastHit[] hits = new RaycastHit[20]; بعد: Physics.RaycastNonAlloc(ray, hits); یونیتی دیگه هر بار آرایه جدید نمی‌سازه. همون آرایه قبلی رو برمی‌داره و نتیجه جدید رو داخلش می‌ریزه. یعنی: با Alloc: Raycast → آرایه جدید → Garbage → GC بدون Alloc: Raycast → همون آرایه قبلی → استفاده مجدد پس اصل قضیه اینه که Alloc یعنی هر بار یه تکه حافظه جدید برای نتیجه بسازیم، ولی NonAlloc یعنی حافظه رو یک بار بسازیم و مدام از همون استفاده کنیم. #HowToWork @GODModeGameDev
2 · 81 ·
A
AlbertOv
مش در واقع اطلاعات هندسی یه آبجکت سه‌بعدیه یا دوبعدی و به یونیتی میگه این مدل دقیقاً چه شکلیه. خود Mesh از چند بخش اصلی تشکیل میشه. ورتکس‌ها یا Vertices نقطه‌های مدل هستن و موقعیت هر نقطه رو در فضای سه‌بعدی مشخص می‌کنن. مثلاً گوشه‌های یک مکعب همین نقطه‌ها هستن. مثلث ها یا Triangles مشخص می‌کنن این نقطه‌ها چطور به هم وصل بشن. هر سه نقطه کنار هم یک مثلث می‌سازن و تعداد زیادی مثلث در کنار هم سطح کامل مدل رو تشکیل میدن. نرمال‌ها یا Normals جهت هر سطح رو مشخص می‌کنن و یونیتی ازشون برای محاسبه نور استفاده می‌کنه. یعنی مشخص می‌کنن نور چطور روی سطح مدل پخش بشه. یووی‌ها یا UV مشخص می‌کنن تکسچر کجای مدل قرار بگیره. در واقع میگن هر قسمت از تصویر باید روی کدوم قسمت از مدل بیفته. تَنگِنت‌ها یا Tangents بیشتر برای Shader و چیزهایی مثل Normal Map استفاده میشن و به یونیتی کمک می‌کنن جهت سطح رو نسبت به UV درست محاسبه کنه. باندز یا Bounds هم محدوده کلی دور Mesh هست و یونیتی ازش برای چیزهایی مثل تشخیص اینکه مدل داخل دید دوربین هست یا نه استفاده می‌کنه. تو پست بعد در مورد چگونه ساخت و محاسبه Normal ها صحبت میکنیم #Mesh @GODModeGameDev
2 · 84 ·
A
AlbertOv
برای ساخت Normal یک سطح، از دو ضلع مثلث دو بردار می‌سازیم و با ضرب خارجی - Cross product جهت عمود بر سطح رو به دست میاریم. برای محاسبه Normal یک Triangle، اول از سه Vertex مثلث استفاده می‌کنیم. از Vertex اول به Vertex دوم یک بردار می‌سازیم و از Vertex اول به Vertex سوم هم یک بردار دیگه. بعد این دو بردار رو با Cross Product ضرب می‌کنیم: "Normal = (Vertex2 - Vertex1) × (Vertex3 - Vertex1)" نتیجه یک برداره که عمود بر سطح Triangle قرار می‌گیره و همون جهت Normal اون سطحه. مهم: البته جهت Normal به ترتیب Vertexها هم بستگی داره. اگر ترتیب Vertexها رو برعکس کنیم، Normal هم برعکس میشه. بعد معمولاً این بردار رو Normalize می‌کنیم تا طولش بشه ۱ و فقط جهتش باقی بمونه. توی یونیتی هم اگر بخوای این کار رو خودت انجام بدی، می‌تونی همین محاسبه رو با "Vector3.Cross" انجام بدی. اگر هم بخوای یونیتی خودش Normalهای Mesh رو از روی Triangleها محاسبه کنه، می‌تونی از "mesh.RecalculateNormals()" استفاده کنی.  در واقع کل داستان خیلی ساده‌ست: سه نقطه داریم، ازشون دو ضلع می‌سازیم، Cross Product می‌گیریم و بردار عمود بر سطح به دست میاد. #Mesh #Normals @GODModeGameDev
1 · 84 ·
A
AlbertOv
اسپرایت برخلاف چیزی که خیلی‌ها فکر می‌کنن، خودش یک عکس PNG نیست. اسپرایت در یونیتی بیشتر به نحوه استفاده و نمایش یک تصویر روی یک Texture گفته میشه. یعنی ممکنه یک تصویر PNG داشته باشی، ولی وقتی وارد یونیتی میشه، هنوز صرفاً یک Texture هست و با تنظیمات Sprite به یونیتی میگی با این تصویر به عنوان اسپرایت رفتار کنه. اسپرایت می‌تونه از یک تصویر کامل ساخته شده باشه یا حتی از یک Texture بزرگ که داخلش چندین تصویر وجود داره و با Sprite Sheet فقط قسمت موردنظر از اون تصویر خونده بشه. توی این داستان چند بخش مهم داریم. Texture خود تصویر و اطلاعات پیکسلیشه، Sprite مشخص می‌کنه کدوم قسمت از Texture قراره به عنوان اسپرایت استفاده بشه، Pivot نقطه مرجع اسپرایته که مشخص می‌کنه مرکز یا نقطه قرارگیریش کجا باشه، و Pixels Per Unit مشخص می‌کنه چند پیکسل از تصویر معادل یک واحد در دنیای یونیتی باشه. مش تایپ Mesh Type هم مشخص می‌کنه اسپرایت با یک چهارضلعی ساده رندر بشه یا یونیتی شکل خود اسپرایت رو تا حدی دنبال کنه. Border هم وقتی برای 9-Slicing استفاده می‌کنی مشخص می‌کنه کدوم قسمت‌های تصویر باید کشیده یا ثابت بمونن. #2D #Sprite @GODModeGameDev
2 · 632 ·
A
AlbertOv
پاسخاسپرایت برخلاف چیزی که خیلی‌ها فکر می‌کنن، خودش یک عکس PNG نیست. اسپرایت در یونیتی بیشتر به نحوه استفاده و نمایش یک تصویر روی یک Texture گفته میشه. یعنی ممکنه یک تصویر PNG داشته باشی، ولی وقتی وارد یونیتی میشه، هنوز صرفاً یک Texture هست و با تنظیمات Sprite به یونیتی میگی با این تصویر به عنوان اسپرای
توی این پست می‌خوایم بریم سراغ چندتا دستور کاربردی برای کار با Texture و Sprite در یونیتی. *دستور GetPixel باهاش می‌تونیم رنگ یک پیکسل مشخص از Texture رو بخونیم. مثلاً مختصات X و Y رو بهش میدیم و رنگ همون نقطه رو بهمون برمی‌گردونه. *دستور SetPixel برعکس GetPixel عمل می‌کنه. باهاش می‌تونیم رنگ یک پیکسل مشخص رو تغییر بدیم. مثلاً می‌تونیم یک قسمت از Texture رو در Runtime تغییر بدیم. بعد از تغییرات باید Apply() رو صدا بزنیم تا تغییرات روی Texture اعمال بشه. *دستور GetPixelBilinear هم برای گرفتن رنگ از Texture استفاده میشه، ولی به جای مختصات پیکسلی مثل X و Y، مختصات بین ۰ تا ۱ می‌گیره و با توجه به پیکسل‌های اطراف، رنگ رو به صورت نرم‌تر محاسبه می‌کنه. *دستور Texture2D هم برای ساخت یک Texture جدید استفاده میشه. می‌تونیم اندازه و فرمتش رو مشخص کنیم، بعد با SetPixel یا SetPixels اطلاعات پیکسل‌ها رو داخلش قرار بدیم و در آخر با Apply() تغییرات رو اعمال کنیم. *دستور Sprite.bounds محدوده‌ایه که Sprite در فضای بازی اشغال می‌کنه. باهاش می‌تونیم اندازه و مرزهای واقعی Sprite رو نسبت به فضای خودش به دست بیاریم و برای محاسبات مختلف ازش استفاده کنیم. #Sprite #Texture @GODModeGameDev
1 · 101 ·
GOD Mode Game Dev
بریم سراغ دنیای شیدر ها 👍👎 ؟
1 · 69 ·
A
چندتا از اصطلاحات پر کاربرد داخل شیدر شیدر در واقع برنامه‌ایه که به GPU میگه با اطلاعاتی که از مدل و صحنه گرفته، پیکسل‌ها و Vertexها رو چطور پردازش کنه و در نهایت چطور نمایش بده. ساب‌شیدر یا "SubShader" بخشی از Shaderه که مشخص می‌کنه این شیدر با چه روش و چه قابلیت‌هایی باید روی سخت‌افزار اجرا بشه. ممکنه یک Shader چندتا SubShader داشته باشه تا اگر یکی قابل اجرا نبود، یونیتی سراغ گزینه بعدی بره. پَس یا "Pass" یه مرحله از رندر کردن آبجکته. یعنی داخل هر Pass مشخص می‌کنیم GPU در اون مرحله دقیقاً چه پردازشی انجام بده. مثلاً می‌تونیم یک Pass برای رندر اصلی و یک Pass جدا برای Shadow داشته باشیم. پراپرتیز یا "Propertiess" متغیرهایی هستن که از بیرون می‌تونیم مقدارشون رو تغییر بدیم. مثلاً رنگ، Texture، شدت نور یا هر مقداری که بخوایم از Inspector کنترل کنیم. تَگ‌ها یا "Tags" اطلاعاتی هستن که به Unity میگن این Shader یا Pass چه رفتاری داره. مثلاً مشخص می‌کنن آبجکت در چه نوع رندری قرار بگیره یا چه زمانی رندر بشه. رندر کوئِیو یا "Render Queue" مشخص می‌کنه آبجکت تقریباً چه زمانی نسبت به بقیه آبجکت‌ها رندر بشه. مثلاً آبجکت‌های Transparent معمولاً باید بعد از آبجکت‌های Opaque رندر بشن. بلِند یا "Blend" مشخص می‌کنه رنگ خروجی Shader چطور با چیزی که از قبل روی صفحه رندر شده ترکیب بشه. برای ساخت افکت‌های شفاف، دود، شیشه و چیزهای مشابه خیلی استفاده میشه. زد تست یا "ZTest" مشخص می‌کنه عمق پیکسل فعلی با چیزی که قبلاً در Depth Buffer ثبت شده مقایسه بشه یا نه. این کمک می‌کنه Unity بفهمه کدوم سطح باید جلوی کدوم سطح دیده بشه. زد رایت یا "ZWrite" مشخص می‌کنه عمق پیکسل فعلی داخل Depth Buffer نوشته بشه یا نه. این مورد مخصوصاً در Shaderهای Transparent خیلی مهمه. کال یا "Cull" مشخص می‌کنه کدوم سمت Faceهای Mesh رندر بشه. مثلاً با "Cull Back" معمولاً Faceهای پشت مدل رندر نمی‌شن و با "Cull Off" هر دو طرف می‌تونن رندر بشن. وِرتکس شیدر یا "Vertex Shader" روی Vertexهای مدل کار می‌کنه و معمولاً وظیفه اصلیش تبدیل موقعیت Vertexها و آماده کردن اطلاعات برای مرحله بعدیه. فراگمنت شیدر یا "Fragment Shader" که بهش Pixel Shader هم گفته میشه، برای هر پیکسل خروجی رو محاسبه می‌کنه و مشخص می‌کنه در نهایت او… خواندن کامل ←
1 · 67 ·
A
پاسخویدیو
توی "Rigidbody" یه تنظیم به اسم "Collision Detection" داریم که مشخص می‌کنه Unity چطور برخورد بین جسم‌ها رو تشخیص بده. این تنظیم وقتی مهم میشه که آبجکت‌ها با سرعت بالا حرکت می‌کنن و ممکنه در یک فریم کامل از داخل جسم دیگه رد بشن. دیسکریت یا "Discrete" حالت معمولیه. Unity در هر فریم موقعیت فعلی جسم رو بررسی می‌کنه و برخورد رو تشخیص میده. برای بیشتر آبجکت‌هایی که سرعت زیادی ندارن کاملاً مناسبه و هزینه محاسباتی کمتری هم داره. کانتینیوس یا "Continuous" برای جسم‌های سریع‌تره. Unity فقط موقعیت فعلی رو نگاه نمی‌کنه و مسیر حرکت جسم بین فریم‌ها رو هم بیشتر در نظر می‌گیره تا احتمال رد شدن از داخل Collider کمتر بشه. کانتینیوس داینامیک یا "Continuous Dynamic" حالت دقیق‌تری برای Rigidbodyهای سریع و متحرکه. این حالت برای تشخیص برخورد با Rigidbodyهای دیگه هم به شکل پیوسته‌تری عمل می‌کنه و برای چیزهایی مثل گلوله یا آبجکت‌های خیلی سریع کاربرد بیشتری داره، ولی طبیعتاً هزینه پردازشی بیشتری هم داره. در نتیجه لازم نیست برای همه‌چی "Continuous Dynamic" بذاریم. معمولاً از "Discrete" شروع می‌کنیم و فقط برای آبجکت‌های سریع یا جاهایی که مشکل عبور کردن از Collider داریم، سراغ حالت‌های Continuous می‌ریم. #Tips #Physics @GODModeGameDev
2 · 52 ·

فید عمومی باز از ایندکس جست‌وجو ChatCrawler — «Google برای Telegram عمومی»؛ با خزش انجمن به‌روز می‌شود. زمان‌ها به UTC است.

فقط محتوای عمومی، API رسمی Telegram. دربارهٔ ما · پرسش‌ها · محدودیت‌های ایندکس · حذف یک صفحه · کاتالوگ · جست‌وجو · روش محاسبهٔ ما