Kompilacja Blendera pod Linux Mint 15

Uwaga!

Zwróć uwagę na datę.

Ten materiał (cokolwiek to jest) został stworzony w czasach gdy nie było Blendera z serii 2.8, i może być PRZESTARZAŁY! Blender rozwija się bardzo szybko.

Kompilacja Blendera z SVN pod Linux Mint 15 za pomocą scons. Kompilacja pod Linux? To jakaś masakra! Oczywiście dla tych, którzy nosa nie wysunęli poza Windows… odważnych zapraszam do systemu Linux!
Ten poradnik ma nowszą wersję, przeznaczoną dla repozytoriów GIT i kompilacji Blendera pod Linux Mint 16. Zapraszam do nowszego artykułu! W tym poradniku tym razem nie pokażę filmu, lecz tekst i obrazki. Taka forma jest lepsza dla osób chcących skompilować program i szybko wybrać z poradnika odpowiednie elementy. Chcę pokazać, jak na nowym, dopiero co zainstalowanym systemie (czyli od zera) uzyskać Blendera skompilowanego na swoją własną maszynę, i to najnowszego, sprzed dosłownie sekund. Prosto od developerów. Zatem bez zbędnego lania wody, zaczynamy. Przygotuj się na dużo czytania.

Dla kogo jest ten poradnik

Zakładam, że poradnik ten jest dla osób, które są w stanie zainstalować windę bez wyrywania włosów z głowy, ewentualnie dla tych, które umieją zainstalować Linuxa i nadal są w stanie żyć z tym doświadczeniem. Nie będę tłumaczył wszystkiego od zera, zatem jeżeli czegoś nie zrozumiesz, poszukaj na sieci, np. przy pomocy Wujka Google. Osoby zaawansowane uprzedzam, że materiał tu przedstawiony może być dla nich zbyt prosty (tłumaczę upraszczając niektóre rzeczy!). No i przypominam, że każdą zmianę na swoich (lub cudzych) komputerach robicie na swoją odpowiedzialność, a informacje przedstawione poniżej nie muszą dla Was działać, nie muszą dawać dobrych efektów i przedstawione są w celach edukacyjno-poznawczych. Stosowanie poniższych porad bez ich zrozumienia… jest hm, niezalecane. Poniżej adresy www, które dotyczą kluczowych spraw są pogrubione (podaję sporo różnych pobocznych linków do zasobów w sieci). Jeżeli Twoja dystrybucja Linuxa jest inna niż Mint15, to polecenia poniższe mogą nie działać. Postępuj wtedy zgodnie z wytycznymi właściwymi dla swojej dystrybucji. A w takim przypadku zapewne nie potrzebujesz tego poradnika 🙂

Od czego zaczynamy

Potrzebny jest Linux, najlepiej tuż po instalacji i aktualizacji. Wykorzystałem dystrybucję, którą bardzo ostatnio lubię, to jest Linux Mint, w wersji 15 (najpopularniejsza dystrybucja wg. DistroWatch, numer 1). Istnieje dla niego polskie wsparcie. Taki system instaluje się bardzo prosto, jedna rzecz na którą trzeba uważać to partycjonowanie. Osoby, które nigdy tego nie robiły, mogą popróbować instalacji np. w wirtualnej maszynie VirtualBox (darmowy program który tworzy w okienku symulację osobnego komputera, na którym można prowadzić eksperymenty z instalacją, ja w ten sposób wypróbowuję różne nowe dystrybucje Linuxa, mam też w takiej klatce Windowsa XP). Na początku zainstalujemy wymagane oprogramowanie (potrzebne jest podłączenie komputera do sieci), potem pobierzemy Blendera z SVN (svn to program do przechowywania wszystkich wersji kodu źródłowego i dodatkowych plików, fachowo – system kontroli wersji, w którym znajduje się repozytorium Blendera). Po takim pobraniu źródeł nasza wersja Blendera będzie najnowsza, tuż spod rąk developerów. Dzięki temu nawet wersje dostępne na GraphicAll.org będą starsze od naszej. Po pobraniu źródeł, będzie trzeba pobrać dodatkowe źródła, ponieważ Blender korzysta z pomocniczych bibliotek, np. OpenColorIO, FFMPEG, itp. Na końcu tego procesu należy skonfigurować proces kompilacji, określając, gdzie leżą poszczególne paczki ze składnikami programu, a potem uruchamia się kompilację. W wyniku kompilacji, otrzymujemy zainstalowanego w określonym wcześniej katalogu nowiutkiego Blendera, gotowego do pracy! 🙂 Proces ten tylko za pierwszym razem jest złożony, potem uaktualnienia robi się banalnie.

Krok 0: Informacje o instalacji

Sposób instalacji Blendera jest opisany na stronach Blender.org pod tytułem Building Blender. Jest to jednak tylko przekierowanie do stron z dokumentacją dla twórców oprogramowania, i rzeczy, które tam znajdziecie mogą być niezrozumiałe dla ludzi nie zajmujących się programowaniem i kompilacją programów. Wchodzimy zatem na stronę WIKI:Building Blender (http://wiki.blender.org/index.php/Dev:Doc/Building_Blender), i tam wybieramy opcję dla Blendera 2.5x oraz dla Linuxa (jest tam opis dla Windows, ale nawet tam nie klikałem). Naszym oczom ukaże się tabelka podobna do tej poniżej:
Tabelka z metodami instalacji
Tabelka z metodami instalacji
Ponieważ Linux Mint jest dystrybucją pochodną od Ubuntu, wybierzemy właśnie pierwszą kolumnę, metody instalacji pakietów są takie same. W tym poradniku opiszę jak skompilować Blendera za pomocą Scons, ponieważ wersja z CMake jest trudniejsza i bardziej złożona. Moje poprzednie instalacje opierały się z cmake, teraz wolę korzystać ze scons, ponieważ jest naprawdę dużo wygodniejszy. Ale to oczywiście opcja do wyboru. Po kliknięciu w link Scons przejdziemy na stronę z właściwym opisem kompilacji. Niestety, brak tłumaczenia tej strony na język polski, dlatego poniżej objaśnię poszczególne etapy.

Krok 1: Instalowanie narzędzi

Zgodnie z opisami na stronie http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux/Ubuntu/Scons, najpierw należy zainstalować warsztat potrzebny do budowania programów. Jeżeli mamy zatem naszego Linuxa gotowego do pracy, otwieramy terminal i wpisujemy polecenie:
sudo apt-get update
Może pojawić się prośba o podane naszego hasła, ponieważ wymagany dostęp do uprawnień administracyjnych. Polecenie to wykona aktualizację informacji o dostępnych w sieci źródłach oprogramowania. Po wykonaniu tego polecenia (i obejrzeniu dość sporej ilości tekstu w terminalu) mamy system, który będzie instalował najnowsze oprogramowanie, jeżeli jakieś sobie zażyczymy. Przechodzimy zatem do instalacji systemu zarządzania kodem (subversion) oraz środowiska potrzebnego do kompilacji programów (build-essential), wpisując:
sudo apt-get install subversion build-essential \
 libxi-dev libsndfile1-dev \
 libpng12-dev libjpeg-dev libfftw3-dev \
 libopenexr-dev libopenjpeg-dev \
 libopenal-dev libalut-dev libvorbis-dev \
 libglu1-mesa-dev libsdl1.2-dev libfreetype6-dev \
 libtiff4-dev libavdevice-dev \
 libavformat-dev libavutil-dev libavcodec-dev libjack-dev \
 libswscale-dev libx264-dev libmp3lame-dev python3.3-dev \
 libspnav-dev libtheora-dev libjack-dev libglew1.6-dev
Znaki ukośnika na końcu oznaczają kontynuację i należy po nich nacisnąć ENTER, aby można było kontynuować w następnym wierszu. Może zostać zainstalowanych sporo pakietów. Na moim komputerze pojawiała się całkiem imponująca lista niezbędnych rzeczy, co widać na poniższym obrazku:
Instalacja podstawowych narzędzi
Instalacja podstawowych narzędzi
Na innych komputerach i instalacjach Linuxa sytuacja ta może wyglądać nieco inaczej. U mnie w momencie wykonania tego polecenia istniało już całe skonfigurowane środowisko graficzne z dodatkowymi programami, zatem lista pakietów może być nawet dłuższa u tych osób, które jeszcze niczego nie instalowały. Oczywiście na pytanie zadane na samym dole odpowiadamy twierdząco, wpisując T i wciskając ENTER. Proces instalacji potrwa chwilę, a gdy się zakończy, nasz system powinien być w stanie kompilować programy i umożliwiać pracę z kodem, tak samo, jak to jest u developerów Blendera. Na liście pakietów widać między innymi takie, które nazywają się lib-cośtam. Są to biblioteki, z których składać się będzie Blender. Większość z nich znajduje się już od razu w systemie, potrzebne jednak są specjalne dodatkowe pliki, aby była możliwa kompilacja nowych programów. Te dodatkowe pliki pochodzą z pakietów których nazwa na ma końcu dodatek -dev. Instalowany jest też kompilator g++ (czasem też make i gcc – pochodzące z pakietu build-essential), oraz narzędzia perlowe do łączenia różnic w plikach.

Krok 2: Pobieranie Blendera z SVN

Po instalacji pakietów narzędziowych, nadchodzi czas na pobieranie samego Blendera, a dokładniej – na pobranie wszystkich kodów źródłowych wraz z plikami dodatkowymi, takimi jak ikonki, skrypty, zasoby, itp. Wystarczy wpisać proste polecenia:
cd ~
mkdir blender-svn
cd blender-svn
svn co https://svn.blender.org/svnroot/bf-blender/trunk/blender
Polecenia te wykonują różne rzeczy. Pierwsze przechodzi do katalogu domowego, następne tworzy katalog (folder) o nazwie blender-svn, kolejne wchodzi do tego katalogu a najważniejsze jest ostatnie – jego wykonanie uruchamia dość złożony proces pobierania plików z serwera deweloperskiego i odtworzenie całej struktury katalogów i plików, wraz z ich historią na naszym komputerze. Wszystko to dzieje się w katalogu blender-svn, zatem nigdzie poza tym nie będą tworzone żadne dodatkowe pliki. Jest to proces, który zależnie od szybkości łącza może zająć więcej lub mniej czasu, a na ekranie będą wyświetlane wszystkie pobierane pliki. W moim terminalu wpisywanie tych poleceń wyglądało tak:
Pobieranie źródeł Blendera
Pobieranie źródeł Blendera
Natomiast po wykonaniu tego ostatniego polecenia, otrzymałem informację, że wszystko pobrano i obecna wersja Blendera, tzw. roboczy numer rewizji, to 57548. Ten numer oznacza liczbę zmian wprowadzonych do kodu i umieszczonych w repozytorium SVN. Nie jest to prawdziwa wersja Blendera, ale numer roboczy, który można porównywać aby ustalić która wersja jest wcześniejsza. Im numer wyższy, tym więcej zmian wprowadzono do kodu, tym bardziej ‚dojrzała’ jest wersja Blendera. W trakcie pisania tego poradnika ten numer zmienił się kilka razy, ponieważ gdzieś na świecie pracują ludzie, którzy nieustannie dodają do Blendera nowe kody lub poprawki, i numer rewizji rośnie. Dzięki niemu ocenicie, na ile wasze kompilacje będą nowsze od tych ze strony Blendera. Poniżej wygląd okna po wykonaniu ostatniego powyższego polecenia.
Po pobraniu źródeł Blendera
Po pobraniu źródeł Blendera
Zapewne zwracać uwagę mogą te tajemnicze litery, które pojawiają się po lewej stronie, np. A lub U, itp. Nie są to błędy ani pomyłki deweloperów, ale informacja na temat każdego pliku i jego status. Litera A oznacza, że plik został dodany jako nowy, wcześniej go nie było. Litera U mówi, że plik był już wcześniej i że został zaktualizowany. Jeżeli któryś z deweloperów zmieni nawet jeden wiersz w jakimś pliku, to pojawi się przy nim litera U. Pliki, które się nie zmieniły, nie są pokazywane. Istnieją także inne rodzaje statusów, ale dla nas to informacje nieistotne. W każdym razie pobierając nowszą wersję po np. tygodniu zobaczycie być może także inne stany plików.

Krok 3: Instalowanie zależności

Blender składa się z wielu elementów stworzonych przez ludzi, którzy nigdy o samym blenderze nie myśleli. Takie części składowe nazywa się pakietami, i aby zbudować kompletnego Blendera, należy takie pakiety posiadać w odpowiednich wersjach. Oczywiście powinny to być ich wersje źródłowe. Całą niezbędną pracę związaną z pobieraniem, kompilacją oraz instalowaniem tych pakietów może dla nas wykonać skrypt, napisany przez twórców Blendera. Skrypt ten wykona podobne operacje do tych, które my zrobiliśmy do tej pory z samym Blenderem, to znaczy przygotuje odpowiednie katalogi i pobierze, a potem skompiluje oprogramowanie, które będzie następnie użyte do zbudowania samego Blendera. Wpisujemy zatem polecenie:
cd ~/blender-svn
./blender/build_files/build_environment/install_deps.sh --install ~/blender-svn/deps --source ~/blender-svn/depssrc
Zadaniem tego polecenia jest automatycznie wykonanie całej żmudnej roboty, dlatego na ekranie zobaczymy sporo różnego rodzaju komunikatów. Ponieważ są to informacje o przebiegu operacji wykonywanych przez skrypt i najczęściej udaje się wszystko, nie będę się o tym rozpisywał. W moim terminalu wpisałem jednak trochę więcej, to znaczy określiłem domyślne miejsce, gdzie mają być pobierane pakiety źródłowe, oraz gdzie mają być instalowane. Dzięki temu wszystkie elementy składowe utrzymuję w jednym katalogu, który można łatwo przenieść lub usunąć (i znika od razu całość – co może być przydatne jeżeli chcemy zacząć od nowa). Oto jak to wygląda w moim terminalu:
Automatyczne instalowanie zależności
Automatyczne instalowanie zależności
Jednakże moja kompilacja Blendera nie powinna zawierać dodatków, których nie chcę posiadać. Można zatem wyłączyć niektóre z nich. Wiem z doświadczenia, że nie kompiluje się u mnie np. collada, oraz że nie działają skrypty osl, z których nie muszę korzystać ponieważ Cycles będę używał tylko na karcie graficznej. Zatem wyłączam dwie rzeczy, dodając dodatkowe elementy do polecenia, i teraz powinno ono wyglądać tak (rozpisuję je na osobne wiersze dla czytelności – pamiętacie znaki ukośnika na końcu wiersza?):
cd ~/blender-svn
./blender/build_files/build_environment/install_deps.sh \
 --install ~/blender-svn/deps \
 --source ~/blender-svn/depssrc \
 --with-all \
 --skip-opencollada \
 --skip-osl
Dopiero takie polecenie działa (u mnie), pobierając wszystko z wyjątkiem pakietów do niekompilującej się (zapewne chwilowo) collady, oraz nie dołączając skryptów OSL. Uruchomienie polecenia bez tych wszystkich dodatkowych parametrów także zadziała, ale skrypt będzie próbował instalować dodatkowe oprogramowanie w miejscach, do których zwykły użytkownik nie ma prawa do zapisu (zatem polecenie takie można wykonać przez sudo). Wolałem jednak trzymać wszystko w jednym miejscu. Skrypt po uruchomieniu wypisuje dodatkowe informacje, które w skrócie objaśniają do czego służą poszczególne opcje podane w wierszu poleceń. Jest dość oczywiste, że argument opcji –install określa, na jakiej ścieżce mają zostać zainstalowane pakiety po kompilacji (znajdą się tam programy oraz ważne biblioteki pomocnicze, bez których zbudowanie Blendera będzie niemożliwe). Opcja –source określa ścieżkę w której będą umieszczone pakiety w wersjach źródłowych, przeznaczonych do skompilowania. Opcja –with-all włącza wszystkie dodatki i zależności, a opcje –skip-cośtam wyłączają niektóre z nich. W tym przypadku wyłączyłem wsparcie dla collada oraz osl. Okno terminala po wykonaniu tego polecenia wygląda tak:
W trakcie instalacji zależności
W trakcie instalacji zależności
Instalacja kończy się gdy zobaczymy informację o dostępnych opcjach kompilacji, oraz na końcu pojawi się komunikat, że „Te informacje zostały zapisane do BUILD_NOTES.txt”. Jeżeli nie, to mamy pecha i trzeba rozwiązać problem, który wystąpił w trakcie kompilowania zależności. Nie wiem, co może się nie udać, jednak możliwości jest sporo i gdyby coś takiego się stało, schemat postępowania jest zawsze ten sam: czytacie uważnie komunikat o błędzie i stosownie do tego naprawiacie sytuację. A jeżeli nie wiecie co i jak, to droga będzie trudna – znowu wujek google… a potem godziny i dnie spędzone na rozwiązywaniu problemów i pokonywaniu trudności… witamy w prawdziwym świecie! 🙂 Wbrew pozorom, cała operacja przeszła na świeżej instalacji Mint15 bez problemów, zatem jest to kolejna miła rzecz, która podoba mi się w tej dystrybucji. Oto wygląd okna po instalacji wszystkich zależności:
Po instalacji zależności
Po instalacji zależności
Informacje, które podane są na ekranie, widoczne w powyższym oknie są istotne w przypadku, gdybyśmy chcieli skonfigurować niektóre opcje kompilacji Blendera, ale to już następny punkt.

Krok 4: Kompilacja Blendera

Doszliśmy do najważniejszej operacji i głównego tematu tego poradnika. Aby skompilować Blendera, należy wpisać polecenia:
cd ~/blender-svn/blender && python scons/scons.py
W moim terminalu polecenie to rozbiłem na dwa wiersze i wyglądało to tak:
Kompilacja Blendera
Kompilacja Blendera
Chodzi o to, że proces budowania Blendera jest bardzo skomplikowany. Zajmuje się tym wyspecjalizowany program napisany w pythonie, dlatego podajemy na początku polecenia słowo python a potem nazwę pliku zawierającego zestaw poleceń przeprowadzających cały proces. Blendera można kompilować na wiele sposobów, w różnych konfiguracjach i pod różne systemy, dlatego program scons korzysta z osobnych konfiguracji, zależnych od systemu w którym pracujemy (lub dla którego chcemy kompilację przeprowadzić). Wszystkie domyślne konfiguracje przeznaczone dla różnych systemów znajdują się w katalogu blender/build_files/scons/config/ i jest ich tam całkiem sporo. W naszym przypadku zostanie automatycznie użyta konfiguracja linux2-config.py, zatem nie musimy się prawie o nic martwić. Warto jednak wiedzieć, gdzie szukać, w przypadku, gdyby wystąpiły problemy. Uwaga: jeżeli proces kompilacji przeszedł bez błędów, przejdź do rozdziału Krok 5. Aby się dowiedzieć, co może czekać pechowców, czytaj dalej 🙂 Po naciśnięciu ENTER rozpocznie się proces kompilacji, który może trochę potrwać. Trzymając kciuki czekamy, i w napięciu patrzymy co się dzieje. Po paru godzinach (lub minutach – zależy od szybkości komputera), naszym przekrwionym oczom może ukazać się przerażający błąd! Oto on – przynajmniej tak było u mnie:
Błąd kompilacji Blendera
Błąd kompilacji Blendera
Jest to niestety, dość częsta, typowa sytuacja. Pokażę poniżej, jak można sobie z tym poradzić. Najpierw czytamy na samym dole komunikat, który zakończony jest słowem Error 1. Oznacza to, że wystąpił błąd, oczywiście, którego skutkiem jest przerwanie procesu kompilacji. Jeżeli czegoś z tym nie zrobimy, Blendera nie skompilujemy. W trakcie kompilacji wypisywanych jest także sporo ostrzeżeń (tak jak widoczne przy pliku multires.c w wierszu 633 ostrzeżenia (warning) o indeksowaniu tablicy za pomocą znaku. Nie należy się takimi rzeczami przejmować – ostrzeżenia to normalna rzecz, a w tym przypadku jest to dopuszczalne. Język C, w którym napisano kod modyfikatora Multires (znamy go z Blendera) dopuszcza indeksowanie tablic znakami, ponieważ w C istnieje równoważność pomiędzy znakiem, a niewielką liczbą całkowitą. Ze względu jednak na czystość i całkowitą zgodność z ideą bezbłędnego programowania, kompilator wyświetla takie (i wiele innych) ostrzeżenia. Najważniejszy dla nas jest jednak błąd, który pojawił się na dole ekranu i przerwał brutalnie proces kompilacji. To jest problem do pokonania, i zależnie od rodzaju błędu, postępowanie może być inne. Nic nie zastąpi tu doświadczenia, jednak przy pomocy Google można znaleźć sporo porad w sieci. W przypadku tego błędu także sięgnąłem do pomocy wyszukiwarki. Aby poprawić błąd, należy przygotować niewielki plik, który zmodyfikuje proces domyślnej kompilacji, jaki wykonuje dla nas scons. Jest to bardzo proste, ponieważ potrzebne informacje dostaliśmy już na ekranie, i dodatkowo mamy je zapisane w pliku. Należy wrócić do pliku BUILD_NOTES.txt, który niedawno widzieliśmy wyświetlony na ekranie. Ten plik zawiera domyślne polecenia ustawiające pewne parametry kompilacji. Potrzebujemy teraz wprowadzić w tym pliku drobną zmianę, aby kompilacja poszła dalej, ale najpierw taki pliki trzeba zrobić w odpowiednim miejscu. Pokazane jest to na obrazku poniżej i ponumerowane, aby łatwiej było ogarnąć, co trzeba zrobić. Aby było wygodniej, warto powiększyć sobie okno terminala, aby nie trzeba było go przewijać.
Tworzenie własnej konfiguracji kompilacji
Tworzenie własnej konfiguracji kompilacji
Punkt (1): Najpierw wychodzimy z katalogu blender, w którym prowadzona była kompilacja, i trafiamy do starego blender-svn. Mamy w tym miejscu już przygotowany plik BUILD_NOTES.txt zrobiony dla nas przez program do automatycznego instalowania zależności (robiliśmy to w Kroku 3). Ten plik zawiera parę potrzebnych informacji, które wykorzystamy, aby przygotować sobie własną konfigurację kompilacji. Punkt (2): Za pomocą polecenia tail wyświetlamy 20 ostanich wierszy z pliku BUILD_NOTES.txt. Polecenie to jest jednym z wielu prostych narzędzi Linuxowych, i nic innego nie umie robić, tylko wyświetlać ileś tam ostatnich wierszy z pliku. Śmieszne, ale przydatne. Te ostatnie wiersze zawierają trochę tekstu oraz parametry kompilacji, które zobaczymy pokazane w terminalu. Punkt (4): Tak, teraz robimy punkt 4. Wpisujemy pokazane polecenie cat (i dalszy ciąg też). Wciskamy ENTER. Kursor powinien zatrzymać się w następnym wierszu i tyle. To polecenie ma zrobić nowy plik z konfiguracją kompilacji. Może to wydawać się skomplikowane, ale chcemy po prostu gdzieś zapisać fragment tekstu, ten zaznaczony. Zaznaczenie trzeba zaraz zrobić a potem tekst z niego wkleić. Punkt (3): Dopiero teraz 3! Zaznaczamy myszą odpowiednie wiersze, jak widać na powyższym obrazku. Używamy lewego klawisza myszy. NIE używamy kółka myszy, ponieważ może ono wprowadzić śmieciowe znaki do tekstu. Interesują nas tylko opcje kompilacji zaznaczone na obrazku. Zaznaczenie myszą w Linux działa tak, że od razu mamy tekst skopiowany do schowka, zatem nie musimy naciskać Ctrl+C (nawet nie wolno, bo ten skrót robi co innego – przerywa działanie programów) 🙂 Po zaznaczeniu wciskamy – uwaga – klawisze Shift+Insert (jest taki na klawiaturze, jeżeli go nie ma, to zamiast tego możemy wcisnąć kółko myszy. Jeżeli nie mamy kółka, to możemy próbować wcisnąć naraz lewy i prawy klawisz myszy jednocześnie). Kombinacja Shift+Insert wkleja tekst ze schowka, a ponieważ przed chwilą zaznaczyliśmy tekst w terminalu, to akurat trafił on do schowka. Na końcu całej operacji, już po wklejeniu tekstu, wciskamy ENTER, aby dodać jeden nowy wiersz do pliku, a potem naciskamy Ctrl+D, czyli klawisze końca pliku. Powinien wrócić znak zgłoszenia systemu w terminalu. Jeżeli coś się nie uda, bez paniki możemy wcisnąć ENTER i Ctrl+D, aby przerwać wpisywanie do pliku za pomocą cat. Jeżeli jednak wciśniemy Ctrl+D w terminalu tak normalnie, to terminal zostanie zamknięty, i będzie trzeba go otworzyć i przejść do katalogu w którym pracujemy (w takim przypadku, czyli po otwarciu terminala, wpisujemy cd ~/blender-svn i wciskamy ENTER). W efekcie tych działań (prostych – uwierzcie mi – pod Linuxem jest to codzienność) – powstanie nowy plik, który zapisany będzie na ścieżce ~/blender-svn/blender i nazywać się będzie user-config.py. Ten plik musi mieć taką nazwę i taką lokalizację, aby scons wykorzystał go do zmiany swojego zachowania. Dla rozwiązania problemu z FFMPEG z powyższego okna to wystarczy, ponieważ nasza konfiguracja zawiera ścieżkę do odpowiednich bibliotek. Zatem warto wznowić proces kompilacji (wpisując cd blender && python scons/scons.py), i obserwować co będzie się działo dalej. Może się okazać, że pojawi się nowy błąd:
Błąd kompilacji COLLADA
Błąd kompilacji COLLADA
Tym razem widzimy napis „fatal error” co oznacza błąd tak straszliwy, że aż fatalny. Tymczasem, ponieważ w naszym skrypcie automatycznie instalującym zależności wyłączyliśmy instalowanie biblitek collady, po prostu ich nie ma, i dlatego cała kompilacja padła. Przyczyna błędu jest w konfiguracji kompilacji, która chce użyć plików, których nie dostarczyliśmy, jak pokazano na obrazku poniżej (na którym wyświetlamy naszą konfigurację używaną przez scons):
Przyczyna błędu kompilacji
Przyczyna błędu kompilacji
Musimy trochę poprawić nasz domyślny sposób kompilacji, aby nie uwzględniał collady, i wtedy nie będą potrzebne brakujące pliki, i całość pójdzie prawidłowo. Zatem, poprawiamy nasz plik z domyślną konfiguracją, wyłączając kompilację collada – trzeba zamienić napis WITH_BF_COLLADA=True na inny – WITH_BF_COLLADA=False. Aby to zrobić w pliku, możemy użyć perla, pewnego magicznego języka, w którym można pisać nie tylko programy, ale i wiersze. Powinien być zainstalowany w każdym popularnym Linuxie. Wpisujemy polecenia pokazane na obrazku poniżej:
Poprawianie konfiguracji za pomocą perla
Poprawianie konfiguracji za pomocą perla
Wyjaśnienia są na rysunku. Perl działa w ten sposób, że bierze każdy wiersz z pliku user-config.py, i analizuje go, patrząc czy jest w nim napis „COLLADA = True”. Jeżeli takiego napisu nie ma, to nic się nie dzieje, ale w jednym przypadku taki napis będzie znaleziony. Wtedy nastąpi jego zamiana na napis „COLLADA = False”. Perl dodatkowo wszystkie te zmiany zapisze w pliku, zatem nie trzeba nawet używać edytora tekstu, aby wprowadzić zmiany do pliku. Oczywiście, jeżeli pomylisz się wpisując polecenie, wszystko może się popsuć, ale Linux to często jazda po bandzie, zatem po prostu wpisuj polecenia bez błędów 🙂 Ja zawsze tak robię! 🙂 Na samym końcu za pomocą polecenia grep sprawdzam, czy faktycznie zmiana została wprowadzona. Polecenie grep przeszukuje plik user-config.py i sprawdza, czy jest w nim napis COLLADA. Jeżeli jest, to wypisywane są wiersze z COLLADA oraz jeden wiersz przed i po nim. Proste? 🙂 W tym momencie mamy przygotowany plik z własną konfiguracją kompilacji, który pokazuje programowi scons, gdzie znajdują się biblioteki ffmpeg, oraz że nie należy kompilować collady. W tym momencie można wznowić kompilację i zobaczyć, czy wszystko się uda. Zakończenie procesu kompilacji będzie wyglądało tak, jak na poniższym obrazku:
Zakończenie kompilacji
Zakończenie kompilacji
Jest tu różnica w stosunku do tego, co jest napisane na stronach deweloperskich z dokumentacją Blendera. Tam wspomniane jest o słowie „Success”, które tutaj się nie pojawia, ale wszystko i tak jest w porządku, ponieważ scons napisał, że skończył budować swoje targety (czyli wykonał zadania, które miał zrobić).

Krok 5: Uruchomienie najnowszego Blendera

Po całym tym procesie Blender jest skompilowany, i znajduje się wewnątrz katalogu blender-svn, na ścieżce install/linux. Oto okno, na którym wylistowana jest zawartość tego katalogu:
Blender gotowy do użycia
Blender gotowy do użycia
Polecenie „l” wyświetla u mnie zawartość katalogów. Standardowo takiego nie ma pod Linuxem, zrobiłem je sobie za pomocą polecenia „alias l=’ls -ltrF’ „, ale aby wyświetlić pliki, napisz po prostu ls -l (eles minus el). Na samym końcu wykonałem polecenie du -sh, które pokazuje ile miejsca zajmuje instalacja Blendera. Jak widać jest ona sporo większa od wersji ze strony Blender.org, dlatego, że zawiera więcej skryptów i różnych dodatków. Jest to bardzo wypasiona wersja, ze wszystkimi wersjami testowymi, niestabilnymi lub częściowo działającymi. Jazda po krawędzi, ale i najnowsze dodatki! Aby uruchomić program, wpisujemy polecenie ./blender (oczywiście musimy się znajdować w katalogu ~/blender-svn/install/linux). Oto wygląd okna powitalnego (tzw. splashscreen) nowo skompilowanego Blendera:
Splashscreen = okno powitlane
Splashscreen = okno powitlane

Zakończenie

Opisany powyżej proces instalacji może przebiegać inaczej u Ciebie. Niestety, nie jestem w stanie pomóc w przypadku problemów, które napotkasz, próbuj z google, i szukaj rozwiązań na sieci, podobnie jak zrobiłem ja. Po pewnym czasie, a być może od razu – kompilacja uda Ci się znakomicie! Zauważ też, że systemy które są starsze mogą mieć inne narzędzia i inną konfigurację potrzebną do przeprowadzenia tego procesu. Na moim domowym komputerze musiałem używać wersji z cmake, ponieważ korzystam z własnej kompilacji ffmpeg i proces pracy z różnymi wersjami tego samego programu działającymi jednocześnie jest bardziej skomplikowany. W razie potrzeby korzystaj ze stron z dokumentacją, które podałem. A w przypadku, gdy nic się nie uda – zawsze możesz pobrać gotową wersję ze strony Blender.org, lub Graphicall.org! 🙂 Powodzenia! W tym poradniku nie opisuję jak przygotować automatyczny skrypt do kompilacji i odświeżania blendera np. raz dziennie, ani nawet nie wspominam jak zrobić program automatycznie budujący całego blendera. Nie mówię też jak zrobić ikonkę z nowym Blenderem, którą się klika i od razu jest najnowszy. Sporo jest tematów do ogarnięcia, a Linux to niewyczerpane źródło możliwości i inspiracji. Moje rozwiązania nie muszą nikomu pasować… u siebie piszę polecenie bmake.sh i Blender robi się sam, potem klikam ikonkę na pasku zadań i uruchamiam od razu najnowszego. Są to proste rzeczy, które zostawiam jako pracę domową 🙂 Aby wykonać ponownie kompilację nowszej wersji, jest już bardzo łatwo, bo wystarczy wydać w zasadzie dwa kluczowe polecenia: pobrania nowszej wersji, oraz kompilacji. Robi się to tak:
cd ~/blender-svn
svn up
cd blender
python scons/scons.p
I gotowe!   Mój Blender wygląda ładniej niż ten standardowy, ponieważ zrobiłem sobie własny splashscreen. Oczywiście, prawda jest taka, że jeżeli czegoś w Blenderze Wam brakuje, to macie kod źródłowy – można sobie brakujące funkcje dopisać! 🙂 Polecam!
Własny splashscreen
Własny splashscreen
  Ciekaw jestem jak Wam uda się kompilacja. Pochwalcie się w komentarzach!  

Wasze przemyślenia

Od kilku dni nic nowego się nie ściąga (za pomocą „svn up”) i nic nowego się nie kompiluje, ostatni build to 61240, na builder.blender.org też od kilku dni jest ta wersja (zmienia się tylko data builda).
Czyżby przeszli na gita? (Piotr gdzieś o tym pisał).
Sprawdziłem na wiki.blender.org (krok 0 tutka), początek jest taki sam. Wybieramy system (Linux), rodzaj i sposób kompilacji (Ubuntu i Scons) i… dostajemy ekran z poniższymi linkami (z ver 2.5?! i tylko po angielsku)
1 REDIRECT Dev:2.5/Doc/Building Blender/Linux/intro
2 REDIRECT Dev:2.5/Doc/Building Blender/Linux/dependencies
3 REDIRECT Dev:2.5/Doc/Building Blender/Linux/get the source
4 REDIRECT Dev:2.5/Doc/Building Blender/Linux/scons
Pierwszy to tylko wstęp;
Drugi to instalowanie narzędzi (krok 1 u Piotra);
Trzeci – pobieranie źródeł z git.blender.org i instalowanie zależności (kroki 2 i 3);
Czwarty – kompilacja Blendera za pomocą scons.py i sposób uruchamiania (kroki 4 i 5).
Jeśli jest to najnowszy sposób na kompilowanie Blendera, to znalazłem dwa błędy w w/w linkach.
W trzecim linku tworzymy folder na pliki Blendera o nazwie blender-git, a w czwartym linku, aby uruchomić scons, mamy wejść do blender-svn (chyba zapomnieli poprawić ścieżki na blender-git).
Drugi błąd – w aktualizacji źródeł (wcześniej używałem ‚svn up’), teraz:
git pull –rebase
git submodule update –remote
w drugiej linii – nie istnieje opcja –remote (git 1.8.1.2). Spróbowałem użyć –rebase, git to przyjął, ale czy coś zrobił, nie wiem (nic nie wypisał)…
Poza tym, po uruchomieniu tak skompilowanego builda, na splashu nie ma numeru builda (ostatnio był 61240), jest tylko data i godzina, oraz tekst ‚Hash: a05e90f’
Jeżeli naprawdę przeszli na git-a, trzeba będzie poprawić tutka…

Wygląda na to, że przeszli na git-a.
Drugi błąd z mojego w/w komentarza odpadł, zainstalowałem najnowszego git-a (1.8.4.3) i ten łyka opcję –remote bez żadnych errorów.
Najprawdopodobniej nie będzie już numerów build-ów (rxxxxx), teraz gdy w konsoli wpiszę:
./blender –version
dostaję m.in. taki tekst:
Blender 2.69 (sub 2)
build date: 2013-11-17
build time: 20:34:38
build commit date: 2013-11-17
build commit time: 15:41
build hash: 84c30ed

Jestem ciekaw, co to jest build hash?

Oczywiście, że przeszli na gita, i ja blendera kompiluję już w nowym systemie od ponad tygodnia. Jednak sprawy jeszcze się stabilizują, będą też dopisane na wiki nowe instrukcje dotyczące kompilacji. U mnie blender po kompilacji w ogóle nie pokazuje wersji, i jest to zrozumiałe. Będzie jednak to naprawione.
Build hash jest to numer buildu w postaci unikalnego napisu generowanego ze specjalnej funkcji haszującej. Działa on tak samo jak poprzednio numery wersji – jednoznacznie identyfikując dany build. A że jest to dla ludzi nieczytelne, to mniejsza o to 🙂 Traktuj to jako numer bez łatwiej do przewidzenia kolejności.
Sergiej w jakimś mailu na bf-development podał opis jak wyciągnąć numery rewizji z gita, ale nie pamiętam 🙂
Tutka poprawię, jak sprawa się ustabilizuje.

jest takie coś

jak wsadzić tego .patch’a (w opisie link) do blendera? bo podane w opisie linki do skompilowanych buildów nie działają ERROR(404)
sprawdzałem to
<a href="
http://blenderartists.org/forum/showthread.php?258004-Patch-for-Sewing-Clothes-in-blender/page4&highlight=cloth+tutorial„>
ale takoż samo, opór ze znalezieniem builda na z clouth- sewing ( czekam na przyjęcie mnie do, zlinkowanego wyżej, forum przez admina )
potrzebuję modelować takie rzeczy – :wpisać w wyszukiwarce: „membran architecture” (od dawna walczę z jakimiś narzędziami do modelowania takich struktur i zawsze kłody pod nogi)
to jak „wsadzić” tego .patch do kodu? przez kompilację całego blenda czy łatwiej się da jakoś? Bartek Skorupa wczytywał tekst do text editor i zapisywał jako addons swój „plugin” do edytora nodów, na konferencji blendera, ale mi tak nie działa)

Fajną rzecz znalazłeś. Niestety, to co robił Bartek Skorupa to było programowanie w pythonie i jako takie może być zrobione w Blenderze bez potrzeby kompilacji. Skrypy, które tworzy Bartek to dodatki, addony, czyli coś, co działa w Blenderze i rozszerza jego możliwości. W przypadku tego patcha masz zmiany w stosunku do kodu źródłowego samego Blendera, zatem musisz go skompilować. Patch dotyczy wersji Blendera 2.63, rewizja 47947 i tylko do niej możesz zaaplikować tego patcha. Robi się to za pomocą programu patch, potem kompilacja.
W wątku, który podałeś są linki do buildów pod Windoze, może będą u Ciebie działać.

Kompilowanie Blendera działa, ale mimo że nie było żadnych błędów (nie licząc Warningów), nie chce się uruchomić OSL (czyli nie działają skrypty w OSL), więc przy renderowaniu na CPU nie ma opcji włączania ‚Use OSL’ (w oficjalnych buildach jest).
Zaznaczam że NIE używałem opcji ‚–skip-osl’, a gdy (wg BlenderWiki) próbowałem dodać opcję ‚–with-osl (oprócz ‚–with-all’ i ‚–skip-opencollada’), wyświetliło komunikat ‚unknown option’.
Nie działały też CUDA, ale to chyba sprawa sterownika grafiki, po doinstalowaniu pakietu CUDA-SDK, jest w porządku (mogę w User Preference wybierać między CPU a CUDA).
Próbowałem też kompilować przez CMake, ale nic z tego. Na dzień dobry nie mógł znaleźć paru bibliotek (OCIO, OIIO), a ponieważ nie wiem jak skonfigurować cmake (brak takiego opisu jak Piotra o Scons), dałem sobie spokój…
Więc, po tym wszystkim, chyba będę musiał używać też oficjalnych buildów.

U mnie po prostu OSL też nie działał dlatego budowałem Blendera bez niego. OSL jest powolny i ponieważ renderuję na GPU, mogłem go sobie odpuścić, ze stratą możliwości tworzenia własnych shaderów, ale na razie mogę to przeżyć.
CMake jest fajny i używałem go wcześniej, do czasu, aż faktycznie coś zmieniło się w źródłach i przestał działać. Trzeba jednak podać dużo ścieżek ręcznie, nawet po wykorzystaniu programiku CMakeGui, który pomaga ustawić ścieżki do zależności. Było dużo ręcznego tuningowania i skrypt, który powstał miał 3 razy dłuższy wiersz do cmake ze zmiennymi, niż ekran. Większość to były zmienne typu -DHAVE_COSTAM, bo nie wiedzieć czemu cmakegui nie zgłaszał problemów, a cmake i tak nie widział ocb. Może teraz dlatego kompilacja z cmake jest tak trudna do wymuszenia. Na pewno jest bardziej wrażliwa na zmiany w SVN.

Niestety, muszę używać CPU, mam za słabą kartę grafiki. A OSL? hmmm…
Może to nie jest aż tak potrzebne…
Coś widzę, że może przydałoby się założyć na forum wątek nt. kompilowania Blendera… w dziale Sprawy Różne.
Tutaj komentarze jakoś dziwnie się układają, jeśli klikam na ‚odpowiedz’ jest OK, a bez tego, wstawia mój komentarz gdzieś pomiędzy innymi (nie na końcu).

Skompilowałem Blendera (po raz kolejny) i niby wszystko w porządku, ale…
CUDA musiałem doinstalować osobno, aby można było je wybrać w User Preference.
Dzisiaj zauważyłem brak okienka do zaznaczania OSL w zakładce Render (build 60641) i nie wiem
czy tak ma być, czy znowu coś się zepsuło (nie używałem opcji –skip-osl). Na ściągniętym buildzie
(60599) jest te okienko…
Poniżej króciutki teścik builda 60599, plik testowy BMW1M-MikePan.blend
Render Win7 Linux
CPU, supported, +OSL – 8’17,36 6’27,49
CPU, experimental, +OSL – 8’08,12 6’23,85
CPU, supported, -OSL – 6’48,30 5’01,71
CPU, experimental, -OSL – 6’48,89 5’03,26
GPU, supported – 4’19,89 4’11,12
GPU, experimental – 4’19,54 4’10,61

A propos… Co to za programik pokazujący (prawdopodobnie) obciążenie rdzeni procesora?
Widać go na tutorialach, znalazłem tylko taki wykresik procka jako całości.
Ciekawe czy jest coś podobnego dla GPU?

Nie znalazłem, ale to możliwe. Mam tylko monitor temperatury. Możesz w terminalu zobaczyć polecenie nvidia-smi – czasami też pokazuje coś ciekawego, zależnie od tego, co wspiera karta. Najlepsze raporty były na Teslach, ale zwykłe GTXy też działały.

Witam,
Co trzeba zmienić przed kompilacją Blendera żebym mógł używać OpenCL i CUDA? Teraz używam wersji 2.68a, którą zainstalowałem z repozytorium: ppa:irie/blender. W ustawieniach programu mam do wyboru CPU i GPU Compute (CUDA), ale po wpisaniu w terminalu: CYCLES_OPENCL_TEST i uruchomieniu blendera poprzez terminal w ustawieniach mogę wybrać OpenCL albo CUDA.
Pozdrawiam

heh. Chyba Tak. Ale chciałem tak zrobić żeby działało to bez używania terminala. Poszukam innej wersji albo skompiluje sobie go sam.
Dziękuję za cały kurs Blendera. Oglądałem kilka filmów i jestem zadowolony.
Pozdrawiam;)

Skoro uruchamiasz sobie z terminala, to czy nie możesz utworzyć sobie odpowiedni skrót?

Napisałem już sobie skrypt w bash. Chwilkę to trwało, ale mam go i działa.

A co Ty o tym myślisz?

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *