IFC'den XKT'ye: Mobilde Akıcı BIM Görüntülemenin Arkasındaki Dönüşüm

Bir BIM modelini masaüstünde açmak ile aynı modeli sahada bir tablette akıcı şekilde döndürebilmek, birbirinden bambaşka iki mühendislik problemidir. Masaüstü tarafında bol RAM, güçlü bir geometri çekirdeği ve ayrık bir GPU vardır; parse süresi biraz uzasa da tolere edilir. Mobil/web tarafında ise WebGL bağlamı, sınırlı bellek ve enerji bütçesiyle çalışırsınız. İşte tam bu noktada ham IFC dosyasını doğrudan istemciye taşımak yerine, onu önceden işlenmiş, GPU-dostu bir formata dönüştürmek devreye girer. Bu yazıda IFC’nin neden mobilde ağır kaldığını, XKT (xeokit’in yerel formatı) yapısını ve dönüşüm hattında koordinat/ölçek/nicemleme kaynaklı klasik tuzakları anlatıyorum.

IFC neden mobilde ağır kalır?

IFC, çoğunlukla STEP fiziksel dosya formatında (ISO 10303-21) saklanır; yani düz metin. Her satır bir #123= IFCEXTRUDEDAREASOLID(...) gibi bir kayıttır ve nesneler birbirine ID referanslarıyla bağlanır. Bunun üç somut maliyeti var:

Metin ayrıştırma maliyeti: Onlarca/yüzlerce MB metni tokenize edip nesne grafiğini bellekte kurmak, tek başına ciddi CPU zamanı ister.
Örtük (parametrik) geometri: IFC geometrisinin büyük kısmı hazır mesh değildir. IfcExtrudedAreaSolid, IfcBooleanClippingResult, sweep’ler, B-rep’ler… Bunların ekranda üçgen olabilmesi için bir geometri çekirdeğiyle tessellate edilmesi gerekir. Bu, dönüşümün en pahalı adımıdır.
Tekrar (redundancy): Aynı kolon, aynı kapı tipi modelde yüzlerce kez geçer ama geometri paylaşımı IFC’de garanti değildir.

Kısacası ham IFC, “görüntülemeye hazır” bir format değil, “veri alışverişine yönelik” bir formattır. İstemcide her açılışta tessellation tekrarlamak, mobilde kabul edilemez.

XKT ne yapıyor?

XKT, xeokit’in ikili (binary) yerel formatıdır ve tek bir amacı vardır: büyük modelleri tarayıcıda hızlı yükleyip çizmek. Dönüşüm hattı geometriyi bir kez işler ve sonucu istemcinin neredeyse doğrudan GPU’ya besleyebileceği hâlde saklar. Temel teknikler:

Önceden tessellate edilmiş geometri: Örtük geometri dönüşüm anında üçgenlere indirgenir; istemci artık geometri çekirdeği çalıştırmaz.
Nicemleme (quantization): Vertex pozisyonları float yerine 16-bit tamsayı olarak, bir sınırlayıcı kutuya (AABB) göre saklanır. Normaller oct-encoding ile 8-bit’e indirilir. Bu, bellek ve dosya boyutunu belirgin biçimde düşürür.
Geometri paylaşımı / instancing: Tekrarlanan geometri bir kez saklanıp çok sayıda nesne tarafından referanslanır.
Sıkıştırma: Nicemlenmiş diziler deflate tabanlı bir şemayla sıkıştırılır; ağdan geçen ve diske yazılan hacim küçülür.

Boyut	IFC (STEP)	XKT
Kodlama	Metin (ISO 10303-21)	İkili (binary)
Geometri	Çoğunlukla örtük/parametrik	Önceden tessellate edilmiş üçgen mesh
Vertex tipi	Kavramsal olarak double	16-bit tamsayı (nicemlenmiş) + dekuantize matris
Amaç	Veri alışverişi	Hızlı görüntüleme
İstemci maliyeti	Parse + tessellation	Dekode + GPU’ya yükleme
Semantik	Tam BIM veri modeli	Görüntüleme + hafif metadata

Önemli bir nokta: XKT bir BIM veri modeli değildir. Tam nitelik/ilişki setini (IFC’nin IfcRelDefinesByProperties vb.) taşımaz; görüntüleme için gereken hiyerarşi ve hafif metadata’yı taşır. Zengin sorgular hâlâ IFC/veritabanı tarafında yapılır.

Dönüşüm hattı

Kavramsal akış şöyledir:

IFC (STEP)
  -> parse (ör. web-ifc / IfcOpenShell çekirdeği)
  -> örtük geometriyi tessellate et  (extrusion, B-rep, boolean -> üçgenler)
  -> birim ölçeğini uygula           (IfcUnitAssignment: mm/m -> hedef birim)
  -> koordinatları merkeze taşı      (RTC: büyük harita ofsetini çıkar)
  -> pozisyonları AABB'ye göre 16-bit nicemle + normalleri oct-encode et
  -> geometriyi dedupe et / instancing
  -> deflate ile sıkıştır
  -> .xkt yaz

Pratikte bu adımlar hazır araçlarla yapılır. Örneğin xeokit-convert paketinin convert2xkt CLI’ı IFC’yi (IFC parse için WASM tabanlı web-ifc’i kullanarak) XKT’ye çevirir:

# Node ortamında
npx convert2xkt -s model.ifc -o model.xkt -l

# -s : kaynak (IFC/glTF/LAS/CityJSON ...)
# -o : hedef .xkt
# -l : dönüşüm log'u (üçgen/nesne sayıları, uyarılar)

Log çıktısını gözden geçirmek şart; çoğu ölçek ve koordinat hatası orada uyarı olarak görünür.

Tuzak 1: Koordinat hassasiyeti ve model orijini

En sinsi problem burada. GPU pipeline’ı pratikte float32 ile çalışır. float32’nin mantissa’sı 24 bit; bu da yaklaşık 7 anlamlı ondalık basamak demektir. Modeliniz gerçek harita koordinatlarında (ör. UTM’de doğu değeri milyonlarca metre) modellenmişse, koordinatın büyüklüğü hassasiyet bütçesini yer; geriye milimetreler için basamak kalmaz. Sonuç, kamerayı gezdirdikçe titreyen geometri (“vertex jitter”), üst üste binen yüzeyler ve bozuk snap davranışıdır.

Kaynağı net görmek gerekir: IFC dosyasındaki koordinatlar double (~15–16 anlamlı basamak) olduğu için dosyada sorun yoktur. Sorun, o double değerlerin GPU’da float32’ye indirgenmesiyle oluşur. Çözüm, geometriyi mutlak harita koordinatında tutmamaktır. xeokit bunu RTC (Relative-To-Center) yaklaşımıyla çözer: yakın bir merkez noktası double olarak saklanır, vertex’ler bu merkeze göreli float olarak ifade edilir. Böylece GPU küçük göreli sayılarla çalışır, büyük ofset ayrı taşınır.

Pratik kural: dönüşümden önce modelin nerede oturduğunu bilin. IfcSite / IfcMapConversion üzerinden gelen georeferans varsa, bunu bilinçli bir merkez ofseti olarak ele alın; körlemesine “0,0,0’a taşı” demeyin, çünkü o zaman gerçek dünya konumunu kaybedersiniz.

Tuzak 2: Birim ölçeği (mm/m)

IFC’de uzunluk birimi IfcUnitAssignment içinde tanımlıdır ve pratikte çoğu proje milimetre kullanır. Dönüştürücü bu ölçek faktörünü okumaz veya yanlış varsayarsa, model ya 1000 kat büyük ya 1000 kat küçük çıkar. Belirtiler: kamera modeli hiç bulamaz (model sahnenin çok dışında), ya da bir kapı bir gökdelen boyutunda görünür. Birim ölçeğinin nicemlemeden önce doğru uygulanması gerekir, çünkü nicemleme kutusu (AABB) yanlış ölçekli geometriye göre kurulursa hata katmanlanır. Farklı disiplin modellerini birleştirirken (federasyon), hepsinin aynı hedef birime normalize edildiğinden emin olun.

Tuzak 3: Nicemleme kaynaklı hassasiyet

Nicemleme kayıplı bir işlemdir; kabul edilebilir çözünürlüğü siz belirlersiniz. Pozisyonlar AABB içinde 16-bit’e (65.536 kademe) haritalandığından, ulaşılabilir çözünürlük kabaca kutu kenar uzunluğu / 65.536’dır. Bir örnekle: yaklaşık 100 m’lik bir yapı için bu, milimetre-altı bir adım demektir ki BIM görüntülemesi için genelde fazlasıyla yeterli.

Ama ölçek büyüdükçe hikâye değişir. Tüm bir kampüsü veya kilometrelerce altyapı hattını tek bir AABB’ye sığdırıp nicemlerseniz, adım büyüklüğü santimetre mertebesine çıkabilir ve ince detaylar birbirine yapışır. Bu yüzden büyük sahnelerde geometriyi tile/segmentlere bölmek (her tile kendi yerel kutusunda nicemlenir) hem hassasiyeti hem de RTC hassasiyet stratejisini birlikte korur. Nicemlemenin bir görüntüleme kararı olduğunu unutmayın: bu değerler ölçüm/analiz için otorite değildir; kesin metraj ve sorgular kaynak IFC üzerinde yapılmalıdır.

Özet

Ham IFC görüntüleme formatı değildir: metin tabanlı STEP parse’ı ve örtük geometrinin tessellation’ı mobilde pahalıdır; XKT bu işi bir kez, offline yapar.
XKT hızını üç şeye borçludur: önceden tessellate edilmiş geometri, 16-bit pozisyon + oct-encoded normal nicemlemesi ve geometri paylaşımı + deflate sıkıştırma.
En kritik tuzak koordinat hassasiyetidir: IFC double’dır ama GPU float32’dir (~7 anlamlı basamak); büyük harita koordinatları titremeye yol açar. Çözüm RTC ile göreli koordinatlardır, orijini körlemesine sıfırlamak değil.
Birim ölçeği nicemlemeden önce doğru uygulanmalı: IfcUnitAssignment (çoğunlukla mm) yanlış okunursa model devasa veya minik çıkar; federasyonda tüm modeller aynı birime normalize edilmeli.
Nicemleme bir görüntüleme kararıdır: çözünürlük ≈ AABB kenarı / 65.536; büyük sahnelerde tile’lara bölerek hassasiyeti koruyun ve kesin ölçüm için her zaman kaynak IFC’ye dönün.