Çizimin doğru görünmesi neden yeterli değildir?
Bir tarayıcı görüntüleyicisi çizgileri tanınabilir biçimde çizebilir, fakat yanlış birim veya eksik dönüşüm yüzünden hatalı mesafe gösterebilir. Ekranda iki kat büyük çizilen bir parça, otomatik yakınlaştırma nedeniyle yine bütün pencereyi doldurur; kullanıcı hatayı fark etmeyebilir. Bu yüzden görsel benzerlik, geometrik doğruluk ve desteklenen dosya kapsamı ayrı değerlendirilmelidir. ‘Dosya açıldı’ bir ayrıştırma ve görüntüleme sonucudur; ölçüm aracının hangi koordinatları kullandığını veya bütün nesneleri eksiksiz yorumladığını açıklamaz.
Örneğin tedarikçi incelemesinde bir braketin iki deliği arasındaki mesafe karar vermek için kullanılacaksa ölçümün kaynağı bilinmelidir. Özgün geometri mi, çizimdeki ölçü yazısı mı, yoksa ekran üzerinde seçilmiş iki piksel mi esas alınıyor? Bu üç yol farklı hata sınıfları taşır. Bu makaledeki hesaplar basitleştirilmiş iki boyutlu örneklerdir; CadFlux'un bütün dosya türlerini, nesneleri veya sayısal doğruluk hedeflerini desteklediği iddiası değildir. Ürünün araştırma aşamasındaki kapsamı ayrıca doğrulanmalıdır.
Bir çizim birimi gerçekten bir milimetre midir?
Koordinattaki 100 sayısı kendi başına fiziksel birim taşımaz. Dosyanın birim metaverisi, dış referansların birimleri ve çizimi hazırlayan ekibin kuralı birlikte değerlendirilmelidir. Autodesk DXF başlık referansı $INSUNITS alanında birim kodlarını listeler; bu alanı bütün nesnelerin her koşulda doğru fiziksel ölçekte olduğunun kanıtı saymak yanlıştır. Birimsiz veya çelişkili dosyalarda kullanıcıya doğrulanacak varsayım gösterilmelidir. Sayfaya sığdırma oranı, ekran yakınlaştırması ve baskı ölçeği de model birimini değiştiren aynı işlem değildir.
Ölçü metni özellikle dikkat ister. Bir ölçü nesnesinde elle değiştirilmiş yazı, stil çarpanı veya yuvarlatılmış gösterim bulunabilir. Ekranda ‘100’ yazması, seçilen uç noktaların geometrik uzaklığının tam 100 olduğu anlamına gelmeyebilir. İnceleme aracı ölçülen geometri değerini, gösterilen metni ve kullanılan birimi gerektiğinde ayrı sunmalıdır. Birim kararı verildikten sonra dönüşümün hangi aşamada uygulandığı kaydedilmeli; aynı dosya her açıldığında veya blok her yerleştirildiğinde yeniden çarpılmamalıdır.
Bölüm kaynakları: Autodesk — DXF HEADER reference ↗
İç içe bloklarda mesafe neden şaşar?
Bir blok kendi yerel koordinatlarında tanımlanır ve sahneye yerleştirilirken ölçek, dönme ve öteleme alabilir. İç içe bloklarda dönüşümler belirli sırayla birleştirilir; öteleme ile dönmenin sırasını değiştirmek aynı sonucu vermez. Autodesk INSERT referansı eksen ölçekleri ve dönme gibi alanları tanımlar. İki boyutlu basit durumda dünya noktası p_dünya = T × R × S × p_yerel olarak düşünülebilir. Bu ifade yalnızca seçilen sütun vektörü ve matris sırası kuralı için geçerlidir; kod tabanının kuralı açık olmalıdır.
Negatif ölçek aynalama oluşturabilir; eksenlerde farklı ölçek ise bir daireyi elipse dönüştürebilir. Böyle bir durumda yerel yay uzunluğunu tek bir katsayıyla çarpmak doğru genel çözüm değildir. Blok temel noktası, dış referans dönüşümü ve nesnenin koordinat sistemi de dosyanın desteklenen kapsamına göre ele alınmalıdır. Desteklenmeyen dönüşümü sessizce yok sayıp düzgün görünen bir resim sunmak yerine, ölçümün neden güvenilir sayılamadığı veya ilgili nesnenin neden ölçülemediği kullanıcıya açıklanmalıdır.
Bölüm kaynakları: Autodesk — DXF INSERT reference ↗
İnçten milimetreye dönüşüm nasıl doğrulanır?
Tamamen tanımlı bir örnek seçelim: yerel koordinatlar inç, dünya koordinatları milimetre olsun; ölçek 25,4, dönme 30 derece ve öteleme (1000, 500) mm olsun. Yerel (2, 1) noktası yaklaşık (1031,294090512; 547,397045256) mm konumuna gelir. Yerelde (0, 0) ile (3, 0) arasındaki uzunluk dünya uzayında 76,2 mm olur. Dönme ve öteleme uzunluğu değiştirmez; bu örnekte uzunluk yalnızca tekdüze birim ölçeğiyle değişir.
Aşağıdaki Node.js kodu hem nokta hem uzunluk için beklenen değerleri kontrol eder. Kullanılan 1e-9 tolerans, bu küçük yapay örneğin aritmetik kontrolüdür; üretim ölçüm doğruluğu veya fiziksel tolerans taahhüdü değildir. Gerçek kabul eşiği dosya hassasiyeti, koordinat büyüklüğü ve kullanım gereksinimiyle seçilmelidir. Aynı testin ters dönüşüm, iç içe blok ve aynalama varyantları eklenebilir. Kod bir DXF ayrıştırıcısı değildir; ayrıştırıcıdan bağımsız olarak geometri katmanının temel varsayımlarını sınar.
const assert = require('node:assert/strict');
const angle = Math.PI / 6;
const scale = 25.4;
function toWorld([x, y]) {
return [
1000 + scale * (x * Math.cos(angle) - y * Math.sin(angle)),
500 + scale * (x * Math.sin(angle) + y * Math.cos(angle))
];
}
const p = toWorld([2, 1]);
assert(Math.abs(p[0] - 1031.2940905122496) < 1e-9);
assert(Math.abs(p[1] - 547.3970452561248) < 1e-9);
const start = toWorld([0, 0]);
const end = toWorld([3, 0]);
const length = Math.hypot(end[0] - start[0], end[1] - start[1]);
assert(Math.abs(length - 76.2) < 1e-9);
// Subtract the origin BEFORE converting to float32.
const origin = 1_000_000_000;
const x = origin + 10;
const wrong = Math.fround(x) - Math.fround(origin);
const local = Math.fround(x - origin);
assert.equal(wrong, 0);
assert.equal(local, 10);
console.log({ point: p, length, wrong, local });Ekrandaki pikselden hassas ölçüm yapılabilir mi?
12.000 mm genişliğindeki model alanının 1.200 CSS pikseline sığdığını varsayalım. Yatay yönde bir CSS pikseli yaklaşık 10 mm'ye karşılık gelir. Cihaz piksel oranı 2 olduğunda daha fazla fiziksel piksel çizilir, fakat kullanıcı işaretçisinin CSS koordinatları kendiliğinden iki kat hassas bir geometrik seçim hâline gelmez. Görüntü daha keskin olabilir; seçilen model noktası hâlâ yanlış olabilir. Yakınlaştırma bu oranı değiştirir ve aynı nesne farklı ekranlarda farklı sayıda piksel kaplar.
Ölçüm aracı önce görüntüleme dönüşümünü tersine çevirerek adayı model uzayına taşımalı, ardından desteklenen geometri üzerinde uç nokta, merkez veya kesişim gibi seçme kurallarını uygulamalıdır. Seçilen nesne kimliği ve yakalama türü görünür olursa kullanıcı sonucu kontrol edebilir. Tolerans yalnızca büyük bir piksel yarıçapı olarak belirlenirse yakın nesneler yanlış eşleşebilir. Dokunmatik ekranda hedef büyütme, yardımcı büyüteç ve seçimi onaylama gibi arayüz kararları geometrik doğrulamanın yerine geçmeden kullanılabilir.
Büyük koordinatlar küçük ayrıntıları nasıl yok eder?
JavaScript sayıları ile çizim verisinin GPU'ya taşındığı temsil aynı hassasiyete sahip olmayabilir. Örnekte 1.000.000.000 ile 1.000.000.010 değerleri ayrı ayrı float32'ye yuvarlandığında farkları sıfır olabilir. Önce ortak başlangıcı çıkarıp kalan 10 değerini float32'ye dönüştürmek ise ayrıntıyı bu örnekte korur. Kodun son bölümü bu sonucu doğrudan kontrol eder. MDN, Math.fround işlevinin 32 bit kayan nokta gösterimine yuvarlama davranışını açıklar. Bu örnek bütün grafik donanımlarının aynı iç yolu kullandığı iddiası değildir.
Bu yüzden ölçüm için korunan model verisi ile görüntülemeye hazırlanan yerel koordinatlar ayrılabilir. Büyük dünya koordinatları daha yüksek hassasiyetli hesap katmanında tutulur; görüntüleme yakın bir yerel başlangıca göre yapılır. Ancak başlangıç değişirken seçim, etiket ve dış referansların da aynı dönüşümü izlemesi gerekir. Sadece görüntüde titreme azaldı diye ölçüm doğrulandı denemez. Model üzerinde bilinen mesafeler, farklı başlangıçlar ve yakınlaştırmalar boyunca değişmeden kalmalıdır. Sıfıra yakın uzunluklar için göreli hata yerine mutlak sınır ayrıca tanımlanır.
Bölüm kaynakları: MDN — Math.fround ↗
Hangi nesneler ayrı doğrulama ister?
Doğru bir düz çizgi ölçümü, yay, eğri, ölçü nesnesi ve iç içe blok için yeterli kanıt değildir. Her nesne sınıfı için destek kapsamını ve beklenen sonucu tanımlayın. Eğriyi ekranda çizmek için kullanılan parçalara bölme yaklaşımı, gerçek eğri uzunluğunu ölçmek için yeterli hassasiyet sağlamayabilir. Görsel parça sayısını artırmak da her durumda doğru ölçüm algoritması oluşturmaz. Alan hesabında kapalı sınır, delikler ve kendi kendini kesen şekiller için davranış ayrıca belirtilmelidir.
Bir dönüşümün determinantı sıfıra yakınsa ters dönüşüm kararsız veya tanımsız olabilir; seçme işlemi bunu ele almalıdır. Aynalanmış nesnede yön ve alan işareti beklenmedik biçimde değişebilir. Birim dönüşümü ile geometri dönüşümünü farklı katmanlarda uygulamak gerekiyorsa toplam dönüşümün testini saklayın. Aşağıdaki matris, her ürünün bu nesneleri desteklediği anlamına gelmez; satın alma veya prototip kabulünde desteklenen alanın açıkça belgelenmesi için örnek bir kapsam listesidir.
| Durum | Kontrol | Beklenen davranış |
|---|---|---|
| Tekdüze ölçek ve dönme | Bilinen uç noktalar ve uzunluk | Örnek uzunluk 76,2 mm |
| İç içe blok | Birleştirilmiş dönüşüm sırası | Bağımsız referansla eşleşme |
| Birim belirsizliği | Metaveri ve kullanıcı varsayımı | Varsayımı görünür kılma |
| Desteklenmeyen eğri | Nesne türü | Sessiz yaklaşık ölçüm yerine açık sınırlama |
Görsel ekran görüntüsü yerine neyi test etmeliyiz?
Küçük, analitik sonucu bilinen bir dosya kümesi hazırlayın. Her dosya tek bir özelliği sınasın: birim dönüşümü, temel nokta, dönme, aynalama, iç içe yerleşim veya büyük koordinat. Beklenen nesne kimliği, uç noktalar ve uzunluk makine tarafından karşılaştırılabilir biçimde saklansın. Daha sonra gerçek kullanım dosyaları eklenebilir; ancak bağımsız olarak doğrulanmamış bir programın çıktısını tek doğru kabul etmek dairesel doğrulama oluşturabilir. Referansın nasıl hesaplandığı da test verisinin parçası olmalıdır.
Testleri farklı yakınlaştırma ve ekran boyutlarında tekrar edin. Model uzunluğu değişmemeli, yalnızca sunum değişmelidir. Sayısal testin yanına seçilebilirlik, klavye kullanımı ve desteklenmeyen nesne bildirimi için arayüz testleri ekleyin. Tarayıcıda yeterince hızlı açılması başka bir ölçüttür; bunun için dosya boyutu, nesne sayısı, ayrıştırma ve çizim süreleri ayrı kaydedilir. Hızlı açılan ama eksik nesne atan bir uygulamanın performans sonucu, kapsam kaybı belirtilmeden başarılı sayılmamalıdır.
- Ölçüm geometriye dayanıyor; ekran pikselleri veya ölçü yazısı varsayılmıyor.
- Birim varsayımı, dönüşüm kapsamı ve desteklenmeyen nesneler görünür.
- Bilinen uzunluk yakınlaştırma ve ekran boyutu değişince sabit kalıyor.
CadFlux için nasıl bir değerlendirme paketi hazırlanır?
CadFlux, tarayıcı tabanlı CAD görüntüleme ve düzenleme araçları için açık kaynaklı araştırma çalışması olarak konumlanır. Bu makale tüm DWG/DXF sürümlerini, tam AutoCAD eşdeğerliğini veya üretime uygun ölçüm doğruluğunu doğrulamaz. Değerlendirme paketi; paylaşım hakkı bulunan örnek dosyalar, gereken nesne türleri, birim kuralları, bilinen referans ölçüler ve hedef cihazlardan oluşmalıdır. Böylece genel ‘dosyamı açıyor mu?’ sorusu, belirli bir mühendislik incelemesi için hangi işlevlerin yeterli olduğu sorusuna dönüşür.
Endüstriyel yazılım yetenekleri, çizim incelemesinin iş emri, doküman sürümü veya onay süreciyle bağlanması gerektiğinde ilgili alandır. Visual Data Core ise operasyonel veriyi gösterme bağlamında ayrı bir araştırma ürünüdür; CAD ölçüm motoru olduğu varsayılmaz. En faydalı pilot, sınırlı bir dosya ve görev kümesinde geometri doğruluğu, kullanıcı etkileşimi ve işletme akışını birlikte sınar. Sonuç, ürünün gösterilebilir mevcut kapsamı ile yeni geliştirme ve doğrulama ihtiyacını ayrı ayrı belgelemelidir.
Teknik kaynaklar
Bu yaklaşımı kendi sisteminize uyarlamak ister misiniz?
Teknik ihtiyacınızı paylaşın →