Fizik debug: görünmez dünyanın vizörünü açmak

Oyuncu yalnızca shader ve doku ile süslenmiş yüzeyi görür; motor ise çoğu zaman daha kaba bir geometri üzerinde kuvvet hesabı yapar. Debug modu açıkken, bu ikinci katman üst üste bindirilir: genelde wireframe kutu/küre/kapsül hatları, bazen çok yüzlü kabukların sadeleştirilmiş tel örnekleri.

Amaç estetik değil, kanıt üretmekdir: “çarpışma neden burada?” sorusunun cevabı, çoğu zaman bu çizgilerde gizlidir.

Bir önceki bölümde debug katmanının ne olduğunu sabitledik; burada hangi sınıf sorunlarda devreye girdiğini ayırıyoruz. Üç başlık birbirini tamamlar: geometrik doğruluk (hizalama), oynanış hissi (hitbox), maliyet keşfi (sahadaki kabuk ağırlığı). Aşağıdaki paragraflar, bölüm 4’teki belirti listesini önden çözümlemez; yalnızca “neden şimdi bakmalıyım?” sorusuna cevap verir.

Hizalama hataları

Model pivotu ile gövde merkezinin kayması, zeminden milimetre yüzen veya duvara gömülen görünümler üretir. Tel katman, mesh silueti ile kabuğun aynı anda görülmesini sağlar; kayma anında ortaya çıkar.

Pratikte hata yalnızca “yanlış konum” değildir: birim ölçek (ör. model FBX’te 100, fizik dünyasında 1), üst düğümün dünya matrisi ile gövde kaydının farklı güncellenmesi veya eksen/yön (Y-up / Z-up) uyumsuzluğu aynı semptomu üretebilir. Debug çizgisi, tartışmayı “motor mu yanlış, dışa aktarım mı?” diye ikiye böler: tel hat ile doku yüzeyi ayrılıyorsa sorun çoğu zaman aktarım katmanındadır.

Hitbox genişliği

Çarpışma alanı çok genişse “havada asılı” tepkiler; çok darsa görünür temasın sayılmaması görürsünüz. Debug, kabuğun gerçekten nerede bittiğini tartışmadan gösterir.

Oyuncu hissi ile motor sözleşmesi arasındaki boşluk burada yönetilir: bileşik (compound) şekillerde alt parçaların ofseti, “sensör” (sensor) ile katı gövde ayrımı veya temas marjı / hafif gömülme (penetration tolerance) ayarları, ekranda aynı modeli gösterirken farklı davranış üretir. Tel çerçeve, hangi alt kabuğun devreye girdiğini tartışma odasına taşımadan ortaya koyar.

Performans denetimi

Her modele ağır convex hull veya gereksiz çokgen kabuk bağlandığında sahnede “sessiz” CPU maliyeti büyür. Tel önizleme, hangi bölgenin gereğinden karmaşık olduğunu sahada seçmenize yardım eder — ölçüm ekranına dönmeden önce ilk eleme burada yapılır.

Buradaki bakış, bölüm 5’teki “çizimlerin kendisi pahalıdır” uyarısından farklıdır: o, yardımcı geometrinin çizim yükünü; bu başlık ise sahnedeki fizik temsilinin ağırlığını hedefler — örneğin üçgen ağına yakın mesh temelli kabuklar veya çok sayıda küçük gövdenin ürettiği aday çift patlaması. Tel hatlar, profil öncesi “şüpheli yoğunluk” haritası çıkarmanızı sağlar.

Cannon.js, Ammo.js, Rapier gibi motorların çoğu, sahnede çizim üreten bir debug renderer / physics debugger yolunu sunar; isimler değişir, fikir aynıdır: simülasyon dünyasını ince çizgilerle “üstte” okunur hâle getirmek.

Aşağıdaki üç başlık, önceki bölümdeki “neden bakıyorum?” sorusunun ardından gelen nasıl okuyorum? katmanıdır; burada belirti çözümlemesi (4) yoktur — yalnızca yardımcıların ne anlattığı ayrıştırılır.

Wireframe kutular / küreler

Gövde sınırlarını gösterir; dinamik ve statik gövdeleri farklı renklerle ayırmak üretimde hızlı tarama sağlar.

Bileşik gövdelerde aynı nesne için birden fazla tel hacim üst üste gelebilir; bu, hatayı büyütmek değil, parçaların birbirine göre ofsetini doğrulamaktır. Uyku (sleep) durumuna geçmiş dinamikler için bazı motorlar soluk renk veya gizleme kullanır — “fizik hâlâ var ama entegrasyon durdu” ayrımını hızlıca görürsünüz.

Temas noktaları (contact points)

İki nesne değdiği anda, temasın hangi uzaysal bölgede üretildiğini küçük nokta veya ok ile işaretler — “çarpışma var ama nerede?” sorusunu somutlaştırır.

Çoğu motor, temas normali ve kısa bir ayırma (separation) vektörüyle birlikte çizer; bu, yüzeyin “içeriden mi dışarıdan mı” itildiğini ayırt etmeyi kolaylaştırır. Birden fazla temas noktası (contact manifold), özellikle kutu–zemin temasında stabiliteyi gösterir: tek noktadaysa denge kolayca savrulur.

Hız vektörleri (velocity vectors)

Nesnenin hangi yöne, ne büyüklükte hareket ettiğini gösterir; beklenmeyen süzülme veya takılı sürtünme gibi sapmaları hız alanından okumak kolaylaşır.

Çizilen ok genelde doğrusal hız içindir; dönüş için ayrı bir angular velocity göstergesi varsa, “neden yan yatıyor ama ileri gitmiyor?” sorusu iki vektörün birlikte okunmasıyla açılır. Uzayı yanlış seçmek (dünya yerine gövde uzayı) okların saçma yöne bakmasına yol açar — bu da yine hizalama tarafına işaret eder, motorun kendisine değil.

Mod açıkken “görünmeyen” hatalar çoğu zaman çizgi davranışına dökülür.

Önceki bölüm yardımcıların dilini öğretti; burada ise tel çizgilerin hikâyesi okunur: aynı desen tekrarlanıyor mu, aniden kesiliyor mu, yoksa boş sanılan yerde mi başlıyor? Aşağıdaki üç başlık tipik senaryolardır — kök neden listesi değil, görünür imza rehberidir; zamanlama ve köprü sırası için entegrasyon · senkronizasyon köprüsü ayrı bir tablodur.

Jittering (titreme)

Nesne zeminde mikro zıplıyorsa, temas noktalarının sürekli oluşup kaybolduğunu veya normal yönüyle oynadığını görebilirsiniz — çözücü adımı, sürtünme veya dinamik/statik etiket hatası burada su yüzüne çıkar.

İmza ayrımı: titreme bazen çözücü salınımıdır (penetrasyon derinliği ile restitution birlikte “fazla düzeltir”), bazen de çift otoritedir — aynı karede hem animasyon hem fizik konumu yazılıyorsa tel hat ile doku aynı ritimde titrer. Sürtünme çok düşükse ayak kayar; çok yüksekse mikro sıkışmada takılır; ikisi de temas noktası yoğunluğunda farklı desen verir.

Tunneling (tünelleme)

İnce duvardan “sızmış” gibi görünen hızlı cisimlerde, tel hatların kareler arası sıçraması, sürekli temas yerine ani konum sıçramasını kanıtlar; CCD veya adım politikası tartışmasına zemin hazırlar.

Burada bakılacak şey yalnızca hız değildir: kabuk kalınlığı ile Δt içinde alınan yolun oranı kritiktir. Tel kutu bir karede duvarın önünde, bir karede arkasındaysa, motor o ara sürede kesişimi hiç üretmemiş olabilir; bu, görsel mesh’in hâlâ duvarda görünmesinden bağımsız bir “kanıt”dır.

Hayalet çarpışmalar (ghost collisions)

Gözle boş sanılan yerde duran cisim, çoğu zaman silinmemiş veya yanlış yerde kalmış statik bir gövdedir; debug çizgisi “burada hâlâ katılık var” der.

Görünmezlik çoğu zaman sahne grafiği ile dünya kaydının ayrışmasından gelir: mesh gizlendi ama gövde dünyada kaldı; veya aynı mantıksal nesne için iki kez gövde açıldı ve biri ofiste kaldı. Katman maskeleri görseli gizlerken fizik sorgusunu gizlemeyebilir — tel hat, “fizik tarafında hâlâ buradasın” uyarısını taşır.

Yardımcı çizimlerin kendisi de CPU ve GPU bandını kullanır; özellikle yüzlerce gövde tel çizildiğinde kare süresi belirgin biçimde kötüleşebilir.

Kritik kural: Görselleştiriciler yalnızca geliştirme ortamında açık olmalı; üretim derlemesinde bu kodların tamamen dışlanması (tree-shaking / bayrakla ölü dal) veya tek bir boolean ile kapalı tutulması gerekir. Sorun yaşanan bölgeye odaklanarak (yalnız ilgili gövdeleri çizmek) debug süresini kısaltmak, en az sonuç kadar disiplinli bir yaklaşımdır.

Holodepth geliştirme alışkanlığında, sahneyi gezerken F3 veya ~ gibi bir tuşla debug katmanını anında açıp kapatmak (toggle), geliştirici deneyimini ciddi biçimde iyileştirir: aynı saniyede hem “oyuncu gözü” (estetik) hem “mühendis gözü” (matematiksel katılık) arasında geçiş yaparsınız.