holodepth

3D Model Formatları · OBJ · OBJ vs glTF

Performans: Zaman Çizelgesinde İki Yükleme Hikâyesi

«Aynı üçgen, biri 2 sn'de sahneye geldi, diğeri 200 ms» sihirli GPU değil; metin parse ile binary kopyanın farkıdır. Özellikler menüyü kapattı; bu sayfa: OBJ ile glTF'i indirme–parse–GPU–kare maliyeti üzerinden kıyaslar.

Holodepth'te performans kıyası, glTF Runtime Performansı'ndaki draw call / materyal birim derinliğini kopyalamaz; OBJ Büyük Dosya'daki ASCII vergi dersini de tekrar etmez. Burada soru şudur: zaman çizelgesinin hangi diliminde iki format ayrışır, adil ölçüm nasıl yapılır, ilk kare sonrası ne zaman eşitlenir? Modern ürün seçimi sonraki sayfada kalır.

Sayfayı bitirdiğinizde şu cümleyi kurabilmelisiniz: «OBJ maliyeti çoğu zaman CPU parse + string→float'tadır; glTF maliyeti buffer kopyası ve (varsa) decode'dadır. gzip transferi OBJ'yi affettirir, parse'ı silmez. Aynı topoloji yüklendikten sonra durağan çizim benzer olabilir. Skin/clip yalnızca glTF yolunda ekstra maliyet açar. Ölçümü dilimlere ayırın; tek FPS sayısı yetmez.»

Bu sayfanın sınırı · komşu konularla ayrım

Bu sayfa OBJ ↔ glTF zaman / yükleme performansı kıyasını anlatır:

  • Zaman dilimleri (transfer, parse, GPU, kare)
  • Adil ölçüm ve yanılsamalar
  • İlk kare vs sürekli kare
  • Ne zaman OBJ «yeterince hızlı»
  • Holodepth teşhis açıları

Bilinçli olarak dışarıda bırakılan konular:

Kısa ayrım: Bu sayfa «iki formatın zaman hikâyesi» · glTF Runtime «glTF sahnesi nasıl pahalılaşır?» · Dosya Boyutu «bayt kıyası»

Dört dilimli kronometre

Tek «yavaş» şikâyeti dört dilime ayrılmadan çözülmez:

  1. Transfer: ağdan inen süre (gzip/br dahil)
  2. Parse / decode: dosyadan bellek yapılarına
  3. GPU upload: buffer/texture oluşturma
  4. Kare: her frame CPU+GPU (durağan veya animasyonlu)

Maratonda «kaçıncı kilometrede düştün?» bilmeden antrenman planı yazılmaz. Format kıyası da dilimsiz olmaz.

OBJ'nin ağır dilimi: parse vergisi

OBJ satır satır metindir. Loader her v/f için string ayırır, float parse eder, indeksleri çözer. Köşe sayısı arttıkça bu iş CPU'da doğrusal (veya daha kötü) büyür. glTF'de aynı konumlar çoğu zaman zaten binary typed array'e yakındır; iş kopya + (isteğe) Draco decode'dur.

Holodepth kıyas kuralı: dense mesh'te OBJ aleyhine asıl uçurum genelde dilim 2'dedir. Dilim 1 gzip ile kapanmış görünebilir; dilim 2 kapanmaz.

glTF yolu: kopya, decode, sahne kurulumu

GLB tek istek + binary chunk hızlı başlangıç sağlar. Maliyet kayabilir: Draco CPU decode, KTX2 GPU transcode, çok materyal / çok primitive sahne kurulumu. Bunlar glTF Runtime sayfasının konusudur; kıyas için bilinmesi gereken: glTF «her zaman sıfır maliyet» değildir, ama tipik web mesh'te parse vergisi OBJ'den düşüktür.

Animasyonlu / skinned varlıkta glTF ek dilimler açar (joint palette, mixer). OBJ bu yarışa hiç girmez; özellik menüsü kapalıdır.

Yükledikten sonra: ne zaman eşitlenir?

Aynı topoloji, aynı materyal karmaşıklığı, durağan mesh: GPU'da çizim maliyeti çoğu zaman format bağımsız yakınsar. OBJ ile glTF'in farkı «sürekli 60 FPS»te değil, ilk görünür kareye kadardır.

Eşitlemeyi bozanlar: farklı materyal sayısı, farklı texture formatı, birinde skin/clip açık oluşu, birinde fazla draw call üreten parçalama. Bunlar özellik + sahne düzeni farkıdır; «OBJ yavaş format» diye etiketlenmemeli.

Adil ölçüm disiplini

  1. Aynı cihaz / ağ profili (veya throttling sabit)
  2. Aynı topoloji ve doku seti (Dosya Boyutu adil kuralları)
  3. Dilim dilim süre: TTFB→download, parse, GPU, first paint
  4. Soğuk önbellek vs sıcak önbellek ayrı satır
  5. Worker'da parse varsa not edin (OBJ'yi iyileştirir, sihir değildir)
  6. Tek FPS ortalaması ile karar vermeyin

«OBJ 10 FPS, glTF 60 FPS» iddiası çoğu zaman farklı sahne veya animasyon farkıdır. Kronometre notu olmadan çürütün.

Yanılsamalar

  • gzip zaferi: transfer kısaldı, parse aynı kaldı
  • DevTools FPS: idle sahne; yükleme dilimi görünmez
  • Küçük prop: fark eşiğin altında; formatı perf ile seçmeyin
  • Çoklu OBJ: N istek + N parse; toplam tek GLB'den kötü
  • «Worker'da çözülür»: ana iş parçacığını kurtarır, toplam işi silmez; mobil batarya hâlâ öder

Ne zaman OBJ performansı kabul?

  • Düşük poli prop / eğitim demosu
  • Yerel veya önceden önbellekli tek seferlik yükleme
  • İlk kare SLA'sı gevşek (dahili araç)
  • Özellik menüsü zaten OBJ'de bitiyor

Mobil vitrin, çoklu model, sık soğuk yükleme, dense scan: OBJ parse vergisi ürün riskidir. Publish glTF; OBJ handoff'ta kalsın.

Karar iskeleti (zaman KPI)

  1. Hangi dilim SLA'yı kırıyor? (1–4)
  2. Dilim 2 baskın + dense mesh → glTF/GLB
  3. Dilim 1 baskın → boyutu / CDN'i de tart (Dosya Boyutu)
  4. Dilim 4 baskın + durağan → materyal/draw; format ikincil
  5. Dilim 4 + skin/clip → zaten glTF menüsü
  6. Eşik altı fark → iş akışı / özellik kazansın

Holodepth perspektifleri

Laboratuvar tuzağı

Masaüstü fiber + sıcak cache ile «OBJ de hızlı» demek, mobil 4G soğuk açılışı temsil etmez. Profilü yazın.

Ana iş parçacığı

Uzun OBJ parse scroll/input'u dondurur. Kullanıcı «site dondu» der; FPS sayacı henüz başlamamıştır. First input delay ile birlikte düşünün.

Teşhis maddeleri

  1. Dört dilim ölçüldü mü?
  2. Kapsam / topoloji eşit mi?
  3. gzip yanılsaması var mı?
  4. İlk kare mi, sürekli kare mi şikâyet?
  5. Özellik farkı (skin vb.) karışıyor mu?
  6. Hedef cihaz profili gerçekçi mi?

Holodepth içgörüsü

Performans tartışmasında önce hangi kilometrede olduğunuzu sorun. OBJ çoğu zaman parse kilometresinde kaybeder; finish çizgisinde (durağan FPS) fark kapanabilir. Yanlış dilime ilaç yazmayın.

Kronometre net; sırada ürün seçimi

Boyut, özellik ve performans kıyasları tamamlanmaya yaklaştı. Son sayfa bunları 2020'ler ürün dilinde birleştirir: Modern Kullanım.

Format okuyucusu özeti: OBJ parse vergisi öder; glTF kopya/decode öder. gzip yanıltır. Yükledikten sonra durağan çizim yakınsayabilir. Dilim dilim ölçün; tek FPS ile karar vermeyin.