n-pigeon

Hahahahaha co to jest :D Całe szczęście nie jestem kibicem :D

@Skoti Każdy projekt, ma inne podejście w zależności od zasobów, więc spoko. Blender ma dużo ludzi do pracy, Gimp nie. Przepisali renderer, mesh system, UI, przepisują compositor, cząsteczki, view-port i pewni coś jeszcze, ale chodzi o to że ma kto to robić, a patrząc realistycznie, ilu użytkowników i programistów miałby Blender gdyby robili takie GEGLe? Blender ma za dużo tych systemów, by każdy ładnie zaprojektować. Gimp był w gorszej sytuacji, nie organizowali opłaconych projektów bo niby jak, Open Album Project? Po za tym mają kasę, ale nie mają, co z nią zrobić, nie ma ochotnika który zostałby menadżerem jak Ton. Nie interesują ich pieniądze, wydają je na meetingi gdzie, razem, wspólnie kodują dla przyjemności. Zupełnie inny ekosystem niż Blendera i raczej się nie zmieni. Core Gimpa starczy na dłuuugo, systemy Blendera nawet super zaprojektowane szybko by się zestarzały. Przesadzasz też z bałaganem, gdyby było jak mówisz, ważyłby 900MB i nikt nie chciałby przy nim pracować. PS A przypomniało mi się przepisali system animacji, sculpt i przepisują nurbsy oraz modyfikatory

No i to już wytłumaczyliśmy z Skotim. :) Dlaczego tak było i dlaczego w przyszłości już tak nie będzie. W skrócie. Było tak, ponieważ nie było czym to zrobić. Już tak nie będzie, ponieważ, narzędzie zostało zrobione i podrasowane tak, że pozwala na znacznie więcej, niż by pozwalało uproszczone rozwiązanie. Co więcej, samo narzędzie jest znacznie bardziej podatne na udoskonalenia. Oh dopisałeś posta, pierwsza część zawiera się w tym co wyżej. CMYK Jakie kolorowanie fotografii może być wygodniejsze w CMYK, możesz pokazać przykład? Co do użytkowników, większośćużytkowników go chce - jeśli nie wszyscy - ponieważ chce drukować :)

@mrys Chciałeś perspektywy to Ci je przedstawiłem, to co opisujesz to historia, a historia nie jest przyszłością. Więc nie widzę związku. Wytłumaczyłem też dlaczego tak było w przeszłości. Jak mieli co chwila dodawać nowe bajerki, jak pracowali nad czymś innym, by potem mogli zrobić to czego oczekują użytkownicy, ale lepiej. CMYK. Tylko jakich operacji, nie zmienisz waloru, saturacji, barwy? Czy nie przygotujesz czerni, albo CMY tak by ładnie się drukowała, jak nakazuje tego profil drukarki, bo to już wykorzystanie drukarskie. Scribus świetnie to zrobi i wygodnie sobie ustawisz zdjęcie na formacie do druku, a też jest za darmo. Co do cytatu, jak napisałem, możesz cofnąć operacje która była wcześniej, nie niszcząc tego co zrobiłeś potem i nie chodzi tylko o filtry jak edycja koloru czy blur.

Słowem klucz jest CAŁKOWICIE, PS ma tylko częściowo nieliniową edycje. Reszta to jest dokładnie jak mówisz, możesz wrócić do wszystkiego, nawet do skopiowanego i wklejonego fragmentu, do transformacji, operacji na kanale, nie tylko do filtrów jak w PS. Użytkownika tak, ale mówiliśmy o "perspektywach", sam o tym pisałeś, to o nich właśnie pisze. Charakterem programu jest fotomanipulacja i tworzenie obrazu. Druk należy do innego segmentu. Czymś namacalnym jest 16 i 32 bit w następnym wydaniu już dostępne w 2.9.0. Gimp jest konkurencją na polu fotomanipulacji. Edycje video, 3D i druk zostawia innym programom, specjalizującym się w tych zadaniach. Co do CMYKa, nie jest on, jak już pisałem trybem koloru, nic co w nim robisz, jeśli mowa o edycji koloru, nie dało by się zrobić z RGB lub Lab, a softproofing przytnie Ci niewykorzystane kolory. Po za tym użycie CMYK, jako trybu koloru, wyłączy wiele narzędzi, które nie mogą z nim działać, więc jaki ma to sens? PS Co do pierwszego akapitu, nie, nie jest to super długa historia, zmodyfikowanie czegoś z początku lub środka edycji nie zniszczy edycji wykonanych później.

@natas Z CMYK'iem sprawa jest złożona. Może rozpisze w punktach dla czytelności... 1. CMYK nie jest zaimplementowany w GEGLu, jest możliwy, ale nie był priorytetem, ponieważ. 2. Zarówno programiści GEGL jak i Peter Sikking (szef projektantów GUI), nie są za tym by CMYK był trybem koloru, jak Lab, XYZ, RGB itd. Ponieważ nigdy nim nie był, wszystkie operacje i tak są wykonywane w RGB. Zatem trzeba znaleźć inne bardziej rozsądne rozwiązanie. 3. Powstały plany innego prawdopodobnego workflow z CMYK dla Gimpa, ale też nie jest priorytetem, to raczej projekt, dla kogoś kto bardzo chce CMYK. http://blog.mmiworks.net/2009/05/gimp-enter.html http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html 4. CMYK nie jest priorytetem ponieważ, twórcy gimpa chcą się skupić całkowicie na foto-manipulacji i tworzeniu obrazu. Jeśli ktoś potrzebuje widzieć jak zdjęcie, czy grafika, będzie wyglądać po wydrukowaniu, to sam Gimp od bardzo dawna ma narzędzia, soft proofingu i color menagement, bez których i tak samo użycie CMYKa nie pokazało by, jak zdjęcie wyjdzie w druku. Same przygotowanie do druku w CMYKu, powinno być wykonywane narzędziem do tego przeznaczonym, jakimś DTP np. Scribus: http://www.scribus.net/canvas/Scribus Dlatego CMYK nie jest w planach, ale zdaje się nikt nie postawił na nim kreski, chyba, że coś mnie omineło :D Jednak, nie jest i nie będzie, na liście rzeczy do zrobienia, głównych programistów Gimpa. PS Zapomniałem napisać, przy nowoczesnych drukarkach, przy druku w domu nie jest potrzebna konwersja do CMYK. Nowoczesne drukarki same to doskonale robią. Samo Adobe forsuje workflow z RGB. CMYK jest potrzebny tylko przy zaawansowanych drukach masowych w drukarni, a tam albo są specjalne narzędzia dostarczone przez producenta sprzętu, albo wykorzystywane są narzędzia DTP.

@mrys Właśnie w Gimpie jest najpierw baza potem wodotryski, dlatego wszystko tyle trwało :) z naciskiem na trwa_ło_. Jeśli wrócimy do historii programu, Gimp już dawno miałby większość z funkcji o których mowa, ale tylko gdyby przyjęli model bazarowy taki jak Blender i dodawali nowe elementy core kiedy była by potrzeba. Problem w tym, że programistów Gimpa jest znacznie mniej, więc postanowili, że GEGL będzie biblioteką ogólnego użytku, nie tylko Gimp miał jej używać. Wybrali takie podejście, by przyciągnąć potencjalnych koderów którzy nie są zainteresowani samym Gimpem. Niestety zaprojektowanie i napisanie takiej poważnej, zaawansowanej biblioteki programistycznej, nie jest pracą na rok. Potem jeszcze praca integracji GEGLa w samym Gimpem, które ciągnęło się od 2.5. Jednak spokojnie, teraz to naprawdę się dzieje GEGL jest na pokładzie i prace idą w niesamowitym tempie, dawno nie widziałem takiego CODE RAGE. To cieszy ponieważ pracy jest dużo przy tym wydaniu, to jeszcze nie jest wydanie typu: dodajemy kilka nowych narzędzi. To poważna zmiana. W moim artykule przeczytasz, jakie kroki podjęto by skrócić cykl wydawniczy. Dodatkowo można spodziewać się, że każda następna wersja będzie wydawana w krótszym czasie ponieważ będzie mniej poważnych ingerencji w program, a jedynie napisanie i implementacja nowych narzędzi na tym co już jest. Jeśli chodzi o 3.0 przykładowo, port na GTK3 jest prawie gotowy, leży w branchu, ale odłożono ostateczną implementacje by całkowicie skupić się na GEGL i dostarczyć go jak najszybciej użytkownikom. Jest to pierwszy znak zmiany polityki rozwoju. Wcześniej dodawano wszystko do mastera i na tym pracowano, potem okazywało się, że jakaś funkcja ma poważne wady i trzeba przedłużyć cykl, mimo, że większość nowych funkcji była gotowa. Tego już nie będzie, do mastera trafiają teraz tylko GOTOWE, w miarę stabilne gałęzie rozwojowe. GEGL jest znacznie potężniejszy i lepiej zaprojektowany niż taki poszerzany core, zatem tworzenie narzędzi przy jego wykorzystaniu, trwać będą znacznie krócej niż by to było w innym przypadku. Więc GImp ma szanse szybko nadrobić stracony czas. Za jakiś czas posiadać będzie funkcje których nie ma w PS, np. całkowicie nieliniowa edycja.

Nowe usprawnienia GUI Node Editora: http://code.blender.org/index.php/2012/05/node-editing-tweaks/

@Nezumi Może i masz zły dzień, ale nie odwracaj kota ogonem ;] Nie chce by powstał jakiś brzydki mit, który nie ma nic wspólnego z rzeczywistością. Programiści Gimpa nie olewają Windowsa, ani Maca: 1. Programiści Gimpa nie robią binarek, nawet na Linuksa, kompilują jedynie dla siebie. Właściwie to programiści Blendera tak samo :P 2. Zarówno w przypadku Gimpa jak i Blendera, binarki dla systemów operacyjnych przygotowują ochotnicy, którzy nawet nie muszą być progamistami. Facet zajmujący się binarkami na Win właśnie nad niemi pracuje, ale tak samo facet który przygotowuje binarki dla Fedory :D, koleś robiący dla Ubuntu już to zrobił i jest dostępna :) 3. Wielu, jeśli nie większość, użytkowników Linuksa nie umie kompilować programów, zazwyczaj poddają się jak skrypt konfiguracyjny wyrzuci brak zależności i nie wiedzą co dalej robić :D 4. W zespole Gimpa nie ma nawiedzonych fanboyów Open Source, robią Gimpa na wszystkie platformy, a zgłaszane błędy traktują jednakowo, nie ważne jakiego systemu używa użytkownik. Pracują nad Gimp'em ponieważ to lubią :D 5. Kompilowanie programu pod Windowsem jest znacznie trudniejsze i bardziej upierdliwe, dlatego dobrze, że w ogóle znalazł się ochotnik by to robić. Oczywiście można zrobić cross-compilacje, ale patrz punkt 1. Równie dobrze można powiedzieć, że olewają użytkowników każdej dystrybucji Linuxa :D co oczywiście było by śmieszne xD

@muody Aha, nie znalem tej nazwy, dla mnie to zawsze były filter layers, albo filtry warstw. No czyli tak samo planowane na 3.2. @Mortom @mrys Nowy cykl wydawniczy ma być znacznie krótszy, choć przy 2.10 będzie dużo pracy, ale 2 lata to już na pewno nie będą. Co do perspektyw rozwoju, to już się pojawiły, od kiedy na pokładzie, w końcu, znalazł się GEGL.

@Dobrotek Maski dla grup prawdopodobnie trafią do 2.10. Filtry i efekty warstw + nieliniowa edycja, są zaplanowane na 3.2. @mrys Auto-skalowanie warstw również, jeśli o to Ci chodzi. Choć te założenia, są elastyczne, może być później może być wcześniej. 16 i 32 bit głębia miały być w 3.0, a trafią do następnej wersji.

@ikkiz To nie jest funkcja dla idiotów, tylko usprawnienie workflow z plikami :) Teraz możesz wygodnie zapisywać i exportować jednocześnie, nie musząc zmieniać rozszerzenia za każdym razem :) Dodatkowo dzięki temu, jest możliwa opcja szybkiego exportu z nadpisaniem wcześniej wyexportowanego pliku. Skróty są konfigurowalne jakby co.

@Leleń @Nezumi Spoko następny cykl wydawniczy ma być znacznie krótszy :P

Niezwykle wyczekiwane wydanie programu Gimp, oznaczone numerkiem 2.8, ujrzało światło dzienne. Wyczekiwane, ponieważ jest to pierwszy krok dawno wyczekiwanych zmian. Zapraszam do przeczytania krótkiego artykułu o nowym Gimp'ie, na naszej stronie: http://www.max3d.pl/article.php?id=187 Niestety wersja binarna dla systemu Windows nie została jeszcze przygotowana, ale dostępna jest wersja 2.8RC1, pod adresem: http://gimp-win.sourceforge.net/stable.html Aktualne wydanie powinno pojawić się na tej samej stronie niebawem.

Trzeba jednak pamiętać, że ten model się nie zmieni, chodzi o to jak są wykorzystywane zasoby ludzi przy takich projektach, budowanie katedry z takim zespołem zajmie lata, ale czekania, model bazarowy czy - jak to nazwałeś - chaotyczny, też zajmie lata, ale przynajmniej coś po drodze zrobią. Ta metoda, może i szalona, ale i tak się na razie sprawdza, a do innej nie mamy zbytnio dostępu. Projekty Open Movie rozwiązują jedynie część problemu. Jedyne czego brakuje to projektów które polegały by na doszlifowaniu istniejących rozwiązań, ale ostatnio w GSoC widać tendencje do takich projektów, zamiast jakichś nowiutkich funkcji, kończą zaczęte projekty, albo dodają mniejsze narzędzia, przykładowo tegoroczny GSoC. Właściwie ostatnio mam wrażenie że GSoC, robi więcej dobrego niż Open Movie. Najlepsze co spotkało ostatnio Blendera to granty z publicznej zbiórki, Nicholas właśnie teraz pracuje pełną parą ponieważ jest finansowany, więc może PTex ruszy z kopyta, tak jak powinien. Na razie wróże z fusów :P Jest jeszcze projekt nowych cząsteczek oraz compositora. Co do Nicholasa, jak wyżej, właśnie wszystkie projekty wykańcza pracując za granty z BF. Jason pisał również, że modernizacja ułatwi w przyszłości implementacje wsparcia dla nowszych kart, chociaż tyle. Tylko moim zdaniem wina stoi po innej stronie, użytkownicy, za mało wiedzą by wdać się w tak techniczną dyskusje, brak dyskusji, albo jeszcze gorzej, lobby userów z złomem zamiast komputerów. Wynika z tego, że taki stan, to wina społeczności użytkowników xD. Użytkownicy w tym przypadku są jak rak :D Z ML i IRCem u mnie jest podobnie, Blendera tylko śledzę, bardziej aktywny jestem przy innych projektach, które mają w sumie większe problemy niż Blender xD

Spoko, widziałem twoje maile o collada, to był najgłupszy pomysł jaki się zrodził w tym projekcie Co do game project, może i by tak było, ale może nowy bake by skapnął :D Zapomniałem, że nie istnieje dobry, stabilny posiadający edytor GE OS. :P PTex: W sumie uważałem to za efektowny projekt, ale myślałem, że na co mi ptex jak nie będę miał czym na nim malować, choć jeszcze jest projekcja. Jednak jeśli stawiasz sprawę w takim świetle o czym przyznam nie wiedziałem, to muszę Tobie przyznać rację. Jednak spodziewam się, że pierwsza implementacja PTexa będzie tylko dla Vertex Painta, może i dobrze lepiej krokami, nawet robiąc coś kilka razy, niż raz a dobrze na hura z czego wychodzi 5 lat odkładania bo projekt skomplikowany. Zdaje się Nicholasowi nie został żaden inny projekt poza PTexem do skończenia, więc prawdopodobnie przekonamy się niedługo co z tego wyniknie. Co do kart i OpenGL, święta racja, mnie też to drażni... Widziałeś projekt Jasona Wilkinsa na tegoroczny GSoC? Jako jedną z korzyści wymienił, iż łatwiej będzie rozgraniczyć różne możliwości trybów wyświetlania dla różnych generacji i edycji OpenGL, nie wiem na ile to rozwiąże problem. Właśnie się zastanawiałem czemu tak rzadko coś piszesz na ML, masz odpowiednią wiedzę by czasem coś wytknąć i lubisz pisać :P. Chyba, że pisujesz na IRCu albo forum, bo tech rejonów akurat nie śledzę, więc nie wiele wiem co się tam dzieje...

Chodziło mi raczej o miejsce, niż o samą czynność, ale na Mango to jeszcze rozumiem, marudzenie na _to_ w odpowiednim miejscu i tak by nic nie dało ;] Sam wolałbym Game Project, ale i Mango mnie trochę cieszy, przynajmniej coś skapnie Cyclesowi, choć nie używam go jakoś specjalnie intensywnie. Co do PTex, mówi się trudno, Nicholas teraz dużo pracuje przy Blenderze, czuje że jak skończy maski i Skin Modifier to zabierze się za PTexa, przy którym już pracował. Swoją drogą pierwszej dwójki bardziej wyczekuje, bez piteksa mogę na razie żyć i zamiast niego, chętniej jako pierwsze zobaczył bym udoskonalenie Paint Toolsów i ujednolicenie ich z Sculptem. Na szczęście Antonis przy tym pracuje, wydaje się całkiem solidny, więc prawdopodobnie ukończy projekt. Na lepszy bake również czekam :P Ha sam zaczynam rozpisywać wishlistę :D ten klimat się udziela eh :D

1. Loop Tools był addonem, autor nie zaktualizował go do nowego API i trzeba czekać, aż to zrobi. 2. Bevel miał posiadać tą opcje, ale tuż przed wydaniem ją zablokowali ponieważ były bugi. 3. Ponieważ BMesh nie wspiera n-gonu w n-gonie, właściwie żaden znany mi program tego nie wspiera, musisz w choć jednym miejscu je połączyć edgem.

PTex jest w planach przecież, z resztą psioczenia na UV Editor się zgodzę. Problem w tym, że marudzenie jak stara zrzęda na maxie niewiele da :P

Ha, świetny klimat :D wybiorę się do kina na bank. Aktor grający Bane'a pasuje idealnie, wygląda jak tępy osiłek, ale głos ma idealny dla geniusza psychopaty. Ciekawe czy głos należy do tego samego aktora, hmmm

@Plejground Ale Gutek i Artozi powiedzieli, że nawet jako "pierwszy zarys" wiele im brakuje i źle do nich podchodzisz. :) Niepotrzebna kreska, to niepotrzebna kreska, nawet jak szkic jest bardzo luźny to każda linia powinna spełniać jakieś zadanie, coś opisywać.

Kilka miesięcy temu informowaliśmy o pojawieniu się bardzo ciekawego Addon'a dla programu Blender o nazwie Bsurfaces, pozwalającego generować geometrię na podstawie narysowanych linii lub krzywych, przydatnego również przy retopologi oraz modelowaniu. Wspomniany dodatek został niedawno udostępniony całkowicie za darmo oraz uwolniony na licencji GNU GPL Pełna treść wiadomości znajduje się na stronie głównej serwisu pod adresem: http://www.max3d.pl/news.php?id=2360

@floo Wieczorem dam newsa na główną, bo teraz trochę zajęty jestem, a Adek ma wolne odpoczywa gdzieś hen daleko :P

Niestety loop toolsy nie zostały jeszcze przeniesione na nowe API.

W Cycles wylądował Motion Vector i UV pass. http://lists.blender.org/pipermail/bf-blender-cvs/2012-April/045300.html