Varlık başına tek bir türün bir bileşenini kırmadan varlık başına birden çok kafes kullanabilirim?

11

Hiyerarşi tabanlı bir oyun motorundan bileşen tabanlı bir oyun motoruna geçiyoruz. Benim sorunum, kafes hiyerarşisi olan bir modeli yüklediğimde ve anladığım şekilde, bileşen tabanlı bir sistemdeki bir varlığın aynı türden birden fazla bileşene sahip olamayacağı, ancak her biri için bir "meshComponent "'e ihtiyaç duyduğu bir modelde örgü. Peki bu sorunu nasıl çözebilirim?

Bu sitede Bileşen tabanlı bir oyun motoru uyguladılar: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

architecture component-based

— Mathias Hölzl
kaynak

Bunun çok yerel olduğunu düşünüyorum.

— jcora

4

Bence bu genel bir soru. Bir oyun nesnesinin aynı bileşenin birden çok örneği olabilir mi?

— Mathias Hölzl

Evet, olabilirdi böyle soruldu, olmuştur. Bana göre sanki çok özel bir soruna cevap arıyormuş gibi görünüyor.

— jcora

4

"... bileşen tabanlı bir sistemdeki varlığın aynı türde birden fazla bileşeni olamaz ..." - neden olmasın?

— Den

Çok yerel olduğunu sanmıyorum. Örneğin UE3'te SkeletalMeshActorsadece bir tane var SkeletalMeshComponent. Bu, birçok farklı şekilde ele alınabilecek yaygın bir sorundur.

— sam hocevar

13

Position bileşeninizde, "Pozisyona sahip herhangi bir Varlığın bir ebeveyni olabileceği ve konumlarının ebeveynlerine göreli bir" ebeveyn / çocuk "mantığı olabilir. Aynı varlık üzerinde birden çok ağa sahip olmak yerine, her biri kendi ağına sahip birden fazla varlık oluşturabilir ve bunları birbirine bağlayabilirsiniz. Çocuk varlıkların ebeveyn olaylarını (veya varlıklar arasındaki iletişim için sahip olduğunuz herhangi bir sistemi) dinlemelerini ve buna göre tepki vermelerini bile sağlayabilirsiniz.

— Luke B.
kaynak

Bu yüzden bir varlık hiyerarşisine sahibim ve bu varlıkların bileşenleri var ve bunlar birbirine bağlı. O zaman hala Bileşen tabanlı bir oyun motoru mu =)

— Mathias Hölzl

@ MathiasHölzl bu bir soru mu? Bu tür bir hiyerarşi, OOP'deki sorunlu hiyerarşiyle aynı değildir. Bu sadece grafiksel bir hiyerarşidir, çocuk varlıkları işlevselliklerini ebeveynlerinden devralmaz ve size sorun çıkarmaz, bu genellikle yine de yapılır (işlenecek bir ağaç ağacına sahip olmak). Ayrıca, Asakeron'un probleminize cevabı ile gidebilirsiniz, bir Mesh listesi var, bunun nasıl sorunlu olduğunu görmüyorum. Belki sorunuzu anlamıyorum?

— Luke B.16

-1 Bunun gerçekten yol olup olmadığından emin değilim. İhtiyacınız olan şey, kafes hiyerarşisini işleyen bir bileşense, neden kafes hiyerarşisini içeren bir bileşen olmasın ModelComponent? Bir varlığı sadece bunun için bölmek soruna yanlış bir çözüm gibi gelebilir. Asakeron ve Byte56'nın cevaplarına bakınız.

— Laurent Couvidou

@LaurentCouvidou Birden fazla varlık kullanmanın neden yanlış olacağını anlamıyorum, benim için iyi bir çözüm gibi görünüyor. Kafeslerin bir listesine sahip olmak için farklı bir alternatif vermek istedim, ancak bir kafes listesinin de iyi bir çözüm olacağını kabul ediyorum.

— Luke B.17

@LukeB. Çünkü bu örgü grubu, AI, ses, fizik gibi bileşenlere sahip bir bütün olarak tek bir varlığa karşılık gelebilir ... Bunu yaparak bir sahne grafiği ve tüm tuhaflıkları ile sonuçlanırsınız.

— Laurent Couvidou

8

MeshComponent'iniz bir mesh listesi içerebilir. Motorunuzu nasıl uyguladığınızdan emin değilim, ancak bir sistem tüm kafesleri kolayca tekrarlayabilir ve kolayca çizebilir.

— Asakeron
kaynak

1

Bir kafes ayrıca dönüşüm, fizik, grafik gibi bileşenlere de sahiptir ...

— Mathias Hölzl

1

Öyleyse bir kafes bir varlık mı? Yoksa her şey bir bileşen midir? Gördüğüm, dönüştürdüğüm, fizik ve grafik, örgüde olmayan varlıktaki bileşenler olmalı, bir kafes sadece köşelerin bir açıklamasıdır.

— Luke B.16

1

Evet, bu bir bileşen olmalı, ancak bileşenlerin bileşenleri olamaz, bu nedenle model hiyerarşisini uygulamak zor.

— Mathias Hölzl

1

Daha iyi yanıtlar almak için motorunuzu nasıl geliştireceğiniz konusunda daha fazla bilgi vermeniz gerektiğine inanıyorum. Varlık Bileşen Sistemleri birçok şekilde uygulanabilir, bu konuda daha fazla bilgi için Kylotan'ın bu cevabına bakın.

— Asakeron

4

Kafes bileşenimi bir Kafes nesneleri listesi ile yaratacağım. Her kafes nesnesinin, bir ofset ile birlikte kafes verileri vardır. Çizim yaparken, çizim sistemi pozisyonu pozisyon bileşeninden alır, daha sonra kafes bileşenindeki her bir ağı pozisyon + ofsetinde çizer.

Her varlık için tek bir ağ bileşeniyle söylerken, ağ bileşeninizin içinde birden çok ağ olabilir.

— Michaelhouse
kaynak

1

TLDR: Bileşeni yaparak ile başlayacak birden mesh oluşur.

Kafes / malzeme çiftleri ile varlığın kendisi arasında başka bir dolaylama seviyesinin gerekli olduğu konusunda Asakeron / Byte56 / Laurent ile aynı fikirdeyim. GraphicsComponent'e köşe noktaları ve materyaller olarak bakmak yerine, onu son taramadaki piksel bloğu olarak düşünün - nasıl elde ettikleri / uyguladıkları bir uygulama detayı ve daha fazlası.

Projem için bunu çok düşündüm ve bence en uygun çözüm, geleneksel 'Model' nesnesinin işlevselliğinin çoğunu kapsayan GraphicsComponent'i çok daha yüksek bir bileşen haline getirmektir - çünkü bu işlev isteğe bağlı değildir! Bu çokgenleri sadece arabellek verilerinden çok daha fazla hale getirmek için ve gölgelendiriciye ihtiyaç vardır, örneğin:

Bahsettiğiniz pozisyon
Kaplama / Animasyon verileri
Geçerli Geçiş (örneğin iki geçişli alfa kullanılıyorsa)
Gölge döküm bilgisi (eğer yapıyorsanız)
İle ilgili bilgiler nasıl malzemeyi güncellemek ve ne zaman
Toplama işlevselliği

Ve bu sadece 3B varlıklar için, parçacık sistemleri, reklam panoları vb. Göz önünde bulundurulmadan, ancak hepsi sadece grafik / oluşturma kodu ile ilgilidir - fizik, ses veya komut dosyasını etkilemez, bu yüzden oturması mantıklıdır Grafik / İşleme bileşeni.

Sonunda:

Model : Entity, IHasGraphicsComponent, IHasSkeleton, IHasAnimationStore     //This is the 'game object' - it is passed to the GraphicsController
    ModelComponent : GraphicsComponent                      //This is the actual graphics component, used by the GraphicsController in the context of the game object.
        ModelComponentPart : GraphicsComponent              //This is also a graphics component
            Mesh                                        //These are implementation details
            Material
        ModelComponentPart : GraphicsComponent
            Mesh
            Material
    Skeleton
    Animations

Bunda:

Model, grafik bileşeni olan herhangi bir oyun öğesidir.
ModelComponent geleneksel Model ile benzerdir ve aslında 3D varlıklar içindir. GraphicsComponent denetleyicisi (Model-View-Controller desenini kullanırsanız), ne tür grafik öğesinin olduğunu bulmaktan ve doğru şekilde çizmekten sorumludur (ModelComponent'in GraphicsComponent'in bir alt sınıfı olduğunu unutmayın).

Ayrıca, her bir Grafik Bileşeni de bir Varlık ve Varlık Konum verilerini doğrudan tek bir yerde hesaplandığı için saklar, ancak fikir aynıdır: GraphicsComponent, sadece modellerden gelenleri değil, gerekli olan her şeyi - çizmek için gerekli.

— sebf
kaynak