LEGO Renderingi

Cześć!

O tym, że w świecie wirtualnym  istnieje możliwość tworzenia i publikowania własnych konstrukcji LEGO  wiedzą już chyba wszyscy, którzy od czasu do czasu przeglądają flickry czy fora tematyczne. I nie, nie chodzi mi tu o zdjęcia prawdziwych MOCów – myślałem tu raczej o ich renderach, t.j. obrazkach stworzonych w oparciu o wirtualne klocki tworzące pewną całość. Najpopularniejszym – i chyba najprostszym do ogarnięcia, chociaż nie pozbawionym też wad – programem, wykorzystywanym w tym celu jest LEGO Digital Designer (LDD).

Największą zaletą programu jest prosty i intuicyjny interfejs. Wśród wad należy wymienić: komplikację przy łączeniu niektórych elementów (pomimo, że w świecie rzeczywistym takich problemów nie ma), oraz jakość samych grafik, która nie umywa się do renderów, które możemy zaobserwować w galeriach „wirtualnych” MOCerów. To tak w dużym skrócie.

O ile na pierwszą wadę jednego dobrego rozwiązania jeszcze nie znalazłem, o tyle kwestia rozwiązania drugiego problemu stała się przyczyną powstania niniejszego artykułu. Ale lećmy po kolei.
LDD vs POV-Ray

 

Cóż zatem?

Przyznam, że tematem wcześniej się nie interesowałem, więc całkiem możliwe, że rozwiązanie podał już ktoś inny wcześniej. W każdym razie, przeglądając wyrenderowane MOCe zostałem na tyle oczarowany ich jakością, iż postanowiłem samemu coś podobnego zrobić. Wiedziałem jednak, że samo LDD tu nie wystarczy, dlatego też rozpocząłem poszukiwania czegoś, co mogłoby poprawić jakość renderów …

… i w zasadzie nie musiałem długo szukać, bo wyszukiwarka dość szybko pomogła mi w odnalezieniu takiego „wspomagacza”. Program nazywa się „LDD to POV-Ray Converter” i podobnie jak LDD dostępny jest całkowicie za darmo, na stronie producenta.

 

Jak to działa?

Generalnie idea jest taka, że tworzymy model w LDD w taki sam sposób, jak robiliśmy to do tej pory. Następnie zapisujemy projekt w jakimś sensownym miejscu na dysku (plik z rozszerzeniem *.lxf). Następnie plik ten ładujemy do naszego konwertera, klikamy „CONVERT” i czekamy, aż uruchomi się POV-Ray i zacznie renderować (obliczać) naszą grafikę. Gdy wszystkie piksele będą już policzone, zostaniemy o tym poinformowani przez program, a w wybranym przez nas wcześniej folderze pojawi się nasz końcowy obrazek. Proste, nieprawdaż Watsonie?

A zatem będziemy potrzebowali łącznie trzech programów:

 

Instalacja

Kolejność instalacji poszczególnych programów nie powinna mieć znaczenia, ale jeśli czujesz się niepewnie, możesz użyć takiej, jaką przedstawiłem powyżej :)

Na stronie konwertera autor opisał dość dokładnie proces instalacji, dlatego pozwolę go tutaj pominąć. Pomocne mogą być też pierwsze kroki, instalacja POV-Raya oraz dostosowanie go do pracy z konwerterem.

Wszelkie moje spostrzeżenia bazują na wersji 64-bitowej. Podczas dostosowania POV-Raya do pracy z konwerterem, z jakiegoś powodu nie działała mi funkcja „edit master” (być może dlatego, że ustawiłem niestandardowe ścieżki i partycje przy instalacji), dlatego musiałem dopisać linijkę w pliku „POVRAY.INI”:

; Note that some platforms (e.g. Windows, unless this feature is
; turned off via the configuration file) will automatically append
; standard locations like those mentioned above to the library
; path list after reading this file, so in those cases you don’t
; necessarily have to have anything at all here.
;
Library_Path=”\\.\LDDIncludes”

… by następnie ponownie odpalić POV-Raya.

W linijce z komendami wpisałem sobie (zgodnie z instrukcją, chociaż nie wiem, czy ten krok jest konieczny):

+L”\\.\LDDIncludes”

… po naciśnięciu przycisku RUN (biały ludzik w zielonym kółku) program wygenerował testowe herbatniki i nic się nie wykrzaczyło ;)

UWAGA!!!
Jeśli macie uruchomionego LDD, to konwerter Wam nie pójdzie! Dzieje się tak, ponieważ dwa programy korzystają z jednakowych zasobów. A zatem, po zapisaniu projektu wyłączamy LDD i włączamy konwerter.

 

Do dzieła!

Zakładam, że instalacja i konfiguracja niezbędnego oprogramowania przeszła pozytywnie i możemy kontynuować nasze rozważania. W dalszej części artykułu będę zmieniał ustawienia poszczególnych suwaków z naszego konwertera i porównywał jakość powstałych grafik, jak również czas niezbędny do ich powstania. Mam prośbę – nie traktujcie tego jako prawdę absolutną, bo tu naprawdę bardzo wiele zależy od różnych czynników (ilości wątków procesora, odległości MOCa od kamery, jak również stopnia przezroczystości samych klocków …). Generalnie chodzi o to, żeby mieć jakieś pojęcie o tym, jakich ustawień lepiej używać, a z jakimi dać sobie spokój, coby nie tracić później cennego czasu …

W dalszych rozważaniach zakładam, że:

  • wyżej wymienione programy używane są w wersjach 64 bitowych
  • dostępny procesor: Intel Core i-5-4460 (4 jednocześnie pracujące wątki)
  • pamięć ram: 8 GB
  • rozdzielczość: 1920 x 1200 (przy czym w artykule zaprezentowane zostały jedynie fragmenty grafik – pełne rendery znajdziecie TU i TU)
  • w trakcie renderowania włączona była jedynie przeglądarka, notatnik, POV-Ray i konwerter – żadnej „dodatkowej działalności” (typu słuchanie muzyki itd.)
  • klikając na dany obrazek powinien otworzyć się jego odpowiednik w większej rozdzielczości
  • jeżeli w danej tabelce pogrubiona jest jakaś kolumna, oznacza to wartość domyślną dla danego parametru
  • dla osób ciekawskich udostępniłem współdzielony plik z dotychczasowymi, dokładniejszymi obliczeniami
  • Czasy poszczególnych renderów starałem się nieco zaokrąglać w górę, stąd rozbieżności w stosunku do tego, co znajdziecie w pliku

Modelem, który wykorzystałem w procesie renderowania jest głowa 1-ej wersji Optimusa. Aby otrzymać lepsze porównanie czasowe, w paru przypadkach użyłem dwóch wersji obiektu – posiadającej przezroczyste elementy i takiej, która ich nie posiadała.

 

Domyślne ustawienia

Użycie domyślnych ustawień konwertera zaowocowało powstaniem następujących grafik:

   
ok. 1h 56 min ok. 0h 10 min 30 sek

Pod każdym obrazkiem znajduje się wartość odpowiadająca czasowi, jaki był niezbędny do ich wyrenderowania. Dane te są przybliżone i sformatowane do postaci „użytecznej” dla przeciętnego użyszkodnika ;)

Jak widać, użycie przezroczystych elementów znacznie wydłuża proces generowania grafik. Nie chciałbym tutaj zagłębiać się w algorytmy, które są wykorzystywane w procesie obliczeń (jak ktoś ma takie ambicje, to zapraszam na grafikę komputerową ;) ), ale generalnie chodzi o to, że komputerowi łatwiej jest obliczyć światło odbite od zwykłego klocka, niż bawić się z klockami przezroczystymi (część światła zostaje odbita, ale część przenika przez przezroczysty klocek o pewnym stopniu załamania światła i idzie dalej, aż natrafi na kolejny przezroczysty klocek itd.; następnie dane te są zbierane do kupy i na ich podstawie tworzony końcowy obrazek). To tak w dużym uproszczeniu.

Ważna tu jeszcze jest inna kwestia – odległości klocków przezroczystych od oka obserwatora – im dalej taki klocek się znajduje, tym szybciej powinien wygenerować się obraz (powierzchnia takiego przezroczystego elementu znacznie się zmniejsza i liczba promieni przechodzących przez nią również).

I na tym w zasadzie mógłbym zakończyć – ustawienia domyślne powinny dać całkiem niezły rezultat w miarę normalnym czasie. Ja jednak już tak mam, że lubię wynajdować koło od nowa, dlatego też w dalszej części pobawię się nieco różnymi „suwaczkami”, aby zobaczyć, na co wpływają i czy w ogóle opłaca się ich używać …

 

LEVEL OF DETAIL

Parametr odpowiada za szczegółowość detali naszej grafiki. Znajdziemy go w zakładce Model.

       
 Level of detail  3  2  1  0
 czas  1h 56m  1h 56m  1h 49m  13m 30s

Tabelka z objaśnieniem:

 Level of detail  Info  O co chodzi?
 0 Original LDD geometry  Sama geometria LDD, bez większych detali (wcięć, krągłości, prymitywniejsza przezroczystość …)
 1 Original LDD geometry + visible bevels Geometria LDD + skosy klocków (lepsze detale)
 2 Original LDD geometry + visible bevels+ LEGO text on studs Geometria LDD + skosy klocków (lepsze detale) + napis „LEGO” na klockach (+ ich cienie)
 3 Original LDD geometry + all bevels+ LEGO text on studs Geometria LDD + wszelkie możliwe skosy klocków (jeszcze lepsze detale) + napis „LEGO” na klockach (+ ich cienie)

Jak widać, w większości wypadków zmiana parametru nie wpływa istotnie na szybkość renderingu. Zmienia się za to jakość samego renderu.

Domyślnie ustawiona jest opcja 2, ale biorąc pod uwagę, ile renderuje się opcja 2, a ile 3 – polecam ustawić tą wartość na maksimum.

 

QUALITY

Quality (jakość) to parametr mający bezpośredni wpływ na … jakość końcowej grafiki. Znajdziemy go w zakładce Rendering.

         
 quality  11 (max) 10 8  7 5
 czas   1h 56m   1h 56m  0h 7m 40 s   0h 4m 10s  0h 1m 23s
       
 quality 4 3 1 0
 czas 12s 7,5s 6s 6s

Poniżej mała tabelka ze skrótowym objaśnieniem, co poszczególne wartości oznaczają:

 Quality  Info  O co chodzi?
 0-1  Quick colors, full ambient lightning only  Szybkie kolory + światło otoczenia
 2-3  show specified diffuse and ambient light  światło rozproszone + otoczenia
 4  show specified diffuse and ambient light, render shadows, but not extended lights  światło rozproszone + otoczenia + cienie (bez rozbudowanego oświetlenia)
 5 show specified diffuse and ambient light, render shadows, including extended lights  światło rozproszone + otoczenia + cienie (rozbudowane oświetlenie)
6-7  show specified diffuse and ambient light, render shadows, including extended lights, include texture patterns, compute photons  światło rozproszone + otoczenia + cienie (rozbudowane oświetlenie) + wzory textury + fotony
8  show specified diffuse and ambient light, render shadows, including extended lights, include texture patterns, compute photons, compute reflected, refracted, and transmitted rays  światło rozproszone + otoczenia + cienie (rozbudowane oświetlenie) + wzory textury + fotony + załamanie/odbicie/transmisja promieni świetlnych
9-11    show specified diffuse and ambient light, render shadows, including extended lights, include texture patterns, compute photons, compute reflected, refracted, and transmitted rays, compute media, radiosity and subsurface light transport   światło rozproszone + otoczenia + cienie (rozbudowane oświetlenie) + wzory textury + fotony + załamanie/odbicie/transmisja promieni świetlnych, wykorzystanie mediów transportu światła, metody energetycznej,  oraz imitacja materiałów (np. że gładkie elementy wyglądają na gładkie, a szorstkie na szorstkie)

Jak widać, użycie maksymalnej wartości parametru  quality powoduje wygenerowanie grafiki o najlepszej jakości. Niestety wydłuża to też czas obliczeń – dobrze jest wówczas pójść na dłuższy spacer i dać komputerowi dokonać niezbędnych obliczeń.

Kategoria 8 daje render dobrej jakości – powierzchnie chropowate są rzeczywiście chropowate, a gładkie są gładkie. Nawet czasowo nie jest tak źle. Problem polega jedynie na tym, że model jest … nieco zbyt ciemny. Być może udałoby się rozjaśnić całość w programie graficznym, ale obawiam się, że wówczas oczy Optimusa mogłyby być nienaturalnie jasne.

Kategoria 7 pozbawiona jest specyficznych właściwości materiałów, również same cienie nie wydają się być zbyt naturalne (ostre, nie rozpraszają się tak, jak w świecie rzeczywistym). Kategoria 5 powoduje, że przezroczyste elementy wyglądają jak jakieś ciemne, nieprzezroczyste klocki. Obniżając dalej wartość quality, jakość cieni spada (brak rozmycia przy „uszach” dla 4). Dla wartości poniżej 2 w miejscu klocków widzimy tylko ich podstawowe kolory – co może nie jest takie złe, bo dzięki temu całość zyskuje nieco kreskówkowego wyglądu, co przy niektórych prezentacjach może okazać się pomocne (już wyobraziłem sobie biały kubek z takim nadrukiem!). Zastanawiam się też, czy tak wyrenderowanych kolorków nie dałoby się użyć do jakiejś maski, którą następnie nałożyłoby się na obraz wyższej kategorii w GIMPie – jakość pewnie nie będzie tak dobra jak przy maksymalnym ustawieniu rendera, ale przynajmniej powinniśmy nieco zyskać na czasie.

Szybkie porównanie:

 

 

THRESHOLD

Threshold – podobnie jak Jitter, czy Depth – to parametr antyaliasingu POV-Raya, który znajdziemy w zakładce rendering. Z tym antyaliasingiem to generalnie chodzi o to, żeby krawędzie obrazu nie były za bardzo rozpikselowane, ale nieco rozmazane – dzięki temu grafika wygląda bardziej realistycznie, a nie jak „stare gry DOSowskie”.

Tym razem postanowiłem zbadać zachowanie dwóch typów grafik – z przezroczystością i bez.

Grafiki zawierające przezroczyste elementy:

Threshold 0 0,3 1,5 3
Czas 2h 45m 1h 56m 1h 32min 1h 32m

Dla porównania – grafiki pozbawione przezroczystości:

Threshold 0 0,3 1,5 3
Czas 19m 43s 10m 34s 6m 29s 6m 27s

Można zauważyć, że zwiększenie parametru Threshold powoduje poprawę ostrości modelu, ale kosztem wspomnianego już anty-aliasingu. Innymi słowy, im większa jest jego wartość, tym wyraźniejsze są kontury (i napis na klockach!), ale przy zbyt dużej wartości przy przybliżeniu widoczne są wspomniane „kwadraty” na krawędziach (np. na antenkach Optimusa).

W zasadzie już o tym wspomniałem, ale powtórzę jeszcze raz, bo tabelki pokazują to bardzo czytelnie – czas renderingu wersji nieprzezroczystej jest dużo krótszy od  jej przezroczystego odpowiednika. Różnica ta może wynieść nawet 1,5h i więcej!

 

JITTER

Jitter (z ang. Fluktuacja piksela) to kolejny ciekawy parametr anty-alisingu POV-Raya, związany z zakłóceniami. O co chodzi? Na jednej ze stron znalazłem takie wytłumaczenie, które wydaje się być napisane w miarę „po ludzku”:

Załóżmy, że rzeczywisty sygnał wideo jest czarny na początku linii i zmienia się w czasie aż do bieli po osiągnięciu końca linii. Fluktuacja piksela powoduje, że dowolny pozyskany piksel jest trochę bardziej czarny lub trochę bardziej biały niż wynikałoby to z rzeczywistości. (…) Kiedy monitor wyświetla pozyskany obraz, piksel pokazywany jest jaśniejszy niż powinien być. Efekt fluktuacji piksela można łatwo zauważyć na granicy dwóch kontrastujących kolorów lub poziomów szarości (np. test ekranu ze słupkami poziomów szarości). Można wtedy zaobserwować zakłócenia na granicy dwóch kolorów lub poziomów szarości w postaci nieostrości lub mienienia się kolorów.

 

A jakie ma to przełożenie w praktyce?

Jitter 0 5 10
Czas 1h 54m 1h 55m 1h 56m
Jitter 0 5 10
Czas 8m 43s 8m 52s 9m 2s

W przypadku obrazu przezroczystego, zmniejszenie wartości jittera nieco poprawia jakość cienia, rzucanego przez grill znajdujący się na głowie Optika. W przypadku obiektu nieprzezroczystego widać odwrotny trend (dla upewnienia się powtórzyłem badanie z identycznymi parametrami dla obrazu nieprzezroczystego – poza drobnymi różnicami w czasie cała reszta się zgadza).

 

DEPTH

Czyli kolejny, znaczący parametr.

Oprócz sprawdzania samej wartości depth, w powyższym teście ustawiłem poziom detali na wartość 3 (max; wcześniejsze testy jasno pokazały, że nie powinno mieć to dużego wpływu na czas renderowania). Wartość depth ograniczyłem do przedziału 1-5 ze względu na znaczące wydłużanie się czasu renderowania (9 jest maksymalną możliwą wartością).

Przy okazji – pozwoliłem sobie na zabawę parametrem Method.

Wersja przezroczysta:

Method Method1 (good) Method1 (good) Method1 (good) Method1 (good) Method1 (good)
Depth 1 2 3 4 5
Time 1h 36m 1h 34m 1h 55m 2h 16m 2h 35m
Method Method2 (slow) Method2 (slow) Method2 (slow) Method2 (slow) Method2 (slow)
Depth 1 2 3 4 5
Time 1h 29m 2h 5m 2h 55m 2h 54m 4h 14m

Odpowiednik nieprzezroczysty:

Method Method1 (good) Method1 (good) Method1 (good) Method1 (good) Method1 (good)
Depth 1 2 3 4 5
Time 7m 30s  7m 38s  9m 2s 10m 35s  12m 22s
Method Method2 (slow) Method2 (slow) Method2 (slow) Method2 (slow) Method2 (slow)
Depth 1 2 3 4 5
Time 7m 8m 45s 8m 48s 11m 15s 14m 31s

Jak widać, im większa jest wartość depth, tym krawędzie obrazu są bardziej rozmyte. Zauważyć też można, iż w przypadku obrazu z przezroczystymi elementami – mają one jakby „mniej kropek” (porównaj sobie oczy Optimusa dla depth 1 i 5). Podobnie rzecz się ma z zastosowaniem metody slow – obliczenia trwają dłużej, ale oczy Optimusa wydają się bardziej naturalne niż przy metodzie good.

Ogólnie, to odnoszę wrażenie, że im większa wartość parametrów (depth, method), tym lepsza jakość, co ma też niestety wpływ na czas obliczeń – w skrajnym przypadku dla method2, obliczenia dla przezroczystego obrazu trwały ponad 4h!

 

CIENIE I DODATKOWE OŚWIETLENIE

Light3 (top) 40% 40% 40% 80% 100% 40%
Shadow 0% (FALSE) 0% (TRUE) 10% 10% 10% 100%
Time 1h 30m 1h 55m 1h 56m 1h 58m 1h 58m 1h 59m

Jak widać, konwerter pozwala również na manipulację światłem oraz cieniami. W powyższych renderach ograniczyłem się jedynie do światła padającego z góry oraz odpowiadającemu mu cieniowi.

Spoglądając na wyniki – odnoszę wrażenie, że momentami render wychodzi ładniejszy, niż przy manipulacją głębokością. Uważam, że najlepsze rendery wyszły dla dwóch przypadków – cienia ustawionego na 0% (i zaznaczonego na true) oraz dla 80% światła padającego z góry. Choć oczywiście nie chciałbym tu tworzyć tezy, że jest to jedyna słuszna kombinacja – być może wiele zależy od samego modelu … Ważniejsze jest jednak to, żeby wiedzieć, że manipulacja tymi parametrami naprawdę ma sens – tym bardziej, że w stosunku do wcześniejszych parametrów czasy się aż tak diametralnie nie różnią …

Jest jeszcze jedna rzecz, na którą wypadałoby wrócić uwagę. Otóż chodzi o rozróżnienie dwóch przypadków dla shadow 0% włączonego na true/false. Okazuje się, że wykorzystanie tych dwóch metod daje różne grafiki! Co więcej, wyłączenie cienia zauważalnie zmniejszyło czas renderowania – o prawie pół godziny – kosztem niestety jakości.

Poniżej zamieszczam jeszcze mały test z wymieszaniem efektu light+shadow oraz oświetleniami bocznymi (left, right – 2 ostatnie obrazki):

 

Light Top, 80% Top, 10% Left, 80% Right, 80%
Shadow 0% (true) 80% 10% 10%
Time 1h 54m 1h 57m 1h 57m 1h 57m

Mój komentarz do tabeli jest następujący – światło padające z góry nieco poprawia kolory, ale wydaje mi się też, że nie ma co z nim przesadzać i drobne cienie nie wyglądają tak źle. Dodatkowo można zauważyć, że oświetlenie z lewej strony daje – w tym konkretnym przypadku – lepszy rezultat, niż oświetlenie z prawej (które przypomina mi dość ostre światło w południe).

Możecie się ze mną nie zgodzić, ale uważam, że światło padające z boku (left) daje nieco lepszy rezultat, niż światło padające z góry (top), głównie z uwagi na takie detale, jak cień na faceplate Optika czy jego antenkach. Odnoszę również wrażenie, że uzyskane w ten sposób kolory są nieco łagodniejsze.

 

WNIOSKI

Jak widać, renderowanie to proces dość długotrwały i wymagający cierpliwości. Czas tego procesu zależy nie tylko od użytych wartości pewnych parametrów programu, ale też od samych modeli i ich odległości od obserwatora. A skoro tak, to być może przed zrobieniem finalnego rendera należałoby wcześniej wykonać kilka próbnych, z gorszymi parametrami – dzięki temu łatwiej wyłapiemy ewentualne błędy, a i nie będzie to tak kosztowne pod względem czasu i pracy dla naszego procesora.

Wiele też zależy od samego sprzętu, na którym dokonujemy obliczeń, dlatego też nie ma co traktować podanych tu wartości jako prawdy absolutnej – najlepiej zrobić kilka prostych testów na swoim sprzęcie. Dużym błogosławieństwem jest udostępnienie w najnowszym POV-Rayu obliczeń wykorzystujących pracę wielowątkową – dzięki temu nasze procesory są lepiej wykorzystane, a same rendery liczą się szybciej. Żałuję tylko, że nie udało mi się jeszcze znaleźć jakiejś opcji pod GPU …

Na myśl nasuwa mi się jeszcze jedno – LDD co prawda ma bardzo bogatą bazę elementów, ale dobrze jest tak od czasu do czasu pobudować coś z rzeczywistych klocków ;) Z drugiej strony – ładne renderingi mogą posłużyć nie tylko jako MOCe w galerii, ale też w video na YT bez konieczności posiadania profesjonalnego sprzętu (w postaci aparatu czy namiotu bezcieniowego) … A jak ktoś ogarnia Blendera, może sobie zaimportować model i stworzyć naprawdę porządną animację (ale o tym może innym razem ;) ) …

Reklamy

2 uwagi do wpisu “LEGO Renderingi

  1. Może pisze o tym w nieodpowiednim miejscu ,ale znalazłem fajny zestaw creator 31034. Swoją drogą to taki wypasiony mixel ,z tym ,że jest o wiele droższy. Czy tylko mi się wydaje że projektant tego setu to jedna z nielicznych osób która słucha fanów, dając im modele z ruchomymi palcami, przydatnymi bardzo elementami i własnoręcznie zrobioną głową. To (moim zdaniem) brzmi i wygląda naprawdę dobrze!
    Następny akapit. Widziałeś bionicle na 2016? Który z nich to twój faworyt(moim zdaniem dżungla jest najciekawsza).
    Ostatnie pytanie oraz pomysł. Może zrobisz jakiegoś prostego świątecznego moca. Choć wiem że będzie to trudne to trzymam kciuki( na upartego mógłbyś Executorowi nałożyć świąteczną czapę i byłby spokój).

    • Powiem tak.
      Seria creator już wcześniej oferowała kilka fajnych modeli, jak np. 31007 Power Mech, 31008 Thunder Wings czy 5764 Rescue Robot. Każdy z nich z osobna jest (a raczej był) ciekawą pozycją, która jeśli nie na półkę, to z pewnością posłuży(ł) jako świetny dawca części na mecha.

      W 2004 roku był dostępny taki duży, fajny mech (4508 Titan XP), ale z tego co mi wiadomo był drogi i niestety nie załapałem się na niego.

      31034 jest o tyle ciekawy, że kupując go zyskujesz możliwość tworzenia robotów z 4-roma palcami na każdej ręce. Jest też bazą ciekawych elementów, jak np łączniki. Jeżeli masz zatem niewystarczającą ich ilość, to możesz zastanowić się nad jego kupnem. Przyznam się, że też się nad nim zastanawiałem, ale na razie nie zdecydowałem się na zakup, gdyż bazę potrzebnych elementów już mam i klocki w zestawie nie są dla mnie już tak atrakcyjne. No ale ja to ja, Ty masz prawo do odmiennej opinii ;)

      Co do Bionicle 2016 – mówiąc szczerze jestem troszkę zawiedziony, bo liczyłem na reaktywację Toa Nuva. Przyszłoroczne Bio kojarzą mi się z taką krzyżowką starych Bionicli z tymi z 2008/2009 roku za którymi nie przepadałem. Ale poczekajmy na ostateczne zdjęcia i finalne konstrukcje, być może nie jest tak najgorzej. Tak czy inaczej – gdybym miał kupić jakiegoś bohatera, zrobiłbym to dla części – a na razie ich nie ma na Bricksecie.

      No ale gdybym miał wybrać – zastanowiłbym się nad Onuą lub Tahu (części).

      Co do świątecznego MOCa – Executor raczej odpada, bo rozebrałem go jakieś 2 miesiące temu (została sama głowa), ale spróbuję coś wykombinować :)

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s