Skoti

Blender zapisując do exr zapisuje to co pokazuje (dlatego mimo że zapiszesz obrazek do exr masz małą precyzję i będziesz widział kłopoty z utraconą precyzją (32bit float zbuffora -> 8bit na kolor int -> 32bit na kolor w exr). Faktycznie źle się wyraziłem - pozwala na większą liczbę kombinacji w danym przedziale liczb co wpływa bardzo korzystnie na zapis obrazu (dużo większa precyzja w liczbach bliskich 1, a mała w bardzo dużych liczbach (int ma stałą odległość pomiędzy kolorami)). Nie wykorzystuje scanline, a do przyspieszenia renderingu i sprawdzania w co najprawdopodobniej uderzy promień używa drzew - wcześniej ósemkowego (octree), a w 2.5 dostał jeszcze kilka odmian BVH (dzięki czemu przyspieszył) Wiesz nazwy obiektów, siatek, kości, materiałów, tekstur, grup wierzchołków, grup materiałów, cząsteczek, włosów, pomnóż to przez ilość wszystkiego na scenie i może to trochę zajmować - każda jedna rzecz to dodatkowe 70bajtów (ofc każdy obiekt może mieć wiele innych, każdy materiał może mieć wiele tekstur...) - da się to przeżyć, ale da się też przeżyć 30 znaków na nazwę.

ZBuffer jest 32 bit, ale 32bit int (1 bit na znak i 31 na liczbę) nie równa się 32bit float (1 bit na znak, 8 bitów na wykładnik (liczba całkowita) i 23 bity na liczbę całkowitą) - we float masz dużo więcej możliwych kombinacji (dlatego np. od kiedy karty graficzne obsługują tekstury zmiennoprzecinkowe, problemy z precyzją zmalały prawie do zera). Jak zapiszesz Zbuffor w blenderze (np. do png (zapisujesz liczby całkowite), albo po prostu oglądasz w okienku to nie dziwne, że widzisz problem, bo blender zapisuje/wyświetla renderery w liczbach całkowitych (1 int to 1 piksel (po 8 bitów na każdy kanał)), i tracisz wtedy precyzję - w wypadku zbuffora (szara mapa czyli każdy kanał ma takie same wartości masz tylko 256 stanów (co strasznie wygląda i sugeruje na małą precyzję) - ale to co widzisz, nie musi być tym co jest wykorzystywane (czy jest nie wiem bo nie zagłębiałem się w źródła, ale raczej tak sądząc po braku większych problemów z bufforowanymi cieniami (które właśnie opierają się na renderingu ze światła w kierunku padania z przycięciem far przy końcu Dist - jeśli byłoby to na liczbach całkowitych więcej byłoby artefaktów niż cieni ;p))). Tylko co precyzja buffora głębokości ma wspólnego z problemem nie mam pojęcia (tym bardziej, że zbuffor jest w blenderze tworzony jako "efekt uboczny" do wykorzystania w composite nodes (po prostu jak primary ray uderza w najbliższy obiekt, zapisuje nie tylko kolor, ale i odległość (interpolowaną liniowo pomiędzy bliską (0) i daleką (1) płaszczyzną przycięcia kamery))) - nie służy do samego tworzenia sceny. Tak takie liczby w C/C++ to double (64bit) i long double (80bit) - a nawet na wielu GPU (większość dosyć nowych) takie liczby są możliwe (wydany nie darmo nowy OpenGL wymusza wręcz 64bitowe zmienne (AMD chce emulować takie liczby, na kartach, które nie mają odpowiednich jednostek - budżetowych kartach)). Jednak zupełnie nie o to tu chodzi i nie ma to nic wspólnego zbufforem (ani brakiem precyzji w 32bit zmiennoprzecinkowych) - po prostu dac zna jedynie liczby całkowite. Blender w większości jest pisany w C, a tam nie ma "samo rosnących" stringów (po zmianie alokuje nowe miejsce w pamięci, kopiuje, i usuwa stare) tylko tablice znaków wcześniej alokowane (ofc da się to samo uzyskać za pomocą realloc, ale nie widzę sensu) - po prostu ustalili, że n znaków będzie wystarczające i nazwa w obiekcie (strukturze) to char name[30]; na sztywno (bardzo często stosowane rozwiązanie) - pewnie nie jest też na sztywno w pisane 30 tylko ustalona stała i wystarczy zmienić jej wartość, żeby można było więcej - ja w bazie danych też nie daję więcej na nazwę niż 30 znaków ;p.

Działa - ustawiasz Smooth View w milisekundach (1000 to jedna sekunda) i przy przechodzeniu z front do top, etc... masz płynne przejście. Ja wolę do orientacji włączyć sobie View Name, który napisze mi która to kamera, zamiast tracić czas na oglądanie animacji, ale jak najbardziej działa (i to od dawna, a nie od wersji 2.49).

Modyfikator Subsurf (Subdivide Surface) z algorytmem Catmull-Clark (używanym w popularnej ostatnio tesselacji), i zmieniając jego poziom. Nie znam takiej opcji.

Tak - nie dla każdego KDE jest idealny, bo np. na komputerze z 64mb ram nie będzie dobrym rozwiązaniem, a wręcz tragicznym (wtedy wkraczają e17, lxde (xfce nie bo się roztył do poziomu kde/gnome i już nie ma żadnego racjonalnego powodu, żeby go używać - tak jak gnome ;p)). Nie sądzę, żeby była regresja względem Visty, a w niej wiele się zmieniło (wygląd to najmniejsza zmiana)... po prostu nie wszystko jest tak łatwo dostępne jak np. w KDE i np. do zaznaczania wielu ikonek musisz w ustawieniach explorera ustawić, żeby pokazywał check box (będą tak jak + w KDE) - takich rozwiązań w Vista i 7 jest bardzo wiele - w Gnome po prostu nie masz wyjścia musisz robić to tak jak za czasów xp czy 98. Może psioczyli bo w żadnej bibliotece nie ma każdego rodzaju widgetu (np. nie ma koła kolorów, a inne proste wybieranie koloru (gtk ma kilka, bo to jest do tego programu pisane (Gimp Toolkit), ale do innych programów już się nie nadaje)). Co do dokumentacji to żadna biblioteka okienkowa nie ma tak dobrej dokumentacji - można ją pokazywać jako wzór... z QT, Wx i GTK to GTK wyraźnie kuleje pod tym względem, a pisanie widgetów w QT to czysta przyjemność. Potrzebowałem nody (do toola sterującego postprodukcją w moim silniku) i godzinę później już je miałem widget gotowy do wykorzystania (działają tak jak w Blenderze i tak samo możesz robić sobie zoom in/out): http://img251.imageshack.us/img251/9176/1157y.jpg Czyli rozumiem nie używasz Dolphin, Gwenview, digiKam, Okular, Amarok, Kate, skype, Linux MultiMedia Studio (jedyny warty uwagi program do tworzenia muzyki pod linuksem), Konsole, Konversation, Luxrender (który zrezygnował z wx na rzecz qt), Ark - ale jeśli używasz jakiejś alternatywy do wyżej wymienionych (poza Lux, którego rzadko używam), która dorównuje tym programom - jak nie chcesz ciągnąć tematu to napisz na priv bo mnie to ciekawi (ja szukałem, ale nie znalazłem żadnej przyzwoitej chociażby konkurencji - niestety)

Nie - to jest argument za siłą marketingową firmy Canonical (pierwszy linux którego widziałem plakaty na mieście, oraz pierwszy i jedyny do którego firma dokłada oferując płyty i wysyłkę gratis ;p). Nie ma jednego słusznego rozwiązania - jest przecież jeszcze E17 ;p. Nie pisałem, że Gnome jest gorsze od XP tylko od nowszych niż XP windowsów - co do wirtualnych pulpitów etc, to możesz mieć to samo i na XP (instalując jeden z tysięcy programów tego typu... lub instalując KDE w wersji dla windowsa ;p). Nie liczyłbym na to Możesz napisać jakie? Możesz napisać jakie (żebym mógł zapytać jakie znasz lepsze alternatywy dla innych).

N-pigeon zadał pytanie to dostał nie wyczerpującą, ale jednak dość solidną odpowiedź, do której pewnie będzie ciężko się ustosunkować i będzie koniec flame ;p

Wygoda i wydajność pracy (wszystko możesz zrobić na wiele sposobów, który akurat jest Ci potrzebny (nawet prozaiczne - nie chce mi się wyciągać klawiatury z pod biurka, żeby zaznaczyć kilka plików (klawiatura pod biurkiem na szynach) to kliknę szybko w + na pliku)), konfigurowalność (prawie wszystko jest konfigurowalne i jest w ustawieniach systemowych - w gnome jeśli już coś jest konfigurowalne to tylko w minimalnym zakresie, bo użytkownik może się przestraszyć opcji... problem gdy chce przestawić opcję które twórcy gnome uznali za zbędne to musi edytować pliki tekstowe i bazy danych, zamiast wejść w ustawienia i przełączyć jedną opcję - ach ta wygoda), oparte jest na lepszej i bardziej przyszłościowej bibliotece Qt zamiast na Gimp Toolkit (GTK w którym nikt już nie chce pisać od kiedy QT wyszło na LGPL (nie dawno) - nawet twórcy ubuntu na stronach nokii chwalą QT i piszą, że się na niego przenoszą), dzięki czemu programy są wygodniejsze (np. panele są dokowane i można sobie dostosować aplikację do siebie), a aplikacje pisze się szybciej i są lepsze mimo że młodsze (przykłady z pamięci Opera, digiKam, Okular, K3b, Amarok, SMPlayer, Krita - do tego można doliczyć Adobe Photoshop Elements czy Lightwave Core, ale jeden tylko win/mac, a drugi jeszcze powstaje), Dolphin posiada bardzo łatwe skrypty menu (dzięki czemu w kilka linijek napiszesz montowanie plików iso pod prawym przyciskiem - ofc nie musisz, bo są na kde-apps). Dodatkowo QT i KDE szybciej reaguje na rynek - jak kupisz teraz nowy tablet PC z multidotykiem to aplikacje KDE4.4 i QT4.6 go obsłużą... GTK i Gnome pewnie do wersji 4 nie będą potrafiły. W KDE po włożeniu Pendrive czy czegokolwiek nie musisz szukać wśród plików na pulpicie - pojawia się informacja z ikonki urządzeń o podłączeniu urządzenia (tak samo nie zasypuje masą okienek, o błędach czy kopiowaniu plików - to wszystko jest w obszarze powiadomień i nie przeszkadza podczas pracy). Uważam, że tylko trzy programy na GTK są warte używania (jednak wiele zyskałyby po zmianie biblioteki), a są to Gimp (na które ludzie narzekają, bo toole nie są dockowalne), Eclipse i Firefox... są to dobre rozbudowane aplikacje których jednak wadą jest GTK - no ale nie ma co się dziwić, bo IBM nie chciał pisać na QT, jak było na GPL (zamiast LGPL), z jasnych przyczyn, a Mozilla (jako twór wielu firm które wydawały programy o zamkniętym kodzie jak Netscape) wprost nie mógł. Gnome oferuje funkcjonalność poniżej KDE2 (już 10 lat temu jak porównywałem to brakowało mu wiele, a od tamtego czasu Gnome stoi w miejscu). Co do założeń Gnome to są one takie: Zrobić alternatywę dla KDE, tylko na jakiejś bibliotece zgodnej z GPL (QT było wtedy na licencji niezgodnej z GPL czy LGPL - KDE było na GPL, ale korzystało z QT) - niestety nie mieli ani kasy, ani wielu programistów więc, użyli Gimp Toolkit, który powstał dla Gimpa, i oparli na nim środowisko, które nigdy nie dogoniło KDE z tamtych czasów. Rozwój Gnome stanął pomiędzy wersją 1, a 2, a później były tylko coraz gorsze pomysły (przepisać GTK co C#, który działa na linuksie tak, że szkoda gadać (projekt mono który pisze twórca Gnome wzbudza tylko śmiech)). Tak było - jak jesteś szefem firmy która nie wie czy nie zamknie softu/niektórych programów jak zdobędzie popularność używałeś GTK (tak jak twórcy ubuntu który ożywił Gnome z grobu niepamięci, bo jak sami przyznają QT pozwalało tylko na otwarte programy (licencja GPL), lub komercyjną licencję która kosztowała swoje - teraz jest na LGPL i wszystko powoli wraca do normy). Taka tendencja jest mniej więcej dlatego, bo użytkownicy KDE po przejściu do Gnome są pozbawieni podstawowych narzędzi, a użytkownik Gnome to przeważnie początkujący który przeszedł z XP i nie zna wielu małych narzędzi narzędzi którymi dysponuje KDE które umilają i przyspieszają pracę z komputerem (zanim poznałem dobre IDE programistyczne mogłem programować w notatniku, zanim nie zrobiłem prawka jazdy mogłem chodzić na piechotę wiele kilometrów (np. 10km, jak w nocy nie było autobusu przez 2h) i uważałem, że nie potrzebuję auta, zanim poznam coś wygodnego tego nie potrzebuję i uważam, że to co mam jest równie wygodne, bo nie mam porównania). Gnome nie jest nowoczesny, a Windowsowi w wersjach powyżej XP wiele ustępuje (na szczęście nautilus ma przeglądanie w kartach co jeszcze go trochę ratuje w porównaniu z win). Gnome 3 z tego co piszą twórcy nie będzie rewolucją, zmieni się kilka małych rzeczy (płynne przejście pomiędzy gdm a gnome, kilka nowych tapet, czcionek, motywów, ikonek, poprawki w apletach, kilka animacji kilka poprawek w programach typu Brasero i to by było na tyle, w mapie drogowej na Gnome3) i bez wielkich nowości typu multidotyk, wygoda zarządzania plików, zmniejszenie ilości okien fruwających po ekranie przez wrzucenie komunikatów i zadań na plikach do osobnego panelu chowanego w ikonce i masy innych rzeczy znanych z KDE (a do wydania mimo, że pół roku to pewnie znowu przeniosą premierę o pół roku) Innymi słowy nie licz na wielkie zmiany w Gnome, bo on się nie zmienia od 10 lat praktycznie (zmiany jakie zaszły przez 10 lat są dużo mniejsze niż pomiędzy KDE 4.0, a 4.4). Gnome zresztą ciężko się będzie rozwijać ze względu nie tylko na to, że nie wiele osób chce go rozwijać, a przez GTK, które umiera, to że GTK jest tylko do tworzenia okienek w przeciwieństwie do QT czy Wx, które są pełnymi zintegrowanymi pakietami do wszystkiego (obsługa sieci, wejścia, wielowątkowości, OpenGL, Webkit, obsługi urządzeń najróżniejszego typu i masa innych rzeczy - już pomijam, że samo tworzenie okienek czyli to czego konkurentem jest GTK jest dużo lepiej przemyślane oparte na layoutach (w qt są jeszcze świetne sockety), a programuje się w obiektowym języku C++, a nie w C). Co więcej Gnome to w praktyce Miguel de Icaza - człowiek, który się gdzieś pogubił który czego się nie dotknie to upada - Ximian (kto to jeszcze pamięta?), Gnome (cudownie wskrzeszony przez Ubuntu już z grobu), Mono (projekt z założenia skazany na porażkę, ale pewnie będzie to robił tak długo jak się da bo dostaje nie małą kasę od Microsoft za robienie zamieszania i złudzenia wśród programistów, że C# jest wieloplatformowy (jak się dowiadują, że żaden praktycznie program nie działa na macos i linux jest już za późno)), chciał pomóc Microsoftowi w promowaniu w części zamkniętego formatu ooxml (np. docx), kosztem otwartych formatów ISO czyli odf (np. odt) pisząc artykuły, promujące format MS i oczerniający ODF(na szczęście to też zaraz upadło po jego zaangażowaniu i MS w nowych produktach obsługuje ODF ;p) - niedawno za swoją pracę na niekorzyść linuksa (promowanie .Net i formatów MS, kosztem rozwiązań otwartych) dostał Microsoft Most Valuable Professional.

System MacOS X jest bardzo fajny (mam go na MacBooku obok linuksa), ale osobiście wolę korzystać z Arch Linux + KDE.

Światło Sun i ustawić mu w Sky/Atmosphere szczegóły jak ma wyglądać.

To, że buildy są robione na ubuntu to nie działa niby na innych dystrybucjach? Nie wiem po co takie teksty piszesz. Swoją drogą jeśli chce się oglądać rozwojowe wersje to lepiej samemu budować (zbudowanie aktualizacji sprowadza się wtedy do "svn up && scons" i poczekania na koniec (wcześniej ściągnąć z svn i jeśli się chce zoptymalizować konfigurację w config/linux2-config.py))... jeśli jednak się nie potrafi lub nie chce można ściągać z graphicall.org zoptymalizowane do sprzętu budującego, a nie własny, lub jeśli się ma arch to wydać polecenie "yaourt -S blender-svn" (ściągnie się wersja najnowsza (z sekundy rozpoczęcia ściągania i zbuduje (jednak nie będzie, żadnych optymalizacji, bo buduje automat i nie ma się dostępu do config/linux2-config.py))). Dokładnie tak - dlatego większość osób razi się rozejrzeć i sprawdzić co pasuje, a nie słuchać zdania innych, które rzadko zbiega się z preferencjami innych.

Jednookienkowy Gimp już jest gotowy http://www.linuxzone.es/wp-content/uploads/2009/10/gimp-single-window-mode.png (2.7 - gałąź developerska tak jak 2.5 blendera), a oficjalnie pojawi się w 2.8 (z wieloma innymi usprawnieniami (m.in. obsługi tabletów), które już są w 2.7). Mnie bardziej interesuje to czy zintegrują gimpa z gimp paint studio, czy dalej trzeba będzie go dociągać osobno (http://code.google.com/p/gps-gimp-paint-studio/)... pewnie dlatego bardziej mnie to interesuje bo na linuksie nie przeszkadza tak bardzo wielo-okienkowy interface, bo lepiej można zarządzać okienkami ;p (dopiero kiedy próbowałem użyć gimpa na windowsie to zrozumiałem dlaczego tyle osób narzeka ;p). Pewnie w ustawieniach będzie po prostu trzeba wpisać ścieżkę do programu i tyle - blender po prostu zapisuje w temp plik i otwiera za pomocą jakiegoś programu - plik możesz otworzyć nawet za pomocą paint - a po kliknięciu ładuje ją i robi normalne rzutowanie tekstury z kamery - nic wielkiego, a cieszy ;p

XSI jest dostarczany razem z bibiotekami (bez tego nawet na fedorze by nie działał ;]), więc nie ma problemu na ma problemu.

FC do wersji 4-5 działały całkiem dobrze (Redhat musiał przyciągnąć użytkowników redhata, który przestał być darmowy i fedora została powołana właśnie po to, żeby społeczność skupiona wokół redhata nie uciekła do konkurencji i wtedy nie była poligonem tylko stabilną ciekawą dystrybucją). Z KDE/Fluxbox/Gnome/XFCE/E17... to wszystko zależy co będziesz robił - jeśli ma to być stacja robocza to zdecydowanie KDE do codziennego użytku (procek i rendering będzie tak samo szybko się robił jak i na fluxboksie - no chyba, że na scene braknie miejsca w pamięci - ale to wtedy wystarczy się przełączyć na jakieś środowisko które mniej pamięci zużywa (fluxbox lub e17 (ja wybrałbym e17 ;p)). Jeśli chcesz tylko i wyłącznie do renderingu to można faktycznie użyć mało wygodnego fluxboxa lub wygodnego, ale jeszcze nie do końca stabilnego e17, ale w takim wypadku to najlepiej zrezygnować całkowicie ze środowiska biurkowego i włączyć X z xterm (konsolą, z której uruchomisz blendera), lub nawet sam blender zamiast xterm uruchamiający się razem z X (coś jak w chrome os od google, który włącza tylko przeglądarkę Chrome i nie ma żadnego innego programu). Co do systemów plików to ja na Twoim miejscu rozważałbym większą ilość: EXT4, Reiser4, JFS, Btrfs i XFS. XFS (zaprojektowany przez SGI (twórców OpenGL)) jest bardzo szybki jeśli pracujesz na dużych plikach, ale przy usuwaniu wielu małych plików jest strasznie wolny. JFS (stworzony przez IBM) szybki system plików (~ext4), ale np. nie obsługuje dynamicznego zmniejszania w LVM (jeśli inna partycja potrzebuje miejsca to nie zabierze automatycznie z niej - za to jak ta partycja potrzebuje miejsca może się sama dynamicznie rozszerzyć względem innych w danym LVM) - z tego powodu zrezygnowałem z niego na korzyść EXT4. Reiser4 bardzo szybki system plików, ale dosyć nowy (tzn jest już chwilę i jego twórca potrafił trafić za kratki za morderstwo, ale w jądrze dopiero teraz się pojawił i jeszcze nie jest dobrze przetestowany przez większe grono użytkowników), i nie zaufałbym mu do przechowywania ważnych danych. Btrfs (B-tree File System, ale nazwa ma też nawiązywać do "lepszy fs" ;p - pracuje nad nim Oracle) jest bardzo szybki (~ReiserFS), i ma zalety ZFS znanego z Solarisa... ale tak jak Reiser4 jest dosyć młody (chociaż w przeciwieństwie do reiser4 rozwija się bardzo dynamicznie i jest wspiera duża firma)... póki co mimo wszystko nie polecam. EXT4 to stabilny i szybki system plików, ale nie najszybszy. Jednak to, że jest stabilny i posiada kurczenie się partycji w ramach LVM (zaleta tylko jeśli chcesz stosować LVM), jest teraz moim głównym systemem plików. Wybór należy do Ciebie ;] Nie jedyna i są dużo lepsze - pakiety są przygotowane do RHEL (komercyjny Redhat) i najlepiej działa na nim, a CentOS to RHEL ze zmienioną nazwą, ikonkami i bez supportu (dzięki temu darmowy) i jest on dużo lepszym rozwiązaniem niż fedora (a z softimage czy maya nie ma problemu na innych dystrybucjach - trzeba tylko zainstalować rpm (lub w debian/ubuntu/... pakiety rpm przerobić na deb za pomocą programu alien)).

Zaznacz siatkę i wciśnij menu Mesh -> Vertices -> Separate (lub po prostu wciśnij P - skrót klawiaturowy).

Wstawiając nowy obiekt wstaw nowy obiekt, a nie nową siatkę do istniejącego obiektu. Czyli jak wstawiasz te obiekty to wstawiaj w Object mode, a nie w Edit mode (czyli w trybie edycji zaznaczonego, istniejącego już obiektu).

@natas: Nikt Ci nie powie co będzie Ci pasować - mi nie pasują dystrybucję o których piszesz w najmniejszym stopniu i już chyba wolałbym się przerzucić na windowsa (na szczęście są inne dystrybucje pasujące do mnie, FreeBSD i MacOS ;p). Za to odradzałbym Ci fedorę - ta dystrybucja to zwykły poligon doświadczalny komercyjnego redhata i wydania stabilne dystrybucji potrafią mieć wersje beta lub alpha programów (a nawet wstępne developerskie branche jak było z debuggerem gdb (redhat chciał przetestować swój branch gdb nazywany wtedy jeszcze archer)). Dodatkowo ostatnio jak "testowałem" fedorę, aktualizacje też się nie popisały i w aktualizacjach poszła biblioteka do obsługi sieci stosowana przez wiele programów w tym firefox i... program do aktualizacji systemu (więc poprawka sama nie przyjdzie i trzeba było kompilować bibliotekę ręcznie, żeby przywrócić sprawność systemowi). Z tego co mówisz wynika, że nie wiele wiesz o linuksie, więc Ci nie polecę dystrybucji, które ja używam/używałem (slackware przez dekadę i arch linux od kilku lat), ale myślę, że warto się zainteresować sabayon linux - dystrybucja europejska więc, olewa sprawy związane z patentami w stanach i masz dużo większy zestaw sterowników (np. sterowniki do większej ilości kart wifi czy nawet modemów neostrady na usb, sterowniki do kart graficznych z automatyczną konfiguracją już na liveCD), kodeków out-of-box, dodatkowo ma wiele zamkniętych programów, które wiele osób sobie chwali (przykładem niech będzie np. skype) - dla osoby początkującej jest w sam raz. Sabayon to dystrybucja pochodząca od Gentoo, ale stworzona dla początkujących, skonfigurowana, wszystko out-of-box i nie trzeba kompilować wszystkiego, bo ma własne repo z binarnymi pakietami (ale można, bo jest kompatybilna z gentoo i masz wszystkie jego narzędzia więc jak chcesz skompilować coś z repo gentoo to kilka kliknięć (i dużo czekania ;p)). Co do środowiska graficznego to polecam zdecydowanie KDE - zużywa minimalnie więcej pamięci od Gnome, ale IMO warto, bo dużo przyjemniej i szybciej się pracuje. Gnome pamiętam jeszcze za czasów 1.x gdzie gonił funkcjonalnością KDE (bo QT nie było wtedy na licencji zgodnej z GNU GPL/LGPL więc chcieli zrobić coś otwartego i zrobili gnome na Gimp Toolkit (GTK)) i wtedy był realną alternatywą, ale od tamtego czasu stoi praktycznie w miejscu i jedyne co zwiększyło jego popularność to Ubuntu (które nie wybrało kde ze względu na licencje Qt (była wtedy już GPL, ale żeby napisać zamknięty program trzeba było kupować komercyjną licencję) - teraz twórcy Ubuntu reklamują Qt na stronach nokii (po zmianę licencji na LGPL) i zapowiadają migracje swoich narzędzi jak i systemu). Co do pytania o zarządzanie pamięcią i prockiem to tak różni się ona od XP (gdzie wiele rdzeni było marnowane przez słabą implementację SMP, słabe planer, a pamięć była alokowana tylko na żądanie aplikacji (co nie jest najszybszym rozwiązaniem))... Vista i 7 trochę tu zmieniają bo jest już lepsza implementacja SMP, lepiej napisany planer i pamięć jest prealokowana jak w linuksie/bsd/macos/solaris... jednak implementacja SMP ustępuje tej napisanej przez Intela w Linuksie, planer w linuksie przyspiesza i w tej chwili już jeśli się nie mylę trzecia zmiana planera w jądrze z serii 2.6 jest (planer stosowany w windowsie czy bsd został porzucony po serii 2.4), a pamięć windows alokuje tylko kilkaset mb (za co mu się obrywa, że potrzebuje więcej zasobów), a nie jak linuks praktycznie 100% - dzięki czemu jeśli renderer chce więcej pamięci (niż te kilkaset mb prealokowanych przez viste) to linux nie musi jej alokować tylko podaje wskaźnik do pamięci zaalokowanej przy starcie systemu (co zmniejsza czas renderingu). @tjviking: możesz powiedzieć coś więcej o Cloud Computing w ubuntu? Bo z tego co na szybko zobaczyłem na stronie ubuntu to prywatna chmura to nic innego od klastra jaki mam w domu na archu, a publiczny to chmura nie ubuntu tylko Amazon (Amazon's Elastic Computing), którą testowałem w 2008 po jakimś artykule opisującym go w Linux Magazine. Czym to "ma cloud computing" różni się od tego co mają inne dystrybucje? Pytam z ciekawości bo nie czytałem dokładnie info na stronach ubuntu - może np. są jakieś promocje na obliczenia w Amazon lub jest nawet darmowe?

Klasycznego pathtracera nie ma w Luxrender - tam jest bi-pathtracer, ale też nie klasyczny bo to rendering unbiased z Metropolis light transport (który jest mutacją metody Monte Carlo)... więc już na wstępie kłuci się z "algorytmem pathtracera" - co do wersji GPU to ona nie ma działać tak samo, a to samo generować i nie ma co sztywno się trzymać tego co było pisane dla Cpu (daje się łatwo zdekomponować na passy, ale trzeba robić multi render target, żeby zapisywać więcej informacji niż kolor jak normalnie). Ale kto powiedział, że będzie stosowany algorytm z CPU, a nie jego modyfikacja? Tak tylko tym złożonym przepływem jest samo GI. Nie do tego "stworzono" generowanie długich ścieżek (które jest w raytracerach dla wielokrotnych odbić bardziej przydatne), bo sam pathtracer (jako rozwinięcie raytracingu, czyli od kamery do światła) nie pozwala liczyć dokładnego przepływu światła (nie masz np. kaustyki). To daje path casting lub inaczej zwany forward pathtracer (w przeciwieństwie do klasycznego pathtracera i raytracerów, a podobnie jak w Forward raytracing promienie idą od światła do kamery (i ten rodzaj rendererów wymaga już długich ścieżek i daje lepsze rezultaty)).

Na razie się nie dały, bo jeszcze dobrze nie zaczęli robić. Passy nie muszą służyć tylko do tego, a można ich użyć jak przy Deferred shading gdzie przy renderingu pierwszego poziomu zapisujesz dane potrzebne przy kolejnym passie (kolejnej głębokości) i możesz spokojnie to posortować i wysłać do przeliczania tylko te ścieżki, które tego potrzebują. Z obiektowością nie ma to nic do rzeczy, a dzisiejsze pathtracery na raz pracują na kilku ścieżkach (a każda z tych ścieżek jest liczona na kilku rdzeniach). Głównym powodem użycia pathtracerów jest GI i właśnie nie obchodzi cię jakie GI ma 100 obiekt w kolejce odbicia, tylko pierwszy, ewentualnie 2gi - głębiej cię nie obchodzi (nie obchodzi Cię to jaki kolor oczu ma obiekt w innym pomieszczeniu ;p)... za to bardzo ważna dla jakości obrazu (mały szum) jest ilość sample (czyli drzewo pathtracera nie idzie w głąb, tylko w szerz (każda ścieżka ma po kilka poziomów, ale różnych ścieżek jest olbrzymia ilość), co świetnie się zrównolegla na GPU i CPU).

Nie dzieje się wolna amerykanka i licząc w wielu pasach liczysz tylko to co musisz i nic nie czeka (to z czekaniem to był przypadek jakby nic nie zmieniać). Poza tym podaj mi kto liczy na 100 poziomów (nikogo nie obchodzi światło odbite więcej niż 4 razy, ani które przejdzie przez 5-6 ścianek), a ty mówisz o śledzeniu 100 poziomów ;p. Jednak w przypadku robienia w passach nic nie czeka. Kolejny raz się pytam co Cię tak boli obiektywność, skoro to nic nie zmienia (minimalnie zmienia zapis, ale nie jest to zmiana godna wspomnienia).

Możesz powiedzieć co to za różnica jak jest napisany (obiektowo możesz pisać i w C, mimo że nie jest to język obiektowy). Ścieżki są różnej długości, ale jak renderujesz w passach to możesz posortować, po kazdym passie (na GPU zeby było szybko) tak żeby na i wysłać do przeliczenia tylko te piksele które tego potrzebują... ale nawet bez tego wydajność GPU będzie dużo większa niż CPU (nawet jak w procesory strumieniowe w jednym core będzie np. 32 i będziesz, miał 1 piksel taki, że idzie na 5ty poziom, a 31 zostają na pierwszym to zysk z uzyskania 32 pikseli na raz zrównoważy poczekanie na ten 1 piksel kolejne 4 poziomy (na CPU w optymistycznym wypadku (4x core) te 32 piksele byłyby robione przez na 4xcore na 9 razy (31+5 poziomów czyli 36 dzielone 4 rdzenie w wypadku = 9 promieni na każdym wątku)) - ofc to się równoważy bo CPU przeważnie mają 2x większe taktowanie i szybciej wykonują pewne instrukcje... z tym że porównanie było do 1core na GPU a takich zestawów po 32procki jest więcej (po przemnożeniu się liczy w setkach/tysiącach) i w bardzo pesymistycznej dla gpu wersji (wszystkie czekają na jeden procek, a CPU nie czeka na nic- gdyby było więcej poziomów w tych które mają na 1 to CPU pogrążyłby się zupełnie)).

Tu nie chodzi o Tweakowanie źródeł Luxrendera. Jest udostępniona osobna gałąź gdzie przepisują na OpenCL (http://src.luxrender.net/lux-opencl/). Przecież na forum grafików nie pisałbym przepisz sobie sam ;p. Jednak póki co nie ma co w tym branchu oglądać (ostatnio jak testowałem scena cube i światełko wywalało program, bo zajętość pamięci hosta rosła w nieskończoność (8gb mam i się skończyło)). Pathtracer da się na CPU zrównoleglić w bardzo wielu miejscach i na wielu poziomach (rzucanie promieni od kamery, da się przetwarzać równoległo, przeglądanie drzewa w poszukiwaniach który najbliższy obiekt został uderzony, tęż można na wiele wątków rozbić, rzucanie losowych sampli w GI/materiałach Glossy też się da zrównoleglić...). Z pisaniem tego na GPU jest trochę trudniej, ale też się da (w razie jak się nic nie wymyśli to można renderować w kilku przebiegach (każdy poziom, osobno i na każdym będziesz mógł przetwarzać równolegle)).

@mujas: zostanie dodana razem z bmesh (beta3).

Źródła są dostępne i można sobie zbudować we własnym zakresie - ale póki szkoda czasu (póki co nawet nie nadaje się do testów).

Tak są już gotowe od dawna - do Twojego zastosowania idealnie pasuje symulator dymu (a np. jak chcesz lawę to dobry będzie symulator fluidów (bo to po prostu bardzo gęsta i powolna ciecz)). Ale jak chcesz to zrobić szybko, a znasz max'a i pluginy to lepiej zrób tam, zanim się nauczysz użyć tych (a jeszcze smoke może mieć błędy) to pewnie kilka dni zejdzie. Kilka linków (próby programistów (poza fluidem, bo nie wiem kto go robił ;p), więc efekty nie zachwycają):