Skoti

Wyżywanie się artystów nie ma nic wspólnego z BGE tylko z viewportem. Wyżywanie się programistów jest zdrowe o ile wyżywają się w wolnym czasie, a wyżywanie się programistów BF na BGE dla przyjemności w czasie pracy, zamiast praca nad innymi nie ma sensu, bo nie przynosi ona nikomu nic (poza tym, że programiści dostają kasę za zabawę, a nie pracę). Ty chyba nie wiesz co to jest prototyp gry, a animację musisz sprawdzać w silniku docelowym (sprawdzanie mechaniki zewnętrznego silnika docelowego w bge to testowanie zachowań godowych kanarków na głodowanie biedronek). W prototypie nic nie musi ładnie wyglądać czy się zazębiać animacja - ma po prostu działać (a doprowadzenie do działania prototypu w bge to męka). A możesz przynajmniej spróbować uzasadnić dlaczego nie chcesz rozmawiać o tych silnikach - są darmowe i o niebo lepiej się sprawdzą w prototypach, a nawet w grach (bo jak już z prototypem znajdziesz wydawce i fundusze, nie musisz wszystkiego co zrobiłeś wywalić, żeby zrobić grę, bo te silniki nadają się do gier równie dobrze). Po pierwsze nie ma wielu, są tylko nieliczni, amatorzy, którzy robią w bge tylko dlatego bo usłyszeli, że jest prosty (nie dlatego, że jest, ale alternatyw nie znają). Co do tego co zacząłem pisać o prototypie... to ty napisałeś o prototypowaniu, a prototypy gier służą jako Proof of concept dla potencjalnych wydawców/inwestorów (więc jeśli o czymś mówisz to wypadałoby się dowiedzieć co to oznacza, a nie ukrywać pod nazwą prototypu dziecinne zabawy). Yo Frankie służył rozwojowi Blendera (aby był lepszym narzędziem GRAFICZNYM, dla GRAFIKÓW tworzących GameArt) i Cristal Space (jako silnik graficzny), i to, że graficy byli zainteresowani poprawianiem viewportu podczas tego projektu w aplikacji której używają (a nie silnika który był słabym wyborem, którego nigdy w życiu już więcej nie zobaczą). Ale w BGE tam nic nie ruszono. Coś co praktycznie nie istnieje, nie pasuje do profilu programu, oraz darmowa konkurencja wyprzedza o lata świetlne nie powinno być rozwijane spowalniając rozwój kluczowej części programu, a uśmiercone, aby nie przeszkadzało (lub odseparowane jako osobny projekt, gdzie prace nad nim prowadzono by w wolnym czasie, a nie w czasie przeznaczonym na rozwój programu graficznego). Bzdura - rozwój viewportu jest kluczowy dla grafików i to nie tylko gameart - wydajność w bge była od zawsze olewana, a dostał wydajność dzięki sculptowi, który potrzebował wydajności, bge nigdy nie dostałby obsługi shaderów gdyby nie poprawki do viewportu dla grafików chcących widzieć efekty przed eksportem do zewnętrznego silnika - shadery weszły do viewportu, jeszcze zanim uznano, że blender w projekcie YF zrobią wersję gry w bge, a zrobili to tylko jako pomoc dla grafików do współpracy z zewnętrznym silnikiem (który ostatecznie okazał się słabym wyborem)). To nie BGE ciągnie rozwój viewportu, a wręcz przeciwnie i bez bge byłoby więcej czasu na viewport i inne rzeczy.

Nie przeczę sobie - BI ma powód istnienia, bo istnieje zastosowanie w którym się sprawdza wyśmienicie... BGE nie ma takiego zastosowania, poza wyżywaniem się programistów. No dobra - BGE nadaje się odrobinę lepiej do prototypów niż notatnik i kompilator... może być? Samo wyświetlanie siatki to mały pryszcz przy tym co musisz mieć, żeby zrobić prototyp - używając do tego BGE po prostu piszesz silnik praktycznie od zera, a python jest ok do małych skryptów max kilkadziesiąt linijek, ale nie nadaje się Z tym, że OS dlatego bo inny silnik nie ma prawa się utrzymać to straszna bzdura - BGE się nie utrzymuje, a jest na GPL (bardzo nie przyjaznej licencji dla osób które chcą robić na niej gry), a Unity czy UDK to darmowe silniki które nie mają prawa się nie utrzymać (niekomercyjne dla prototypów i zabawy, a komercyjne do komercyjnych zadań). Zabawne ile jeszcze bezsensownych kryteriów wymyślisz, żeby udowodnić sobie, że masz rację... Tak samo jak wymaganie OS w przypadku prototypów nie ma żadnego sensu (olewać wygodę, czas i możliwości tylko dlatego, że jest OS i ubzduranych upadków darmowych zamkniętych wersji komercyjnych silników), tak w wypadku prototypów wieloplatformowość jest głupotą (bo tylko głupiec robi prototyp na wiele platform (strata czasu przy prototypach), a robienie prototypu na inną platformę niż Windows, aby pozyskać wydawcę i fundusze jest jeszcze większym błędem), a takich silników otwartych windows only jest wiele - samych polskich znam kilka, jak nGENE Tech czy The Final Quest, ale jeśli się upierasz otwartych, wieloplatformowych silnikach do prototypów z edytorem to np. Ardor3D Bzdura - Viewport sam się rozwija (chyba nie myślisz, że przepisanie sposobu renderingu, struktur przechowywania danych itd. w 2.5 zrobiono dla BGE? Celem było właśnie poprawienie wydajności viewportu i sculptu (a BGE jak zwykle dostał po prostu rykoszetem poprawkę)). W innych programach jak 3ds max XSI czy Maya mają viewporty bardziej rozwinięte, shadery w viewportach są generowane na podstawie ustawień materiałów, a Maya nawet generuje shadery do użycia w zewnętrznych silnikach/grach. BGE nie przyspiesza rozwoju viewportu, a wręcz przeciwnie - spowalnia go (bo jakoś trupa trzeba ciągnąć jak już jest i tracić na niego, czas, zamiast zabrać się za viewport i inne potrzebne sprawy). Teraz w BGE nie możesz sobie nawet ustawić wielkości i jakie dane przechowuje rendertarget, przez co wiele rzeczy nawet jak chcesz nie możesz zrobić, a jak możesz to jest 4x mniej wydajne (np. w HDR/DoF/Bloom/Light scattering...), nie możesz ustawić nawet AA czy zrobić shaderów geometrii już o tesselacji możesz zapomnieć przez najbliższe 3-4 lata. Poza tym, jeśli chcesz mieć cienie nie takie jak w grach 10 lat temu to musisz sobie sam wszystko napisać np. CSM (co przy braku możliwości ustawiania rendertargetu, jest trochę jak wycieczka w Bieszczady, przez Sidney). Tak mniej więcej się ma ten rendering... ale do prototypów grafika by wystarczyła. A ja po raz kolejny zapytam co ma viewport do BGE - BGE jest właśnie do tworzenia gier (przynajmniej z nazwy), a grafika w nim to viewport który do BGE nie należy i rozwija się sam.

Blender Internal ma swoje zastosowanie w animacjach i Yafaray nie dorasta mu tam do pięt (w statycznych scenach Yafaray może pokazać fajne efekty, ale nie nadaje się do animacji). Ludzie widzą powód żeby rozwijać BGE, nie dlatego, że widzą sens jego istnienia - tylko pisanie silnika do gier to dla wielu świetny cel sam w sobie i świetna zabawa. Do prototypowania BGE nie nadaje się zupełnie - może się tak wydawać, bo prototypy nie potrzebują dobrej grafiki (ale jest to bardzo naiwne, bo jedyne co BGE ma to właśnie renderer, który jest w dodatku bardzo słaby) - prototypy potrzebują narzędzi, które szybko pozwolą zrobić gameplay (a tu BGE jest wręcz żałosny - nawet jak chcesz zrobić najprostszy GUI czy AI (to tylko przykłady z setek rzeczy które muszą być w narzędziu do prototypów) zamiast skorzystać tego co jest w silniku musisz pisać silnik, w dodatku w nieprzyjaznym do takich celów pythonie). Co do jedynego OS engine z GUI to jest ich więcej niż można spamiętać, a jako przykład podam Ci Irrlicht z gui irrEdit - ten silnik sam nie nazywa się game engine i bardzo słusznie bo jest on silnikiem graficznym (jednak jest dużo bardziej game engine niż BGE i dużo bardziej nadaje się do prototypów), ale zupełnie nie rozumiem dlaczego postawiłeś ograniczenie OS - dla osób robiących prototypy nie jest to ważne zupełnie (piszących grę AAA już to interesuje bardzo - dlatego kupując licencje na silnik dostają źródła), a najwyżej ważna może być cena, a darmowe Unity czy UDK się świetnie nadają do prototypownia (mają w sobie wszystko co potrzebujesz do zrobienia prototypu, a nie jak BGE wszystko musisz programować sam). Ja nie jestem przeciwny pracą nad poprawą viewportu, tylko bez sensu jest praca nad BGE, bo, żeby był on faktycznie game engine, należałoby napisać CAŁY silnik od nowa, rozpoczynając od tego co już jest (czyli przepisania renderera - który sam w sobie jest bardzo małą częścią Game Engine, a w BGE jest całością). @Nezumi: co do tego filmiku to w Bullet, który jest wykorzystywany przez BGE od bardzo, bardzo, jest symolacja fluidów z wykorzystaniem Cuda i OpenCL dokładnie taka jak na tym filmiku - jeśli tak jak mówi autor tego filmiku nie jest to związane z Bullet to tak jak napisałem robi to tylko dla zabawy, a nigdy jego kod do BGE nie wejdzie, bo poczekają co najmniej do Bullet 3 (może koniec tego roku), ale pewnie jak zwykle po wydaniu Bullet 3 (cały w OpenCL) do blendera trafi dopiero po 3-4 kolejnych wydaniach bullet. PS. jeśli mówisz o sobie "matematyczno-programistyczny glab" to BGE nie jest dla Ciebie, bo w nim musisz po prostu programować wszystko sam (rzeczy które zdecydowanie nie są łatwe do napisania, a powinny być gotowe do użycia w silniku).

@Nezumi: nie ma sensu rozwijać BGE, ale znajdują się ochotnicy chcący reanimować trupa Co do drzewa to nie rozumiem problemu - zaznacz gałęzie na których chcesz liście, zrób grupę wierzchołków i rozsiej cząsteczki-włosy z reprezentacją obiektu liścia, na tej grupie.

@Kris_R: Używane były poprzednie wersje, a teraz powstaje nowa wersja, której betę udostępniono i która ostatecznie będzie miała otwarte źródła.

Mówiłem o: Co nie jest takie oczywiste - jest lepszy w jednym, ale gorszy w wielu innych rzeczach (jeśli miałbym wybrać do tworzenia gry wybrałbym UE3 mimo, że renderer ma gorszy). Nic o tym nie wiem, ale jest to całkiem możliwe (wystarczyło, że ktoś z takiej korporacji uznałby, że akcje firmy będą rosły i zainwestował).

@plasti: jeśli piszesz, że jest lepszy to lepiej napisz w czym - bo ogólnie jest imo gorszy (tylko renderer ma lepszy).

@graphic: Zdecydowanie nie jestem fanem CE, ani nie pracuje w CI. Wydaje mi się wręcz przeciwnie, że to ty jesteś antyfanem CE i nie widzisz, jego mocnych stron (a renderer jest niewątpliwie jego mocną stroną - posiada większe możliwości (jak chociażby Subsurface Scattering czy dynamicznie liczone GI, ale też wiele innych rzeczy) - tu nie ma się co kłócić - za to UE3 nadrabia z nawiązką na narzędziach i całej reszcie (bo to jest silnik gier, a nie silnik renderujący i renderer jest tylko jednym z wielu elementów - praktycznie w całej reszcie UE3 jest lepszy)).

@Bad Moon: a mnie to wcale nie dziwi.

@ZelvaBOi: Nie jest za free do celów edukacyjnych, tylko jest za darmo dla ludzi związanych z edukacją (a to jest spora różnica i ogranicza ilość osób które mogą z niego skorzystać nawet do nauki bez wydawania swoich produktów). CryEngine stawia na wygląd i tu daleko w tyle zostawia UE3, ale UE3 stawia rzeczy nie związane z grafiką, a tworzeniem gier, jest starszy i już ma całą masę klientów, gdy CryEngine jest stosunkowo młodym produktem - jednak to nie decyduje, a decyduje po prostu cena produkcji gier na danym silniku - CryEngine 2 działa tylko na Windowsie, a UE3 działa na Windows/Mac/Linux/PS3/Xbox/iPhone (ofc darmowy UDK tylko Win), dzięki czemu kupując ten silnik masz od razu silnik na większość platform i większość pracy jest wspólna, a koszty portów są minimalne (w wypadku CryEngine 2 porty potrzebowałyby innego silnika i praktycznie napisania gry od nowa). CryEngine 3 już jednak jest wieloplatformowy i działa na PS3 i Xbox, co już wygenerowało zainteresowanie i np. polski City Interactive wykupił licencję (ale też inne firmy już mają licencję na ten silnik, i w przeciwieństwie do CE2 nie będzie tak, że praktycznie jedyna grą jest Crysis).

Nie dali Unreal Engine 3 za darmo przecież, tylko jego kastrata UDK, a nawet jak chcesz wydać coś na kastracie to musisz zapłacić 99$ (to akurat śmieszna cena), ale do tego 25% dochodu (czyli strasznie drogo) jeśli dochody przekroczą 5k $ (co jeśli coś wydajemy można założyć w ciemno), więc nie nazwałbym tego darmowym (darmowy jest dla osób, które robią same dla siebie), a brak źródeł praktycznie wyklucza udk z poważnego zastosowania. To tak w kwestii sprostowania, a ogólnie to fajny projekt do robienia na szybko PoC, ale do czegoś większego to za droga jest ta "darmowa" wersja ;p.

Nie rozumiem tych którzy chcą zrozumieć malarstwo (rzemiosło), ale od strony emocjonalnej/sensu - której jest często pozbawione (bo od warsztatu wiele osób powinno chcieć poznać dogłębnie ;p), za to sztukę już jak najbardziej tak - nie każdy malarz jest artystą. Tu nie wydaje się, żeby animacja przekazywała cokolwiek, więc bez walorów artystycznych można oceniać tylko warsztat... a ten kuleje (jak zobaczyłem animacje to pomyślałem, że musi mi skopać tyłek fabułą, bo jeśli nie to nie mam pojęcia po co to polecać). Po obejrzeniu tego czuje tylko, że zmarnowałem czas.

@dac77: na wydajność w tym wypadku gdy wąskim gardłem jest dostarczanie dużej liczby wierzchołków do karty graficznej nie ważny, jest system operacyjny, rozdzielczość ekranu czy ustawienia jakości obrazu (to ma stały narzut niezależnie, od ilości wierzchołków). Procesor ma wpływ na to, ale zależnie od tego, jak programiści napisali kod wpływ ma ogromny lub znikomy (jakby dobrze napisali) - ofc w przypadku shaderów fragmentów często przewyższają one czas potrzebny na geometrię, ale ten czas nie jest zależny od ilości wierzchołków, a od ilości fragmentów do obliczenia. Duży wpływ mają jedynie karta graficzna i to jak podłączona jest do kompa (AGP, PCI-E 1.0, PCI-E 2.0, czy planowana PCI-E 3.0), bo to definiuje przepustowość danych pomiędzy prockiem, a cpu. Mały wpływ ma tu CPU (już większy ma RAM) - co innego przy sculpt, bo tu dodatkowo procek musi się namęczyć, i grafika często nie jest wąskim gardłem i jest mniej ważna. @Chrupek3D: to zależy jaką akurat mam w kompie włożoną ;p. więcej niż 3M poly płynnie (płynnie nie stopklatka) uzyskuje na lo-endzie czyli 8600GT - na średniej półce czyli GTX460 1GB jest stosunkowo więcej.

No chyba znowu żartujesz prawda? W 2.5 właśnie viewport bardzo przyspieszył (w starym rysowanie odbywało się za pomocą trybu bezpośredniego - żeby wysłać jeden trójkąt potrzeba było użyć 9x funkcji (każdy wierzchołek * 3 (pozycja + uv + normalna), poly pokazywane na tym filmiku to quady więc 18 funkcji na poly (bo stary blender nawet czworokąty traktował jako tri), przy 2M*18 to 36M funkcji do wykonania przy czym w takiej ilości narzut jest olbrzymi (ten sposób dostarczania wierzchołków był tak zły, że wyleciał z hukiem z OpenGL 3.x) - dla porównania nowy blender obsługuje VA lub VBO (jeśli VBO jest obsługiwane przez kartę), i w obu przypadkach niezależnie od ilości wierzchołków używasz jednej funkcji, więc narzut jest minimalny, a wydajność przy tak dużej ilości rośnie wielokrotnie - niestety blender nie używa statycznego VBO tam gdzie można (przy obracaniu, bez animacji jest idealnym miejscem na użycie statycznego VBO, zamiast strumienia ;p), bo wtedy nie musiałby nawet przesyłać nic - po prostu powie karcie, tam w pamięci już masz wierzchołki, więc sobie ich uzyj i zostaje tylko narzut bindowania (jak użyliby Bindless Graphic (do tego DSA i np. VAO, które są dostępne zarówno na Ati jak i nVidii) jeśli jest dostępne to nawet to by odpadło http://developer.nvidia.com/object/bindless_graphics.html))). Mówiąc, że OpenGL zawsze tak tnie, oraz to, że nowy blender tu nie poprawił po prostu mnie rozbawiasz - co prawda wymienił dinozaura, na starocie (VA to OpenGL 1.1 czyli przełom lat 1996/97, VBO w lutym 2003 był już w ARB i działał na kartach nVidii i AMD), ale starocie wielokrotnie szybsze (aby więcej było możliwe musieliby przebudować budowanie kontekstu i jeśli jest możliwe tworzyć większy niż OpenGL 1.x (przypominam mamy już OpenGL 4.1, a za chwilę wyjdzie nowa wersja)). W scupcie stosunkowo niewiele zmienili - tu procek był wąskim gardłem, więc poprawiono rzucanie promienia tam gdzie klikasz dokładnie tak jak rzucanie w rendererze usprawniono - wykorzystali po prostu strukturę BVH, którą wykorzystuje renderer, do szybszego wyszukiwania zderzenia siatki z promieniem. Co do podglądu renderera, to zanim coś zobaczysz w LW to już Ci się wyrenderuje w Blenderze w podglądzie, a druga sprawa to to, że nadużywanie słowa realtime, gdy daleko mu do tego boli słuchacza.

@dac77: Nie żartuj. Po pierwsze tekstura nie ma wpływu na wydajność (ma identyczny wspływ jakbyś miał jeden face - tekstura jest niezależna od wierzchołków i ich rasteryzacji, a zależy tylko od powierzchni którą trzeba teksturować (bo jej odczyt jest już w shaderze fragmentów)). Co do "nie skulptował w LW tylko obracał viewport" - no właśnie, bo sculpt prędzej będzie ciął - nie dość, że jest widok w viewporcie gdzie aktualizuje co klatkę dane dla karty, to jeszcze procek musi ostro harować. OpenGL tak tnie, jak programiści zrobią słabą optymalizację.

@tjviking: w przypadku tabletów i telefonów to jest tyle świetnego dodatkowego sprzętu, że część z tego co napisałeś można by wyeliminować (wystarczy gps ustawić na chwilę w miejscu gdzie jest obiekt (lub zrobić kilka zaznaczeń z kilku miejsc, żeby określić położenie obiektu w przestrzeni 3d (i wymazywać to co jest w tej sferze 3d)) i z żyroskopu odczytać jak obrócona jest kamera i część z problemów znika). OFC nie znikną wszystkie problemy, a już z pewnością zawsze będzie można zauważyć błędy po usunięciu (no chyba, że miejsce z którego coś usuwamy jest jednolite).

@Wray: Faktycznie... zmylił mnie tytuł newsa (który mówi, że to jest plugin, a taki by nie działał ;p). Ten nDo to jest skrypt, a nie plugin co zmienia postać rzeczy (taki może działać - chociaż pewnie przy CS2 trzeba zedytować skrypt i wartość INSTALLPATH_FOR_CS2_USERS (bo katalogu "C:/nDo" raczej nie odnajdzie ;])). Nie sprawdzę czy działa bo nie mam PS na moim MacBooku.

@cortes: ten ndo też raczej nie działa na mac ;p. Na Mac, musisz poszukać innych pluginów (lub innych programów jak Gimp + http://code.google.com/p/gimp-normalmap/ - tylko tu też jest problem bo nie jest w wersji binarnej (tylko dla windowsa i dla linuksa w repozytoriach dystrybucji), więc musiałbyś zabrać się za kompilację tego, lub szukania w sieci (może ktoś już skompilował i udostępnił)).

Spoko, tylko zastanawiam się po co ktoś to pisał skoro już mamy darmowy plugin tworzący normal mapy do PS od nVidii http://developer.nvidia.com/object/photoshop_dds_plugins.html

Nie chce mi się odpisywać na wszystkie posty przeciw filmikowi, ale pragnę przypomnieć kilka rzeczy. Główny cel tego projektu to był rozwój oprogramowania w danym kierunku, a fabuła, jakość i wartości propagandowe to sprawy drugorzędne dla twórców. Zgadzam się, że jakość wykonania i fabuła nie jest najwyższych lotów, ale trzyma niezły poziom, mimo, że nie było to priorytetem (trzyma dużo wyższy poziom niż spodziewałem się, że będzie).

3ds to bez problemu - blender ma importer 3ds (jednak nie poleciłbym tego formatu). Co do formatu max to tu jest gorzej bo to format który swoją budową praktycznie uniemożliwia to (ten format obsługuje tylko 3ds max, a i to nie zawsze, bo trzeba mieć 3ds max + wszystkie pluginy, których użyto przy tym co w *.max zapisano, żeby nie krzaczyło (sam 3ds max jak nie masz jednego pluginu który użyto może Ci zrobić sieczkę)). Jeśli chcesz przenosić modele między programami użyj Collada, FBX lub w ostateczności OBJ.

@lucek: póki co n-gony (bmesh) rozwija się równolegle w branchu i podobno już jest gotowy do połączenia z główną gałęzią rozwojową... ale kiedy to nastąpi dokładnie nie wiadomo (ja ze swojej strony powiem, jednak, że niedawno patrzyłem jak idzie rozwój bmesh i już działa dobrze).

Indigo z założenia powstawało jako projekt komercyjny (w trakcie powstawania po prostu był darmowy, aby zmniejszyć koszty produkcji (darmowi beta testerzy)). Mambo dalej jest darmowy i są dostępne źródła, na licencji GPL (http://mambo-code.org/gf/download/frsrelease/388/791/MamboV4.6.5.zip). Tak, jest kilka, ale przeważnie nie mają zamkniętego kodu nawet części, a jedyne (przeważnie) za co płacisz to wsparcie techniczne (bardzo ważne przy większych inwestycjach, dlatego takie dystrybucje ze wsparciem znajdziesz w np. w Żabce czy większych firmach). Yast jest akurat typowym oprogramowaniem opensource i źródła Yast2 masz dostępne tu: http://svn.opensuse.org/svn/yast/trunk/ Masz rację, że nie wszystko w SLED jest OS, ale tez nie musi (dystrybucja linuksa (zbiór różnych programów) nie jest może mieć licencję jaką chce, ale nie może zmienić licencji programów będących na licencji GPL (dlatego każda zmiana redhata, czy novella w jądrze czy innych programach jest udostępniana dla każdego - inną sprawą są całkowicie ich programy na które mają 100% praw - tu mogą robić co im się podoba (jak wypuszczą jednak na GPL, oznacza to, że praktycznie każdy może rozwijać i wydawać za darmo (lub nawet za opłatą, jeśli też wydadzą na licencji GPL i ich kod będzie można wydać za darmo...), niezależnie od ich zmiany licencji))). Te dwa przyklady nie pokazują nic - kod który jest na licencji GPL nie mogą zmienić na inny, a jedynie mogą wydawać swoje programy na licencji jakiej chcą (nic odkrywczego). Stosując to do blendera nie ma się nijak, bo nie można dopisać do programu części kodu i udostępniać tą część jako zamknięta (nie pozwala na to licencja, aby kod gpl był linkowany statycznie lub dynamicznie z kodem nie gpl), nie mogą pozbyć się kodu od środowiska (jest go za dużo i jest zbyt ważny - byłby to powrót o 4 lata wstecz (co dla blendera jest gigantycznym okresem czasu)), bo oznaczałoby to koniec blendera (a blender ze zmienioną nazwą (np. mixer) nie musiałby robić nic, z cofaniem się, tylko miałby aktualny kod bez żadnych problemów - musiałby po prostu rozwijać się jako oprogramowanie GPL). Jest jeszcze jedna opcja i jeśli już najbardziej możliwa (chociaż tylko minimalnie mniej nierealna niż tamte, które mają szanse spełnienia dążącą do 0) czyli wydanie blendera na GPL, z obsługą pluginów i wydawanie płatnych pluginów do blendera (jednak ograniczyłoby to bardzo rynek zbytu aplikacji i popularność - np. w USA i kilku krajach UE (np. Francja) program stałby się nielegalny, ze względu na licencje (w zależności od ustawodawstwa zalezy czy takie coś jest legalne czy nie w tej licencji)). Każda z tych opcji jest albo awykonalna, albo bardzo trudna, a przy okazji nie eliminuje się programu z "darmowego" rynku, a jedynie robi się mu konkurencje, albo jest to w wielu strategicznych państwach nielegalne. Teoretycznie jest możliwe, żeby blender zmienił licencję - ale jest bardziej prawdopodobne, że trafisz 50x 6 w lotto z rzędu ;p (bo w tym wypadku nie mówimy o napisaniu jakiegoś małego programiku od zera i 100% praw do kodu, a o już istniejącym programie już wydanym na licencji GPL (dystrybucje linuksa nie są wydawane na licencji GPL (bo ta licencja z zasady dotyczy tylko samego pojedyńczego kodu), a GPL dotyczy (części) programów które dystrybucja zawiera)).

@kpulka: Licencja nie pozwala na nie udostępnianie źródeł - zmusza dystrybutora do udostępniania źródeł, na licencji GPLv2 (czyli każdy może zabrać kod i stworzyć swoją wersję i wydawać ją na licencji GPLv2). Nie oznacza to ofc ze musi być darmowy (w praktyce to jednak oznacza, bo wystarczy ze jedna osoba kupi, dostanie kod i udostępni go innym za darmo). To jest tak jak z Linuksem (nie mylić z dystrybucjami linuksa - jak np. RedHat który ma tylko komercyjną wersję (ale udostępnia źródła na licencji gpl i powstała dystrybucja CentOS - czyli redhat za darmo, lub mandriva, czyli darmowy linuks i płacisz za licencje na zamknięte programy które są dostarczone razem z nim, i wsparcie techniczne)) - licencja tak bardzo chroni kod, że nie są w stanie zmienić licencji z GPL w wersji 2 na wersję 3 (bo wymaga to zgody wszystkich osób którzy brali udział w projekcie). Tak samo jest z blenderem - wiele kodu pochodzi od osób niezwiązanych z BF, i ich kod nie jest własnością BF. BF wprawdzie mogłoby skomercjalizować i zamknąć źródła, ale musieliby się pozbyć całego kodu który nie jest ich własnością (co jest praktycznie nie możliwe i oznaczałoby cofnięcie się blendera o wiele lat), a i tak nie mogliby zamknąć tego co już jest na licencji GPLv2 - więc program rozwijałby się dalej (tylko pewnie pod inną nazwą, jako fork). @stach13: Tak było wiele programów OS, które stały się komercyjne, ale albo nie były na licencji GPL, tylko na bardziej liberalnych np. BSD/zlib (np. część windowsa czy prawie cały macos x to kod z FreeBSD, na licencji BSD, która pozwala na zamknięcie kodu), lub programy rozwijane tylko przez daną osobę/firmę która miała do kodu pełne prawa (nie jak w przypadku blendera, gdzie w dużym stopniu to społeczność go rozwija) - a nawet wtedy kod za czasów gdy program był na GPL zostaje na tej licencji i jeśli program jest coś wart powstaje fork i dalej się rozwija program tylko pod inną nazwą. W Mandriva Xtreme nie płaciłeś za sterowniki (lol) tylko, za programy komercyjne (jak Cross Over Office, Cedega, czy płatne kodeki/playery fluendo) i zdaje się rok wsparcia technicznego

@dac77: Jakbyś słyszał szkota to nie narzekałbyś na mówienie przez nos tu ;p.