Kısa bir süre önce orijinal OGL Redbook'u verdiğim birinden bir eğitim sitesine bu bağlantı verildi . Üçüncü başlık, tipik render yöntemi olarak glBegin () & glEnd () 'i unutmayı açıkça söylüyor. Redbook'un yöntemini öğrendim, ancak VBO'larda bazı faydalar görüyorum. Bu gerçekten gitmenin yolu mu ve eğer öyleyse, oluşturma kodunu ve daha sonraki gölgelendiricileri kolayca VBO'lara ve sonraki veri türlerine dönüştürmenin bir yolu var mı?
Yanıtlar:
Modern OpenGL'nin VBO'ları gitmenin yoludur, sabit işlevli şeyler (glBegin / glEnd ve aradaki şeyler dahil) 3.0'dan beri kullanımdan kaldırılmış ve 3.1'den beri kaldırılmıştır.
OpenGL Çekirdek Profili, OpenGL ES 2.0+ ve WebGL ile eski öğelere bile erişemezsiniz.
Bazı insanlar önce eski şeyleri öğrenmenin daha iyi olduğunu düşünür, çünkü biraz daha kolaydır, ancak öğrendiğiniz şeyler çoğunlukla işe yaramaz ve daha sonra öğrenmeniz gereken şeyler.
Bu sadece VBO'lar değil, her şey için gölgelendiriciler kullanmanız ve matris dönüşümlerini kendiniz yapmanız (veya GLM kullanmanız) gerekir.
Eski şeyleri kullanmanın tek nedeni, 2.0'dan önce OpenGL'yi hedeflemek istiyorsanız olabilir. 1.5 olan birkaç gerçekten berbat gömülü netbook yonga seti var, ancak 1.5 bile VBO'ları desteklemiyor. Veya sabit işlev kanalına dayanan OpenGL ES 1.x (örneğin eski iPhone'larda kullanılır). Veya OpenGL SC (kritik güvenlik sistemleri için).
Aşağıdaki yaygın olarak kullanılan işlevlerin tümü kullanımdan kaldırılmıştır:
opengl-tutorial.org öğreticiler ne düşünüyorum OpenGL öğrenme gitmek için en iyi yoldur var. Bazı eski uyumluluk konularına güveniyorlar, ama aslında size öğretmiyorlar. Örneğin, gölgelendirici olmadan hiçbir şey işlememeniz gerekiyordu, ancak işe yarıyor. Ve matris işlemlerini (döndürme, çevirme vb.) Kendiniz halletmeniz gerekir, ancak varsayılan olarak temel bir düz 2B görünüm alanı elde edersiniz.
Kullanımdan kaldırılmış şeylerden kaçınmanın yanı sıra, OpenGL kodlamasını çok daha hoş hale getiren bir dizi işlev vardır, ancak birçoğu ile OpenGL'nin yeni 3.x + sürümlerini ve uyumlu donanımı gerektirip istemediğinize karar vermeniz gerekir.
Burada yaptığım bir gönderide daha fazla bilgi var .
Herhangi bir nedenle eski OpenGL'yi desteklemeniz gerekiyorsa, mümkün olduğunda VBO'ları kullanabilirsiniz ve olmadığında, köşe verilerinizde glBegin / glEnd ve döngüler kullanan bir geri dönüş sağlayabilirsiniz.
Öte yandan, eski oluşturma kodunu dönüştürmek için gerçek bir 'kolay' yol yoktur. Belki de bir diziye / vektöre köşeleri ekleyen ve daha sonra onu bir VBO'ya döker ve sahte glEnd çağrıldığında onu çizen işlevlerin kendi sürümünü uygulayabilirsiniz. ancak bu, her karede yapacağı için çok verimsiz olurdu (yalnızca bir kez yapmak için bir onay vermezseniz, ancak bu animasyonlu nesneler için işe yaramazsa) ve muhtemelen sadece VBO'lara geçiş yapan daha fazla çalışma olurdu. Sanırım bu yaklaşımın işe yarayabileceği çok fazla kodunuz varsa.
VBO'lar ile genellikle iki önemli avantajınız vardır.
Avantaj 1, tamamen statik verilerle ilgilidir ve tepe noktası verilerinizi GPU için daha uygun olan bellekte tutabilmekten gelir.
Avantaj 2, dinamik verilerle ilgilidir ve tepe noktası verilerinizi oluşturma için kullanmadan önce herhangi bir zamanda belirleyebilmekten gelir ve bu da daha iyi boru hattı oluşturabilir.
Üçüncü bir avantaj, beraberlik çağrı toplu işleminden gelir, ancak eski okul köşe dizileriyle de paylaşılır, bu yüzden özellikle VBO'lar için çağırmıyorum. GPU'ya veri göndermek (veya zaten GPU'da veri kullanmak) disk G / Ç ve ağ trafiğine birçok yönden benzer - birkaç büyük partiniz varsa birçok küçük partiden daha verimlidir.
Bunun için iyi (% 100 doğru değil, fikir edinmenize yardımcı olacak kadar) bir benzetme, bir şehirden diğerine 50 kişi getirmek zorunda olan bir otobüs şoförüyseniz. Bunları birer birer yükleyebilir ve 50 ayrı seyahat yapabilirsiniz - bu glBegin / glEnd. Alternatif olarak, bunların 50'sini otobüse koyabilir ve sadece tek bir yolculuk yapabilirsiniz - bu, tepe dizileri veya VBO'larla toplu iş yapar (VBO durumunda 50 kişi zaten otobüste olurdu;)).
Bu bir fiyata geliyor ve burada fiyat, köşe verilerini istediğiniz gibi ve ne zaman belirtebileceğinizi kaybetmenizdir. Tamam, bunu yapabilirsiniz (bazı ek çalışmalarla), ancak tüm performansı kodunuzdan çıkarmayacaksınız. Bunun yerine, köşe verileriniz, nasıl kullanıldığı, nasıl (ve eğer) güncellenmesi gerektiği, gölgelendiricide herhangi bir animasyonun yapıp yapamayacağı hakkında daha fazla düşünmeniz gerekir (böylece verilerin statik kalmasını sağlar - VBO'lar gerçekten çok sayıda animasyon vakası) veya her çerçevede köşe verisine saygı duymanız gerekip gerekmediği, ikincisi varsa etkili güncelleme stratejileri vb. yapmazsanız ve sadece naif bir dönüşüm uygularsanız, sadece sonuçta aslında daha yavaş çalıştırmak için bir sürü işte!
Bu, ilk karşılaştığınızda çok fazla iş gibi görünebilir, ama gerçekten değil. Böyle düşünme moduna girdiğinizde, bunun inanılmaz derecede kolay olduğunu ve neredeyse doğal olarak geldiğini göreceksiniz. Ancak ilk birkaç denemenizi berbat edebilirsiniz ve eğer öyleyse cesaretiniz kırılmamalıdır - berbat etmek yanlış yaptığınız şeyi öğrenmek için bir fırsattır.
Birkaç son düşünce.
Model verilerinizin VBO'ya kolayca yüklenebilecek bir biçimde olması, tüm bu işlemi sizin için çok daha kolay hale getirebilir. Bu, en azından ilk başta (ve işlemden daha rahat olana kadar) daha karmaşık veya egzotik formatlardan kaçınmanız gerektiği anlamına gelir; öğrenirken işleri olabildiğince basit ve basit tutun ve yanlış gitmek için daha az şey ve yanlış gittiğinde (veya ne zaman!) hata aramak için daha az yer olacaktır.
İnsanlar bazen optimize edilmiş / sıkıştırılmış glBegin / glEnd uygulamasından daha fazla bellek kullanan bir VBO uygulaması görürlerse ertelenir (hatta "atık" olarak da adlandırılabilir). Böyle olma. Aşırı durumlarda dışında, bellek kullanımı gerçekten değil o önemli. Burada açık bir denge - önemli ölçüde daha yüksek performans karşılığında potansiyel olarak daha yüksek bellek kullanımını kabul ediyorsunuz. Ayrıca, hafızanın kullanılabilecek ucuz ve bol bir kaynak olduğu fikrini geliştirmeye yardımcı olur; performans değildir.
Ve son olarak eski kestane - zaten yeterince hızlıysa, işiniz yapılır. Hedef kare hızınızı vuruyorsanız, geçici koşullar için boşluk varsa, o zaman yeterince iyidir ve bir sonraki adıma geçebilirsiniz. Gerçekten ihtiyaç duymayan bir şeyden% 10 daha fazla sıkarak çok fazla zaman ve enerji harcayabilirsiniz (orada bulunmuş, bunu yapmış, yine de tuzağa düşüyor), bu yüzden her zaman kendi zamanınızın en uygun kullanımının ne olduğunu düşünün - çünkü programcı zamanı performanstan daha ucuz ve daha az bol!