Flowbox na SIGGRAPH ASIA 2014

[adek]

W serwisie FXGuide pojawił się interesujący materiał wideo w którym Wojtek Daniło opowiada o programie Flowbox do kompozycji. Warto obejrzeć.

 

Pełna treść: Flowbox na SIGGRAPH ASIA 2014

[deshu]

Spoko. Czyli posłuchali potencjalnej klienteli i skupili sie na compo a nie na otwartym systemie do przetwarzania wszelkich danych.

[tmdag]

Spoko. Czyli posłuchali potencjalnej klienteli i skupili sie na compo a nie na otwartym systemie do przetwarzania wszelkich danych.

 

No tak, oni (FX Guide) patrza od strony VFX a od strony VFX to nie wprowadza ten soft niczego nadzwyczajnego. Compositing w VFX ma inne problemy do rozwiklania na dzien dzisiejszy. Nikomu w Compo nie potrzebne jest skryptowanie nodow na takim poziomie a podejscia GPU probowalo juz wielu. Nawet polskie Lightcraft, 10 lat temu zaczelo pisac wlasny system do compositingu pod GPU (mialo to miliony nazw, min "Zeus", nie wiem co z tym sie stalo czy sprzedali czy ukratrupili projekt?)

 

Mimo wszsytko gratuluje chlopakom sukcesow i wlasnym skromnym zdaniem proponowal bym ruszyc droga rozwijania jezyka skryptowego dla technicznych firm z jakimi teraz wspolpracuja. To wydaje sie byc najlepsze rozwiazanie dla nich oraz najbadziej dochodowe. Mam nadzieje, ze sie to rozwinie bardzo!

[Rotomonks]

Owszem niczego nadzwyczajnego nie wprowadza, dokładnie tak samo powstawał Nuke, tylko na bazie TCL-a. Jak wiadomo system nodowy to jest po prostu szczególna forma programowania funkcjonalnego — ma więc reprezentację skryptową — do dzisiaj tak jest w Nuku. I dokładnie tak samo na samym poczatku w Nuku można były skrypt i pisać i tworzyć wizualnie. Tyle że Nuke ma liczne ograniczenia, np. przesyła w streamie tylko piksele i metadane, więc pisanie np. własnych przekształceń przestrzennych jest ciężkie. I ja tu widzę ogromne niewykorzystane pole, a w zasadzie ślepą uliczkę Nuke'a. Druga sprawa, to fakt, że dojrzałe softy nodowe takie jak Houdini czy Nuke, nie były projektowane z myślą o przetwarzaniu równoległym, a Flowbox jest i tu może mieć wkrótce sporą przewagę. Trochę rażą buńczuczne zapowiedzi, ale ja kibicuję zespołowi Flowboxa. W porównaniu z tymi wszystkim spinoffami Nuke'a typu Natron, to jest jednak coś świeższego.

[danilo2]

Hej ho! :)

Ja tu tylko chciałbym zaznaczyć jedną rzecz - Luna (nasz język programowania) nie jest językiem skryptowym - to jest jedna z ważniejszych różnic. My kompilujemy Lunę do kodu maszynowego działającego z prędkością porównywalną do kodu pisanego w C++. Dzięki temu nasze nody mogą być tak otwarte bez strat wydajności :)

 

tmdag - dziękujemy :) Albercie, to co mówisz o samym języku jest bardzo ciekawe. Też o tym myślimy od pewnego czasu. Z chęcią porozmawiałbym z Tobą (jeżeli będziesz chciał) więcej na ten temat :)

 

Rotomonks - dziękujemy za kibicowanie! Robimy wszystko by było dokładnie tak jak piszesz (może poza "buńczucznymi zapowiedziami" :) )

 

Korzystając z okazji - wesołych Świąt! :)

[Rotomonks]

Hej Wojtek,

gratuluję hype'u. :)

 

Właściwie co rozumiesz przez język skryptowy? To już od dłuższego czasu nie jest obelga :) Obecne projekty z LLVM i JIT-ami w tle skutecznie zacierają tę różnicę. Nawet JavaScript już nie jest językiem skryptowym :)

Chętnie dowiedziałbym się więcej o Lunie. Czy to jakieś nawiązanie do Lua? [oba w sumie oznaczają to samo, tylko jeden po portugalsku drugi po hiszpańsku :)]

No i pytanie, kiedy będzie można potestować flowbox? :)

 

Pozdrawiam i również życzę wesołych świąt

[danilo2]

Rotomonks - dziękujemy! :) (dziękując zazwyczaj mówię per "my", ponieważ to zasługa całego teamu)

 

Ja wiem że język skryptowy dla wielu osób nie jest już obelgą - dla mnie jest. I może zabrzmię tu okrutnie, ale JavaScript nie zasługuje nawet na miano języka :) Już tłumaczę - i nie chodzi mi tu tylko o wydajność.

 

Jasne że języki "interpretowane" doczekały się swoich JIT kompilatorów i optymizatorów, przez co ich wydajność wzrosła, choć nie jest i nigdy nie będzie zbliżona do np. takiego kodu pisanego w C++. Możemy optymalizować programy analizując dane pojawiające się w czasie ich wykonania (JIT-optymizery), ale wciąż optymizacje te bazują na o wiele mniejszej ilości danych dostarczonych kompilatorowi niż w sytuacji gdy język sam o to zadba. I tu dochodzimy do drugiego punktu - czyli system typów. Języki takie jak Python czy Ruby nie dostarczają użytkownikowi mechanizmów kontroli typów. Z drugiej strony C++ czy przegadana Java robią to za mocno i w rezultacie przyjemniej pisze się w Pythonie, ale gdy aplikacja rośnie, to ilość błędów i czasu potrzebnego na debugowanie / pisanie testów (które dodatkowo skutecznie utrudniają refaktoryzację takich tworów jak języki dynamicznie typowane) gwałtownie rośnie.

 

Luna jest językiem statycznie typowanym z pełnym type inferencerem, którego reprezentacja tekstowa jest podobna do Pythona / Rubego. Oznacza to, że każde wyrażenie, każdą funkcję możemy otypować explicite, a jesli tego nie zrobimy, nasz kompilator zrobi to za nas. Dzięki temu mamy język który jest bezpieczny, statycznie typowany i bardzo mocno optymalizowany (też korzystamy z LLVM'a!).

W rezultacie (co przekłada się również na postać wizualną) - Luna pozwala na pisanie wydajnych programów, których poprawność sprawdzana jest w czasie kompilacji. Ponadto nasz kompilator pomaga w pisaniu takich programów (np. podświetlają się te porty nodów do których jest sens podpiąć obecne dane).

Ciekawostką może być fakt, że Luna potrafi analizować przepływające dane, sprawdzać w których miejscach występuje komunikacja ze światem zewnętrznym, oraz automatycznie zrównoleglać operacje na wiele CPU i GPU!

 

A! I Luna nie ma nic wspólnego z Lu'ą poza trzema literkami :)

 

Dla osób które lubią techniczne słówka, Luna jest czysto funkcyjnym, obiektowym*, leniwym, szczerym, statycznie typowanym, generalnego przeznaczenia językiem programowania z pełną inferencją typów. *-w Lunie występują obiekty, ale ich stan jest niemutowalny (nie oznacza to, że nie można zmieniać ich wartości).

 

Przepraszam za lekko techniczne zabarwienie tej wypowiedzi, ale chciałem jakkolwiek uzasadnić to co mówię :) Mam nadzieję że odpowiedziałem na pytanie, w razie pojawienia się kolejnych, z chęcią odpowiem! :)

[tmdag]

tmdag - dziękujemy :) Albercie, to co mówisz o samym języku jest bardzo ciekawe. Też o tym myślimy od pewnego czasu. Z chęcią porozmawiałbym z Tobą (jeżeli będziesz chciał) więcej na ten temat :)

 

Porozmawiac moge zawsze ale nie wiem czy jestem w stanie wprowadzic cokolwiek kontruktywnegow stostunku do waszego jezyka ;]

 

pozdro!

[deshu]

Dla osób które lubią techniczne słówka, Luna jest czysto funkcyjnym, obiektowym*, leniwym, szczerym, statycznie typowanym, generalnego przeznaczenia językiem programowania z pełną inferencją typów. *-w Lunie występują obiekty, ale ich stan jest niemutowalny (nie oznacza to, że nie można zmieniać ich wartości).

 

1. Co znaczy statycznie typowanym? Tzn w jakim sensie typy są statyczne?

2. Skoro luna jest obiektowa, to rozumiem że dziedziczenie będzie grane?:)

[Rotomonks]

@danilo2

Brzmi trochę jak Haskell? Czyli nieźle. :)

JavaScriptu nie bronię i generalnie trzymam się z daleka, ale zobaczysz, Waszą konkurencją w przyszłości będzie webowy soft do kompozycji zrobiony emscriptenem albo na V8. :)

 

Widziałem na stronie też zapowiedź ryneczku dla nodów. To świetny pomysł, pod warunkiem, że zadbacie o możliwość opcjonalnego zamknięcia produktu w binarce, tak żeby kod nie był jawny. Porównanie monetyzacji na Nukepedii i AEScripts mówi samo za siebie.

 

Nie odpowiedziałeś też na najważniejsze pytanie: kiedy i gdzie będzie można ściągnąć soft do testów :) Zrób nam prezent! :)

 

Pozdrawiam

[Monio]

To jest świetne. Życze wam wytrwałości bo tylko tego wam trzeba żeby zacząć zarabiać miliony. :) Tylko się nie sprzedajcie nikomu za wcześnie, to nie gry video. Z dobrą strategią (a widzę że na nią macie pomysł) rozjedziecie konkurencje.

Jestem bardzo ciekaw jak rozwiążecie dodawanie przez userów contentu do waszego marketu. Nody będą tylko zamknięte czy będzie się dało kupić otwarte setupy? Jeśli to drugie to czy przewidujecie jakieś zabezpieczenia przed sprzedawaniem cudzych otwartych setupów? Ostatnio sporo nad tym myślałem w kwesti mojego projektu (eta 20 lat ;)), sprawa jest nietrywialna ale mam parę pomysłów jak to ogarnąć.

[Azbesty]

Nie odpowiedziałeś też na najważniejsze pytanie: kiedy i gdzie będzie można ściągnąć soft do testów :) Zrób nam prezent! :)

 

 

z przed rozmów mailami z rok temu, jeśli dobrze pamiętam to.. indywidualnie jest udostępniane.

[olaf]

JavaScriptu nie bronię i generalnie trzymam się z daleka, ale zobaczysz, Waszą konkurencją w przyszłości będzie webowy soft do kompozycji zrobiony emscriptenem albo na V8. :)

Dodając wsparcie chmury obliczeniowej, to jesteśmy bliżej niż dalej ;)

 

Serdecznie gratuluje i życzę sukcesów. Inne firmy prezentowane w filmie też są bardzo pozytywne.

[danilo2]

tmdag - Albercie, nie mówiłem stricte o języku, bardziej o Twoich pomysłach :) Odezwę się po Świętach :)

 

deshu - wyrażenie to oznacza, że kompilator naszego języka zna typy wszystkich wyrażeń podczas procesu kompilacji i ma gwarancje że typy te nie ulegną zmianie w czasie wykonania programu. Pozwala to na:

1) zwiększenie bezpieczeństwa danego programu - wiemy że nigdy w runtimie nie dostaniemy błędu związanego z nieoczekiwanymi typami / wartościami które nie posiadają pewnych pól lub nie poleci nigdy jakikolwiek "null-exception" (Luna nie ma wartości null)

2) Lepsze optymalizacje danych funkcji - skoro znamy typy oraz ich układ w pamięci podczas pisania programu, możemy cały plik wykonywalny lepiej zoptymalizować + (jak wyżej już pisałem) automatycznie zrównoleglać obliczenia

 

Więcej: http://pl.wikipedia.org/wiki/Typowanie_statyczne , http://en.wikipedia.org/wiki/Type_system#Static_type-checking

 

Dodatkowo - Luna nie wspiera i nigdy nie będzie wspierała dziedziczenia. Jest to decyzja świadoma i celowo tak zaprojektowaliśmy język. Tylko bez obaw tutaj :) W językach takich jak C++ lub np. Python nie możemy wyobrazić sobie pisania programów bez dziedziczenia - taki design języka, nie ma innych mechanizmów. Bez dziedziczenia musielibyśmy pisać strasznie dużo boilerplatu i wszystko byłoby słabo utrzymywalne. Luna jednak, tak jak więszkość nowoczesnych języków programowania (np. Google Go), nie wspiera dziedziczenia i dostarcza innych, bezpieczniejszych mechanizmów, które pozwalają na tworzenie w prosty sposób nawet bardzo złożonych struktur danych, które dodatkowo są dużo bezpieczniejsze (jak już wpsominałem - brak wartości null, brak potrzeby rzutowania wartości etc). Znów wchodząc w szczegóły - Luna wspiera pełne algebraiczne typy danych oraz type mixiny.

 

Rotomonks - Racja! Wybacz, przeoczyłem to najważniejsze pytanie. Tak jak mówi Azbesty - współpracujemy z niektórymi firmami + freelancerami i oni już testują Flowboxa. Dodatkowo chcemy wypuścić publiczną wersję beta gdzieś w okolicach marca / kwietnia (natomiast jeśli chcesz możemy odłożyć to do kolejnego grudnia by był prezentem na Boże Narodzenie! :D)

Ryneczek dla nodów jest zintegrowany w aplikacji - możesz kliknąć na zakładkę toolset i po prostu zainstalować to co chcesz. Jest możliwość uploadowania zarówno zamkniętych, jak i otwartych narzędzi :)

 

Dodatkowo - co do V8 i takich tam - czuję że niedługo JavaScript stanie się asemblerem przeglądarkowym i (mam nadzieję) nikt ne będzie pisał bezpośrednio w niej dużych aplikacji. Prawdziwy software wymaga lepszego (bezpieczniejszego) języka - co nie zmiania faktu,*że JS (lub ASMJS) jest idealnym wieloplatformowym asemblerkiem :) Hmm, nie wiem czy wpsominałem, ale Luna jest językiem wieloplatformowym, w takim sensie, że możliwa jest jej kompilacja nie tylko do kodu maszynowego ale również innych platform - obecnie pracujemy własnie nad JS, ale w przyszlosci powinno pojawic sie wsparcie dla Pythona, C++ i Javy. Oznacza to że w Lunie bedzie mozna złożyc z bloczków (lub napisac w kodzie) komponent dla systemu pisanego w innym języku + mamy już testy działającej Luny w przeglądarce :)

 

Monio - dziekujemy bardzo za miłe słowa! :) Zrobimy co w naszej mocy by nie zabić tego produktu - nie po to poświęcamy już kilka lat z naszego życia :) Co do nodów - można je udostepniać / sprzedawać - jako narzędzia otwarte lub zamknięte. Co do zabezpieczeń otwartych nodów - przyznam się że nie myślałem o tym jeszcze - i tak, jest to bardzo ciężki temat. Bardzo chętnie porozmawiam z Tobą o tym - wyślesz mi proszę na pw swój adres mailowy ? :)

 

olaf - dziękujemy bardzo! :)

[Rotomonks]

Co do dziedziczenia... hats off, nareszcie ktoś, kto nie dobiera gwoździ do jedynego słusznego młotka OOP. Super.