SYmek

1. Kto to jest człowiek od FX? To osoba, która tworzy ruchomy obiekt/zjawisko/cokolwiek - byle nie była to postać. Co to jest postać? Jest to obiekt/zjawisko/cokolwiek, co twórcy filmu uznali za postać. Czyli podział jest raczej arbitralny, z czego wynika, że animator fx NIE jest kimś, kto zajmuje się cząsteczkami i rozwałką, nawet jeśli tym właśnie zajmuje się najczęściej. Postacią może być bowiem wszystko, za czym stoi animator, czyli komputerowy aktor, także walący się budynek, jeśli zażyczy sobie tego reżyser/supervisor. A skoro tak, to człowiek od FX powinien potrafić zająć się wszystkim, co nie zmieści się w kategorii postaci lub, choć nie zawsze, środowiska (environment). Prostym przykładem jest symulacja tłumu, która wymaga znajomości zarówno cząsteczek jak i podstaw riggowania. 2. Oczywiście wiele zależy od tego, czy animator fx pracuje w firmie animacyjnej, efektowej czy reklamowej. Ot, choćby dlatego, że w pierwszym przypadku rzadko kiedy będzie musiał myśleć o integracji swoich efektów z materiałem filmowym. A to cała dziedzina wiedzy. 2.1 W filmie animowanym liczy się przede wszystkim spójność z estetyką filmu. Dlatego też znacznie rzadziej stosuje się w nim prawdziwe symulacje zjawisk fizycznych, co wymusza inne podejście do efektów - ręczne. Mówiąc najprościej w filmie animowanym każdy piksel opowiada historię, więc takie terminy jak wyraz, energia, nastrój, grają zasadniczą rolę. Zdarza się, że symulacja kole w oczy, a nie pomaga… 2.2 Zupełnie przeciwnie jest w przypadku efektów filmowych. Dwa słowa-klucze to realizm i skala. Masz przed sobą najczęściej kilkadziesiąt ujęć i wszystkie powinno kleić się z materiałem filmowym. Wymusza to inne myślenie o swojej pracy - w kategoriach kosztów osiągnięcia danej iluzji. Wymaga też pewnego obycia z pracą kamery i materiałem filmowym a także ciekawości, która skłania do przyglądania się światu z bliska, ponieważ estetyką w tym przypadku jest rzeczywistość. Przypuszczam, że właśnie dlatego fotografia jest taką plagą wśród efekciarzy. Trzeba się zaopatrzyć w jakąś cyfrową lustrzankę, bo nikt z tobą nie pójdzie na piwo. 2.3 Kończąc, w przypadku reklamy idzie przede wszystkim o relację czasu do efektu końcowego – czas w reklamie odgrywa zasadnicze znaczenie, a realizm już niekoniecznie - reklama jest z założenia ekspresowym filmem stylizowanym. 3. Jakie znaczenie dla doboru narzędzi, rozwoju zawodowego i twojej wiedzy mają powyższe wynurzania daruję sobie tu pisać. Na wszystko trzeba by jeszcze nałożyć filtr długości geograficznej, specyfikę danego kraju etc. Mam nadzieje widać, że są tu pewne różnice i wynikają z nich decyzje, które należy rozważyć. Skoro będę musiał symulować dym, który nie zachowuje się poprawienie fizycznie, albo muszę go wykonać w setce ujęć, albo musi być dwa razy większy, niż umożliwia mi mój program, to z tych wszystkich zadań wynikają jakieś decyzje, które należy umieć nazwać i podjąć. 4. Nie chce się wdawać w dyskusję o prymacie doświadczenia nad teorią, przydatnością lektur etc. Jeśli jednak czujesz się zagubiony w temacie jest parę książek, które pomogłyby Ci zyskać rozeznanie. Założenie jest takie, że poza znajomością oprogramowania, które już Ci polecono, powinieneś rozumieć swoje poczynania, tj. podążać myślą za swoimi narzędziami, choćby po to, by radzić sobie, kiedy Cię zawiodą, albo potrafić odnaleźć alternatywną ścieżkę postępowania, gdy wymaga tego sytuacja (a wymaga tego bardzo często). Nie jest to bynajmniej „rocket sciene”, ale mówiąc wprost nie przyjąłbym do pracy człowieka, który nazywa siebie animatorem FX, a nie potrafi pomnożyć kwaternionów i nie ma pojęcia co to jest równanie naviera-stroka. Nie, nie musi wcale programować sam fluidów, wystarczy że będzie wiedział, czym różnią się podejścia do tematu różnych softwarów i z czego te różnice wynikają. To właśnie czyni z niego profesjonalistę na równi ze znajomością oprogramowania - dlatego, że robi z niego człowieka wiarygodnego, na którym można polegać. Taka wiedza przychodzi z czasem, ale im wcześniej zaczniesz, tym lepiej. 4.1 Pozycji jest mnóstwo, pierwsze, z czubka głowy (nie polecam ich jakoś szczególnie) to: Physics-Based Animation albo Computer Animation Algorithm & Techniques. Wszystko, co tam napisano, znajduje się w Internecie a część także w Helpach odpowiednich programów, ale jest rozrzucone i trudne do ogarnięcia. Być może zresztą istnieją lepsze źródła. Polecam po prostu nie myśleć w kategoriach nowych zabawek, które od czasu do czasu pokazują się torrencie, tylko zainteresowanie zjawiskami, których odtwarzania się podejmujesz, oraz technikami, które do tego służą. Jest też parę książek traktujących o efektach specjalnych w filmie w ogólności, ale nie znam żadnej, więc nie polecę. Google it. 5. Co do potrzeby skryptowania i programowania. Oczywiście nie każdy musi umieć programować, choć to się po prostu przydaje, w najprostszym scenariuszu, kiedy chcesz przenieść dane między programami. Nie przejmowałbym się przy tym czasem, niby co będziesz robił za 4 lata? Skryptowanie opanujesz w miesiąc, za dwa lata będziesz znał większość interesujących Cię programów. Za trzy zacznie Ci się nudzić i siądziesz do c++. Taka jest w każdym razie droga wielu, jeśli nie większości ludzi w tej branży (fx). Wcześniej czy później siadają do C++, bo niby dlaczego mają sobie odcinać drogą do dziesiątków rozwiązań odległych na wyciągnięcie ręki… 6. Na koniec drażliwy temat wyboru oprogramowania. Jak napisałem wcześniej istnieje pewne zasadnicze rozróżnienie w programach. Jedna ich grupa powstała wiele lat temu w świecie filmu, druga poza nim. Przez lata te dwa światy żyły oddzielnie. Dzisiaj, głównie dzięki rozwojowi hardwaru oraz Internetowi, który ułatwia wymianę informacji, te światy się zazębiają. Dzisiaj jest możliwe, aby filmy powstawały na domowych pecetach, więc nie potrzeba już specyficznego podejścia, którego wymagał film 10 lat temu i które ukształtowało Mayę czy Houdiniego. To pewne uproszczenie, ale mniejsza o to. 5.1 Sprawa ma znaczenie o tyle, o ile pomaga zrozumieć swoje wybory. Świat filmu (Maya, Houdini) to stare programy, które prawie nigdy nie dorównują przystępnością i prędkością działania młodszym narzędziom, jak pluginy Maxa. Z drugiej strony, rynek pluginów wymusza na ich konstrukcji pewne ograniczenia, które bywają trudne do strawienia z punkty widzenia kogoś, kto przywykł do wolności dawanej przez Maję czy Houdiniego. Właśnie dlatego są to jednak dwie ścieżki rozwoju, które w miarę możliwości należy łączyć, ale warto zdawać sobie sprawę, co tak naprawdę, poza powierzchowną funkcjonalnością dostajemy w pakiecie. Minusem pluginów jest odtwórczość, walorem skuteczność. 5.2 Sprawa zasadza się na naturze wszechświata ;) : albo prędkość i przystępność, albo elastyczność i wszechstronność, tertium non datur. W przeciwnym razie, wszystkie Porche byłyby Hammerami, wszystkie laski miałyby phd, a ja byłbym i przystojny i bogaty... 5.3 Mimo tego zachęcam do uczenia się wszystkiego, co wpadnie w ręce. Nic tak nie pomaga w tym zawodzie jak wszechstronność (wszechstronność narzędzi, nie koniecznie specjalizacji). I Max i Maya i Houdini i XSI, obowiązkowo Real Flow. Jest to możliwe właśnie dlatego, że wszystkie one robią to samo, więc o ile się wie, co robią, nie powinno robić człowiekowi różnicy, w jakim GUI się to odbywa. Jest to wyłącznie kwestia obycia. Adwekcja to adwekcja, kwaternion to kwaternion, a SDF to SDF. 5.4 Są przy tym dwie szkoły. Jedni twierdzą, że lepiej jest zacząć łatwo a potem sięgnąć głębiej, inni, że nic tak nie procentuje, jak ciężka praca u podstaw, a potem wykorzystanie tej wiedzy przy pracy w wygodnych narzędziach. Jedno jest pewne, możesz przez lata pracować w 3d nie wiedząc czym różni się punkt od werteksu, choć moim zdaniem to jednak obciach. Good luck and good night. Skk. Ps przykłady efektów, które wymagają skryptowania? No, nie wiem, wszystko zależy od środowiska, w którym pracujesz… a co robisz, kiedy cię proszą o przygotowanie kilku wersji tego samego efektu z małymi wariantami (gęstość dymu), siedzisz po nocy i generujesz jeden za drugim? Nie mówiąc już o tym, że wiele funkcjonalności niektórych środowisk jest dostępna tylko via skrypt, vide Real Flow, Maya Particles* czy Houdini VEX. *) pierwszy komercyjnie dostępny system cząsteczkowy na ziemi, prawdziwa matka wszystkich systemów, a nie jakiś crap Thinking Particles, o połowę młodsza zrzynka z POPów Houdiniego! ;) Ps2 dlaczego kompozycja jest ważna? Bo pomaga zrozumieć istotę tej roboty, tj. odtworzenie kawałka świata i wiarygodne umieszczenie go w pewnej całości; bo umożliwia komunikację z kolegami, którzy będą te wypociny składać i męczyć się maskując twoje błędy; bo zaczynając swoją przygodę długo sam będziesz składał sceny testowe - żeby wymienić kilka powodów z brzegu.

Maya/Houdini a Max/pluginy to dwie alternatywne ścieżki rozwoju. Trochę jak prman i raytracery. Można używać obu środowisk, ale najczęściej ludzie wybierają jedno albo drugie, bo mało realne jest być specjalistą we wszystkim (ale wszystko wypadałoby mieć przynajmniej liźnięte). ...i nie, nie ma dobrej odpowiedzi na pytanie, która droga jest lepsza, bo żadna po prostu nie jest lepsza. Wszystko zależy od dziesiątków czynników, od konstytucji psychofizycznej zawodnika, po szerokość geograficzną,w której chcemy się ostatecznie znaleźć. Anyway, jest więcej niż pewne, że umiejętność* co najmniej skryptowania bardzo pomaga w tym zawodzie, podobnie jak znajomość czegoś poza pluginami Maxa, jak RF, Maya czy Houdini. skk. ps to w ogóle jest skomplikowany, ale ciekawy temat. Jeśli tylko znajdę chwilę... ----------- *- osobiście twierdzę, że taka nieumiejętność po prostu dyskwalifikuje.

Uznajmy to za żart... Nie można radzić sobie w efektach nie znając się na kompozycji. Kto za ciebie będzie ogarniał, jak wyrenderowałeś dym, które obiekty będą matte, a które phantom, jakie passy wypluć, żeby kompozytor miał na czym pracować. Dobry człowiek od efeków to nie małpa od cząsteczek, ale niestety ktoś, kto ogarnia dużą część produkcji. Co mi po efekcie, który przygotujesz, a którego nikt nie będzie umiał wyrenderować. Kompozycja jest jedną z podstawowych umiejętności kogoś, kto zajmuje się fx.

Racja. To nie polskie akcenty, ale potop ;). Gratulacje!

Reasumując Gpu jest trudne w użyciu do niemal wszystkiego, co nie jest grafiką online, co nie powinno dziwić, skoro do tego zostało stworzone. Łatwo jest oczywiscie napisać, że swietnie się robi fluidy na Gpu, choć prawda jest taka, ze ich kod na cpu jest znacznie prostszy, ze połowa metod z agebry liniowej słabo się paralelizuje (np. faktoryzacja LU), albo wymaga stałego dostępu do ram i tak dalej. Gdyby Intel miał alternatywę, nikt nie zawracalby sobie głowy gpgpu. Fakt, ze do dzisiaj walcza o solver RBD na Gpu o czymś świadczy. Racja, zapędziłem się, a co wiecej w tym przypadku ma to znaczenie, bo jest świetnym przykładem na to, jak trzeba stawać na rzęsach, żeby zmusić Gpu do współpracy. Tak, chodziło mi o złozonosc (gratuluje, zdales test na człowieka). Oczywiście istnieją niższe rzędy złożoności, tyle ze zwykle uważa się, ze od liniowych w dół algorytm jest uzywalny. Upraszczajac oczywiście... (muszę to napisać, bo mam poważne obawy, ze rozmawiam z komputerem). Kończę. Pozdro, Skk.

Znów nie czytasz, co piszę, tylko się popisujesz.Owszem, drzewa binarne są dobre do renderingu albo SPH - co napisałem, więc nie musisz tego powtarzać - bo rdzenie mogą liczyć niezależnie od siebie. Natomiast propagacja sił w kolizji kilku obiektów nie może być tak liczona, trzeba je sprawdzać szeregowo, albo przynajmniej cholernie się napocić, żeby zsynchronizować wątki. A to jest tylko prosty przykład. Ergo, założenie, że jak maszyna jest dobra do liczenia wektorów, jest dobra do fizyki jest grubym uproszczeniem. Wystarczy zmienić specyfikację floata i wszystko zacznie działać inaczej. Właśnie to mam na myśli, kiedy mówię, że implementacja implementacji nie równa. proszę: $HFS/houdini/public/SIM_SolverODE Napisałem, że liczy się liniowa wydajność, nawet jeśli prędkość nie jest początkowo zawrotna. A ty na to... tłumaczysz dlaczego x*n jest lepsze od n^2. Hm? True. pozdro, skk.

Wątpię, aby obliczenia na wektorach były gwarantem przydatności obliczeń na GPGPU, to jest jednak uproszczenie*. Akademicka dyskusja. Nie zrozumiałem, co z czym porównujesz, scenę ODE/XSI z ODE/Houdini, DOPsy z ODE w H., czy dwie identyczne sceny ODE w H? Tylko ostatnia ewentualność ma prawo zachować ten sam w wynik w tych samych warunkach. O to właśnie chodzi, że ODE w dwóch aplikacjach zachowa się inaczej, bo jest zbyt wiele elementów, które mogą się różnić, mimo tego samego silnika. BTW kod solvera ODE dla Houdiniego jest otwarty. Możesz go sobie obejrzeć. Co ty robisz, żeby uzyskać taki efekt? Piszesz dokładnie to samo, co ja, ale zaczynasz zdanie od "wręcz przeciwnie" i dalej eksplikujesz to, z czego sam, najwyraźniej, zdaję sobie sprawę, skoro zwróciłem na to uwagę. True. Napisałem "wygląda na stabilny", bo widzę kilka softbodies odbijających się od sobie i od małych, wąskich RBD w czasie bliskim real time (a zatem bez jakiegoś wysokiego super samplingu). Napisałem również, że Bullet jako taki, nie podnieca mnie specjalnie, bo niestety wszystkie te cuda osiąga za pomocą poważnych uproszczeń, i to niestety widać nawet w najprostszych przykładach. Wieje plastikiem. pozdro., skk. * - Choćby taki kawałek kodu, jak rozwiązywania penetracji wielu obiektów zderzających się jednocześnie. Większość tego zadania trzeba po prostu wykonać szeregowo, albo stawać na rzęsach. Inaczej jest np. z SPH, gdzie można z powodzeniem założyć, że cząsteczki oddalone od sobie o 5 m, nie mają wpływu na siebie, itd itd.

Niczego nie mylę, tylko wiem o czym mówię. Skąd wiesz, jak wygląda implementacja ODE w Houdinim? Widziałeś kod? Gdybyś go widział, nie wypowiadałbyś z takim przekonaniem fałszywych sądów. Anyway, ODE jest w pełni zaimplementowane w H., podobnie jak w Xsi. Tyle, że w pierwszym można zrobić znacznie więcej za jego pomocą, niż w drugim. Tego dotyczył przykład. Nie schodźmy z tematu w jałowych przepychankach. Wiem coś innego, ze źródła. Jak by nie było, nie jest to ten sam silnik. Pytanie, czy to są wąsy. Zwracam uwagę, że jeden algorytm jest tak samo szybki lub wolny, bez względu na to, czy liczymy go na CPU czy GPU, czy liczy gęstą siatkę czy rzadką. Zmieniają się warunki testu, a nie algorytm. Porównujmy jabłka do jabłek. Prawdę mówiąc szybki algorytm ma liniową relację zadania do czasu. I tyle. Nawet nie musi być taki szybki... Tak, oczywiście, każdy silnik bywa niestabilny. Są też takie, które rzadko kiedy bywają stabilne. I tego dotyczyła uwaga.

Bzdura. Integracja, którą bagatelizujesz ma zasadnicze znaczenie dla efektów końcowych. Łatwo to zrozumieć per analogia, porównując na przykład pełny Syflex z Mai, z tym obecnym w XSI. Albo ODE w Houdinim i ODE w XSI. Warto też zauważyć, że studia, które wspominasz używają Bulleta jako framework, udoskonalając go o dziesiątki rzeczy - włączając w to tak zasadnicze rzeczy, jak własna detekcja kolizji (jak miało to miejsce w 2012 i DD), więc powoływanie się na nie w kontekście C4D czy powyższego pluginu nie ma wielkiego sensu. Nie ma wiele do liczenia, bo przyjęty w Bullecie model fizyczny jest prosty (gierkowy), a nie dlatego, że siatki są rzadkie. Gdyby Bullet miał bardziej kompletny fizycznie model ciał miękkich i te rzadkie siatki liczyłyby się długo. Inna sprawa, że ten uproszczony model jest najwyraźniej bardzo stabilny, co wiele mówi o jakości metod Bulleta, a czego nie zauważają ludzie kolejny raz oglądający kulki, gridy i boxy...

Rozumiem Cię, w xsi wszystko idzie zbyt łatwo ;). Bardzo jestem ciekaw, co wymodziłeś! pozdr., skk.

To literówka, miało być "przynajmniej"!

Na świecie co roku powstaje kilka nowych rendererów, a każdy robi to samo, co poprzedni. Stosując waszą logikę, wszystkie owe silniki są warte tyle samo... To jest Bullet, ale jakość jego implementacji ma zasadnicze znaczenie, bo od niej przede wszystkim zależy to, co da się z nim zrobić w danym programie. Ten plugin wygląda bardzo solidnie. To raz. Dwa, że demko jest banalne dla kogoś, kto nie zajmuje się fizyką. W istocie jest tam kilka trudnych efektów, które o ile działają stabilnie i szybko, są poważnym atutem. To tyle. Natomiast przyznaję, że sam Bullet nie rozgrzewa mojej wyobraźni... pozdro, skk.

Cześć, sorry za zwłokę, nie było mnie w okolicy. Tak, jak sądzę możesz smoothować wagi, ale nie za pomocą SmoothSOPa, bo ten, najwyraźniej, radzi sobie tylko z wektorami. Wagi są zapisane jako tablica floatów pCapt, pierwsza liczba to numer kości, druga to jej waga. Czyli (0.0, 0.002, 1.0, 0.03, 2.0, 0.99) to trzy wagi dla trzech kolejnych kości. Trochę tego nie widać, bo Detail View zamienia numery kości na ich nazwy. Najłatwiej jest użyć AttribTranserSOP, oba inputy z captureLayer i za pomocą radius, max samples i distance kontrolujesz wygładzanie Point Attrib pCapt. Musisz mieć także włączone transferowanie Detail Attrib, o czym Cię powiadomi warning. Gdybyś potrzebował więcej kontroli, trzeba by zapewne zrobić narzędzie, najpewniej w PythonSOP, które będzie wygładzać wagi, zapewne selektywnie, według innego atrybutu itd. Daj znać, gdybyś jeszcze potrzebował. pozdro, skk. ps czy mnie się wydaje, czy dodano właśnie podforum dla Houdiniego? Gratuluję i podziękowania dla kierownictwa ośrodka!

Obstawiam od początku do końca Maya+mr ;)

Może niekoniecznie w imieniu całego zespołu, bo nie wszystkich nawet poznałem, ale w imieniu HA, Kamila i swoim, dziękuję za miłe słowa. Przy projekcie pracowała grupa niezwykle zdolnych artystów, zarówno jeszcze w Semaforze, jak i potem w Humanie. Nie podejmę się teraz wszystkich wymieniać, bo lista jest długa. Myślę, że dla wszystkich nas wysłać ten film w świat jest wielką satysfakcją. Z mojej strony podziękowania i pozdrowienia dla całego studia HA i jego współpracowników za dzielną pracę nad filmem w nie zawsze komfortowych warunkach... Powinienem jeszcze wspomnieć, że film miał realne szanse powstać w 2021 roku - zrobiony przez samego reżysera (bo w to, że go kiedyś zrobi, choćby samemu, nie wątpił chyba nikt). Uchronił nas zapał nowych producentów, którzy w chwili, kiedy projekt był na skraju przepaści uwierzyli w film, a potem bujali się kilka miesięcy z problemami, o których nie wypada tutaj pisać. Nie był to łatwy strzał. Świteź ma bardzo dobre przyjęcie i nawet nie chodzi tu o szanse na nagrodę w konkursie (w którym zdarzają się również słabe, studenckie filmy!). Chodzi przede wszystkim o to, że film do ludzi przemawia, mimo swojej egzotyki, że miał kilka pokazów przy pełnej sali, że ludzie niezwiązani z animacją, telewizje z drugiego końca świata, lub innych kultur, przychodzą rozmawiać o filmie, wzruszeni obrazem i muzyką. Co ciekawe wielu nawet się nie domyśla, że film powstał w komputerze... powtarza się przekonanie, że jest to animacja klasyczna. Kamil dopiął swego, zrobił nie tylko film, ale dzieło. Warto było czekać. pozdrawiam! skk. ps dziś wieczorem gala, a ja w samolocie, nawet nie będę wiedział pierwszy :(

Axis swego czasu mocno wszedł w Houdiniego, ale raczej do fxów i ciężkich renderów (mieli kilka takich wojennych kawałków). To mi wygląda na renderer Modo (może poza postaciami?). Tak zgaduję, ale zawsze można zapytać. Trailer fajny, choć jakoś taki przewidywalny ;)

Ach, widziałem całość i z przyjemnością donoszę, że animacja rządzi. Bardzo udana stylistyka. Można by cały film tak poprowadzić. Gratuluję! skk.

Jak to jeden Olaf potrafi zepsuć dyskusje...

prasówka przy śniadaniu ;). Variety, max3d...

Zawsze czułem, Kreska, że nie pracujesz, tylko siedzisz i klikasz.

Problemem w scenie z helikopterem jest skala. To dlatego śmigłowiec razi, kiedy pojawia się nad drzewami. Linia lasu jest o dobre 100 metrów od kamery, ale śmigłowiec pokonuje je jakby to były 30 metrów (czyli 2 lub 3 jego długości). Poza tym jest ok (nie licząc realizmu maszyny, ale rozumiem nie o to chodziło).

Mówiąc wprost: branżowy brendzl bez wytrysku. Szkoda.

Podróbka rsl'a made in mental images. czyli meta-język programowania shaderów, rodzaj wzorców, które mogą generować kod wielu języków z jednego wspólnego źródła. W założeniu shader pisze się raz, a środowisko powinno wygenerować z tego kodu interesujący cię target: c++ dla menta, glsl dla OpenGL, albo rsl dla rendermana itd. W praktyce koncept jest tak popaprany, że lata lecą, kasa na marketing idzie, a meta jeszcze daleko.

To oczywiste, bo oba powstały do produkcji filmowych, a nie do wizualizacji. Co do reszty: 3delight jest niestety droższy (2400$ per host), jest znacznie bardziej skomplikowany w użyciu, bo jest po prostu rendermanem, czyli posiada wiele funkcji i api, które nie istnieją w arnoldzie. No i liczy rozmycie ruchu i głębię ostrości prawie zawsze szybciej (o ile mówimy o typowych dla niego scenach, a nie o w pełni trace'owanych powierzchniach bez akceleracji brickmapami). Co do instancji, nie robiłem dokładnych testów, ale 3delight posiada, podobnie jak arnold, możliwość współdzielenia geometrii między instancjami, więc nie powinno być wielkiej różnicy, choć prawdą jest, że mikro-poligony gorzej radzą sobie w tym temacie, bo nie mogą współdzielić mikro-poligonów między instancje.

Jest, jest, ale wobec mantry rewolucją nie jest, tak samo, jak wobec 3delighta. Być może dla tego drugiego o tyle, że proponuje znacznie prostszy pipeline, więc jak się komuś nie chce grzebać w ribach i rsl'u, arnold robi mu dobrze.