SketchUp Ruby API ile model otomasyonu: bileşen ve geometri rehberi

SketchUp Ruby API, açık modelin içeriğini okuyup değiştirmek için model, geometri ve bileşen sınıflarını kullanır. SketchUp’ın resmî Ruby API belgelerinde yer alan bu rehber, özellikle model verisine erişme, bileşen örneklerini yönetme ve geometri koleksiyonları üzerinde işlem yapma akışını ele alıyor. Belgelerde temel sınıflar için SketchUp 6.0 sürüm bilgisi yer alsa da bazı yöntemlerin daha yeni sürüm koşulları bulunuyor; bu nedenle kullanılacak yöntemin kendi sürüm notu ayrıca kontrol edilmeli.

1. Model içeriğine doğru bağlamdan erişin

Bir otomasyon akışının başlangıç noktası Sketchup.active_model ile alınan açık model nesnesidir. Model nesnesi üzerinden kök geometrisi, bileşen tanımları, malzemeler ve seçim koleksiyonu gibi bölümlere erişilebilir. Böylece işlem yapılacak verinin modelin hangi bölümünde bulunduğu netleşir.

model = Sketchup.active_model
entities = model.entities
definitions = model.definitions
materials = model.materials
selection = model.selection

model.entities, modelin kök düzeyindeki çizim öğelerini kapsar. Kullanıcı bir grup ya da bileşeni düzenliyorsa model.active_entities o açık düzenleme bağlamının öğelerini döndürür. Açık bir grup veya bileşen yoksa bu koleksiyon entities ile aynı olur. Bu ayrım, komutun yanlış bağlamdaki geometriyi değiştirmesini önlemeye yardımcı olur.

Örneğin, seçili öğeler üzerinde işlem yapacak bir araçta seçim koleksiyonu, mevcut düzenleme bağlamında çalışacak bir araçta ise etkin öğeler koleksiyonu başlangıç noktası olabilir. İşlem kapsamını belirlemeden doğrudan modelin tüm içeriğini değiştirmeye yönelmek, istenmeyen model değişikliklerine yol açabilir.

2. Bileşen tanımı ile örneğini ayırın

SketchUp bileşenlerinde tanım ve örnek aynı şey değildir. ComponentDefinition, bileşenin içerdiği öğeleri tanımlar; ComponentInstance ise bu tanımın modeldeki bir yerleşimini ve dönüşümünü temsil eder. Aynı tanımdan birden fazla örnek oluşturulabilir. Tanım üzerinde yapılan düzenlemeler, onu kullanan örneklere yansır.

Bir örneğin hangi tanıma bağlı olduğunu definition yöntemiyle öğrenebilirsiniz. Örneğin başka bir tanıma geçirmek de mümkündür; belgeler bu değişiklik sırasında örneğin modeldeki konumlandırma dönüşümünün korunduğunu belirtiyor.

instance = model.entities[0]
definition = instance.definition
puts definition.name

Bu örnekte ilk öğenin bir bileşen örneği olduğu varsayılır. Gerçek bir eklentide koleksiyondaki her öğenin türünü doğrulamak ve boş sonuç ihtimalini ele almak gerekir. Bileşen tanımı üzerinden count_instances ve count_used_instances yöntemleriyle kullanımı sayabilirsiniz: ilki farklı örnekleri, ikincisi modelde bu tanımı kullanan toplam örnekleri sayar.

Tek bir örnekte bağımsız düzenleme gerektiğinde make_unique kullanılabilir. Bu yöntem, o örnek için başka örneklerce paylaşılmayan bir tanım oluşturur. Bu nedenle toplu düzenleme yapmadan önce değişikliğin ortak tanıma mı, yoksa yalnızca seçilen örneğe mi uygulanacağı belirlenmelidir.

3. Geometri koleksiyonlarını verimli işleyin

Entities, modelde veya bir bileşen tanımında bulunan öğeler koleksiyonudur. Belgeler, öğeleri tek tek dolaşmak için indisle erişim yerine genel olarak each yöntemini kullanmanın daha verimli olduğunu belirtiyor. Bu yaklaşım, koleksiyon üzerinde tarama yapan betiklerde okunabilir bir akış da sağlar.

model.entities.each do |entity|
  puts entity.typename
end

Belirli bir indisle erişim gerektiğinde entities[index] kullanılabilir; ancak geçerli indis, sıfır ile koleksiyon uzunluğunun bir eksiği arasındadır ve bulunamayan öğe için nil dönebilir. Dolayısıyla kullanıcı tarafından seçilen bir indekse bağlı işlemlerde bu sonucu kontrol etmek önemlidir.

Tek bir çizgi oluşturmak için add_line, daire için add_circle, yüzey için add_face gibi yöntemler vardır. Çok sayıda geometri öğesini performansı gözeterek üretmek için Entities#build yöntemi bir EntitiesBuilder oluşturur. Belgeler bu yöntemi toplu geometri üretimine yönelik tanımlar; ancak belirli bir hız artışı ya da donanım gereksinimi belirtmez. Bu yüzden gerçek projedeki fayda, kullanılan geometri ve eklenti akışı üzerinde ölçülmelidir.

İşlem geri alınabilir bir adım olarak kaydedilecekse model düzeyindeki start_operation ve commit_operation yöntemleri kullanılabilir. Hata durumunda resmî belgeler, başlatılan işlemi iptal etmek için abort_operation yöntemini gösteriyor. Belgede ayrıca şeffaf bir işlemin iptal edilmemesi gerektiği uyarısı bulunuyor.

model.start_operation("Model düzenlemesi")
begin
  # Geometri işlemlerini burada yürütün.
  model.commit_operation
rescue
  model.abort_operation
  raise
end

4. Mimari ve görselleştirme iş akışında kullanım

Mimari modelleme ve iç mekân projelerinde bu API; tekrarlanan öğeleri bileşen olarak düzenlemek, model içeriğini incelemek ve yinelenen geometri işlemlerini betiklerle yürütmek için kullanılabilir. Örneğin aynı mobilya tanımının farklı yerleşimlerini yönetmek, tanım ile örneğin ayrımını doğru kurmayı gerektirir. Bir öğeyi bağımsızlaştırmak gerektiğinde make_unique seçeneği; ortak güncelleme isteniyorsa paylaşılan tanım yaklaşımı değerlendirilmelidir.

Bir ofis otomasyon betiği geliştirirken önce kapsam belirlenmeli: kök model geometrisi mi, açık grup içeriği mi, yoksa seçili öğeler mi işlenecek? Ardından bileşen tanımı ve örnek ilişkisi göz önünde bulundurulmalı. Eklentinin SketchUp sürümüyle uyumu için kullanılan yöntemlerin resmî belgelerdeki sürüm bilgileri incelenmeli. Donanım açısından belgeler belirli bir gereksinim belirtmediğinden, özel bir donanım önerisi çıkarmak mümkün değil; yoğun geometri işlemlerinde performansın hedef model üzerinde denenmesi daha sağlıklı olur.

Sık yapılan hatalar

• entities ile active_entities koleksiyonlarını aynı kapsamdaymış gibi kullanmak.

• Ortak tanımda yapılan düzenlemenin bileşen örneklerine yansıyacağını hesaba katmamak.

• İndisle alınan öğenin bulunamayabileceğini ve sonucun nil olabileceğini göz ardı etmek.

• İşlem başlatıldıktan sonra başarılı akışta commit_operation, hata akışında uygun kapatma adımını yönetmemek.

Bu rehber, SketchUp Ruby API’nin belgelenen temel model, bileşen ve geometri sınıflarına dayanır. Arayüz menü yolları, lisans koşulları veya donanım gereksinimleri bu doküman parçalarında açıklanmadığından burada varsayım yapılmamıştır.