Oyunda grafikler ve fizik motoru arasında veri paylaşmalı mıyım?

Birkaç modülden oluşan oyun motorunu yazıyorum. Bunlardan ikisi grafik motoru ve fizik motorudur .

Aralarında veri paylaşmak iyi bir çözüm mü?

İki yol (paylaşıp paylaşmama) şöyle görünür:

Veri paylaşmadan

GraphicsModel{
    //some common for graphics and physics data like position

    //some only graphic data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
    //some common for graphics and physics data like position

    //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data 
//e.g. update graphics model's position when physics model's position will change

İki ana sorun görüyorum:

1. Çok fazla veri (hem fizik hem de grafik verileri için iki konum gibi)
2. Veri güncelleme sorunu (Fizik verileri değiştiğinde grafik verilerini manuel olarak güncellemem gerekiyor)

Veri paylaşımı ile

Model{
     //some common for graphics and physics data like position
};

GraphicModel : public Model{
    //some only graphics data 
    //like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
     //some only physics data 
    //usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assingModel3D(&model); //will cast to 
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model 
//(which it treats like PhysicsModel), the position for graphics data 
//will change as well (because it's the same model)

Buradaki sorunlar:

1. PhysicsEngine yeni nesneler oluşturamaz, sadece engine3D'den mevcut olanları "atar" (bir şekilde benim için daha anti-bağımsız görünüyor)
2. AssingModel3D işlevinde veri yayınlama
3. PhysicsEngine ve graphicsEngine dikkatli olmalıdır - ihtiyaç duymadıklarında verileri silemezler (çünkü ikincisine ihtiyaç duyabilir). Ancak bu nadir bir durumdur. Dahası, sadece işaretçiyi silebilirler, nesneyi değil. Veya graphicsEngine nesnelerini sileceğini varsayabiliriz, physicsEngine sadece onlara işaret eder.

Hangi yol daha iyi?

Hangisi gelecekte daha fazla sorun yaratacak?

İkinci çözümü daha çok seviyorum, ama çoğu grafik ve fizik motorunun neden ilkini tercih ettiğini merak ediyorum (belki de normalde sadece grafik veya sadece fizik motoru yapıyorlar ve birileri oyuna bağlanıyor?).

Daha gizli profesyoneller ve kontratlar var mı?

Günümüzde, daha fazla oyun motoru bir bileşen tasarımı benimser (örneğin Unity, Unreal). Bu tür tasarımda a GameObject, bileşenlerin bir listesinden oluşur. Durumunuzda, her ikisi de tek bir oyun nesnesine bağlanan a MeshComponentve a olabilir PhysicalComponent.

Basitlik için, bir dünya dönüşüm değişkenini GameObject. Güncelleme cümlesi sırasında PhysicalComponent, dünya bu değişkene dönüşür. Oluşturma sırasında MeshComponentbu değişkeni okur.

Bu tasarımın arkasındaki mantık bileşenler arasında ayrıştırmaktır. Ne MeshComponentne de PhysicalComponentbirbirini tanıyor. Bunlar sadece ortak bir arayüze bağlıdır. Ve sistemi tek bir miras hiyerarşisi kullanmaktan ziyade kompozisyonla genişletmek daha kolay olabilir.

Ancak gerçekçi bir senaryoda, fizik / grafik senkronizasyonu arasında daha karmaşık bir işleme ihtiyacınız olabilir. Örneğin, fizik simülasyonunun sabit zaman adımında (ör. 30Hz) çalıştırılması gerekebilir, bununla birlikte oluşturma değişken olmalıdır. Ve fizik motorunun çıktısından elde edilen sonuçları enterpolasyonlamanız gerekebilir. Bazı fizik motorları (örneğin Bullet) bu konuyu doğrudan destekliyor.

Birlik, bileşenlerine iyi bir referans verdi , ki bu da görülmeye değer.

Motorlar genellikle birinci seçeneği (kendi fizik ağı ve kendi render ağı) seçerler çünkü hem kalite hem de miktar bakımından çok farklı verilere ihtiyaç duyarlar.

Kalite, çünkü fizik motoru doku koordinatlarını, normal grupları ve tüm bu süslü şeyleri umursamıyor. Her biri, hizalama sorunları, paketleme, verilerin harmanlanması vb. Gibi çok özel bir düzende veri bekler .

Miktar, çünkü fizik ağının genellikle daha az üçgenleri vardır, yüksek çözünürlüklü render ağının basitleştirilmiş bir versiyonu.

Her ikisini de birbirinden ayırarak, birini daha iyi performans için veri düzenini değiştirmek de dahil olmak üzere diğerini bozmadan tweek yapabileceğimizden emin oluruz. Çok daha ölçeklenebilir.

@Millo Yip harika cevabının yanı sıra size Kontrol Verileri modülü ve AI modülü ile aynı verileri paylaşmanız gerektiğini hatırlatmak isterim ve yanılmıyorsam çoğu ses kütüphanesinde ses yayıcısının konumu hakkında bir fikir vardır böylece verileri bu modülle paylaşmanız gerekir.

Diğerlerinin söylediği gibi, fiziğin dahili veri durumunun, oluşturma motorunun dahili veri durumundan ayrı olarak yönetilmesi oldukça yaygın bir yerdir. Hem fizikten hem de yenilenebilirliklerden ayrı olarak depolanan dönüşüm verilerinin (konum / yönlendirme / ölçek) bile görülmesi genellikle yaygındır, çünkü fizik tarafından empoze edilmeyen veya oluşturulmayan ancak diğer mekanikler için bir dünya pozisyonu gerektiren bir oyun nesnesi vardır.

Verilerin fizikten yenilenebilirliğe nasıl ulaştığı tamamen size bağlıdır.

Bunu, olayları / iletileri kullanarak bazı alt sistemler arası gönderme işlemi ile yapabilirsiniz. Bunu, render alt sisteminin genel bir arayüzünü fizik alt sistemine maruz bırakarak yapabilirsiniz; böylece fizik, özellikle yenilenebilir bir konum belirleyebilir. Başka bir seçenek de, yenilenebilir alt sistemin güncelleme sırasında varlığı dönüşüm için sorgular ve okunabilir bileşenin konumunun güncellenmesini ve ardından çizimi gerçekleştirmesidir.

Doğal olarak, oyununuza bağlı olarak bu araçlardan birkaçı önbellek dostu olacak ve diğerlerinden daha iyi performans gösterecektir. Bu noktada belirli bir şekilde çok fazla yakalanmam ve bir iletişim modeli seçip denemem. Çeşitli optimizasyon araçlarını test etmek için bu bölümü daha sonra kolayca yeniden çalışabilirsiniz.