Flowbox FX - narzędzie do przetwarzania i kompozycji obrazów

[adek]

Flowbox FX to narzędzie do przetwarzania i kompozycji obrazów współtworzone przez jednego z naszych forumowych kolegów - Wojciecha Daniło. Zachęcam do przeczytania kilku informacji o tym projekcie.

 

Pełna treść: Flowbox FX - narzędzie do przetwarzania i kompozycji obrazów

[Mortom]

Fajnie by było zobaczyć jakiś filmik bo na razie trochę enigmatycznie na stronie :)

No ale jak alfa dopiero to się nie dziwie :)

 

Pozdr.

[danilo2]

Cześć :) Jestem jedną z osób, która poczyniła Flowboxa :) Jeżeli macie pytania, z ochotą na nie odpowiem :)

 

@Mortom: Bardzo dziękujemy za uwagę. Obecnie jesteśmy pochłonięci dopieszczaniem wersji alpha, ale w niedalekiej przyszłości zamierzamy zamieścić więcej informacji na stronie :)

 

pozdrawiam, Wojtek

[Kramon]

Czy to jest bardziej 2D czy bardizej 3D?

[deshu]

Ja sie z chęcią zgłąszam na testera.

Kontakt: [email protected]

Folio niekomercyjne: www.deshu.pl

 

Obecnie pracuje nad wizkami produktowymi, wnętrzami, i 2 animacjami "for fun"

Dajcie znaka na maila, jeśli chcecie na mnei to potestować (tak, szukam tańszej alternatywy dla Nuke:P )

[danilo2]

@Kramon: Flowbox FX jest skupiony na przetwarzaniu i kompozycji obrazu, a więc jest zdecydowanie bardziej 2D.

 

Nie zmienia to jednak faktu, że przetwarzanie grafiki 2D jest przykładową funkcjonalnością, jaką można zbudować na Flowboxie. Nic nie broni Ciebie przed stworzeniem bloczków przetwarzających obiekty 3D, dźwięk, czy obliczających symulacje :)

Jako pierwszy "use case" wybraliśmy właśnie grafikę 2D.

 

Mam nadzieję, że ogólna idea jest teraz jaśniejsza? :)

 

 

@deshu: Zapraszam Cię na naszą stronę internetową: www.flowbox.io - tam możesz zapisać się do wersji alpha :)

 

Btw - nie chcemy być tylko tańszą alternatywą Nuka - chcemy dostarczyć narzędzie, które pozwoli Tobie na szybszą pracę, którą będziesz mógł lepiej dostosować do swoich potrzeb.

Mówię tu zarówno o technicznych jak i nietechnicznych aspektach pracy. Dla przykładu - nasz kompilator analizuje przepływ stworzony przez Ciebie, optymalizuje go i kompiluje, przez co nawet bardzo duże sceny składające się z tysięcy nodów powinny działać szybko, niczym pisane w C++. Mówię tu również o automatycznym zrównoleglaniu przepływu pomiędzy istniejące CPU i GPU czy też możliwości rozszerzania samej platformy (o własne narzędzia) przy użyciu nodów - bez potrzeby pisania pluginów w C++ lub innym niskopoziomowym, podatnym na błędy języku.

Edytowane 12 Listopad 2013 przez danilo2

[manabanana]

cuda/opencl są wymagane, czy na samym cpu też można operować?

[deshu]

Brzmi to świetnie:) Dokałdnie tak pracuje w nuke. Zrobiłem sobie pare swoich gizmo, i właściwie już nie uzywam wbudowanych, defaultowych narzedzi.

 

 

Ok, wpisałem adres maila i odpaliłem rakiete, dzięki!

[danilo2]

@manabanana: Oczywiście na samym CPU też można pracować. Mamy obecnie wsparcie dla automatycznego rozpraszania na wiele CPU, ale nie wiem czy będzie to dostępne w Alphie. Jeżeli nie, to na pewno niedługo po jej wypuszczeniu :)

 

@deshu: Dzięki! Czekaj na powrót kosmonauty :D

[smiler]

A gdzie można się na te testy zapisać ? Ja z chęcią ;)

[Monio]

Mega szacun za ten flowbox. Ostatnio co raz bardziej siedzę w kreacji proceduralnej i jaram się wszelakimi nodalnymi systemami. :)

[Idlero]

Kocham wszelakie nody na pewno będę obserwował wasz projekt bardzo uważnie.

[danilo2]

@smiler: Na naszej stronie - jest podana na samym początku newsa :)

 

@Monio: Bardzo nas to cieszy :) Chyba właśnie dlatego cały nasz team zrezygnował z pracy zawodowej i zajął się tym projektem. Cieszy nas wizja platformy proceduralnej, która pozwala na przetwarzanie dowolnych danych (2D, 3D, dźwięku, symulacji etc) w bardzo wygodny i wydajny sposób. Rozumiem, że o takich systemach mówisz? :)

 

@Idlero: Dziękujemy :)

[legomir]

A co mi daje wasz język w porównaniu do ICE/VEX?

[Bilay]

Zgłoszenie wysłane :) Można jakoś przyrównać flowbox do clarisse? - mam na myśli pracę z instancjami zaimportowanych obiektów.

[Monio]

danilo2 - Właśnie takich. Mnie szczególnie interesuje proceduralne tworzenie leveli i całych światów w grach. Jak ktoś robi gry to wie że nie zawsze coś co wygląda dobrze na papierze przekłada się na dobrę grę. Dlatego nieliniowe tworzenie i edytowanie środowisk jest lepszym rozwiązaniem.

[Gość User190]

Chyba dobrze dla projektu, że poszło to w tą stronę. Kroczycie ścieżką utartą przez Nuke'a - tam były dokładnie takie same początki.

Edytowane 13 Listopad 2013 przez User190

[szawel]

linux osx win .. ? czy dystrybucja będzie na wszystkie platformy ?

"...zamkniętą wersję alfa..." czy to oznacza że zamierzacie sprzedawać wasz projekt jako produkt ?

[danilo2]

@Bilay: Odpiszę Ci jutro, bo dzisiaj zdążyłem odpisać tylko legomirowi (poniżej). Przepraszam :)

 

@Monio: Racja. Co ciekawe (i może Cię to zainteresuje) - nasz Flowbox pozwala Tobie na definiowanie bloczków przetwarzających dowolne dane - możesz na przykład stworzyć bloczki, które przetwarzają 3D albo tworzą proceduralne opisy tekstur. Co jeszcze ciekawsze - możesz takie bloczki wraz z naszym środowiskiem "obrandować" i dystrybuować jako Twoją platformę do proceduralnego tworzenia leveli do gier - pozwalając Twoim użytkownikom na wizualne ich tworzenie.

My właśnie w ten sposób tworzymy Flowboxa FX - to są bloczki pozwalajjące na przetwarzanie i kompozycję obrazu, bazujące na naszej platformie Flowbox. :)

 

@M@Ti: Dzięki :) Też się cieszymy!

 

@szawel: Flowbox będzie działał na wszystkich platformach - linuxie, macu i windowsie. "...zamkniętą wersję alfa..." oznacza, że nie wszystkie osoby, które się zapiszą zostaną przyjęte do grona alpha testerów - grono to zamierzamy powiększać aż do wydania produktu w wersji 1.0. Odpowiadając na pytanie poboczne - tak, nasze narzędzie będzie produktem komercyjnym.

 

@legomir: Hej :) W dużym skrócie: Luna (nasz język) posiada o wiele większe możliwości, daje Ci większą kontrolę, o wiele łatwiejszy sposób wyrażania myśli i często dużo większą szybkość niż VEX czy ICE.

 

A teraz, żeby wyjaśnić moje powyższe słowa, musimy zajrzeć pod maskę :)

 

Problemy istniejących systemów nodowych

1. Wraz ze wzrostem ilości node'ów, przepływ wykonywany jest coraz wolniej
   
2. Jesteśmy bardzo mocno ograniczeni możliwościami takich bloczków - często musimy głowić się i wykorzystywać pewne bloczki "naokoło", wykorzystując bloczki nieprzeznaczone do tego konkretnego zastosowania.
   
3. Nie jesteśmy w stanie w pełni wykorzystywać naszego hardware'u - z wielu CPU / GPU potrafią korzystać tylko te narzędzia, które zostały specjalnie do tego przygotowane - sam natomiast, tworząc przepływy bloczkowe, nie możesz oczekiwać tego, że będą one wykorzystywały CPU / GPU wydajnie.
   
4. Istniejące systemy nodowe skupione są na pewnym rodzaju danych - jeżeli chciałbyś dla przykładu komponować obrazy 2D w ICE, musiałbyś napisać odpowiednie bloczki w C++ albo poczekać aż Autodesk to zrobi (chyba że ICE ma już wsparcie dla 2D) - w każdym razie sam łatwo tego nie zrobisz.
   

 

Zarys działania istniejących systemów nodowych (np. ICE)

Postaram się pokazać Ci trochę głębsze spojrzenie na cały temat, ale będzie to wymagało nieco bardziej technicznego spojrzenia.

Luna (nasz język) nie posiada schedulera node'ów - mechanizmu spotykanego w większości bloczkowych rozwiązań, który opisuje w jaki sposób wykonują się nody. Taki sheduler najpierw każe wykonać pierwszy node, potem drugi, kolejny (etc) przesyłając pomiędzy nimi dane.

Podejście to sprawdza się przy niewielkiej ilości bloczków, ale przy większych scenach szybko pokazuje swoje wady. Dlatego też w praktycznie wszystkich rozwiązaniach dostępne są bloczki napisane w pewnych niskopoziomowych językach (jak C++), a oprogramowanie pozwala nam używać ich w celu opisu pewnych wysokopoziomowych operacji. To jest też powodem tego, że nie możemy np. w Houdinim "wejść do środka" nodu "blur" lub nodu opisującego symulacje rigid body.

To wszystko niesie za sobą wyżej wymienione konsekwencje - spowolnienie działania przy dużych networkach, często utrudnioną pracę, dalekie od optymalnego wykorzystanie mocy sprzętu (CPU, GPU).

 

 

A co z VEX?

Vex jest bardzo specyficznym rozwiązaniem, więc opiszę go osobno. W VEX'ie jesteś w stanie opisywać pewne ograniczone przepływy (np. w kontekscie SOP'ów możesz używać Vexa w VOP'ach tylko do przetwarzania atrybutów punktów bez kontekstu - czyli bez uwzględnienia sąsiadów tego punktu). Oczywiście pewne proste operacje można "fakować" używając node'ów do obsługi chmury punktów - ale w tym momencie staje się to wszystko ciężkie w użyciu, a sam ten opis jest już bardzo skomplikowany.

VEX'a nie możesz używać również do przetwarzania dowolnych danych - jak geometria, dźwięk, obraz 2D, symulacje - możesz używać go w ściśle okreslonych miejscach. To co zrobisz w Vexie zamieniane jest na coś C++ podobnego, a następnie kompilowane i uruchamiane. Vex może być uruchomiony na wątkach, bo jest dozwolony właśnie w takich kontekstach - jak np. przetwarzanie atrybutów każdego punktu geometrii.

Takie rozwiązanie co prawda pozwala na uzyskanie szybkiego kodu (często szybszego niż analogiczny działający na bloczkach ICE), ale możliwości wykorzystania VEX'a są (jak już wspomniałem) są bardzo ograniczone. Poza tym nie ma co liczyć na automatyczną równoległość na GPU / CPU czy dostęp do standardowych struktur programistycznych (skoro pytasz o VEXa to jesteś blisko programowania) - takich jak tablice, mapy czy choćby funkcje lub lambdy.

 

Kilka słów o nodach w Houdinim

Poza tym, że w niektórych miejscach możemy używać VEX'a - problem pozostaje ten sam - jeżeli stworzymy wiele node'ów, network działa coraz wolniej. Bloczki są bardzo ograniczone, a o automatycznej ich równoległości na CPU i GPU możemy tylko pomarzyć.

 

A więc co z tą Luną? (bloczkowym językiem Flowboxa)

Bardzo ważna dla nas jest łatwość pracy użytkownika. Nie chcemy aby kiedykolwiek czuł sie ograniczony przez nasze narzędzie albo by musiał szukać jakiś obejść, wynikających z ograniczeń bloczków - co ma miejsce w codziennej pracy takiego przykładowego Houdiniowca.

 

Sama Luna to ogromne przedsięwzięcie. Nasze nody kompilowane są przez nasz kompilator do szybkiego kodu maszynowego. Innymi słowy - nasze narzędzie analizuje w jaki sposób przepływają dane, optymalizuje przepływ, wyszukuje miejsc możliwych do zrównoleglenia na CPU i GPU i robi to wszystko przeźroczyście dla użytkownika.

W wyniku, dostajesz dostęp do standardowych narzędzi - znanych z innych softów, ale masz pewność, że nie ważne ile bloczków połączysz, z Twojego sprzętu zostanie wyciśnięte więcej mocy (i co ważniejsze - mamy tutaj duże pole do popisu i wyniki będą się poprawiały wraz z ulepszaniem naszego narzędzia, co nie jest łatwe a czasem nawet możliwe w rozwiązaniach takich ja Houdini, czy XSI).

 

Innymi ciekawymi cechami jest to, że możesz używając naszych node'ów opisywać programy wykonywalne - czyli takie "exeki", które możesz potem komuś dać i które nie wymagają Flowboxa do uruchomienia i działania.

Dla mnie natomiast najważniejszą cechą jest to, że ze względu na tą architekturę Luny, możliwe jest przetwarzananie 2D, 3D, dźwięku, analiza obrazu i tak na prawdę, sam możesz zdecydować jakie jeszcze dane będziesz przetwarzał w wizualny (lub tekstowy) sposób.

My obecnie koncentrujemy się nad działką 2D (czytaj kompozycją i przetwarzaniem obrazu)

 

Reasumując

Mam nadzieję, że odpowiedziałem Ci na pytanie, przedstawiając zarys tego jak to działa od środka. Jeżeli masz dalsze pytania, z chęcią na nie odpowiem. Każdemu, kto zastanawia się nad tym jak nasz projet działa pod maską i jakie korzyści niesie, polecam zapoznanie się z wątkiem na cgsociety. Opisałem tam również, czemu idea kompilowania node'ów do czegoś takiego jak C++ jest po prostu zła (jak to dla przykładu robi VEX) :) : http://forums.cgsociety.org/showthread.php?f=59&t=1132960&page=1&pp=15

 

Jeżeli macie dalsze pytania, z chęcią na nie odpowiem! :)

[legomir]

Okey co jeśli będę chciał napisać za pomocą kodu nowego nodu, bo układanie węzłów jest zbyt długie i nieczytelne?

 

Co do houdiniego to w wersji 12.5 doszło coś takiego:

http://www.sidefx.com/docs/houdini12.5/nodes/vop/neighbour

 

I czy na końcu nie wyjdzie z tego coś jak Fabric Engine/Houdini Engine/Bifrost?

[danilo2]

@legomir: Nasza Luna ma 2 równoważne reprezentacje - wizualną i tekstową - oznacza to, że możesz przełączyć się między kodem a językiem wizualnym w dowolnym momencie pracy (edytując kod - edytujesz nody, edytując nody, edytuje się kod). Jeżeli chcesz, możesz również nody pisać w C++ lub innych wspieranych językach, ale nigdy nie jest to wymagane.

 

Dzięki za info od Houdiniego - fajnie, że to dodali akurat tą konkretną możliwość, co nie zmienia wyglądu całej sprawy.

 

Fabric Engine - służy do tworzenia wydajnych aplikacji w Pythonie i JavaScripcie. Ich logiczny system nodów znowu podlega pod sheduler a ich język KL jest mega prymitywny. Celują w zupełnie inną działkę niż my.

 

Houdini Engine - to już prędzej. Natomiast Houdini (tak jak i Houdini Engine) bazuje na tym samym "silniku node'ów", który opisywałem powyżej. Poza wadami, które wymieniłem - Houdini celuje w przetwarzanie grafiki 3D i symulacje (2D też mają po drodze). Natomiast w każdej z tych działek - jeżeli chcesz zrobić coś bardziej zaawansowanego, szybko dochodzisz do ściany, ponieważ dostępne nody nie pozwalają Ci na nic więcej.

 

Bifrost - o nim dokładniej napisałem na cgsociety: http://forums.cgsociety.org/showpost.php?p=7695786&postcount=17

Z chęcią odpowiem na dalsze pytania na ten temat :)

 

Flowbox, tak jak i każdy produkt na świecie ma konkurencję - do tej konkurencji możemy zaliczyć każdy system nodowy przetwarzający dane. Mówię tu o Houdinim, Max MSP, ICE, Fabric Engine, XSI, TouchDesignerze, vvvv, etc - przykłady można mnożyć. Chcemy dostarczyć rozwiązanie, które będzie działalo lepiej, dawało większą swobodę i szybkość pracy, a przy okazji będzie o wiele bardziej otwarte, niż pozostałe.

Chcemy, abyś na naszych nodach był w stanie w prosty sposób stworzyć przepływy modyfikujące np. dźwięk, w momencie gdy my dźwięku nawet nie wspieramy :)

 

Czy udało mi się wytłumaczyć Tobie naszą ideę lepiej? :)

[SYmek]

Hej Wojtek! Gratuluję postępów!

 

Kilka słów a propos porównania z VEX i ICE. Takie porównanie jest kłopotliwe. Zarówno VEX jak i ICE powstały w bardzo konkretnym celu i kontekście aplikacji macierzystych, podczas gdy Luna wydaje się znacznie bardziej ogólnym konceptem. Trochę jakby porównywać otwieracz do konserw ze scyzorykiem... Ten scyzoryk zresztą zapowiada się rewelacyjnie.

 

Saying that...., Wojtek jest zaaferowany swoim błyskotliwym konceptem, co jest zresztą zupełnie zrozumiałe, ale warto pamiętać, że VEX już dawno nie jest procesorem SIMD dla punktów i może przetwarzać obrazy, dźwięk, voxele, prymitywy, a właściwie dowolne dane za pomocą CVEX'a, portu w Pythonie, procesora standalone i embedowalego interpretera. VEX staje się uniwersalnym procesorem danych. To bardziej architektura samego Houdiniego odróżnia go od Flowboxa, niż przetwarzanie danych w VEX.

 

To raz. Dwa, że SESI nie stoi w miejscu i podobnie jak chłopcy od Flowboxa, Biforsta, Fabric Engine i wielu innych, podąża z duchem czasu, kiedy niemal każdy projekt wymagający wydajności, opiera się na jakieś wersji auto optymalizacji/ runtime-paralelizacji, JIT, czy abstrakcji kodu od platformy sprzętowej

 

Tak dla przykładu: od wersji H13, VEX nie działa już na wirtualnej maszynie SIMD, co poważnie ograniczało jego możliwości, jest natomiast kompilowany w locie do kodu maszynowego i nic nie stoi na przeszkodzie, żeby wcześniej czy później wykonywał się także na GPU (będzie miał w tym względzie dokładnie te same problemy, co Luna - czyli na przykład, co zrobić z strukturami danych, które nie są GPU firendly, albo które trzeba odtworzyć na GPU w inny sposób). To nie operacje algebraiczne, ale operowanie na skomplikowanych strukturach jest prawdziwym wyzwaniem przetwarzania danych. Jeśli Lunie uda się połączyć unikatowość swojego środowiska z standardowymi bibliotekami (jak VDB), będzie to prawdziwa petarda :)

 

Ile się dziś dzieje w tych tematach łatwo zauważyć czytając choćby o V8 Google'a..., właściwie już dziś można go po prostu zaimplementować do Blendera i mieć swój VEX ;)

 

Anyways, Luna zapowiada się super!

skk.

[legomir]

Tak. Zresztą wielki dzięki dla Ciebie i SYmka za wyjaśnienie paru spraw. Życze powodzenia i chyba zgłoszę się do testów swoją drogą :)

[olaf]

Heej, brzmi to na tyle fajnie, ze chciałbym zobaczyc czy mogę sobie Waszymi procedurami wesprzeć swój workflow. Jest gdzieś dostępna dokumentacja języka, czy mam się zapisać na beto-alfe?

[danilo2]

@olaf: Zapraszam do zapisania się do Alphy :) Dokumentacje i podstawowe tutoriale mamy, ale udostępnimy je dopiero w Alphie.

 

@legomir: Nie ma za co - postaram się następnym razem więcej spać i dokładniej opisać rzeczy (jak celnie zauważył w niektórych przypadkach Szymon :) )

 

@Szymek:

Hej Wojtek! Gratuluję postępów!

Hej Szymku! Dziękujemy bardzo!

 

Porównanie Luny do scyzoryka w kontekscie VEX'a i ICE'a jest bardzo fajne! Muszę to zapamiętać :)

 

Saying that...., Wojtek jest zaaferowany swoim błyskotliwym konceptem, co jest zresztą zupełnie zrozumiałe, ale warto pamiętać, że VEX już dawno nie jest procesorem SIMD dla punktów i może przetwarzać obrazy, dźwięk, voxele, prymitywy, a właściwie dowolne dane za pomocą CVEX'a, portu w Pythonie, procesora standalone i embedowalego interpretera. VEX staje się uniwersalnym procesorem danych. To bardziej architektura samego Houdiniego odróżnia go od Flowboxa, niż przetwarzanie danych w VEX.

Masz Szymku absolutną rację! Moja wypowiedź powyżej była niekompletna i mogła wprowadzać w błąd. Wynika to trochę z faktu, że przez ostatnie dni bardzo mało sypiam ale postaram się takie tematy tłumaczyć dokładniej.

 

VEX jest typowym procesorem SIMD - ja wiem, że może przetwarzać dźwięk, obrazy, voxele etc. Dużym problemem z VEX'em natomiast jest to, że jest on językiem imperatywnym. Oznacza to (to tłumaczenie nie jest skierowane do Ciebie Szymku), że pisząc w Vexie piszemy krok po kroku instrukcje które mają być nałożone na dane. (To tak jak w C++, Javie, Pythonie, Rubym, JavaScripcie i wszystkich innych językach imperatywnych). Luna jest językiem funkcyjnym (podobnie jak Erlang, Haskell czy Scala) - oznacza to, że my piszemy co chcemy uzyskać, niekoniecznie w jaki sposób. Mimo, że podejścia wydają się podobne, w Lunie i Flowboxie nie występuje bardzo wiele problemów występujących w ICE lub Vexie. Mówię tu między innymi o "side effectsach" (czyli efektach ubocznych - termin informatyczny, nie mylić z producentem Houdiniego), globalnym stanie danych etc (można więcej poczytać tutaj: http://en.wikipedia.org/wiki/Functional_programming).

 

Co takie podejście niesie za sobą? Luna nie tylko jest doskonałym procesorem SIMD! Nie musimy zastanawiać się nawet jakie dane ktoś chce przetwarzać - możemy z łatwością wykrywać przepływy, które można zrównoleglić i jesteśmy w stanie dostarczyć wielu funkcjonalności, których nie będzie w stanie dostarczyć ani VEX ani ICE dopoki nie przepiszą wszystkiego od nowa - mówię tu zarówno o bardzo fajnym zarządzaniu pamięcią (mamy w wielu miejscach praktycnzie statyczny garbage collector - dane są niszczone dokładnie w miesjcu, w którym przestają być potrzebne, Luna jest językiem "lazy", co oznacza, że nie oblicza zbędnie danych - jeżeli każemy jej zblurować obrazek, a potem wyciąć tylko dolny lewy róg, to tylko ten róg zostanie zblurowany (oczywscie na GPU) etc).

 

Reasumując - stworzyliśmy nasze bloczki i tekstową wersję Luny bazując na bardzo mocnych przemyśleniach dotyczących architektury istniejących aplikacji i jak dla mnie największą siłą Luny jest to, że daje ona zupełnie nowe możliwości optymalizacji, niż jest to obecnie możliwe.

Nie wierzę, by Vex bez zmian architektonicznych mógł być "automatycznie" i w każdym przypadku tłumaczony na GPU, tak jak nie istnieje możliwość tłumaczenia C++, Pythona, Javy i innych języków imperatywnych. Oczywiście Side Effects będzie w to wkładał kase i dorabiał pewne ograniczone możliwości - np. dla każdego punktu geometrii, lub kazdego voxela, lub każdego pixela etc - ale w ogólności nie dostarczy takich rozwiązań jak Luna, dopóki nie napiszą tego od 0.

 

To raz. Dwa, że SESI nie stoi w miejscu i podobnie jak chłopcy od Flowboxa, Biforsta, Fabric Engine i wielu innych, podąża z duchem czasu, kiedy niemal każdy projekt wymagający wydajności, opiera się na jakieś wersji auto optymalizacji/ runtime-paralelizacji, JIT, czy abstrakcji kodu od platformy sprzętowej

Już Bifrost jest o wiele bliższy bardziej ogólnego rozwiązania, ale wciąż - ich idea robienia z bloczków jednego dużego grafu i jego kompilacji jest słaba - szczerze mówiąc jest to idea jaką Flowbox miał 1,5 roku temu - gdy rozmawialiśmy o Lunie z Tobą Szymku wtedy w Krakowie o ile dobrze pamiętam :)

 

Tak dla przykładu: od wersji H13, VEX nie działa już na wirtualnej maszynie SIMD, co poważnie ograniczało jego możliwości, jest natomiast kompilowany w locie do kodu maszynowego i nic nie stoi na przeszkodzie, żeby wcześniej czy później wykonywał się także na GPU (będzie miał w tym względzie dokładnie te same problemy, co Luna - czyli na przykład, co zrobić z strukturami danych, które nie są GPU firendly, albo które trzeba odtworzyć na GPU w inny sposób).

Racja, oni przeszli, jak się nie mylę, na LLVM'a i JIT. LLVM dostarcza im pewnych optymalizacji + dodatkowo możliwość wsparcia OpenCl'a w fancy way (jak opisałem powyżej). Nie zmienia to jednak faktu, że dopóki nie zmienią podejścia imperatywnego na funkcyjne (też opisane wyżej) będą mieli zupełnie inne problemy niż my.

 

Będą mieli problem choćby w zrównolegleniu kodu wywołującego funkcje (!) - analiza zależności między funkcjami jest niemożliwa (jeszcze nikomu się tego nie udało zrobić) - mówiąc prościej - nie jesteśmy w stanie np. w C++ przeanalizować czy wywołując funkcje nie zmienia ona pewnych globalnych danych w programie, które mogą wpływać na wyniki działania innych funkcji, a co za tym idzie nie wiemy czy tą część kodu da się zrównoleglić, bo nie wiemy jak powinna wyglądać komunikacja między wątkami na takiej przykładowej CUDA'ie.

 

Oczywiście mogą ograniczyć VEX'a i zrobić z niego prościutki imperatywny język z bardzo ograniczonym dostępem do pamięci i trochę poprawić sytuację na tym polu, ale w tym momencie nie ma co porównywać drewnianego scyzoryka do takiego samego, tylko z metalu :)

 

To nie operacje algebraiczne, ale operowanie na skomplikowanych strukturach jest prawdziwym wyzwaniem przetwarzania danych. Jeśli Lunie uda się połączyć unikatowość swojego środowiska z standardowymi bibliotekami (jak VDB), będzie to prawdziwa petarda :)

Bardzo mocno nad tym pracujemy! :)

 

Anyways, Luna zapowiada się super!

skk.

Dziękuję Szymku za ważne uwagi! :)

Edytowane 15 Listopad 2013 przez danilo2

[SYmek]

He, he jesteś w swoim żywiole. Tylko pozazdrościć... A teraz wytłumacz, dlaczego języki funkcyjne wymyślone 40 lat temu do dziś się nie przyjęły poza specjalizowanymi zastosowaniami, jak Erlang dla telekomunikacji ? :)

 

tak czy tak, sukcesów i pozdrawiam!

skk.

[deshu]

Otóż to:) Gdy nadchodzi rewolucja, i nie jest ukrywana, zawsze powstaje pytanie: dlaczego, skoro to takie oczywiste (dla specjalistów), nikt tego jeszcze nie zrobił?

 

Pytanko co do przykładu z blurem, który podałeś.

Wasza platforma, rozumie ciąg wydarzeń, jaki spotka dany obrazek.

Czyli jeżeli pod nodem zaczytującym obrazek po kolei podłączone są:

-> blur -> grain -> transform (powiedzmy flip w poziomie) -> crop

aplikacja zrozumie, że jeżeli zamieni kolejnośc nodów, to będzie duzo mniej obliczeń. Zatem zamienia to na:

-> crop -> blur -> grain -> transform

 

Tak mam rozumieć "analizowanie przepływu danych przez bloczki" ? :)

[olaf]

zapisalem sie do alfy i mam nadzieje, ze dokumentacja dla jezyka bedzie czytelna nawet dla noobow, bo narobiliscie mi smaka.

[Kramon]

Sprawa z blurem jest taka że jest totalnie inny efekt kiedy użyjesz blura i strzelisz cropa aniżeli Strzelisz cropa a potem blura.

[Monio]

Zależy od podejścia. W shopie tak jest ale to nie jest dogmat. Wystarczy że przy cropie zapamięta dodatkowo odpowiednią ilość pixeli (dokładnie-radius blura) i masz wynik identyczny.

[Kramon]

true true..

 

Kiedy testy pierwsze bo niemogę się doczekać.

[piotrek]

Nie mogę się doczekać tego fukcyjnego języka. W ogóle jest dzisiaj na rynku aplikacja (3D albo do kompozycji), która używa języka funkcyjnego? Tak, Python jest niby trochę funkcyjny, ale taki Houdini chyba nie wykorzystuje tego. A może wykorzystuje?

 

Podejrzewam, że też może was czekać ciężka batalia z przekonaniem środowiska do podejścia funkcyjnego. Dla kogoś, kto całe życie pisał i myślał imperatywnie może to na początku być problemem.

[deshu]

Wśród znajomych programistów obserwuje dużo większa zdolność i chęć do adaptacji do nowych środowisk, niż na przykład wśród grafików:)

[olaf]

bo programistą zostają pracowici, a grafikami leniwi ;)

[Kramon]

Wśród znajomych programistów obserwuje dużo większa zdolność i chęć do adaptacji do nowych środowisk, niż na przykład wśród grafików:)

 

ja się uczyłem osobiście HTML php, i dużo pawn. i Kodowanie to dużo trudniejsza sprawa niż grafika, w grafice w większości przypadków sprawdzają się ustalone metody zasady proste zrób i gotowe. Kodowanie jest bardziej trudne i jeśli coś można lepiej to chętnie po to sięgają. Przynajmniej ja mam tak po sobie.

 

Dlatego używam poczesci blendera bo mogę go dostosować dosłownie pod siebie, albo zmienić coś co mi się nie podoba.

 

houdini umnie od zawsze widnieje jako, must kiedyś jak będzie więcej czasu.

[danilo2]

@SYmek:

To jest bardzo dobre pytanie :) Pytasz typowo o język tekstowy, warto natomiast pamiętać, że reprezentacja graficzna rządzi się swoimi prawami i jak na razie nie znam żadnego rozwiązania, które pozwalałoby graficznie reprezentować przepływy funkcyjne.

Erlang ma zastosowanie w telekomunikacji przede wszystkim dlatego, że został opracowany właśnie do tego zastosowania (firma Ericsson). Jak chodzi o erlanga to obsługuje on świetnie wątki, ale wciąż jest to język uruchamiany na maszynie wirtualnej erlanga => nie nadaje się do wydajnych obliczeń (chyba, że kluczowe elementy napiszesz w C++).

Oczywiście istnieją języki funkcyjne, które nie działają na maszynach wirtualnych. Problem z nimi był i wciąż jest inny - ich składnia i sposób kodowania wydają się dziwne i nienaturalne.

 

Dołożyliśmy wszelkich starań aby Luna - zarówno tekstowa, jak i graficzna, nie miały tego problemu. Ale to już pozostawiamy do oceny w Alphie :)

 

 

@deshu, @Kramon, @Monio:

Działa to tak jak mówi Monio :) Jeżeli masz obrazek i go blurujesz, to tak na prawdę robisz konwolucję tego obrazka przez pewną macierz - mówiąc po polsku - mnożysz 2 macierze i sumujesz pewne elementy. A więc możemy łatwo powiedzieć, które pixele są potrzebne do produkcji innych pixeli. Znając tą informację i informacje z innych bloczków, można stwierdzić jakie elementy można pominąć.

Przykład - mamy nieskończoną tablicę liczb [1,2,3,4,5,6,7,8,..] i mamy bloczek, który dla każdego elementu zwraca wartość jego zsumowaną z kolejną wartością, czyli [1+2,2+3,3+4,4+5,5+6,..], czyli [3,5,7,9,11,..] - jeżeli teraz położysz bloczek "wypisz 5 pierwszych elementów", to z tej nieskończonej tablicy liczb zostanie pobranych 6 elementów - bez żadnego przestawiania operacji :) (tak, Luna wspiera nieskończone tablice i ogólnie nieskończone struktury danych :))

 

 

@olaf:

Cieszę się, pamiętaj jednak, że Alpha to nie jest finalny produkt i na pewno nie będzie nadawała się do zastosowań produkcyjnych, ani nie będzie miała funkcjonalności porównywalnych np. do Nuke :)

Edytowane 16 Listopad 2013 przez danilo2

[danilo2]

@Kramon: Testy za kilka tygodni :) Robimy co możemy :)

 

 

@piotrek: Bardzo mnie to cieszy. Python nie jest w żadnym wypadku funkcyjny - to, że reklamują go w taki sposób, że możesz w nim pisać funkcyjnie jak się postarasz, czyli masz funkcje będące obiektami pierwszego rzędu lub możesz używać mapowania funkcji na iterowalne obiekty, to jest to fajny feature, ale nie ma to za dużo wspólnego z pełną funkcyjnością :)

 

Co do batalii, to tak jak napisałem, bardzo dużo czasu poświęciliśmy na to, by Luna była prosta w użyciu, zrozumiała i szybka. Jak na razie ludzie, którzy korzystają z Luny i piszą w niej bibliotekę standardową, mówią że takiego języka jeszcze nie widzieli i nie jest on cięższy od Pythona - ale o tym porozmawiamy jak wyjdzie alpha :)

 

 

@deshu, @olaf: Jest mnóstwo leniwych programistów i mnóstwo leniwych grafików :)

 

 

@Kramon: Nie mogę się z Tobą zgodzić. Zależnie od zastosowania, można powiedzieć, że informatyka to też wykorzystanie kilku gotowych elementów, które należy połączyć i ... gotowe.

Jest to prawda w niektórych zastosowaniach i tak samo jest z grafiką. Gdyby jednak tak było, to programy nodowe (Nuke, Houdini, poniekąd Maya) nie miałyby sensu - wszyscy używaliby AE i 3ds maxa :)

[Kramon]

oj źle mnie zrozumiałeś :> Chodzi mi oto że kodowanie jest trudniejsze niż grafika. i z mojego doświadczenia, wygląda według mnie to tak że. Grafika ma utarte schematy postępowania. Po pewnym czasie mamy już gotowe presety gotowe studia. Wystarczy poskładać wszystko do kupy więc kolesiowi nie chce się uczyć totalnie nowej metody. skoro ma działającą dobrą. Kodowanie zakażdym razem jest podejściem jakby od zera więc nowa metoda jest w sumie tak jakby starą.

[Monio]

Jakie kodowanie i jaka grafika? Tysiące godzin nauki wymiataczy sculptu niby miałby być łatwiejsze od nauki kodowania np prostych stron? I też za każdym razem podchodzisz do formy od zera bo jak nie podchodzisz to przestajesz się rozwijać. Inna robota ale czy łatwiejsza czy trudniejsza to bym nie powiedział.

Edytowane 16 Listopad 2013 przez Monio

[deshu]

Cóż Kramon. Pamiętaj, że wielu grafików, nawet w pracach komercyjnych zawsze stara się osiągnąć coś ponad rzemiosło.

Po ponad 10 latach w 3d, nadal na dość niewielki procent sytuacji mam presety. I to nie z lenistwa, tylko z różnorodności zadań:)

 

Informatykiem nikt by mnie nie nazwał*, ale to i owo napisałem w ciągu ostatnich paru lat. I to wiem na pewno, że w informatyce zdecydowanie częściej, właściwie na okrągło wykorzystuje sie to, co już sie wcześniej napisało, lub ktoś inny napisał:P

Wyguglaj sobie choćby tak podstawowe koncepty jak enkapsulacja czy dziedziczenie. Przeciez cała algebra jest już wciśnięta w biblioteki, i nie ma sensu tego pisac od nowa. Ale co tam...

 

A tak poza tym, to chyba normalne że dla grafika, to właśnie grafika jest mniej problmatyczna, niż programowanie. Działa to z pewnością i w drugą strone, hehe.

 

 

*korekta:P

[Kramon]

no nie wiem w pawn byłyo od groma bibliotek i w cale to nie ułatwiało sprawy tak samo jak powiedzenie po prostu że w 3D masz już gotowe nody. z których robisz materiały... czy to oznacza że robienie materiałów jest proste. nie.

 

Co do studia i tak dalej. zależy co robisz i w jakim silniku robisz. Ja osobiście lubie właśnie cycles za to że jak mam już jakiś materiał preset to on działa po prostu, a nie tak jak jest w niektórych silnikach że wszystko musisz stroić pod konkretne oświetlenie.

 

Chodzi o sposób myślenia, no według mnie grafika jest zdecydowanie łatwiejsza. Zależy też odnośnie kodowania.

 

Przykładasz mega doświadczonego kolesia od sculptu do kolesia który zaczyna dopiero kodować -,- gdzie tu sens?

 

To tak jakby pisać że Maluch jadący 70km/h bez problemu wyprzedzi ferrari jadące 40km/h.

 

Prosta sprawa, Jeżeli kodowanie to taka zaiste banalna sprawa, to dlaczego jakoś tam mało userów houdiniego? przeco kodowanie proste.

[deshu]

Bo jest stosunkowo mało etatów na symulacje, partylke, i renderowanie w mantrze, w porównaniu do archwizu i productwizu?

Popyt -> podaż? Nieeee, to nie to.

[Kramon]

To chyba dobrze. A nie tak jak jest z wizkami, Miliard wizkowców i pan zdzisiu zrobi za 10zł :>

[deshu]

Nie rozumiem o czym mówisz. Ja nie oceniam rynku, tylko odpowiadam na twoje pytanie.

[Kramon]

Nie rozumiem o czym mówisz. Ja nie oceniam rynku, tylko odpowiadam na twoje pytanie.

 

pytanie? A kiedy je zadałem

[Monio]

pytanie? A kiedy je zadałem

to dlaczego jakoś tam mało userów houdiniego?

 

Nie zrozumiałeś mnie. Grafa potrafi być równie wymagająca i trudna jak programowanie. W obu dziedzinach ludzie mogą dojść do ściany której nie przeskoczą. Wszystko zależy od poziomu w jaki celujesz.

[Kramon]

Tak ale ogólnikowo Kodowanie jest bardziej indywidualne. Przynajmniej tym ja się zajmowałem nigdzie nie miałem kogoś kto już kiedyś coś podobnego napisał.

 

Grafika wystarczy spojrzeć na interiory jest prosty schemat oświetlenia To samo auta.. większość też ma już przygotowane studia kwestia ich tylko kwestia ustawienia. względem auta.

 

o to mi chodziło. Dlatego nie zajmuje się wizkami bo są dla mnie nudne.

[olaf]

ok, nie bede się udzielał w tej dyskusji o programistach i grafikach, bo czekam na alfe i tyle. Chciałem tylko sprostować. Miałem na myśli comfort zone. Łatwo zamknąć się w swoim comfort zone na 60lat w grafice. W programowaniu niezbyt.

[Kramon]

ok, nie bede się udzielał w tej dyskusji o programistach i grafikach, bo czekam na alfe i tyle. Chciałem tylko sprostować. Miałem na myśli comfort zone. Łatwo zamknąć się w swoim comfort zone na 60lat w grafice. W programowaniu niezbyt.

 

no właśnie o to mi chodziło.

[deshu]

(...)Łatwo zamknąć się w swoim comfort zone na 60lat w grafice. W programowaniu niezbyt.

Za 60 lat aktualne wizki też będą o dupe potłuc. Moze miałeś na myśli sztukę, Olaf - wtedy się zgodzę.