Transform Verileri — glTF Yapısında Dönüşüm Nasıl Saklanır?

Node hiyerarşisi sayfasında gördüğünüz gibi her nodes kaydı sahnedeki bir varlığı temsil eder. Hiyerarşi children ile kurulur; transform ise her node'un kendi kaydında ayrı ayrı durur. Parent'ın transform'u child'ı otomatik olarak «içermez» child kendi yerel değerlerini taşır; birlikte hareket hissi runtime birleşiminden gelir.

Bu ayrım yeni başlayanların en sık karıştırdığı noktadır: «Station node'u hareket edince Ring A da gider» doğru bir gözlemdir; fakat dosyada Ring A'nın translation alanı genelde değişmez. Ring A, Station'a göre sabit bir ofsetle tanımlıdır; Station kaydırıldığında birleşim sonucu ikisi birlikte kayar. Dosyada saklanan şey yerel ofsettir, dünya konumu değil.

Node = transform bağlantı noktası

Mesh geometrisi kendi model uzayında tanımlıdır vertex'ler genelde mesh'in yerel origin'ine göre yazılır. Node, o mesh tanımını sahneye hangi noktadan asmak istediğinizi söyler. Boş bir grup node'u da transform taşıyabilir: «Core» mesh taşımasa bile «Station» altında konumlandırılabilir; altındaki «Ring A» ve «Ring B» bu çerçeveye göre yerleşir.

Uzay istasyonu örneği: parça başına kayıt

Holodepth sahnelerinde modüler bir uzay istasyonu kullanılır. Kök grup Station altında Core (merkez gövde), Ring A ve Ring B (iki halka modülü), Solar Panel Left / Solar Panel Right (sol ve sağ panel yaprakları) ile Antenna (anten) node'ları durur. Her parça ayrı bir node kaydıdır; her kayıtta (varsa) kendi transform alanları vardır.

{
  "nodes": [
    { "name": "Station", "children": [1, 2, 3, 4, 5, 6] },
    { "name": "Core", "mesh": 0, "translation": [0, 0, 0] },
    { "name": "Ring A", "mesh": 1, "translation": [12, 0, 0], "rotation": [0, 0.707, 0, 0.707] },
    { "name": "Ring B", "mesh": 2, "translation": [-12, 0, 0] },
    { "name": "Solar Panel Left", "mesh": 3, "translation": [0, 8, 4], "scale": [1.2, 1, 1] },
    { "name": "Solar Panel Right", "mesh": 4, "translation": [0, -8, 4], "scale": [1.2, 1, 1] },
    { "name": "Antenna", "mesh": 5, "translation": [0, 0, 6], "rotation": [0.383, 0, 0, 0.924] }
  ]
}

Yukarıdaki JSON öğretim amaçlı sadeleştirilmiştir; indeksler ve quaternion değerleri örnektir. Mesele şudur: Station kök node'u genelde yalnızca children taşır; görünür parçalar yaprak veya ara node'lardır ve her birinin Station'a göre farklı yerel transform'u vardır. Panel isimleri «Left / Right» ile ayrılır aynı mesh indeksine bakabilirler; fark transform'da yaşar.

Transform node'da, geometri mesh'te

Tablo JSON Structure haritasındaki tablolarla uyumludur: ağır veri binary'de, anlam JSON'da, yerleşim node transform alanlarında. Mesh koordinatlarını değiştirmeden yalnızca node translation ile «Solar Panel Left»'i yukarı taşımak mümkündür bu, format tasarımının temel esnekliğidir.

Transform alanı yoksa ne olur?

glTF spesifikasyonunda transform alanları isteğe bağlıdır. Hiçbiri yazılmazsa node kimlik dönüşümle (origin'de, eksenler hizalı, birim ölçek) kabul edilir: translation [0,0,0], birim quaternion, scale [1,1,1]. «Station» kök node'unda transform görmemeniz normaldir tüm istasyonu sahneye taşımak için kökte tek bir translation eklemek yeterli olabilir.

JSON Structure ile bağ

nodes tablosunun genel şeması indeks referansları bölümünde anlatıldı. Bu sayfa yalnızca o kayıtların transform yüzünü açar: hangi alan adları, hangi tipler, hangi birlikte kullanım yasağı. Hiyerarşi soruları için parent–child bölümüne dönün.

glTF çekirdek spesifikasyonu her node için iki karşılıklı dışlayıcı temsil sunar: TRS (translation + rotation + scale) veya tek bir matrix (4×4 column-major). Aynı node'da hem TRS hem matrix yazmak geçersizdir validator'lar bunu hata sayar. Export aracınız hangi yolu seçerse seçsin, anlam aynıdır: «bu node, ebeveyn koordinat sistemine göre nerede duruyor?»

Üç bileşen: T, R, S

Tablo «nasıl birleştirilir?» sorusunu cevaplamaz birleşim sırası ve world matrix üretimi bu sayfanın bilinçli dışındadır. Burada öğrenilecek şey: dosyada üç ayrı sayı dizisi olarak saklandığı ve her birinin birim / aralık beklentisi olduğudur.

Kavramsal sıra: önce ölçek, sonra dönüş, sonra öteleme

TRS kısaltması «Translation, Rotation, Scale» der; fakat motorlar bu üçünü tek bir yerel dönüşüm matrisine dönüştürürken sabit bir sıra kullanır (genelde S → R → T bileşimi). glTF dosyasında alanlar ayrı yazıldığı için DCC aracında «önce taşı sonra döndür» ile export sonucu farklı hissedilebilir bu, depolama formatı ile editör manipülasyon sırasının ayrı kavramlar olduğunu gösterir. Bu sayfa editör gizmo davranışına girmez; yalnızca export edilen JSON'da ne görürsünüz onu tarif eder.

İstasyonda TRS dağılımı

Core genelde birim transform ile merkezdedir. Ring A hem translation (halkayı gövdeden uzaklaştırır) hem rotation (halka düzlemini yönlendirir) taşıyabilir. Solar Panel Left/Right çoğu export'ta yalnızca simetrik translation + hafif scale ile ayrılır aynı mesh'i paylaşsalar bile transform farkı onları iki bağımsız yaprak gibi konumlandırır. Antenna tipik olarak yukarı ofset + eğim quaternion'u ile Core tepesine oturtulur.

{
  "name": "Ring A",
  "mesh": 1,
  "translation": [12.0, 0.0, 0.0],
  "rotation": [0.0, 0.7071067811865476, 0.0, 0.7071067811865476],
  "scale": [1.0, 1.0, 1.0]
}

Export neden TRS veya matrix seçer?

Bazı pipeline'lar (özellikle skinning veya karmaşık constraint sonrası) yalnızca birleşik matrix üretebilir o zaman matrix alanı yazılır, TRS alanları atlanır. Diğer export'lar insan okunabilirliği ve animasyon kanalları için TRS'yi tercih eder. glTF her iki yolu da kabul eder; loader'ın ikisini de okuyabilmesi gerekir. Hangi yol seçilirse seçilsin node başına tek temsil kuralı değişmez.

Doğrulama kuralları (özet)

rotation birim quaternion olmalıdır (uzunluk ≈ 1). scale eksenlerinde sıfır değer teknik olarak yazılabilir fakat ters dönüşümde sorun çıkarır export araçları genelde kaçınır. Negatif ölçek aynalama yaratır; glTF buna izin verir fakat materyal / normal tarafında ek dikkat gerekir (bu sayfa materyal konusuna girmez).

translation, node'un ebeveyn koordinat sisteminde origin'den kaydırılmasını üç sayı ile ifade eder: [x, y, z]. glTF birimleri metredir; dosyada birim etiketi yoktur bu spesifikasyon varsayımıdır. Web'de «1 birim = 1 metre» kabulü yaygındır.

Eksen yönleri

glTF sağ el koordinat sistemini kullanır: +X sağa, +Y yukarı, +Z ekrandan dışarı (kamera varsayılan konumundayken). «Solar Panel Left» ismi editörde sol tarafı çağrıştırır; dosyada bu genelde −Y veya +X ofseti olarak yazılır isim ile sayı yönü her zaman örtüşmeyebilir, güvenilir kaynak JSON'dur.

{
  "name": "Solar Panel Left",
  "mesh": 3,
  "translation": [0.0, 8.0, 4.0]
},
{
  "name": "Solar Panel Right",
  "mesh": 4,
  "translation": [0.0, -8.0, 4.0]
}

İki panel kaydında rotation yoktur simetri yalnızca Y ekseninde ters işaretli translation ile kurulmuştur. Mesh geometrisi aynı elips panel ise tek mesh indeksi iki node'da referanslanabilir (paylaşılan mesh); sağ/sol ayrımı transform'da yaşar.

Parent'a göre yerel

Ring B için "translation": [-12, 0, 0] değeri dünya koordinatında −12 demek değildir Station (veya arada ara grup varsa o grubun) uzayında −12'dir. Parent'ın kendi translation'ı varsa child'ın dünya konumu dosyada tek satırda görünmez; bu, «local transform depolanır» ilkesinin doğrudan sonucudur.

Alan yoksa ve sıfır farkı

Transform alanı tamamen atlanmış node ile "translation": [0,0,0] yazılmış node loader açısından eşdeğerdir. «Core» çoğu istasyonda origin'de durduğu için export'ta translation satırı görünmeyebilir bu, Core'un Station'a göre ofsetsiz oturduğu anlamına gelir, «konum bilgisi yok» anlamına gelmez.

Hassasiyet ve yuvarlama

JSON metin olarak yazıldığında ondalık basamak sayısı export ayarına bağlıdır. 12.0 ile 12.000001 pratikte aynı yerleşimdir; fakat animasyon dışı statik sahnelerde gereksiz uzun literal'ler dosya boyutunu şişirir. Binary GLB'de JSON chunk yine metin olduğu için aynı kural geçerlidir. Öğretim örneklerinde okunabilirlik için kısa ondalık tercih edilir.

Kök Station kaydırması

Tüm istasyonu sahne içinde toplu taşımak için yalnızca kök Station node'una translation yazmak yeterli olabilir alt parçaların Core, Ring A, paneller, Antenna yerel ofsetleri aynı kalır. Bu desen «grup taşıma»yı dosyada tek satırla ifade eder; child kayıtlarını tek tek güncellemeniz gerekmez. Tersine, yalnızca Antenna'yı yukarı almak için yalnızca Antenna node'undaki Z bileşenini değiştirirsiniz Station translation'a dokunmazsınız.

Birim tutarlılığı

glTF metre varsayar; JSON'da birim etiketi yoktur. Editörünüz santimetre ile çalışıyorsa export öncesi ölçek faktörü uygulanmış olmalıdır aksi halde istasyon parçaları beklenenden 100× küçük veya büyük yüklenir. Bu sayfa birim dönüşümü yapmaz; yalnızca dosyada gördüğünüz sayıların «metre cinsinden parent uzayında ofset» olduğunu hatırlatır.

Translation ne değildir?

translation mesh vertex'lerini taşımaz yalnızca node'un çerçevesini kaydırır. Vertex offset'i accessor seviyesinde ayrı bir konudur ve normal glTF export'ta tercih edilmez. Kamera «bakış noktası» veya ışık «menzil» parametreleri de translation değildir; onlar ilgili cameras / extension kayıtlarındadır, node yalnızca o tanımı sahneye taşır.

glTF'de rotation alanı dört bileşenli birim quaternion olarak saklanır: [x, y, z, w]. Spesifikasyon Euler açıları veya eksen-açı tuple'ı kabul etmez. Dosyayı okurken quaternion'u «dört sayı» olarak parse edersiniz; ne kadar döndüğü ve hangi eksen etrafında olduğu bu sayılardan türetilir bu sayfa o türetimin matematik derinliğine girmez.

Birim quaternion beklentisi

Geçerli bir kayıtta x² + y² + z² + w² ≈ 1 olmalıdır. Export araçları genelde normalize edilmiş değer yazar. Okuma tarafında hafif sapma görülürse normalize etmek yaygın bir tolerans uygulamasıdır; fakat «format okuma» perspektifinde asıl kural spec'teki birim uzunluk şartıdır.

{
  "name": "Antenna",
  "mesh": 5,
  "translation": [0.0, 0.0, 6.0],
  "rotation": [0.383, 0.0, 0.0, 0.924]
}

Antenna örneğinde quaternion, dish'in Core tepesinde hafif eğik durmasını sağlar. Dosyada yalnızca dört float görürsünüz; editörde «45° pitch» olarak hatırladığınız açı export sırasında quaternion'a dönüştürülmüştür. Ters yönde (quaternion → editör açısı) dönüşüm loader değil DCC veya debug aracı işidir.

Ring A yönelimi

Halka modülleri genelde gövde eksenine göre 90° döndürülmüş export edilir örneğin Ring A'nın rotation değeri Y ekseni etrafında dönmeyi kodlar (örnek quaternion: [0, 0.707, 0, 0.707]). Mesh'in kendi iç geometrisi halka düzleminde modellenmiş olsa bile node rotation ile ek düzeltme yapılması normaldir; mesh + node rotation birlikte «son görünümü» tanımlar.

Kimlik dönüşüm

Alan yoksa veya [0, 0, 0, 1] ise node ebeveyn eksenleriyle hizalıdır ek döndürme uygulanmaz. «Station» kök node'unda rotation görmemek bu yüzden sık karşılaşılan bir durumdur; tüm istasyonu sahne içinde döndürmek isterseniz köke quaternion yazılır veya TRS yerine matrix export edilir.

Euler ve gimbal bu sayfada yok

Birçok 3D editör kullanıcıya Euler açıları gösterir; glTF dosyası ise quaternion saklar. Gimbal kilidi, XYZ vs ZYX sıra tartışmaları ve interpolasyon (slerp) animasyon kanallarıyla ilgilidir statik transform depolama okuyucusu için kritik değildir. Yapmanız gereken: JSON'daki rotation dizisini dört float olarak okumak ve loader'a iletmek.

Rotation ile scale etkileşimi (depolama notu)

TRS ayrı alanlar olarak yazıldığında « önce ölçekle sonra döndür » birleşim kuralı motor tarafında uygulanır. Non-uniform scale sonrası rotation görsel olarak shear yaratabilir bu, dosyada ayrı alanlar olmasının runtime yorumuyla ilgilidir; glTF yine de TRS yazmayı destekler. Matrix temsilinde bu üçü tek pakette birleşmiş olabilir (§6).

scale üç pozitif (genelde) float ile eksen bazlı ölçek çarpanını taşır: [sx, sy, sz]. [1, 1, 1] birim ölçektir mesh'in export boyutları olduğu gibi kullanılır. Uniform olmayan ölçek, silueti eksenlere göre gerer «Solar Panel Left» örneğinde [1.2, 1, 1] paneli X'te %20 uzatabilir.

{
  "name": "Solar Panel Left",
  "mesh": 3,
  "translation": [0.0, 8.0, 4.0],
  "scale": [1.2, 1.0, 1.0]
}

Uniform vs non-uniform

Uniform ölçek üç eksende aynı çarpandır model «büyütülür / küçültülür» gibi davranır. Non-uniform ölçekte Ring veya panel gibi parçalar yalnızca bir eksende gerilir; mimari sahnelerde kapı yüksekliği ayarı sık görülür. glTF'de scale her zaman ayrı bir vektör olarak saklanır; «toplam scale» tek sayı değildir.

Negatif ölçek (aynalama)

Spesifikasyon negatif scale değerlerine izin verir bu geometriyi ilgili eksende yansıtır (mirror). İstasyon örneğinde iki panel ayrı node ile simetrik konumlandırıldığı için negatif scale zorunlu değildir; tek mesh + negatif scale ile ayna kopya da mümkündür fakat normal ve materyal tarafında ek kurallar devreye girer. Bu sayfa aynalama sonrası normal hesabına girmez.

Sıfır ölçek tuzağı

Herhangi bir eksende 0 scale matrisi tekil yapar ters dönüşüm tanımsızlaşır. Export araçları genelde minimum epsilon kullanır veya sıfır scale'i reddeder. Dosyayı elle düzenlerken "scale": [0, 1, 1] yazmak validator uyarısı üretebilir; runtime'da parça «kaybolmış» gibi görünebilir.

Hiyerarşide birikim (kavram)

Parent'ta scale: [2,2,2] ve child'da [1.2,1,1] varsa child'ın etkin ölçeği dosyada tek satırda yazmaz her node kendi yerel scale'ini taşır, birleşim motor sorumluluğundadır. Bu cümle world matrix hesabına giriş değildir; yalnızca «scale de parent zincirinde yaşar» gerçeğini vurgular.

Scale atlanmışsa

Varsayılan [1, 1, 1]. Core, Ring A/B ve Antenna çoğu istasyonda explicit scale satırı olmadan export edilir «doğal mesh boyutu» yeterlidir. Panel yapraklarında hafif non-uniform scale görmeniz, sanat yöneliminin dosyaya yansımasıdır.

Alternatif temsil: node başına 16 float, column-major 4×4 affine dönüşüm matrisi. matrix yazıldığında translation, rotation, scale alanları olmamalıdır. Spesifikasyon bunu net kılar ikisi bir arada «belirsiz hangisi geçerli» durumu yaratır.

{
  "name": "Ring A",
  "mesh": 1,
  "matrix": [
    0.0, 0.0, -1.0, 0.0,
    0.0, 1.0,  0.0, 0.0,
    1.0, 0.0,  0.0, 0.0,
    12.0, 0.0, 0.0, 1.0
  ]
}

Yukarıdaki matris öğretim amaçlıdır gerçek değerler export pipeline'a göre değişir. Column-major düzen: ilk dört sayı birinci sütun, sonraki dört ikinci sütun… Alt sağ 1.0 homogeneous koordinat satırının tipik kalıbıdır. Okuyucu olarak «16 sayı gördüm → matrix temsil» demek yeterli; matris çarpımı ve parent zinciri birleşimi bu sayfada anlatılmaz.

Ne zaman matrix export edilir?

Karmaşık rig, constraint veya «bake» edilmiş animasyon sonucu DCC aracı bazen TRS'ye güvenli geri dönüşüm üretemez o zaman birleşik matrix yazar. Skinning'li karakterlerde kemik node'ları matrix ile gelme eğilimindedir. Modüler istasyon gibi sert cisim sahnelerinde TRS daha okunabilir olduğu için yaygındır.

Okunabilirlik trade-off

İnsan gözü "translation": [12,0,0] satırını hemen yorumlar; 16 float'lık matrix aynı bilgiyi tek pakette gizler. Debug sırasında matrix'i TRS'ye ayırmak isteyebilirsiniz bu «depolama formatı okuma» değil, araç / analiz konusudur. glTF loader'ları her iki yolu da desteklemelidir.

Matrix → TRS ayrıştırma sınırı

Bazı matrix'ler saf TRS ile ifade edilemez (shear içerir). glTF spesifikasyonu matrix'in affine olmasını bekler; shear içeren durumlar nadir ve genelde bilinçli bake sonucudur. Ayrıştırma algoritması ve numerik tolerans bu sayfanın dışındadır bilmeniz gereken: dosyada matrix varsa loader onu doğrudan node dönüşümü olarak kabul eder.

İstasyonda matrix görme olasılığı

Holodepth uzay istasyonu statik modüler parçalardan oluşur; eğitim dosyalarında genelde TRS tercih edilir. Pipeline'ınız Blender «Apply All Transforms» sonrası matrix bake ediyorsa Ring node'larında TRS yerine matrix görebilirsiniz davranış hatası değil, export seçimidir.

Yerel (local) transform, node'un doğrudan ebeveyninin koordinat sistemine göre tanımlanan translation / rotation / scale veya matrix değeridir. glTF dosyasında transform alanları daima yerel olarak yorumlanır «world» veya «global» diye ayrı bir alan yoktur.

Station ağacında yerellik

Antenna'nın translation: [0,0,6] değeri «dünyada Z=6» demek değildir «Station (veya bağlı olduğu ara node) origin'inden 6 birim yukarı» demektir. Eğer Station kök node'una translation: [100, 0, 0] eklerseniz Antenna'nın JSON'daki altı değeri değişmez; birleşim sonucu dünya konumu değişir. Dosyada saklanan yerel değerler sabittir.

{
  "name": "Station",
  "translation": [100.0, 0.0, 0.0],
  "children": [1, 2, 3, 4, 5, 6]
},
{
  "name": "Antenna",
  "translation": [0.0, 0.0, 6.0]
}

«World» kelimesi bu sayfada

World space kavramı runtime ve sahne graph konularında sık geçer; glTF JSON'unda karşılığı yoktur. World matrix hesaplama, parent zinciri boyunca çarpım ve cache stratejileri bilinçli olarak dışarıda bırakıldı. Format okuyucusu için yeterli kural: JSON'daki her transform yereldir.

Mesh uzayı vs node uzayı

Vertex'ler mesh'in kendi model uzayında tanımlıdır; node transform mesh'i sahne ağacına taşır. Core mesh'inin geometrik merkezi origin'de değilse, node translation ile görsel hizalama yapılır bu «pivot» konusuna köprü kurar (sonraki sayfa: Pivot ve Origin). glTF'de ayrı pivot tablosu yoktur; pivot hissi mesh + node transform birleşiminden gelir.

Ara grup node'ları

Station altında «Rings» gibi boş bir grup node'u tanımlayıp Ring A/B'yi onun children'ı yapmak yaygın bir organizasyon desenidir. Ring'lerin translation'ı artık Station'a değil «Rings» grubuna göre yerel olur. Hiyerarşi derinliği arttıkça yerellik katmanları artar dosyada hâlâ node başına bir transform seti vardır.

Debug ipucu

glTF Inspector veya benzeri araçlarda «local» ve «global» sekmeleri runtime'da hesaplanmış değerleri gösterir; bunlar dosyaya ek alan olarak yazılmaz. Karışıklığı önlemek için ham JSON'a bakarken yalnızca node kaydındaki alanları okuyun Inspector global sekmesi world matrix türevidir.

glTF parent bilgisini çocuk listesi ile değil, ebeveyn tarafında children ile saklar. Her node'un transform'u kendi kaydında durur; parent'ın transform'u ayrı kayıttadır. İlişki + yerleşim birlikte sahne graph'ı tanımlar parent–child mekaniği Node Hiyerarşisi sayfasında, transform alanları bu sayfada.

Depolama modeli

{
  "name": "Station",
  "children": [1, 2, 3, 4, 5, 6]
},
{
  "name": "Core",
  "mesh": 0
},
{
  "name": "Ring A",
  "mesh": 1,
  "translation": [12.0, 0.0, 0.0]
}

Station kaydında transform olmayabilir; Core ve Ring A kendi yerel değerlerini taşır. Parent–child bağlantısı Station'un children dizisindeki indekslerle kurulur Ring A'nın kaydında «parent: 0» alanı yoktur. Parent'ı bulmak için tüm node listesinde «children içinde beni kim sayıyor?» taraması gerekir (Node Hiyerarşisi'nde anlatıldı).

«Miras» yanılgısı

OOP'deki «class mirası» gibi düşünmeyin: child, parent'ın translation değerini JSON'da devralmaz. Her node bağımsız yerel transform taşır (veya varsayılan kimlik transform). Parent hareket edince child'ın birlikte gitmesi, runtime'da parent dönüşümünün child'a uygulanmasından kaynaklanır dosyada tek bir «miras alanı» yoktur.

Kök node ve scene

scenes[0].nodes kök indeksleri listeler; kök node'ların da kendi transform'u olabilir. İstasyon tüm sahneyi kaydırmak için kök Station'a translation yazılabilir. Kök olmak «transform yok» demek değildir yalnızca «parent yok» demektir.

Aynı mesh, farklı parent/transform

İki farklı parent altına aynı mesh indeksini bağlayan node'lar farklı yerel transform taşıyabilir. İstasyonda simetrik paneller bunun tipik örneğidir. Geometri bir kez meshes'te; sahne örnekleri node + transform ile çoğaltılır.

Derin zincirler

Station → Rings → Ring A → DockingPort gibi derin ağaçlarda her seviye kendi yerel transform'unu taşır. Dosya boyutu node başına birkaç float ile büyür; derinlik sınırı spec'te yoktur. Okuma tarafında parent zinciri uzadıkça runtime birleşim maliyeti artar bu performans konusu format depolama sayfasının dışındadır.

«Neden translation, rotation, scale ayrı alanlar? Tek matrix yetmez mi?» sorusu format tasarımının özünü hedefler. glTF her iki temsili de destekler çünkü kullanım senaryoları farklıdır: TRS insan okunabilirliği ve animasyon kanalları için; matrix bake edilmiş / ters ayrıştırılamayan durumlar için.

Okunabilirlik ve debug

Sahne hata ayıklarken «Antenna neden eğik?» sorusuna JSON'da rotation dört'lüsüne bakarak başlarsınız. Matrix temsilinde aynı bilgi 16 sayıya dağılmıştır. Holodepth eğitim dosyalarında istasyon parçaları TRS ile tutulur öğrenci gözü konum ve yönü ayrı satırlarda görür.

Animasyon sınırı (adı geçer, derinlik yok)

glTF animasyonu transform kanallarını hedefleyebilir örneğin yalnızca translation veya rotation anahtar kareleri. Ayrı alanlar kanal hedeflemeyi mümkün kılar; tek matrix'e her frame yazmak hem dosya boyutunu hem düzenlenebilirliği zorlaştırır. Interpolasyon (lerp / slerp) ve sampler detayı bu sayfada anlatılmaz; yalnızca «format neden ayrık TRS'ye izin verir» sorusuna cevap verilir.

Export / import pipeline esnekliği

Blender, Maya, 3ds Max farklı internal temsiller kullanır; glTF çıkış aşamasında TRS'ye normalize etmek veya matrix bake etmek araç politikasına bağlıdır. Tek zorunlu format olsaydı bazı sahne türleri kayıp verirdir. İki temsil + karşılıklı dışlama kuralı pipeline'ları rahatlatır.

Node vs mesh ayrımıyla uyum

Transform'un node'da, geometrinin mesh'te olması aynı felsefenin parçasıdır: organizasyon ile veri tanımı ayrılır. Paylaşılan mesh + farklı node transform = veri tekrarı olmadan çoklu yerleşim. Ayrı TRS alanları = tek matrix paketi olmadan kısmi düzenleme.

Interchange format hedefi

glTF «3D için JPEG» sloganıyla taşınabilirlik hedefler. TRS alanlarının açık isimleri, farklı motorların aynı dosyayı yorumlamasını kolaylaştırır rotation dizisinin quaternion olduğu spec'te sabittir. Matrix-only bir dünya daha kompakt olabilirdi fakat debug ve kısmi düzenleme zorlaşırdı. İki temsil + net dışlama kuralı hem araç hem insan okuyucu için denge sağlar.

İstasyon metaforu ile kapanış

Modüler uzay istasyonunu düşünün: Core gövde mesh'i bir kez tanımlanır; Ring A/B farklı node transform ile monte edilir; paneller simetrik translation ile ayrılır; Antenna quaternion ile eğilir. Dosyayı açtığınızda gördüğünüz şey «montaj talimatı»dır parça tanımları + her parçanın parent'a göre vidası. Runtime'da istasyonu döndürmek kök transform'u değiştirmek veya motor sahnesinde ek manipülasyon gerektirir; fakat child node JSON'ları yerel ofsetlerini korumaya devam eder.

Holodepth okuma yolu

Önerilen sıra: JSON Structure → Node Hiyerarşisi → bu sayfa (transform depolama) → Pivot ve Origin → Scene Graph. Runtime takip ihtiyacı doğduğunda format serisinden çıkıp Three.js çoklu model hattındaki ilgili sayfaya geçilir transform sync stratejileri dosya anatomisinden bilinçli olarak ayrı tutulur.

Kapanış cümlesi

Özet: glTF transform'u node kaydında saklar; TRS veya matrix olmak üzere iki geçerli yol sunar; dosyadaki değerler daima parent'a göre yereldir. Hiyerarşi children ile, yerleşim transform alanları ile tanımlanır birlikte okunduğunda modüler istasyon parçalarının sahneye nasıl «monte edildiği» görünür olur. Runtime birleşim ve objeler arası senkron ayrı kanaldadır.

Sonraki doğal adım: pivot ve origin kavramları mesh uzayı ile node yerleşiminin görsel hizası. Matrix birleşimi derinliği Scene Graph ve runtime pipeline sayfalarına bırakılır.

Metin «transform dosyada nasıl saklanır?» sorusunu cevaplar; bu laboratuvar seçili node'un TRS veya matrix alanlarını slider ile değiştirip JSON'da canlı görmeyi hedefler. Node Explorer hiyerarşi ve parent–child ilişkisini cyan silüet ve bağlantı ışınlarıyla gösterir; Transform Inspector aynı istasyon verisini wireframe analiz modunda açar yerel eksenler, origin noktası ve TRS/matrix JSON'u bir arada.

Soldan bir parça seçin orta panelde translation, rotation, scale slider'larını kaydırın; alttaki JSON anında güncellenir. Matrix modu premium Matrix View rozetiyle tek matrix bloğunu vurgular. Sağda seçili node'un origin küresi ve X/Y/Z eksenleri görünür; wireframe katmanı geometriyi, transform katmanı yerleşimi ayırır. World matrix hesabı, animasyon oynatma veya runtime senkron yok.

Bu demo, Node Hiyerarşisi laboratuvarından sonra gelen ikinci istasyon laboratuvarıdır. Öğretmek istediği cümle: «Aynı model, farklı analiz aracı hiyerarşi ilişkiyi, transform yerel konum/yön/ölçeği dosyada saklar.»