1: Chunked LOD boru hattının hangi noktasında örgünün parçalara ayrıldığını anlayamıyorum. Bu, ilk mesh oluşturma sırasında mı yoksa bunu yapan ayrı bir algoritma var mı?
Sorun değil. Örneğin, parçaları ağ oluşturma algoritmanıza entegre edebilirsiniz. Plazma benzeri bir arıtma algoritması kullanarak daha düşük seviyelerin dinamik olarak (örn. Oynatıcı yaklaştıkça) eklenmesi için bunu dinamik olarak bile yapabilirsiniz. Ayrıca sanatçı giriş veya yükseklik ölçüm verilerinden yüksek çözünürlüklü bir kafes oluşturabilir ve bunu varlık sonlandırma zamanında tüm LOD parçalarına toplayabilirsiniz. Veya karıştırıp eşleştirebilirsiniz. Bu gerçekten uygulamanıza bağlıdır.
2: Chunked LOD verilerini saklamak için bir Quadtree veri yapısının kullanıldığını anlıyorum, sanırım noktayı biraz özlüyorum, ancak quadtree her alt bölüm seviyesi için köşe ve üçgen verilerini saklıyor mu?
Şart değil. Ağaç sadece geometri ve nasıl oluşturulacağı hakkında bilgi depolar. Bu, her ağaç düğümünde bir tepe / yüz listesine sahip olmak anlamına gelebilir. Daha gerçekçi bir şekilde bu gün ve yaşta, kafeslerin / örneklerin tutamaçlarını GPU belleğinde saklarsınız.
3a: Kamera mesafesi genellikle nasıl hesaplanır. Quadree'leri okurken Eksen hizalı sınırlama kutularından çok bahsedilir. Bu durumda, her bir yığının kamerayı veya oyuncunun yakında olduğunu algılamak için bir çarpışma sınırlayıcı kutusu olur mu? ya da bunu yapmanın daha iyi bir yolu var mı? (raycast belki?)
Çok ucuz ve kolay bir seçenek, parçanın merkez noktasına olan mesafeyi kullanmak ve daha sonra düzeltmektir. Bu mesafenin her zaman bir hafife alındığını biliyorsunuzdur: eğer merkez nokta uzaktaysa Z, bu, parçanın yarısının bundan daha yakın olduğu anlamına gelir. Ancak bilmediğimiz yönelim. wKenar genişliğinde bir yığın görüntülüyorsak, yığının en yakın biti mesafe olacakZ-w . Bununla birlikte, önce yığın köşesini görüntülersek, en yakın bit uzaktadır Z-sqrt(2)*w. Bu belirsizlikle yaşayabiliyorsanız (neredeyse her zaman yapabilirsiniz), işiniz bitti demektir. Temel trigonometri kullanarak görüntüleme açısını da düzeltebileceğinizi unutmayın.
Artefaktları en aza indirmek için kameradan parçaya olan mutlak minimum mesafeyi hesaplamayı tercih ederim. Pratikte, bu nokta-kare mesafe testi yapmak demektir . Merkez noktalara olan mesafeleri hesaplamaktan biraz daha fazla iş, ama her kareden bir milyonunu yapacağınız gibi değil.
Bunu yapmak için fizik motorunuzdan yararlanabiliyorsanız, elbette bunu yapın, ancak gerçekten "çarpışma" dan "mesafe sorgusu" açısından daha çok düşünmek istersiniz.
3b: Parçalar kamera mesafesini kendileri hesaplıyor mu?
Gerçekten motorunuzun tasarımına bağlıdır. Yine de yaprakları nispeten hafif tutmanızı tavsiye ederim. Platformunuza bağlı olarak, sadece birkaç bin arazi parçasının kendi güncellemelerini gerçekleştirmesi için çağrı yükü her kareyi performansı ciddi şekilde etkileyebilir.
4: Her yığın aynı "çözünürlüğe" sahip mi? örneğin üst seviyede ağ 32x32, alt bölümlere ayrılmış düğümler de 32x32 olacaktır.
Yapmak zorunda değiller, ancak tüm parçalar aynı miktarda yer kaplarsa uygundur. Ardından (GPU) bellek yönetiminizi "yığınlar" birimlerinde yapabilirsiniz. Bir çözünürlük diğerinin katlarıysa, daha fazla köşeyi paylaştıkları için farklı boyutlardaki iki parça arasındaki dikişleri çıkarmak / gizlemek de daha kolaydır. (örneğin: 32x32 ve 64x64'ün yönetimi 32x32 ve 57x57'den daha kolaydır) (teşekkürler Guiber!). Öbek geometri boyutunu değiştirmek için iyi bir nedeniniz varsa, elbette bunun için gidin.
