Skoti

@makak_: tak unifikacja to ważna sprawa dlatego khronos group opracował format collada, żeby przenosić sceny pomiędzy aplikacjami, bez strat (w DTP czegoś takiego nie ma to byś wolał zmienić prace).

Wejdź w panel physics - symulatory ubrań, ciał miękkich, fluidów są od jakiegoś czasu (dymu od 2.5 ;p). Mięśnie można zasymulować za pomocą modyfikatora shrinkwrap (http://wiki.blender.org/index.php/User:Jaguarandi/SummerOfCode2008/ShrinkwrapModifier), ale mięśni jako mięśni nie ma (tzn. są bo ktoś tam pisał i jest udostępniona łatka na blendera z serii 2.4x, ale kod nie jest na tyle dojrzały, żeby do blendera go wsadzić i raczej twórca już nie będzie rozwijał - jak komuś będzie brakować, albo jakiś student będzie chciał napisać w ramach gsoc to się pojawi).

Z komercyjnych poza Maya jest jeszcze Softimage XSI, Houdini, Cinema4d i wiele innych - to, że nie ma 3ds max, czy Lighwave nie oznacza, że innych softów nie ma, więc jak widzisz wcale przejście na linuksa nie ogranicza za bardzo możliwości wyboru.

@Ulfar999: poniosło Cię trochę. Oferty pracy są dla max/maya, ale jak napiszesz, że modelujesz w blenderze i wyślesz swoje portfolio to niezależnie od innego softu przyjmą Cię do pracy (zasady są takie same wszędzie, a programy różnią szczegóły). Większość firm też mimo, że mówi, że film powstaje w np. max większość pracy graficy wykonują w lepszych narzędziach do danych dziedzin (np. modelowanie w modo/blender/silo/wings), a w 3ds jest składany tylko efekt końcowy i renderowany w vray (bo oficjalna integracja jest tylko do max/maya (Lightwave nie ma, Blender dopiero się tworzy i to nieoficjalna, XSI w wersji beta)) - przykład filmu, który tak powstawał to, żeby nie szukać daleko Kinematograf.

Nie dzięki tym ziomkom tylko dzięki temu ziomkowi jak już (jedna osoba to pisała - Farsthary, a dopiero pod koniec prac podłączył się Matt Ebb, żeby połączyć kod Farsthara z blenderem), i tu nie zależy czy jest amatorem, bo pathtracer, photon mapping czy volumetryka to są rzeczy tak dobrze udokumentowane, że napisze je nawet amator - po prostu nie każdemu chce się czytać kod blendera i go modyfikować i zintegrować i wszystkimi jego narzędziami (w wypadku rendererów łatwiej napisać nowy od zera (pierwszy bi-pathtracer z photon mapping ze strukturą akceleracji kd-tree napisałem w 2 dni)). 2ga opcja jest bardzo słaba (jest wiele lepszych opcji ;p) - Kerkythea nie jest już rozwijany, więc nie spodziewałbym się integracji z blender 2.5, jest komercyjna wersja rozwijana (Thea Render), ale imo lepiej zainwestować w Vray (który już praktycznie ma integrację z blender2.5) lub użyć yafaray/luxrender (zależnie czy zależy nam na MLT).

Może dorzucą pathtracing do BI (jeśli będą potrzebować w durian (w alpha 4 mają dodać poprawki w rendererze z projektu durian)). Jest to możliwe technicznie, ale raczej twórcy vraya nie wprowadzą do niego takich zmian pod blendera skoro nie robią eksportera (eksporter jest niezależny i sam nie może dodać node do vraya). Tylko w wypadku nodów postprodukcyjnych - node tekstur czy materiałów będą już problemem.

@czajnick: problem w tym, że tych programistów jest bardzo, bardzo wiele, nic ich ze sobą nie łączy, a co chwile się zmieniają ;].

Wszystko o co pytasz zaznaczyłem na czerwono (jak można tego nie zauważyć to nie wiem ;p), a co do tych kilku narzędzi których nie ma pod "w" to dlatego, że jeszcze ich nie dodano - będzie dopiero w alpha 2 razem z bmesh. http://img22.imageshack.us/img22/567/128i.png

@tjviking: nie pisałem, że wszyscy są, ale właścicielami są programiści pracujący nad otwartym blenderem od lat (i każda aktualizacja projektami np. z GSoC już nie należy do blender fund. tylko programisty, który napisał daną rzecz). Pisałem przecież, że może kupić blendera, ale właściwie to tylko nazwę i przestarzały mało potrafiący rdzeń blendera (pozostawiając jednak dalej go jako otwarty). Może zrobić zamknięty program, ale musieliby włożyć wiele lat pracy, żeby dogonić otwartego blendera (będą musieli wyrzucić wszystko do czego praw autorskich nie ma blender fund - czyli większość), który mimo wykupienia, dalej będzie rozwijany i będzie darmowy (a każda aktualizacja otwartego blendera nie będzie mogła trafić do zamkniętego produktu, chyba, że autodesk będzie każdą taką aktualizację kupował od twórców). W wypadku blendera, czy linuksa wykupienie jest zupełnie nieopłacalną strategią, bo za dużo jest twórców i za bardzo rozsiane prawa - taka strategia jest możliwa np. w wypadku luxrender/aqsis/pixie..., gdzie renderer jest dobry, a mimo to mało osób nad nim pracuje, w wypadku bardzo popularnych wśród programistów aplikacji opłacalność wykupienia kodu jest zerowa (same straty, wiele pracy, żadnych zysków(lub oddalone przynajmniej na 5lat w przód)).

@tjviking: BLender jest na licencji GPLv2. Nie ma żadnych sporów - po prostu w każdym kraju inaczej jest licencja prawnie zgodna (tak samo jak eula microsoft windows też w polsce w kilku punktach jest też niezgodna z polskim prawem np.) ważne jest to, że GPL jest zgodne z amerykańskim prawem i w większości europejskich krajów jest w najważniejszych punktach zgodny z prawem (w tym z prawem uni europejskiej), więc nie ma co tu gdybać - może zamknąć i sprzedawać w jakiś arabskich krajach (ale kodu już opublikowanego nie odbierze), ale w stanach/europie/japoni nie więc można powiedzieć, że żadna poważna międzynarodowa firma. Mógłbyś przybliżyć bardziej przypadek 3delight - ale jeśli kupili prawo do kodu bezpośrednio u twórców (było ich na tyle mało) i wywalili to czego kupić nie mogli to mogli zamknąć (właściciel praw może swój kod na raz rozpowszechniać na ilu chce licencjach)... jednak to że zamkneli nie zmienia faktu, że kod na gpl dalej jest dostępny i może być rozwijany!

@narwik: Zależy jak zasymiluje - jeśli zasymiluje pomysł/funkcje (jak np. ostatnio z narzędziami do loopów/ringów, czy większość zmian w najnowszym 3ds max) to jest ok (bo przecież nie chodzi o to, żeby blender był najlepszy, tylko żeby był wybór i było kilka dobrych softów), jeśli zasymiluje kod to jeszcze lepiej, bo zależnie od sądu będzie musiał wydać kod swojego programu na licencji GPL (co wręcz automatycznie robi darmową konkurencję, bo robi się darmowy fork kodu), lub zostanie nałożona na autodesk gigantyczna kara.

@tjviking: Wykupienie jest możliwe, ale jest bardzo nieopłacalne dla kupującego, bo jest to bardzo utrudnione - wręcz uniemożliwione, bo blender fund. nie jest właścicielem kodu źródłowego blendera, a jedynie jego części i nazwy - więc autodesk kupując od blender fund. (co nie będzie łatwe, bo są tam ideowcy), ma prawo do nazwy, ale nie do programu, czy kodu źródłowego, i musiałoby kupić kod bezpośrednio u każdego kto kiedykolwiek napisał tam chociaż linijkę na licencji GPL (bo nie mogliby zamknąć kodu, bo licencja gpl zabrania - linkując statycznie, czy dynamicznie z kodem gpl, cały kod musi być gpl)... jednak nawet po kupieniu nazwy od blender fund i części kodu, oraz odszukania wszystkich właścicieli kodu i odkupienia od nich, autodesk nie pozbywa się konkurencji - kod już opublikowany jest dalej wolny i po prostu blender zmienia nazwę na mixer i jest dalej rozwijany jako wolne oprogramowanie, a autodesk nie ma prawa nic z tym zrobić! Jak widzisz wykupienie blendera, może i jest możliwe, ale i jedna i druga strona tego nie będzie chciała zrobić.

Puściłem pierwszy filmik i jest na nim blender 2.45.16, więc 2.45 ;]

Bo dużo lepiej rozdziela wątki na rdzenie (a windows mimo poprawy względem xp dalej jest daleko za Linuksem/*BSD/Solaris/MacOS względem wydajności implementacji SMP) i lepiej zarządza ramem - dzięki tym zaletom jest dużo niższy czas renderingu. SM 3 to już staroć o którym się zapomina (żyje tylko dzięki MS w grach dx (ale na OpenGL XP też obsługuje SM4)) - wcale bym się nie zdziwił, jeśli za niedługo programy będą korzystały z geometry shaderów (SM4) przy subsurf/sculpt/displece - wcale nie jest trudno znaleźć mobilne karty SM4 (nVidia od 8xxxM, ATI od HD2xxx i Intel od GMA X3100 więc nie ma co szukać słabszych, bo ciężko będzie takie znaleźć).

No właśnie, że support na forach ubuntu jest na bardzo niskim poziomie (chyba, że mówisz o płatnym) - co z tego, że jest dużo użytkowników, jak ich poziom wiedzy jest niski i większość tematów jest bez odpowiedzi. A w repozytorium potrafią być programy nieaktualizowane od wielu lat. Sabayon nie jest fajny z powodu tego, że jest na gentoo tylko dlatego, że działa w nim wszystko out-of-box - nie masz problemu z instalacją sterowników do karty graficznej, kart sieciowych/modemów neostrady, lightscribe, kodeki audio/video (europejska dystrybucja to olewa amerykańskie patenty, np. na mp3), skype, office ... - po prostu dla początkującego użytkownika dostarcza pełne środowisko z akceleracją grafiki i możliwością oglądania filmów/muzyki już od włożenia liveDVD, a nie tworzy problemów z takimi pierdołami (można wygodnie pracować, nawet nie mając HDD ;p).

Ja nie wiem co ludzie widzą, w ubuntu, bo jest to IMO jedna z gorszych, bardziej zawodnych i trudniejszych dystrybucji, Ja polecałbym raczej początkującemu Sabayon'a, a później Arch/Slackware.

ATI z OpenGL miał duże problemy jakiś czas temu, i chociaż ostatnio poprawili jakość to są do tyłu względem nVidii. Dodatkowo Ati ma słabe sterowniki dla linuksa i jeśli masz zamiar używać linuksa to odpuść sobie ATI (ale ogólnie do grafiki gdzie króluje OpenGL, karty ati są słabym wyborem).

@mamoulian: To nie jest moja definicja tylko tak definiowane są zespoły indie. To co Ty nazywasz indie jest określane jako causal (one są często tworzone najczęściej przez małą grupę osób, dla niewymagającego gracza, są proste i są tworzone zarówno przez grupy indie, jak i przez zależne (w polsce takie gry powstają na zlecenie playa i często w jednoosobowych zespołach - jednak to nie indie)). Podział przez ilość osób pracujących mógłbyś robić gdyby wszyscy mieli równy udział w zyskach, a nie pracowali za wynagrodzenie, za pracę, a ostateczny zysk nie przypadał jednej/małej grupie osób (ofc mówię o samym teamie, a nie o wydawcy i dalej).

@mamoulian: Indie to jakakolwiek grupa (moja ma 20 osób razem z grafikami i muzykami), która jest niezależna od wydawcy - robi grę sama według swoich założeń, a potem szuka wydawcy gotowego produktu/wydaje sama.

@mamoulian: 93k$ to nie jest polska gra indie z największym sukcesem komercyjnym.

Można też skorzystać z jednej z licznych bibliotek matematycznych. Tak ukończyłem i nie nie tworze RPG. Grupy Indie nie tworzą RPG za często - robią to przeważnie amatorskie teamy które nie wiedzą na co się porywają (chyba nie mylisz amatorki z niezależnością?).

Ja nie pisałem o tym, że umyślnie zmieni typ, ale właśnie jeśli nieumyślnie zmieni to wtedy szukać może problemu godzinami, a język w znalezieniu problemu nie pomoże (w wypadku statycznych typów rozwiązanie problemu to kilka sekund, bo powie dokładnie co się stało i w której lini). Język skryptowy powinien być językiem skryptowym - nie ma wymogu elastyczności i łatwości, a jedynie żeby był interpretowany w trakcie uruchomienia. A to, że typy są statyczne/dynamiczne nie robią wcale język łatwiejszym czy trudniejszym, a wcięcia jako bloki danych to właśnie bardzo nieelastyczne rozwiązanie ;p. NumPy jest napisany w C, a w pythonie jest tylko wrapper na bibliotekę napisaną w C, Cortex podobnie jak NumPy z tym, że główna część była pisana w C++, a nie w C, Django w sumie nie ma dużego wyboru (aplikacja internetowa to do wyboru miała jeszcze gorszy php, a jsp nie każdemu odpowiada (ale i tak lepszym wyborem niż python byłby imo ruby... ale to już nie duża różnica i wybór pythona można uznać, za racjonalny wybór)). Zope nie znam i ciekawy jestem jak działa, ale wyjątek potwierdza regułę. PS. możesz napisać o jakiej platformie Google mówisz, bo jest ich trochę i dużo eksperymentują z językami skryptowymi. Jeśli mówisz o ich głównych usługach to faktycznie wspierają się pythonem i odgrywa on podobno dosyć ważną rolę, obok C++ i Javy (JSP). Próbujesz usprawiedliwiać pythona w sposób, "każdy ustrój ma swoje wady i nie każdy jest tak samo traktowany, więc dlaczego nie faszyzm?" - tak każdy język jest podatny na błędy, ale nie każdy je prowokuje.

@mamoulian: Silnik 3d. Nie mówię o grze tylko o silniku - gry to wiele na przestrzeni ~8lat, grupa Indie. Teraz realizujemy 2 projekty z czego jeden zbliża się ku końcowi. Szybkość pisania jest porównywalna, szybkość wykonywania na korzyść AC. Tak - w sztucznych testach Java też przegoni znacznie C++ - z tym, że praktyka jest inna niż testy. Co do NumPy to on jest pisany w C/C++ + wrapper pythona, a wykonywany z poziomu pythona jest zawsze wolniejszy, bo jest dodatkowy narzut - jeśli wyprzedzał w jakimś teście C++ to po prostu ktoś użył gorszego algorytmu, bo sam python czy NumPy z pewnością nie dały przewagi ;p

Nie należę do żadnego specjalnego typu ludzi - chyba, że tak nazywasz wszystkich niepoczątkujących programistów. Pythona praktycznie nikt z osób doświadczonych nie lubi (lubią w nim pracować początkujący, zanim przekonają się, że jego zalety na początku przeradzają się w olbrzymie wady przy czymś większym niż paręnaście linijek), Dynamiczne typowanie jest w wielu językach dynamicznych, ale zdecydowanie nie w większości, wcięcia znakami białymi jest charakterystyczny tylko dla pythona. To, że dynamiczne typowanie powoduje błędy jest opinią osób wychowanych na językach o ścisłym typowaniu, bo są to przeważnie doświadczeni programiści również z językami z dynamicznym typowaniem, ale nie tylko - to po prostu fakt, a co najwyżej początkujący jeszcze się na własnej się nie przekonał dlaczego doświadczeni nie lubią dynamicznego typowania. Trudniejsze do opanowania z pewnością nie są - jednak przy braku wcięcia nie zasygnalizuje Ci błędu, tylko zmieni się sposób działania całego kodu - a potem szukaj wiatru w polu (a dodatkowo mało czytelne jest takie rozwiązanie gdy monitora zaczyna brakować w szerz na wcięcia ;p). Co do wskaźników to widać, że nigdy nie programowałeś czegoś wymagającego wydajności - fakt jeśli nie wiesz jak wskaźniki działają lepiej nie używać, ale jeśli wiesz to zdajesz sobie sprawę, że nic lepszego nie ma (kolejna rozbieżność początkujący vs doświadczony). Tak zyskał dzięki temu, że początkujący się w nim dobrze czują, a nie dlatego, że można w nim napisać coś większego - to się zgadza. To co jest zaletą dla laika jest wadą dla programisty. Wcale nie łatwiej - mniej więcej tak samo łatwo się integruje i jest to banalnie proste (sam kiedyś w swoim silniku dopóki nie zaczął sprawiać problemów programistą skryptów). Nie lepiej, każdy soft z innym tylko z takim który można zastosować zarówno w małych jak i dużych skryptach, bez utraty pigmentu włosów. Jednak jeśli mam do wyboru python lub inny język, bez wad pythona to wolę się nauczyć takiego niż użyć pythona. Niczego konkretnie nie sugeruje - sam zmieniłem pythona na angelcode i ja jak i współpracownicy jesteśmy zadowoleni - ale to wszystko zależy od tego dla kogo jest kierowany język. Jeśli dla laików jak w przypadku Nuke (dla użytkowników) to python może nie być takim złym wyborem, jeśli dodadzą możliwość pisania pluginów w C/C++. Jeśli programiści wybierają język dla siebie/innych programistów (jak w moim wypadku - przy tworzeniu gier) to nie wybierają pythona tylko języki ze statycznym typowaniem i bez udziwnień mogących tworzyć błędy (no wyjątkiem jest język LUA który miał swoje 5 minut (tu ze względu na niezłą wydajność), ale też się od niego odchodzi).

Szczerze to w prawie każdym ;p - ja zamieniłem pythona ze swojego silnika na AngelCode. Kwestia przyjemności nie jest w tym wypadku względna (jeśli pominiemy masochistów) - jest to język bez kontroli typów, więc jeśli przypiszesz przypadkiem do zmiennej inną wartość niż powinieneś, żadnego błędu Ci nie wyświetli i szukaj później godzinami błahego błędu... to samo z blokami danych - zrobisz spację za mało/za dużo i skrypt zupełnie inaczej działa, ale dla interpretera wszystko jest ok więc Ci nie pokaże błędu.... takich wad pythona jest bardzo wiele które skutecznie przeszkadzają pisać coś większego w nim, bez rozstroju nerwowego. Samej składni nowego języka jeśli znasz inny to żaden problem - znając język C znasz praktycznie cały python czy inne języki - różnice są naprawdę niewielkie. Nie musisz się wgryzać za głęboko bo rozpoczynając naukę znasz go już bardzo dobrze - a jest tylko kilka małych różnic o których przeczytasz w kilka pierwszych godzin i już cała nauka. Dlaczego nie jest wesoło? Dla programistów to tak naprawdę żadna różnica - ba programiści wolą się nauczyć nowego języka niż mieć język który tworzy problemy. BTW Jeśli firma chce sprzedać swój produkt to nie pisze skryptów, bo one mają otwarty kod źródłowy (taka natura skryptów), co nie jest pożądane i pisze się pluginy w C/C++. Języki skryptowe w programach graficznych nie są dla programistów i firm tworzących pluginy do softu, tylko dla grafików, żeby była prosta składnia i można było łatwo, szybko zautomatyzować niektóre rzeczy - do większych rzeczy się nie nadają - dlatego wybiera się pythona, bo grafik może znać już ten język, a olewa się problemy przy szukaniu później błędów w dużym kodzie... bo duży kod z założenia ma nie powstać.