max9´un verdiği bir hata

max9´da bir proje hazırladım render aşamasına geldiğimde render alırken "there isn´t enough memory for the raytracer to build it´s acceleration data structures the render is being aborted." diye bir uyarı veriyor,
anladığım kadarıyla ram(önbellek) le alakalı ama 2gb ram im var saçma geliyor, çünki 1,2 gb ram kullanıyor, sorunun ne olduğunu anlayamadım yardımcı olursanız sevinirim..

hangi render sistemini de kullandığını söylersen ona göre daha anlamlı yanıtlar verilebilir. default renderer kullanıyorsan, raytracer ayarlarından acceleration controls´e bas
gelen yeri şöyle dene

face limit = 20 veya 30 veya 40
max division = 20 yada 10
max depth = 2 - 5 arası dene
balance default renderer´de tam olarak nasıl tepki verir bilmiyorum. ama default değerinde bıraksan iyi olur. raytracer ayarları doğru yaptığında süperdir ama yanlış yaparsan tamamen berbattır :)

bu ayarlarda limitlediğiniz şeyler tam olarak nedir? Yani face limit derken neden bahsediyor program?Division ve dept in tam olarak çalışma mantığı nedir? bende merak ettim. Kullanacaksam ne işe yaradıklarını bilmek hoş olurdu.

tavsiyen için çok teşekkürler, fakat ben sorunu buldum sorun bnm pc nin ram lerinin dual çalışmasıymış kullandığım ram ler farklıydı, değiştirince düzeldi......
bu arada biraz acemilikten birazda projenin büyük olmasından olacakki hazırladığım sahnelerde ayrı ayrı 2 000 000 yüzey var toplam 3 sahne, yani 6 milyon yüzey kullanmışım......

[quote=30824]bu ayarlarda limitlediğiniz şeyler tam olarak nedir? Yani face limit derken neden bahsediyor program?Division ve dept in tam olarak çalışma mantığı nedir? bende merak ettim. Kullanacaksam ne işe yaradıklarını bilmek hoş olurdu.[/quote]

günümüz render sistemlerinde ışık hesapları, gölge hesapları, yansıma ve kırılma hesapları ve bazı render işlemi sırasında gereken hesaplar ışın izleme denen bir yöntemle yapılır. ışın izleme yöntemi genellikle ışık kaynağı yada ilgili nesne ile hedef vertex, poligon yada nesne arasında doğrusal çizgilerin kesişim yada var olup olmadığı gibi testlerdir.

bu işlemler sahnedeki vertex sayısı arttıkça karmaşıklaşır ve katlanarak artar. özellikle yansımalı yüzeyler, her yüzey için o yüzeyin işgal ettiği pixellerle kesişen ışınların tekrar tekrar hesaplanması demektir.

tabi bu işlemler karmaşıklaştıkça render süresi inanılmaz derecelerde uzayabilir.

bu durumun önüne geçmek için ışın izleme ( yani ray tracing ) hesaplarını daha hızlı hesaplama yöntemleri aranmıştır. tarih içinde bir çok ışın izleme hızlandırma yöntemi geliştirilmiş olsa da bir kaç tanesi çok başarılı olduğu için tercih ediliyor. default scanline renderer bildiğim kadarıyla yansımalı yüzeyler için ışın izlemeyi hızlandırıyor ama gölge ve ışık hesapları için sanırım bir hızlandırma yapamıyor. ancak vray ( kısmen ), mental ray, final render, brazil gibi render sistemleri ciddi derecede gelişmiş ışın hızlandırma yapılarına sahip.

eğer mental ray veya brazil kullanıyorsanız, ve accelerators ayarlarını bilmiyorsanız, amatörce kullanıyorsunuz demektir. üstelik çoğu render´da render sisteminin asıl performansını hiç bir zaman göremeden saatlerinizi harcıyor da olabilirsiniz. aynı sahne, hiç bir görsel kalite kaybı olmadan daha iyi ayarlanmış hızlandırıcı ayarları ile %50 belki %70 gibi bir hız kazanabilirsiniz ( tabi bunlar teorik ve her sahnede %70´e çıkılabilir diye birşey yok. ama ben şahsen birkaç sahnede %70´den fazla performans kazandırdığını gördüm. )

klasik ışın izleme hızlandırma yöntemleri, uzayı belirli bölümlere parçalamayı öngörür.
mesela uzayı bir küp gibi düşünün
ve bıçaklarla, enine boyuna ve dikine 10´ar dilime ayırdığımızı düşünelim. bu da 10 x 10 x 10, yani uzayı 1000 küpe bölmüş olduk. bir çaydanlık uzayın sadece bir köşesinde duruyorsa, ve ondan önce daha büyük bir çaydanlık varsa, ışık kaynağı normalde büyük çaydanlıktan dolayı küçük çaydanlığı aydınlatamaz. ama bilgisayar bunu bilmez.

scanline mantığında,
küçük çaydanlığın ilk vertexinden başlayıp çaydanlığa ışınlar gönderir. eğer bir ışın çaydanlığa varmadan önce bir yüzeyle kesişiyor mu diye de, yol boyunca bulunduğu koordinatlarla alakalı yüzeyleri test eder. çaydanlığın her vertexi ve her poligonu için aynısı tekrarlanır. sahnede vertex sayısı çoğaldıkça scanline yöntemi yavaşlar.

uzay bölümleme mantığı,
uzay önce küplere bölünür. 10x10x10´luk bir bölümleme yaptığımızı varsayalım.
küçük çaydanlık bir küpün içinde kaldı diye varsayalım.
büyük çaydanlık da, o küpün önünde duran 6 tane küpü kaplıyor diyelim. ışın hesabı önce nesneler üzerinde denenmeden, her bir küpün ışık kaynağı tarafından aydınlatılıp aydınlatılamadığına bakılır. örneğin, uzayın sağ üst ve ön tarafında kalan küpten çıkan bir ışın, uzayın sol alt ve arka tarafındaki küp ile test edilirken içinden geçtiği küplerin hiç birinde nesne olmadığı farkedildi. ve en son küpte de nesne olmadığı farkedildi. bu küpler render hesaparından otomatik çıkartılarak render sürelerinde ciddi zamanlar kazanılır. eğer bir ışın bir küpe giderken içinden geçtiği küp içinde bir nesne tanımlı ise, o zaman o küpe başka ışın testleri de yapılarak onun içindeki yüzeylerin etkisi hesaplanır. aksi halde küp hesaptan atılıp zamandan kazanılır.

bu sayede sonuç kalite aynı kalmakla birlikte gereksiz hesaplardan kurtularak render süresinde hiç bir görsel etki yaratmayan bir çok işlemden korunuruz.

var olan hızlandırma sistemlerini elbette bu kadar basit açıklayamayız. aksi halde oturmuş devrim yaratan bir renderer yazıyor olurdum :). ama işin en temel teorisi bu.

elbette bu ışın izlemeyi hızlandırma yöntemlerinin avantajları ve dezavantajları olabilir.

diyelim ki sahnenizde 4 tane vertexten oluşan bir düzlem var sadece

scanline :

4 tane ışın izleme hesabı ile sahnenin ışık ve gölge tahminini yapabilir. ve çıkan sonuçlarla, render alanındaki pixellerin kesişip kesişmediğini test ederek pixel sayısı + 4 hesapta renderi tamamlayabilir.

uzay bölümleme :

uzayı önce tanımlanan verilerde bölümlere ayırır ( biz 10 x 10 x 10 bölüme ayırmayı varsaydık. devam edelim öyle )

öncelikle uzaydaki küplerde ışınkesişmeleri varmı diye her küpe ışın izleme hesabı uygulanacak. bu ilk bakışta 1000 tane ışın izleme demek. bu hesabı yaptıktan sonra ışın kesişimi algıladığı küplerde bulunan vertexlere ışın izleme uygulayacak. toplam 1004 ışın izleme hesabı yapması gerekecek. pixellerle kesişen ışınları tahmin edecek.



peki bunun neresi avantaj?

çok basit. uzayda bir noktada 1500 vertexli bir çaydanlık olsun, ona uzak bir yerde de 1500 vertexli bir çaydanlık daha olsun.
scanline her vertexi ve her pixeli tek tek hesaplayacağından render süresi katlanarak artar.

halbuki uzay bölümleme ile aynı olay, render alanındaki pixellerden çıkan ışınların sahnedeki nesnelerle kesişip kesişmeme hesapları yapılarak, ekranı etkilemeyen alanların hesaplarının otomatik iptali ile hiç bir zaman görmediğimiz ve sahneye hiç bir zaman etkisi olmayan poligon, ışık ve materiallerin hesaplanmasının önüne geçilir.

yani scanline basit sahnelerde ve büyük ebatlı renderlarda çok hızlıdır. sahne karmaşıklaştıkça katlanarak şişer.

uzay bölümleme sahne karmaşıklaştıkça render süresindeki artış çok düşük olur. çünkü sonuçta yapılacak temel hesap pixel sayısı ile alakalıdır. ancak render ebatları büyüdükçe pixel sayısı katlanarak arttığı için ebatlar büyüdükçe uzay bölümleme şişebilir.
yine de, render hesabının büyük bölümünü kaplayan irradiance hesapları yada photon mapping uygulamalarının yoğun olduğu sinema grafikleri hesaplanırken ekrandaki pixel sayısından ziyade ekranı etkileyen yüzeylerin ışın, gölge ve yansıma hesapları inanılmaz boyutlarda olduğundan pixel sayısının artmasının render´a katkısı önemsiz sayılabilir.

her ne kadar açıklayabildim bu uykulu halimle bilmiyorum. ama sonuçta uzay bölümleme bir şekilde render alt yapısında bir çok değişik işlemin hesabını hızlandırmak amacı ile bolca kullanılır....

tabi uzay bölümleme işlemleri sırasında uzayın bölümlere ayrılmasının kriterleri bulunur. mesela uzay kaç ana kutuya ayrılacak, sonra içinde bulunduğu nesnelere göre ana kutular daha küçük alt kutulara ayrılacaklar mı, ayrılacaklarsa en küçük kutu boyutunun kaç olmasına izin veriyoruz, veya kutu boyutu bi tarafta dursunda, en küçük kutunun içinde 5 poligon kalana kadar parçala böl küçük kutulara ayır mı diyoruz.

işte bu ayarlar önemli. bu ayarları doğru yapabildiğin takdirde sahnendeki ışın hesaplarında ciddi bir performans kazanabilirsin. özellikle animasyon renderlarında çok uzun sürecek işlemleri ciddi şekilde kısaltabilir ve çok daha kolay sonuca ulaşabilirsin.

işte bu noktadaki en önemli ayrıntı, bu ayarların doğru olduğu sabit değerlerin olmayışı. bu ayarlar sahnenin içeriğine göre değişir. önemli olan sahneni nasıl küplere ayırdığında daha az işlem gerekeceğini kestirebilmektir. bu da sahnendeki gölge, yansıma ve kırılma içeren bölgeler ile doğrudan alakalıdır. hangi ayarı nasıl yapmak gerektiği hakkında fikir vermek isterdim. ama bu gerçekten ancak tecrübe ile gelişebilecek birşey ve ortada bir sahne olması gerekir bir fikir verebilmek için. ama başka bir sahnede o fikirler anlamsız kalabilir. deneyip görmek deneyim kazanmak biraz çıldırmak :) gerekebilir.

iyi gazel okuduk. gelelim ayarlara

uzayı ayırdığımız küplere bundan gayrı grid diyeceğim. zaten karşınıza hep bu isimle çıkar.
face limit,
uzaydaki en küçük grid içindeki olabilecek en fazla poligon sayısı. bu değeri 5 olduğu zaman, renderer uzayı en küçük gridde 5 poligon kalana kadar daha küçük gridlere ayırır. bir grid içinde nesne bulunuyorsa önce bu grid´i ortadan ikiye ayırır. eğer böldüğü yeni gridlerden birinin içinde 5´den daha fazla poligo varsa gene tam ortadan ikiye ayırır. yeni oluşan gridlerde hala 5´den fazla poligon varsa tekrar ikiye ayırır. bu şekilde limite kadar devam eder. tabi bu durum, daha küçük gridlerin oluşması için daha küçük face limit değeri girmeniz sonucu bellek kullanımında artışlar olur. bu rakamı abartırsanız, bilgisayarınızın asla yetemeyeceği kadar ram ihtiyacı duyabilir ve zaten işletim sisteminin kilitlediği ram hücrelerine saldıracağı için kilitlenir veya hata verir. bu rakamı dikkatli kullanmak gerekir. küçük değerler genellikle ışık hesaplarını ( özellikle ışın izlemeli gölge, yansıma ve photon mapping ) hızlandırır. ancak değer küçüldükçe rami katlanarak daha fazla kullanır.

max division yada bazı sistemlerde max size,
bu, uzayın kaç ana grid´e bölüneceğini belirler, sahneyi ilk anda daha fazla grid´e bölmek daha sonradan ortaya çıkacak yansıma, kırılma ve gölge hesaplarını inanılmaz hızlandırabilir. ancak uzayı daha fazla grid´e böldüğümüzde her grid içinde kalan nesnelerin ve yüzeylerinin ayrı ayrı listesi tutulması gerektiğinden ram kullanımında artışlar olur. bu değer yükseldikçe genelde render süresini hızlandırmaya yardım eder. ama ram kullanımını artırır.

max depth,
uzaydaki her küpün, kaç defa alt küplere bölünebileceğini anlatır. örneğin uzayı 1000 gride ayırdınız. eğer burdaki değeriniz 10 olursa, daha sonradan her grid 10 ayrı parçaya bölünebilir, icabında böl kardeşim demektir. ve eğer her grid´i ayrı ayrı 10 parçaya daha ayırırsa uzaydaki toplam grid sayısı 10.000 olur ve her biri için ayrı nesne/yüzey listesi tutulacağı için ram kullanımında inanılmaz artışlar söz konusu olur. bu değeri artırmak genelde çok karmaşık yansıma ve kırılmaları hızlandırmasına rağmen ram´den çok çalar. düşürdükçe ram´i daha az tüketir ama hesaplar yavaş olur.

balance,
render sistemlerinde genelde bu değer de verilir. bu değer, durumuna göre, max depth ile face limit arasıdında denge kurar. ne alaka diyebilirsiniz.
küçük gridlere ayırma konusunda face limit´in mi baskın yoksa max depth´in mi baskın olacağını balance ile dengeleyebilirsiniz.
bazı render sistemlerinde de ana gridlerin oranı ile en son oluşan küçük gridlerin oranı arasında bir ilişki kurmaya da yarar. bunun için renderer´in manual´ine bakmak yada teknik destek istemek gerekir.


herkes renderer olarak brazil´i ne kadar sevdiğimi bilir :) lakin brazil´i seven nadir insanlardanımdır.

ben neden sevdiğimi anlatmadan önce sevmeyenlerin neden sevmediğine fikir vereyim. kendilerini bulsunlar :)

öncelikle brazil´in tipini beğenmiyor olabilir. eyvallah :) en güzel mazeret.

sonralıkla, raytracing ne demek ve/veya raytrace accelerator kelimesinin anlamı hakkında fikri olmayan bir kişi olabilir.
bu zaat, raytracing´in mantığını anladığında brazil ve mental ray´in neden prodüksiyon sektöründe asıl tercih sebebi olduklarını zaten görecek ve hak verecektir.

100.000 poligonlu bir sahnede vray ile brazil´i karşılaştırmıştır. dolayısı ile vray brazil´den 20 dk önce bitirmiştir. bu sebepten yavaş bu kardeşim iki ayar yapınca şişiyor gözüyle bakabiliyor olabilir.

arkadaşa önerim 100.000 değil de 20.000.000 poligonlu ve bol yansımalı/kırılmalı bir sahnede test etsin vray ile brazil´i. vray light caching olayının başındayken brazil muhtemelen render´in son ışınlarını gönderiyor olur... tabi accelerator ayarları doğru yapıldıysa.

rendererler günümüzde yeterince gelişti. yani bir görüntüyü birisinde oluşturup da diğerinde oluşturamama gibi bir durum ancak yapabilen ve yapamayan diye kıyaslanabilir bence.
bu durumda renderer´i seçerken oluşturduğu sonuç görüntüye değil de, sektörünüze uygun ne sunduğuna bakmak en iyi fikir olur diye düşünüyorum.

örneğin mimarsan vrayden şaşma. basit hızlı kolay kafa şişirmez. ama karmaşık sahnelerde, zor hesaplarda ve stabil çalışmanın şart olduğu çok uzun süreli renderlarda şişer yavaşlar, ve çoğu zaman offf.. aman yaw yapamadım işte deyip zort diye bir hata verir.

prodüksiyon sektörünü hedeflediysen, 20 - 30 milyon dan başlayıp 100 - 500 milyon poligonlu ( sektör kapasitesine göre milyarlarca poligona kadar ) sahnelerle çalışman gerekeceğini hatırlamak gerek.
bu durumda stabil, ve çok uzun süren renderlarda işletim sisteminden bağımsız çalışabilen ve stabilitesini koruyan bir render sistemini tercih etmek gerekebilir. özellikle, film gibi kurgularda yansıma kırılma ve ışık etkileri çok ön planda ise, raytracing hesapları aşırı önem kazanacağından raytracing hızlandırma konusunda başarılı bir renderer seçmek gerekir.
görsel kalite son derece önemli ise, shader yorumlama tekniği en başarılı olan render sistemi tercih edilmelidir diye düşünüyorum.

örneğin mental ray shader yorumlama konusunda en başarılı sistem gibi görünüyor. ama raytracing hesaplarında brazil mental ray´i katlayabiliyor performans olarak. bu da zaten aynı shader kalitesini biraz daha artist emeği ile yakalayabilen brazil´i daha tercih edilebilir hale getiriyor. vray ise prodüksiyon sektörüne henüz girebilecek bir renderer değil.

öte yandan mental ray veya brazil´i mimari sektör yada hızlı sunum gerektiren ( günümüz türkiyesinde :) çalışmalarda vray´in performansını yakalaması mümkün değil.

3d işinizse, raytracing ayarlarını bilmek çok önemli
3d işinizin bir parçası ise, ayarlarını bilmek çok önemsiz :)


emre ustam kusuruma bakmayın :) gaza geldim yazayım dedim. umarım okursunuz sıkılmadan.

aynı hata bendede var bende v-ray 1,5 kulanıyorum neden olur ayarı varmıdır?

zaman ayırdığın ve zahmet ettiğin için çok saol. işime yarayacak çok noktaya değinmişsin. teşekkür ederim.