Pivot ve Origin — glTF Dosyada Pivot Hissi Nasıl Oluşur?

Yeni başlayanların çoğu «origin» ile «geometrinin görsel merkezi»ni aynı sanır. glTF'de bu zorunlu değildir. Node origin, transform verilerinin (translation, rotation, scale veya matrix) uygulandığı yerel kök noktasıdır koordinat sisteminin (0, 0, 0) noktası. Mesh center ise POSITION buffer'ındaki vertexlerin oluşturduğu hacmin ortalama/merkez bölgesidir; matematiksel tanımına göre bounding box merkezi veya ağırlık merkezi alınabilir, fakat glTF bunu ayrı bir alan olarak yazmaz.

İki nokta çakıştığında rotation «gövdenin ortasından» döner bu çoğu statik prop için yeterlidir. Ayrıştığında rotation node origin etrafında uygulanır; mesh görsel olarak origin'in yanında, üstünde veya uzakta duruyorsa hareket «pivot kaymış» gibi görünür. Bu bir bug değil; vertex dağılımı ile origin'in bilinçli veya export kaynaklı ayrışmasıdır.

{
  "nodes": [
    { "name": "PanelNode", "mesh": 0, "rotation": [0, 0.383, 0, 0.924] }
  ],
  "meshes": [
    { "name": "PanelMesh", "primitives": [{ "attributes": { "POSITION": 0 } }] }
  ]
}

Yukarıdaki kayıtta rotation node origin'e uygulanır. Mesh'in görsel merkezi origin'de mi? JSON bunu söylemez cevap accessors[0] içindeki vertex listesindedir. Origin metadata noktasıdır; vertexler ayrı veridir.

glTF 2.0 spesifikasyonunda sahne ve geometri verisi tanımlı tablolarla taşınır: nodes, meshes, accessors, bufferViews, buffers ve bunlara bağlı referanslar. Bu tabloların hiçbirinde "pivot", "pivotPoint", "originOffset" veya «dönüş referans vektörü» anlamına gelen standart bir alan adı bulunmaz. Bu sayfanın en kritik cümlesi budur: format pivot saklamaz yalnızca node origin (transform'un bağlandığı yerel kök) ile vertex dağılımı (POSITION accessor'ındaki koordinat listesi) saklanır. «Pivot» günlük dilde kullanılan bir kavramdır; glTF JSON'unda karşılığı tek bir key değil, bu iki katmanın birleşimidir.

Şemada ne var, ne yok?

JSON Structure sayfasında gördüğünüz gibi glTF bir «interchange» formatıdır: amacı farklı motorların aynı dosyayı okuyabilmesi, DCC aracının özel editör durumunu taşımamasıdır. Pivot handle, cursor, manipulator merkezi gibi kavramlar editörün kullanıcı arayüzüne aittir; spesifikasyon bunları dosyaya yazmaz. Node kaydında görebileceğiniz transform alanları (translation, rotation, scale, matrix) zaten Transform verileri sayfasında anlatıldı bunlar «node'u sahneye nasıl yerleştirirsin?» sorusuna cevap verir; «mesh geometrisi node origin'den ne kadar uzakta çizilmiş?» sorusuna değil. İkinci sorunun cevabı mesh / accessor hattındadır.

{
  "asset": { "version": "2.0" },
  "nodes": [
    { "name": "DoorLeaf", "mesh": 0, "rotation": [0, 0.383, 0, 0.924] }
  ],
  "meshes": [
    { "name": "DoorMesh", "primitives": [{ "attributes": { "POSITION": 0, "NORMAL": 1 } }] }
  ],
  "accessors": [
    { "bufferView": 0, "componentType": 5126, "count": 36, "type": "VEC3", "max": [0.5, 1.0, 0.05], "min": [-0.5, 0.0, -0.05] }
  ]
}

Yukarıdaki örnekte menteşe, pivot veya origin offset diye bir alan yoktur. Kapı levhasının menteşe kenarından mı yoksa merkezinden mi döneceği dosyayı okuyan kodun çıkarım yapması gereken bir «pivot vektörü» ile değil POSITION min/max aralığı ile node rotation birleşimiyle belirlenir. JSON'da grep pivot araması boş döner; bu beklenen davranıştır, eksik export değil.

DCC iç formatı vs glTF: export anında ne olur?

DCC (Digital Content Creation) araçları Blender, Maya, 3ds Max, Cinema 4D pivot bilgisini kendi native dosyalarında tutabilir: object origin, 3D cursor, pivot handle, freeze transform durumu. glTF export plug-in'i bu bilgiyi glTF'ye ayrı bir pivot vektörü olarak aktarmaz; tipik olarak iki «bake» yolundan birine gider:

• Vertex bake: Geometri, mesh uzayında kaydırılır; vertex koordinatları güncellenir, node transform sıfıra yakın kalabilir. Pivot hissi POSITION accessor içine gömülür.
• Node transform bake: Pivot / origin farkı node translation veya hiyerarşik parent-child düzenine yansır; mesh vertexleri göreli olarak merkeze yakın kalabilir.

Her iki yolda da sonuç aynı tür veridir: glTF yalnızca «node transform + buffer'daki float'lar» görür. Export öncesi editörde «Set Origin to Geometry» yaptıysanız bu, native dosyada origin kaymasıdır; glTF'ye yansıdığında ya vertex listesi ya da node TRS değişmiş olur ayrı bir pivot satırı eklenmez. Dosyayı hex editörle değil JSON gözüyle okuduğunuzda aradığınız alanı bulamamanız normaldir; aramanız gereken yer accessors min/max ve nodes transform birleşimidir.

Dosya okuyucusu için kontrol listesi

Bir glTF / GLB açıp «pivot nerede tanımlı?» diye soruyorsanız format dilinde şu sırayı izleyin bu, runtime'da pivot düzeltme adımları değil, statik dosya okuma rehberidir:

1. nodes tablosunda ilgili node'un mesh indeksini bulun.
2. Aynı node'daki TRS / matrix değerlerini not edin bunlar origin'in parent'a göre yerleşimidir (yerel transform).
3. meshes → primitives → attributes.POSITION accessor indeksine gidin.
4. Accessor min / max veya decode edilmiş vertex listesi ile geometrinin mesh uzayında origin'e göre nerede durduğunu çıkarın (Accessor mantığı).
5. JSON'da pivot aramayın bulamazsanız format bozuk değildir.

Loader (three.js GLTFLoader, Babylon, vb.) bu birleşimi runtime sahnesine çevirir; fakat okuduğu veri yine aynı iki kaynaktır. «Pivot alanı loader tarafından gizleniyor mu?» sorusunun cevabı da hayır spesifikasyonda yoktur.

Uzantılar ve vendor metadata sınırı

glTF ekosisteminde extensions ve extras alanları vardır; bazı pipeline'lar editör notunu extras içine yazar. Bunlar standart pivot tanımı değildir: motorlar extras'ı yok sayabilir, vendor extension'ları her loader'da yoktur. Interchange garantisi için pivot hissi yine node + accessor birleşiminden okunmalıdır. «Dosyada pivot var mı?» sorusuna format düzeyinde güvenilir cevap: core şemada yok.

Format sorusu vs runtime sorusu

«Pivot yanlış, nasıl düzeltirim?» sorusu wrapper group, geometry.translate(), menteşe senaryosu, scale davranışı tamamen farklı bir kanaldır: Three.js · Pivot Management bu runtime düzeltmeyi anlatır. Orada «pivotu taşıdım» dediğinizde genelde yeni bir sahne düzeni kurarsınız veya geometriyi kaydırırsınız; dosyada önceden yazılı bir pivot alanını okumak değil. Format sayfasında ise tek soru vardır: «Bu davranış dosyada hangi alanların birleşiminden geliyor?» Cevap: node origin + vertex dağılımı başka standart alan yok.

Bir sonraki bölüm (§3) vertex ofsetinin aynı rotation değerinde neden farklı «pivot hissi» ürettiğini format örnekleriyle açar; Origin Offset Lab demosunda dört preset bu ayrımı görselleştirir pivot taşıma öğretilmez, encoding okunur.

Aynı rotation değeri, farklı vertex dağılımlarında tamamen farklı hareket üretir. Bu, Accessor mantığı ve POSITION verisinin mesh uzayında nasıl tanımlandığıyla ilgilidir runtime pivot düzeltmesi değil.

Örnek A origin merkezde:

     Node Origin
         ●
      [  Cube  ]

Örnek B origin solda, küp sağda:

● Origin
              [  Cube  ]

Her iki durumda da node JSON'u benzer görünebilir: "rotation": [0, 0.707, 0, 0.707]. Fark POSITION accessor'ındadır Örnek B'de tüm vertex X değerleri pozitif ofset taşır. Rotation node origin (●) etrafında uygulandığı için küp geniş bir yay çizer; Örnek A'da ise yerinde döner. «Pivot yanlış» demek, format dilinde, «origin ile vertex kütle merkezi örtüşmüyor» demektir.

BufferView ve binary katman vertexleri ham float dizisi olarak taşır; anlam katmanı accessor'dadır. Pivot tartışması bu yüzden mesh / accessor hattına bağlanır node transform hattına değil, yalnızca complement olarak.

Transform verileri sayfasında gördüğünüz translation, rotation ve scale alanları node'un yerel origin'ine göre tanımlıdır. Translation origin'i kaydırır; rotation origin etrafında döndürür; scale origin'den büyütür/küçültür. Bu kurallar vertexleri doğrudan değiştirmez vertexler mesh tablosunda sabit kalır, node transform sahneye taşır.

«Pivot nasıl taşınır?» sorusunun cevabı bu sayfada yoktur. Dosyada pivot taşımak = ya vertex koordinatlarını yeniden yazmak (export / remesh) ya da node hiyerarşisinde ek bir parent/child düzeni kurmak demektir ikincisi runtime veya export pipeline konusudur. Pivot Management · wrapper group bu ikinci yolu anlatır.

Yerellik kuralı geçerlidir: child node'un origin'i parent'a göre tanımlıdır. Parent origin'i ile child mesh center'ının çakışması gerekmez; her child kendi vertex dağılımını taşır.

Bazı exporter'lar TRS yerine tek matrix bloğu yazar (Transform · matrix alternatifi). Matrix, translation · rotation · scale birleşimini 4×4 column-major dizi olarak paketler; fakat referans noktası yine node origin'dir. Matrix moduna geçmek pivot'u ayrı bir alana taşımaz yalnızca aynı origin etrafındaki birleşik dönüşümü farklı formatta saklar.

{
  "nodes": [
    {
      "name": "ArmNode",
      "mesh": 0,
      "matrix": [1, 0, 0, 0, 0, 0.866, 0.5, 0, 0, -0.5, 0.866, 0, 0, 0, 0, 1]
    }
  ]
}

Matrix çarpım sırası ve math derinliği bu sayfanın dışındadır. Format açısından hatırlanacak tek şey: TRS mi matrix mi origin nerede, vertexler nerede sorusunun cevabını değiştirmez.

glTF dosyasını açıp «pivot bozuk» gördüğünüzde suçu formata atmak yaygın bir hatadır. Çoğu durumda glTF bozmadı exporter mevcut origin / vertex ilişkisini olduğu gibi yazdı. Kaynak araçtaki ayarlar export'a yansır:

• Blender: Object origin mesh merkezinde değilse, «Apply Transform» yapılmadan export edilen glTF vertex ofseti taşır.
• Maya: Freeze Transform sonrası pivot sıfırlanmış görünse bile mesh vertexleri eski uzayda kalabilir accessor verisi eski dağılımı korur.
• CAD export: Model uzayının kilometrelerce uzağında origin, parça centroid'ten ayrı POSITION değerleri büyük ofset taşır.
• Pivot kaydı yok: glTF'de zaten pivot alanı olmadığı için exporter «pivot»u ayrı yazamaz; vertex + transform birleşimini yazar.

Pipeline disiplini: export öncesi origin nerede olmalı, vertexler hangi uzayda bunları DCC tarafında netleştirmek format okuyucusunun işi değildir. Holodepth format hattında bu bölüm «dosyayı okurken ne beklememeliyim?» sorusuna cevap verir; düzeltme Pivot Management kanalındadır.

Node hiyerarşisi ve transform ayrımı sayfalarında gördüğünüz gibi aynı meshes[i] tanımı birden fazla node tarafından referanslanabilir. Tree Mesh örneği: tek geometry tanımı, on node instance her node farklı translation / rotation / scale taşır.

Burada kritik nokta: mesh paylaşımı vertex dağılımını paylaşır. Origin offset'i mesh tanımının içindedir; node transform ise instance'ı sahneye yerleştirir. On ağacın hepsi aynı «pivot hissi»ne sahip olur çünkü POSITION accessor aynıdır. Farklı pivot hissi istiyorsanız ya farklı mesh tanımı (farklı accessor) gerekir ya da export pipeline'da geometri kopyalanıp vertexler kaydırılmalıdır; glTF bunu otomatik yapmaz.

{
  "meshes": [{ "name": "TreeMesh", "primitives": [{ "attributes": { "POSITION": 0 } }] }],
  "nodes": [
    { "name": "Tree_A", "mesh": 0, "translation": [2, 0, 0] },
    { "name": "Tree_B", "mesh": 0, "translation": [5, 0, 1], "rotation": [0, 0.383, 0, 0.924] }
  ]
}

Tree_A ve Tree_B aynı vertex dağılımını paylaşır; rotation her ikisinde de kendi node origin'i etrafındadır. Mesh merkezi origin'den ofsetliyse her instance aynı ofseti miras alır bu, format seviyesinde instance'ların davranışını öngörmenizi sağlar.

Node Hierarchy ve Transform Inspector uzay istasyonunu kullandı; bu laboratuvar telemetry scanner modülü ile origin / vertex offset encoding'ini izole eder. Kapı veya menteşe metaforu yok Pivot Management runtime düzeltmesi de öğretilmez; odak «origin nerede, vertexler nerede, glTF bunu nasıl saklar?»

Dört preset sırası: Core Scanner → Sensor Array → Navigation Beacon (★ ana preset aynı rotation, farklı vertex dağılımı) → Side Bracket (kenar durumu). Sağ panelde kısa Encoding Diff yalnızca değişen meshCenterOffset değerini gösterir; sol panel Origin Analysis + Format Reading şeması ile doludur.